개발 방법론

ONE = 1 이라는 예시를 보고 '내가 만약 그런 코드를 마주했다면' 을 가정하고 생각 해봤습니다. 1. 이 코드를 작성한 사람이 표현력이 부족하더라도 상수화를 통해 무엇인가를 표현하려 했다. 2. 미래의 독자를 염두에 두고 코드를 작성하려는 사람일 수 있겠다. 3. 애플리케이션 전반에 걸쳐 코드 스타일을 일관성 있게 유지하려 노력한다. 4. 용어는 모르더라도 '매직 넘버' 가 무엇인지 개념적으로 알고 있다. 물론 각각의 생각에 부정적인 꼬리가 달리기도 합니다. 1. 표현력이 부족하여 이 사람이 작성한 코드 문맥을 이해하는데 어려움이 있을 수 있겠다. 2. 오버 엔지니어링이 습관이 되어있을 수 있겠다. 3. 융통성이 없을 수 있겠다. 4. 경험은 있지만 이론적으로 정립이 되어있지 않아 작성한 코드마다 ..

잊지 않으려고 노력하는 말이 있습니다. 그 자체로 설명이 가능하다는 것을 뜻하는 'self-descriptive' 와 '코드 자체가 문서가 되게 하라' 는 말 입니다. 말 자체에 대한 이해는 어렵지 않게 할 수 있지만, 보통 현실은 이론과 다른 경우가 많아 실무에 적용하는 것을 또 다른 문제라고 생각 합니다. 항상 같은 텐션을 유지하기란 쉽지 않고, 변경 사항에 대해 동기화를 유지하는 것도 쉬운 일은 아니라고 생각 합니다. 지금까지 그래왔던걸 봐왔기 때문이기도 합니다. 다양한 이유로 의미 없이 남게 된 주석들과 사용하지 않는 코드들이 가득한 레거시가 되고, 이것들은 가독성을 해치고 더 나아가 단순히 읽어 내려가기 어려운 수준을 넘어 오개념을 심어주기도 합니다. 그래서 특히, 2장 '안 쓰는 코드' 에서 ..

소프트웨어 개발을 하다 보면 특정 방법론을 선택하는 경우가 보통이다. 최근 접한 익스트림 프로그래밍(extreme programming, 이하 XP)은 애자일 방법론의 한 갈래로, 빠르게 변하는 요구사항에 대응하면서 높은 품질의 소프트웨어를 개발하기 위한 접근 방법이다. 특정한 하나의 방법론이 소프트웨어 개발의 만능 열쇠가 될 수 없겠지만, 최근 XP 책을 읽으면서 '그래서 뭐가 XP이고, 무엇을 기준으로 하고 있다고 할 수 있는 거지?' 라는 생각이 맴돌기 시작했다. 부분은 이해 했지만 전체를 이해하지 못한 느낌이다. (물론 책을 다 읽기 전이다.)  의사소통과 협업.XP 의 핵심 중 하나는 원활한 의사소통과 협업이다. 프로젝트가 진행 되는 동안 동료와 끊임없는 대화가 이루어져야 한다. 단순히 정보를 ..