Page 11 -
P. 11

아주 작은 기능은 추가해도 나중에 리팩토링하기가 어렵지 않다. 아키텍
                  처가 감당할 수 없는 거대한 기능을 넣었다가 나중에 없애는 건 끔찍하게

                  어려운 일이다. 크기가 중요하다.




                    올바른 방법 도입하기


                    최악의 상황은 팀원들이 몇 달 혹은 몇 년 동안 아무 설계도 없이 기능을
                  추가하도록 내버려두다가 어느 날 문득 뭔가 잘못되었다는 걸 깨닫는 경우

                  다. 이런 상황이 닥치면 코드베이스 전체 뜯어고치기라는 끔찍하게 어려운
                  작업을 감당해야 한다. 새로운 기능을 추가할 때와 마찬가지로, 아예 새로

                  작성하지 않는 이상 뚝딱 할 수 있는 일이 아니다.
                    이제라도 올바르게 일하고 싶은가? 그러려면 올바른 방법을 도입하는 수

                  밖에 없다. 그 말인즉 간단한 절차를 차례로 밟아가며 설계를 조금씩 고쳐

                  야 한다는 뜻이다. 그렇게 하려면 보통 몇 개월에서 몇 년을 수고해야 한
                  다. 아주 허튼 수고다. 프로젝트 초반에 설계했으면 될 일이니 말이다. 애

                  초에 미래를 생각했어야 한다.

                      엄격한 설계 없이 시작한 프로젝트가 계속 성장하면 결국 개발자의 능력을
                      벗어날 정도로 복잡해진다.


                    처음부터 모든 걸 포괄하는 거대한 설계를 완성해야 한다는 뜻은 아니다.
                  장래에 필요한 모든 것을 예측하고 적용해야 한다는 의미도 아니다. 프로젝

                  트를 시작할 초기 단계부터 이 책과 『Code Simplicity』에서 논의한 소프트
                  웨어 설계 원칙을 적용해야 한다는 뜻이다. 그래서 이해할 수 있고 유지 보

                  수도 가능한, 단순한 시스템을 만들어야 한다는 뜻이다.








                                                             9장  설계는 프로젝트 초반에 하라  041




     심플소프트웨어_06.indd   41                                                 2019-10-18   오전 10:33:59
   6   7   8   9   10   11   12   13   14   15   16