유연한 코드를 짜고싶습니다

kws4679의 이미지

이미 만들어져있는 시스템에서 추가적인 부분을 만들고있습니다

나름대로 원칙을 살려서 작은 부분으로 나누고 중복은 피하고

이렇게 만들고 있는데 정말 좌절스러운것은

중간중간에 고객의 요구사항이 변할시(원래 이렇게 잘 변하나요..?)

시스템을 변경하기가 생각보다 큰 스트레스라는 것입니다

특히 어떤시점에 어떤 데이터에 접근해야하는데 못한다던가

나름대로 확장을 고려하고 짜놓은 클래스, 메소드가

오히려 그런 생각때문에 억지로 만들어진 구조가 다시 발목을 잡고..

푸념글에 가깝지만 좋은 설계 좋은 코드를 짜는법과

짧은시간안에 원하는 성과를 얻을수있는 방법에 대해 어떻게 생각하시는지

조언듣고싶습니다...

semmal의 이미지

예측 불가능한 설계변경에 대응할 수 있는 방법은 없다고 생각합니다.

설계변경이 최대한 없도록 여러모로 노력하고(적당히 로비를 하든, 리스크에 대해서 겁을 주든, 애초부터 올바른 요구사항을 끌어내든),
만약 설계변경에 대해서 전혀 예측이 불가능 하다면(좀 더 정확히 말하면, 설계변경이 있으리라는 것을 예상하지만, 어떤 식으로 변할지 전혀 모르겠다면),
예쁘고 멋진 코드를 만들겠다는 강박관념을 버리는게 최선이라고 생각합니다.
어짜피 안되는 걸로 스트레스 받을 필요는 없습니다.

처음부터 너무 유연하게 짜려고 하면, 오버스펙이 될 가능성이 많고,
오버스펙 되면, 설계변경이 많이 이뤄지는 경우에 더 대응하기 어려운 경우도 있습니다.

그러니 차라리 목적에 충실하게 간결하게,
최대한 의존성이 안걸리게 작성해놓고,
나중에 의존성이 생기더라도 약하게 생길 수 있는 가능성 정도로 만족하는게 좋은 듯 합니다.

변경방향이 예측이 가능한데도 설계가 제대로 안된다면, 그냥 경험이 부족한 것일 뿐이 겠지요.
더 많은 경험을 쌓다보면 고객이 요구하는 것이 무엇이고, 대충이나마 어떻게 변경될지 짐작할 수 있게 되리라 생각합니다.

------------------------------
How many legs does a dog have?

용쟁호투의 이미지

정말 적절한 조언이십니다.

제가 처한 현실에 딱이네요...변경되지 않는 설계는없는것 같습니다.

제일 변화가 심한 경우는 고객이 "알아서 해주세요!"와

고객이 프로젝트 기간동안 학습을 하여 업그레이드 되면서 보는 눈(?)이 높아졌을때 인것 같습니다.

항.상.행.복.하.세.요

snowall의 이미지

아무것도 안 만들고 있다가 설계가 더이상 변하지 않을 것으로 생각되는 시점에 개발하는게 가능한 방법론일 것 같네요.

A를 만들다가 B를 만들라고 해서 뒤집어 엎고 B를 새로 만드는 거나 아무것도 안 만들다가 B를 새로 만드는 거나 같아 보이는...

프로그램이 어떻게 만들어지는지 잘 모르는 사람들한테는 요구사항 변경이 아주 쉽거든요.

그리고 짧은 시간 안에 원하는 성과를 내는 방법은, 아무래도 원하는 성과의 수준을 낮추거나 엄청난 내공을 쌓거나 하는 수밖에 없겠죠.

피할 수 있을때 즐겨라! http://melotopia.net/b

gurugio의 이미지

저도 비슷한 고민을 한 일이 있습니다.
제 생각에 우선은 변할수 있는 것과 변하지 않는 것을 분리하는 디자인이 필요하다고 생각합니다.
그 다음이 각 모듈을 잘 구분하는 것입니다.
저는 일하면서 이 원칙을 최대한 적용해서 효과를 좀 봤습니다.

디게 당연한 소리인데요. 뭐라 설명할 길이 없네요.

실용주의 프로그래머라는 책에 직교성, DRY 등으로 설명되어있는데요
예를 들어 UI가 자꾸 바뀐다면 UI를 그리는 프레임워크와 UI자체에 대한 와꾸?를 분리하는 것이지요.

당연한 거지요 뭐..별로 도움이 안되서 죄송합니다. :-(

xyhan의 이미지

전 프로그램의 크기가 일정이상 커지면...
메서드를 아주 잘게 잘게 짜릅니다...

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

익명 사용자의 이미지

1만줄 미만이면 대충 짜도 잘 굴러갑니다.
저같은 경우 코드가 그 이상 커지면서 코드 중복이 생기는 시점은
전체 코드가 2만줄 넘어가면서 파일 하나당 1천줄을 넘기게 되는 시점으로 대충 가늠하고 있습니다.