출퇴근 시간만을 이용하여 대략 열흘 정도 걸려 봤습니다. 내용이 그리 많지 않더군요. 책의 내용은 제목처럼 어떻게 하면 실용적인 프로그래머가 될수 있는지를 이야기해줍니다. 여러가지 항목에 대해 이야기 하고 있는데 그 중 강조하는 것은 DRY 원칙과 테스트입니다.

DRY 원칙 : "Don't Repeat Yourself"
DRY원칙은 한마디로 중복을 없애고 반복 작업을 하지 않는 것 입니다. 반복적으로 수행 해야하는 일은 모두 자동화하고, 만약 클래스 작성시 비슷한 코드가 중복되거나 같은 동작을 하는 클래스들이 있으면 서로 합치고 리팩토링을 합니다.

코드 조금, 테스트 조금
모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.
코딩을 하면서 테스트도 같이 합니다. 작업을 다 완료한 다음 테스트를 하는 것이 아니라 실제 제푸메 들어갈 테스트가 나오자마자 테스트를 합니다. 버그는 한 번만 잡도록 합니다. 버그를 찾아내면 그 버그를 발견하는 것이 마지막이어야 합니다. 해당 버그를 확인할 수 있게 자동화 테스트를 작성해두고 해당 계속 주시하여야 합니다.

위 사항은 프로그래머로서 기본적으로 갖추어야 할 소양이 아닌가 생각합니다. 이 외에도 다양한 항목에 대해서도 나와있습니다.
몇 가지 짚어 보자면...

깨진 창문을 내버려두지 말라
깨진 창문( 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 )을 고치지 않은채로 내버려 두지 말고, 발견하자 마자 고쳐야 합니다. 한 곳이 깨지기 시작하면 급속도로 코드 전체에 악영향을 미치게 됩니다. 당장 고칠 여력이 안되면 판자로 덮는 것 만이라도 하여 ( 주석처리하거나 더미 데이터로 대치 ) 더 이상의 손상을 예방 하도록 합니다.

깨진 창문 이론
오랜 기간 수리 하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 당국자들이 그 건물에 별관심이 없다는 느낌 말이다. 그래서 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서가 등장한다. 심각한 구조적 손상이 시작된다. 꽤 짧은 시간안에 소유주가 그걸 고치려는 의지를 넘어설 정도로 건물이 손상되고, 결국 버려진 느낌은 현실이 되어 버린다. - 실용주의 프로그래머 p34 ~ p35


관련 없는 것들 간에 서로 영향이 없도록 하라
직교적인 시스템을 설계/작성합니다. 한 곳이 변경 되더라도 다른 곳에 영향을 주어서는 안됩니다. 변화가 국소화 되기때문에발 시간과 테스트 시간이 줄어들고 리스크가 감소합니다. 이 는 OOP 원칙의 SRP( 단일 책임의 원칙 )에 해당하기도 합니다.

책을 읽으면서 과연 나는 얼마나 실용적인 프로그래밍을 하고 있었나 생각해봤습니다. 어느정도 실용주의를 따르고 있다고 생각해왔는데 아직은 많이 부족한 듯 싶더군요. 메타 프로그래밍이라든가 자동화에 관해서 좀더 배워봐야 겠습니다.


요즘 저의 바탕화면

+ Recent posts