실용주의 프로그래머

실용주의 프로그래머(20주년 기념판) 

데이비드 토머스•앤드류 헌트

유명한 책이라고 계속 들어온 몇몇 책이 있다. 이펙티브자바, 클린코드 그리고 실용주의 프로그래머, 이 중 실용주의 프로그래머가 정말 공통적으로 도움이 될만하다고 추천받아서 이를 간단히 정리 해보고자 한다. 처음 읽는 만큼 간단히 읽고 넘어가는 부분도 많고, 주관적인 의견이 들어간 정리일 수도 있는 정리이다 (그 앞에는 "개인적인 생각으로는"이 들어가게 적는다.)

1장 - 실용주의 철학

팀 협업에서 신뢰성, 책임감의 문제 

 - "좋은" 개발자란 결국 맡은 일을 다 하는 개발자가 아닐까

깨진 창문의 법칙은 개발에서도 적용된다.

 - 관리 되지 않은 티가 나는 대상에 대해서는 이후로도 그렇게 취급 받게 된다는 이 이론은 코드에도 적용되나 보다. 나쁜 코드를 봤을 때 바로 고치도록 하자. 당장 여건이 되지 않는다면 주석이나 dummy 데이터 등을 이용하여 잠시 덮어두는 것도 하나의 방법이 될 수 있다. 그렇다면 깨진 창문을 고치기 보다 우선 망가뜨리지 않는 것이 더 중요하다.

변화의 촉매가 되라

 - 돌멩이 수프 이야기를 예시로 들었다. 무언가를 시작하는 것은 굉장한 피로감을 요구하지만 일단 시작하고 나면 시너지 효과로 인해 진행에 속도가 붙을 것이다. 하지만 반대로 생각을 해보자, 잘못된 시작은 시너지 효과로 인해 나쁜쪽으로 가속이 붙는다. 즉 진행하며 항상 큰 그림도 생각해야 한다.

 - 도전해보기 -> 상황인식: 주변을 살펴보지 않은 채 주변을 상황을 맞춰보기 (사람은 몇명인지, 문은 몇개인지 등)

완벽보다 완성이 낫다

 - '적당히 괜찮은 소프트웨어' 여기서 적당하다는 것은 너절하거나 형편없는 코드를 의미하지 않는다. 사용자의 요구사항을 충족하고, 기본적인 성능이나 개인 정보 보호, 보안 기준등은 맞추되 자기 자신의 마음의 평화를 유지할 수준이라는 것을 의미한다.

 - 환상에 불과한 내일의 완벽한 소프트웨어보다는 오늘의 훌륭한 소프트웨어가 더 낫다. 즉 요구사항을 지켜라. 피드백을 통해 더 나은 해결책을 모사하자.

 * 기능 블로트(feature bloat)현상: 소프트웨어가 쓰이는 기능에 비해 훨씬 더 많은 기능을 가지고 있어서 버그나 보안 취약 위험성도 높은 것

전략적인 지식 투자를 하자

 - 개발에 관한 지식 자산은 기한이 정해진 자산이다. 가치를 지키기 위해서는 아래의 것들을 지키는 포트폴리오를 만들자 

 i) 주기적인 투자

 ii) 다각화 

 iii) 리스크 관리 

 iv) 싸게 사서 비싸게 팔기

 v) 검토 및 재조정

개인적인 생각으로는 다각화, 리스크관리, 싸게사서 비싸게 팔기는 비슷한 조언 같다. 즉 한가지 기술에만 매몰되지 말고, 여러 정보를 다양하게 배우고, 아직 각광 받지 못한 기술도 어느정도 알아두자라는 뜻, 검토 및 재조정은 반대로 사양된 또는 그렇게 여겨지는 기술도 지식을 어느정도 배워두면 좋을 수 있다는 뜻이다.

구체적 목표 제안은 아래와 같다.

 - 기술 서적을 읽어라

 - 기술 서적이 아닌 책도 읽어라 (결국 사람의 일)

 - 다른 환경에서 실험해보자 (OS, IDE 등)

 - 신문을 읽자 (개발 소식지)

 - 다른 기술을 가진 사람과의 대화 

비판적 사고

 - 왜냐고 다섯번까지 묻기

 - 요구사항에 대해 누구에게 이익이 되는가?

 - 언제 혹은 어디서 효과가 있을까?

 - 이것이 문제인 이유는 무엇인가?

소통해라 

 - 말하고 싶은 게 무언지 알라 (이는 쓰거나 읽을 때도 포함)

 - 때를 골라라 (때로는 '언제가 말하기에 적기인가'에 대해서 말하는 것도 좋다)

 - 스타일을 골라라 (청중을 고려해라)

 - 멋져 보여라 (내용에만 집중하지 말고, 전하는 방법과 출력물의 모양도 고려하자)

 - 청중을 참여시켜라 (개인적인 생각으로는 이건 상황에 따라 다르기에 너무 어려울듯 하다)

 - 경청하라 (다른 사람이 본인의 말을 경청해주길 원한다면 본인도 경청해라)

 - 응답하라 (질문이 들어온다면 적극적으로 대답하자)

 - 문서화 (문서화하자 어려울 것 없이 코드에 문서화할 수 있다.)