Archive for the ‘programming’ tag
(책) Code Craft
줄을 그어가면 볼만한 책이긴 한데 너무 책이 방만하다. -_-
읽기 쉽게 설명하려고 노력한 듯한데 그래서인지 너무 책이 두껍고(번역서 752페이지) 내용이 너무 만연체다. 번역에서 사용된 단어 선정도 눈에 거슬리는 게 있고.
그래도 내용만 두고 본다면 한번 쯤은 읽어두면 좋을 내용들이다.
바벨탑
작은 일들이 묵살되고, 잠재적인 에러가 무시되고, 결함이 잊혀지고, 프로그래머들이 일을 중복해서 하고, 인터페이스가 오용되고, 문제점이 처리되지 않고, 눈에 잘 띄지 않는 약간의 지연이 프로젝트 전체의 매머드급 지연으로 확대된다.
이상적인 프로그러머는 PRAT이고, THICK 하다.
- Politician - 외교적인 수완이 있어야 한다
- Relational - 다른 사람과 함께 능숙하게 일을 할 수 있어야 한다.
- Artistic - 세련된 솔류션을 설계할 줄 알고, 고 품질 구현의 미적 양상을 식별하는 안목을 가지고 있다
- Technical genius - 튼튼하고 견고한 코드를 작성한다.
- Team Player - 다른 사람과 함께 효과적으로 일을 하는 방법을 배운다.
- Honest and Humble - 자신의 능력을 현실적으로 평가한다.
- Improving constantly - 항상 새로운 기술을 배우기 위해 노력한다.
- Considerate - 자신이 무엇을 하고 있는 지 항상 생각하는 훈련을 한다.
- Keen - 열성적인 코더의 열정을 유지하려고 노력한다.
프로그래머는 사회적인 동물이다. 우리는 필요에 의해 사회적으로 살아가도록 강요된다.
팀워크의 원칙
- 코드의 공동 소유
- 다른 사람의 코드를 존중하라
- 코드 가이드 라인
- 성공을 정의하라
- 책임을 정의하라
- 탈진을 피하라 - 똑같은 일을 지쳐서 포기할 때까지 반복하도록 강요하지 말 것. 모든 사람에게 새로운 스킬을 배우고 개발할 기회를 줄 것
(펌) 코멘트 작성하는 방법
- 우리는 책임 있는 프로그래머로서 코멘트를 잘 달아야 할 의무가 있다.
- 코멘트가 필요없을 정도로 좋은 코드(스스로 문서화 하는)를 작성하라.
- 코드를 묘사하지 말고, 왜에 대해서 설명하는 코멘트를 작성하라.
- 과거에 무엇을 했는지 기록하지마라. 그것은 리비전 컨트롤 시스템이 알아서 할 것이다.
- 나쁜 코드는 문서화하지 말고 다시 작성하라.
- 명료하고 일관성있게 작성하라.
- 하나의 사실은 한 곳에만 작성하라.
- 코멘트는 과거가 아니라 현재 속에서 살아야 한다. 코드가 바뀌었다거나 예전에 뭐가 어땠었다는 기술은 하지 마라.
- 코드를 변경할 때 그 주변에 있는 코드도 모두 유지보수하라.
Agile 관련 책에서도 유사한 내용이 나오지만 코멘트는없으면 없을 수록 좋다. 코드만으로도 이해할수 있는 코드가 가장 좋기 때문이다.
그렇지 못하다면 위에서 처럼 코드와 똑같은 내용을 문장으로 적는 것이 아니라 알고르즘이나 코드의 존재 이유에 대해 적어야 한다. 불필요한 코멘트는 코드의 가독성만 떨어뜨린다.