2007/11/28 11:09 Developer
초기결정요소, 변화
초반에 결정을 해야하는 요소를 잡는 기준은 프로젝트 특성마다 다양합니다.
프로젝트 자체의 문제도 있지만, 사람도 문제입니다. 프로젝트 내에서 힘을 가진 사람중에서 "구현안되는 것은 없다"와 "변하지 못하는 것은 없다"라는 것을 실천하시는 분들이죠.
프로젝트마다 상황을 결정하거나 만들어 내기는 어렵습니다. 모든 것을 예상할 수는 없다는 이야기죠.
하지만, 결정의 확률을 높여갈 필요는 있습니다.
결정이 올바르게 할수록 후반부에서 변경에 대한 비용이 적게 드니까요. 변화에 대한 낭비를 최소화를 할수가 있습니다.
제가 생각하는 기본적인 컨셉은 여러가지가 있지만, 2가지 정도 생각을 해봅니다.
-. 자꾸 바뀌는 것과 잘 바뀌지 않는 것을 최대한 빨리 알아내야 합니다.
-. 한번 정하면 바꾸기 어려운 것과 정해도 바꾸기 쉬운 것을 알아내야 합니다.
모든 설계나 코딩시에 중요하게 생각해야 할 부분입니다. 변경이 잦은 것은 변경이 잦은 것끼리 모아두고 잘 안 변하는 것은 변하지 않은 것들끼리 모아둬야 합니다. 자주 변경이 가해지는 것은 손이 닿기 쉬운 곳에 위치를 하는 것이 좋습니다.
하나의 컨텍스트 및 기능을 보기 위해서 여러개의 깊은 패키지를 들추어내면서 확인을 하는 것만큼 시간낭비가 없습니다.
기획이 자주 바뀌는 부분은 시스템이 완료가 될때까지 자주 바뀔 가능성이 높습니다. 이 부분은 특별히 더 관리가 잘되어야 합니다. 변화가 잦은 부분이라 테스트 케이스는 반드시 필요하죠. 기획문서에도 자꾸 바뀌는 내용은 뒤쪽으로 인덱스를 두는 것이 좋습니다. 기획서에 배치 refactoring도 필요한거죠.
결정을 해서 구현을 한 다음 이슈가 발생시 고치기 쉬운 것을 처음부터 여러가지 이슈를 고려하면서 하는 것은 전부를 만족시키기 어렵습니다. 바꾸기 쉽다면, 일단 결정을 하고 넘어갑니다.
설계시에 문서만 죽어라하고 작성하시는 분들이 많은데, 대부분 쓰레기가 되기 쉽상입니다. 설계 자체를 검토하거나 점검을 할수 있는 시간을 가져야 합니다. 예광탄,프로토타입처럼 거창하지 않아도 됩니다. 실행이 되는 것을 눈으로 볼수 있는 설계를 통해서 예상하기 어려운 필요한 부분에 대한 테스트만 가능하게 만들어서 단위기능을 해보는 것이 좋습니다. 대부분 아키텍쳐 및 컴포넌트 개발이 이에 해당을 합니다.
자바지기 아저씨의 글에 있는 덧글중 남종환님이 남긴 내용 가슴이 아프네요.
http://javajigi.tistory.com/105
데이터베이스는 결정이 되면, 자주 바뀌지 않는 부분 중의 하나입니다. 하지만, 이처럼 변화하지 않은 것은 그 어디에도 없는거죠.
하지만, 기본적인 개념인 dependency가 적을 수록 이해가 쉽고, 변경이 쉽다는 것만 잘 지켰어도 조금이나마 마음이 편해지겠네요. DB dependency한 코드가 많다면, 아마 악몽이 되지 않을까요?
관련해서 김민재님이 참고할만한 서적 및 chapter를 추천해주셨네요. 고맙습니다.
http://px.tistory.com/808
프로젝트 자체의 문제도 있지만, 사람도 문제입니다. 프로젝트 내에서 힘을 가진 사람중에서 "구현안되는 것은 없다"와 "변하지 못하는 것은 없다"라는 것을 실천하시는 분들이죠.
프로젝트마다 상황을 결정하거나 만들어 내기는 어렵습니다. 모든 것을 예상할 수는 없다는 이야기죠.
하지만, 결정의 확률을 높여갈 필요는 있습니다.
결정이 올바르게 할수록 후반부에서 변경에 대한 비용이 적게 드니까요. 변화에 대한 낭비를 최소화를 할수가 있습니다.
제가 생각하는 기본적인 컨셉은 여러가지가 있지만, 2가지 정도 생각을 해봅니다.
-. 자꾸 바뀌는 것과 잘 바뀌지 않는 것을 최대한 빨리 알아내야 합니다.
-. 한번 정하면 바꾸기 어려운 것과 정해도 바꾸기 쉬운 것을 알아내야 합니다.
모든 설계나 코딩시에 중요하게 생각해야 할 부분입니다. 변경이 잦은 것은 변경이 잦은 것끼리 모아두고 잘 안 변하는 것은 변하지 않은 것들끼리 모아둬야 합니다. 자주 변경이 가해지는 것은 손이 닿기 쉬운 곳에 위치를 하는 것이 좋습니다.
하나의 컨텍스트 및 기능을 보기 위해서 여러개의 깊은 패키지를 들추어내면서 확인을 하는 것만큼 시간낭비가 없습니다.
기획이 자주 바뀌는 부분은 시스템이 완료가 될때까지 자주 바뀔 가능성이 높습니다. 이 부분은 특별히 더 관리가 잘되어야 합니다. 변화가 잦은 부분이라 테스트 케이스는 반드시 필요하죠. 기획문서에도 자꾸 바뀌는 내용은 뒤쪽으로 인덱스를 두는 것이 좋습니다. 기획서에 배치 refactoring도 필요한거죠.
결정을 해서 구현을 한 다음 이슈가 발생시 고치기 쉬운 것을 처음부터 여러가지 이슈를 고려하면서 하는 것은 전부를 만족시키기 어렵습니다. 바꾸기 쉽다면, 일단 결정을 하고 넘어갑니다.
설계시에 문서만 죽어라하고 작성하시는 분들이 많은데, 대부분 쓰레기가 되기 쉽상입니다. 설계 자체를 검토하거나 점검을 할수 있는 시간을 가져야 합니다. 예광탄,프로토타입처럼 거창하지 않아도 됩니다. 실행이 되는 것을 눈으로 볼수 있는 설계를 통해서 예상하기 어려운 필요한 부분에 대한 테스트만 가능하게 만들어서 단위기능을 해보는 것이 좋습니다. 대부분 아키텍쳐 및 컴포넌트 개발이 이에 해당을 합니다.
자바지기 아저씨의 글에 있는 덧글중 남종환님이 남긴 내용 가슴이 아프네요.
http://javajigi.tistory.com/105
개발이 완료된 시점에서 DB 변환><이 발생해버렸습니다
MySQL 에서 Oracle 로 전환해달라는 요청이 왔습니다
MySQL 에서 Oracle 로 전환해달라는 요청이 왔습니다
데이터베이스는 결정이 되면, 자주 바뀌지 않는 부분 중의 하나입니다. 하지만, 이처럼 변화하지 않은 것은 그 어디에도 없는거죠.
하지만, 기본적인 개념인 dependency가 적을 수록 이해가 쉽고, 변경이 쉽다는 것만 잘 지켰어도 조금이나마 마음이 편해지겠네요. DB dependency한 코드가 많다면, 아마 악몽이 되지 않을까요?
관련해서 김민재님이 참고할만한 서적 및 chapter를 추천해주셨네요. 고맙습니다.
http://px.tistory.com/808
