2008/05/06 09:53 Developer
dependency를 줄이자??!!
우리는 개선을 위한 변경이나 유지보수를 많이 한다.
그때마다 느끼는 것은 dependency가 많으면 이해하기도 어렵고, 코드에 손을 대기가 쉽지 않다.개선의 어려움에 보너스로 테스트도 어렵다.
우리는 이러한 문제들때문에 dependency를 줄이려는 노력을 많이 한다.물론 이 문제는 중요한 문제임에 틀림이 없다.
내가 하려는 이야기는 잘못된 dependency break를 얘기하려 한다.
개발자들은 깔끔한 상태를 좋아하고, 다른 개발자에게 간섭을 받기 싫어한다.
그래서, 커뮤니케이션을 통해서 코드를 개발하는 것을 그닥 즐기지 않는다.
여러 팀이 있을 경우는 상대방 팀에 대한 도메인 영역을 이해하기 어렵기때문에 별도로 분리(separate)하는 일이 종종 생긴다. 커뮤니케이션이 어려운 구조이기때문에 공통의 도메인을 구축하기보다는 별도의 도메인을 구축하는 것이 더 올바른 선택일 수도 있다. 이 경우는 대규모 프로젝트에에 다양하고 많은 팀들이 참여할 경우이다.
대부분 우리가 진행하는 팀단위의 작은 프로젝트들은 팀원간에 원활한 소통을 통해서 도메인 지식을 cohesive하게 만들 필요가 있다. 같은 도메인 영역인데, 기능이 다르다고 해서 많은 구현을 만드는 경우도 보게 된다. 같은 로컬을 바라보는 팀이라면, 잦은 소통을 통해서 구현을 줄이고, 인터페이스를 늘리는 것이 좋겠다.
도메인이 같은데, 도메인 영역이 dependency가 있는데, 코드상으로만 break하는 노력은 잘못된 선택일수도 있다는 것을 명심해야 한다.
대규모, 소규모 프로젝트는 같은 프로젝트라도 context에 따라서 달라질수가 있다. 자신이 하는 일이 어디에 해당하는지는 잘 생각을 해봐야 한다.
그때마다 느끼는 것은 dependency가 많으면 이해하기도 어렵고, 코드에 손을 대기가 쉽지 않다.개선의 어려움에 보너스로 테스트도 어렵다.
우리는 이러한 문제들때문에 dependency를 줄이려는 노력을 많이 한다.물론 이 문제는 중요한 문제임에 틀림이 없다.
내가 하려는 이야기는 잘못된 dependency break를 얘기하려 한다.
개발자들은 깔끔한 상태를 좋아하고, 다른 개발자에게 간섭을 받기 싫어한다.
그래서, 커뮤니케이션을 통해서 코드를 개발하는 것을 그닥 즐기지 않는다.
여러 팀이 있을 경우는 상대방 팀에 대한 도메인 영역을 이해하기 어렵기때문에 별도로 분리(separate)하는 일이 종종 생긴다. 커뮤니케이션이 어려운 구조이기때문에 공통의 도메인을 구축하기보다는 별도의 도메인을 구축하는 것이 더 올바른 선택일 수도 있다. 이 경우는 대규모 프로젝트에에 다양하고 많은 팀들이 참여할 경우이다.
대부분 우리가 진행하는 팀단위의 작은 프로젝트들은 팀원간에 원활한 소통을 통해서 도메인 지식을 cohesive하게 만들 필요가 있다. 같은 도메인 영역인데, 기능이 다르다고 해서 많은 구현을 만드는 경우도 보게 된다. 같은 로컬을 바라보는 팀이라면, 잦은 소통을 통해서 구현을 줄이고, 인터페이스를 늘리는 것이 좋겠다.
도메인이 같은데, 도메인 영역이 dependency가 있는데, 코드상으로만 break하는 노력은 잘못된 선택일수도 있다는 것을 명심해야 한다.
대규모, 소규모 프로젝트는 같은 프로젝트라도 context에 따라서 달라질수가 있다. 자신이 하는 일이 어디에 해당하는지는 잘 생각을 해봐야 한다.
