더 나은 프로그레머 되는법
개발자로서 기술스킬도 중요하지만, 더 좋은 개발자가 되기위한 지혜나 태도도 중요하다.
일반적인 개발자라서 알아야할 지혜와 덕목을 알려주는 책
1. 코드에 신경쓰기
좋은 코드를 만드려면 코드에 엄청난 노력을 들여야 한다.
좋은 코드를 만들어내기 위한 재료는 기술보다는 태도다.
의도가 명확하며, 다른 개발자도 이해할 수 있는 코드를 작성해야 한다.
2. 정돈된코드유지하기
보기좋은 코드는 코드 외관이 예뻐보인다는 것이 아니다. 코드의 의도를 파악하기 쉽다는 뜻이다.
예를 들면 예쁜 주석박스는 좋아보이지만, 쓸때없는 짓이다.
글을 쓰듯 코드를 작성하라. 일반글의 장, 문단, 문장처럼 코드를 구룹화하고 추상화를 맞추자(중요한 코드는 위에 적고 부수적인 코드는 아래에 배치).
팀 동료들과 동일한 코딩 스타일을 맞춰라.
반복은 코드패턴에만 있는게 아니다. 변수나 클래스명 작문에도 있다.
리팩토링시 수정 목적 (코딩스타일 변경인지 기능변경인지)을 명확히 하라.
3. 코드적게쓰기
코드 길이는 적을수록 좋다. 많은 코드량은 버그를 유발하며 상황을 복잡하게한다. 되도록 적은 코드로 기능을 완성하라.
개선의 가장 좋은 방법은 불필요한 코드를 제거하는 것이다.
코드가 많을수록 나중에 기능 변경이나 추가시 수정해야 하는 부분도 많아진다.
코드가 많다는건 버그를 품은 공간도 그만큼 많다는걸 의미한다.
코드를 구구절절 쓰지 말고 최대한 간결하게 작성하라.
리팩토링이란 결과 변경없이 구조를 바꾸는걸 의미한다. 결과의 변경이 있으면 개선이지 리팩토링이 아니다.
코드로만 의도가 잘 드러나지 않을 때에만 주석을 사용하라 (불필요한 주석을 구구절절 넣으면 오히려 코드가 헷갈린다).
죽은 코드를 갈아엎는걸 두려워 하지 마라.
믿을만한 라이브러리를 이용하면 코드가 더 적어진다.
코드 사이에 적절한 공백은, 가독성이 좋은 코드 구조가 된다.
4. 코드줄여개선하기
단순한 것이 더 아름답다.
기능이 당장 필요할 때까지 작성하지 마라.
기능 구현에 연관된 의미있는 코드만 작성하라.
재미로 필요없는 죽은 코드를 작성하지 마라.
죽은 코드는 개발자의 삶을 어렵게 만든다.
사용하지 않은 코드는 제거하라. 필요할때 버전관리 시스템에서 되살리면 된다.
5. 코드베이스의망령
자신이 작성한 코드만 유지보수할수는 없다. 우리는 대개 남이 오래전에 작성한 코드를 보고 비판한다.
하지만 진실은 자신이 작성한 코드도 한참 뒤에 보면 나쁜 습관들로 뒤덮여 있다.
코딩 스타일은 시간에 따라 변하는 것이고 그게 문제는 아니다. 더 큰 문제는 일관되지 않게 작성된 코드스타일이다.
해당 언어의 관례적인 코드를 알게되면, 부끄럽고 잘못된 코드 작성을 피할 수 있다.
프로그래밍의 세계도 발전하므로, 예전에 작성한 코드는 시간이 지남에 따라 신경써서 최신화 해줘야 한다.
예전에 작성한 코드를 자주 되돌아봐라.
6. 경로탐색하기
새로운 팀의 코드에 익숙해지기 위해서는 코드의 관례를 이해하고 코드의 부분별 기능을 파악해야 한다.
동료에게 도움을 청할때는 공손해야한다. '저 대신 이것좀 처리해 줄래요?'와 같은 태도는 좋은 대답을 들을 수 없다.
새로운 팀의 코드를 파악하려고 할때 막막하다면, 아래와 같은 주제를 중심으로 파악하면 도움이 된다. (소스 획득 용이성, 소스빌드용이성, 스스테스트용이성, 파일구조, 프로젝트의존성, 코드품질, 구조)
문서와 코드내용이 틀릴땐 코드를 믿어라.
코드를 배우는 가장 좋은 방법은 직접 수정해보는 것이다.
작은 버그나 큰 위험성이 없는 부분부터 수정해보는것도 도움이 된다.
거침없이 리팩토링해봐라, 프로그램에 대한 다이어그램을 작성해봐라
문서가 없다면 직접 문서를 작성해봐라
7. 똥통에서 뒹굴기
손대면 손댈수록 더 깊은 버그에 수렁으로 빠지는 똥통 코드를 다루는 방법.
똥통 코드라고 함부로 단정짓지 말아라.
자신이 작성한 코드라도 완벽하진 않다.
- 수렁 코드에 필요한 3가지 초기 판단.
- 꼭 고쳐야 하는가?
- 현재 문제를 해결하기위해 최소한의 수정만 해야할까? 전면적인 수정이 필요한가?
- 괴사부위를 도려내고 새로운 구현이 필요할까?
주어진 시간에 따라 판단하며, 시간이 없다면 최소한의 수정만 해라.
최소한의 수정이라도 보이스카웃 법칙을 잊지마라
코드 수정은 신중히 한번에 하나씩 수정해라.
수정 과정에서는 뭔가 잘못되더라도 수정을 되돌려면 된다. 되돌리더라도 실패가 아니다. 코드를 좀 더 잘 이해하기 위한 과정이었을 뿐이다.
코드에 비난을 퍼붓는건 도움이 안된다. 그 코드를 작성한 사람들도 일부로 그런건 아니다.
그냥 즐겨라. 똥덩어리 코드에서 새로운 신선함을 불어넣는 작업은 즐겁다.
8. 오류 무시하지 말기
별거아닌 오류라도 무시하면 걷잡을 수 없이 커진다.
오류를 확인하는 방법에는 반환값 부수적응답, 예외가 있다.
예외를 규칙없이 제멋대로 남용하면 문제가 생긴다.
예외를 이용해 오류를 숨기고 정상적으로 동작하는 것 처럼 위장하지 마라.
9. 예상하지 못한것을 예상하기
예외처리는 언어차원에서 추천되는 관습을 고려하여 예외처리를 해라.
라이브러리나 하드웨어와 같이 다른 외부적 요인으로부터 부수적으로 나타나는 오류는 예외처리 하는게 좋다.
프로그래머 에러 라고 불리우는 개발자의 실수로 인해 발생하는 버그나 잘못된 로직에서 비롯된 에러는 개발 단계에서 수정되어야 하며, 실행 중에 억지로 잡지 않고 그대로 크래시나 에러가 발생하게 놔두는 것이 좋다.(언어 프로세스 수준에서 에러를 뱉으므로서 명시적이 된다.)
보틍 프로그래머들은 시스템을 시작하고 생성하는것에는 많은 신경을 쓰지만 종료되고 멈추는 것에는 익숙하지 않다. 서로 의존하는 스레드 간에 작동을 멈추거나 제거하는 것은 어려운 일이며, 마땅히 신경써서 설계해야 한다.
10. 버그 사냥하기
누구나 아무리 뛰어난 개발자라도 버그를 피할수는 없다.
평범한 코드를 작성하라. 2배 영리한 코드는, 나중에 2배 더 열심히 디버깅해야 한다.
재현 가능성이 낮고 결함이 있는 코드가 코드베이스에 포함된지 오래될수록 디비겅하기 어렵다.
- 디버깅 전략
- 버그의 가능성을 추측하고 좁혀가기
- 두개의 문제를 한꺼번에 추작하지 말고 하나씩 추적하기
- 재현환경 좁히기
디버깅 로그를 포함해 배포하는 것도 좋은 전략이지만, 이런 부분이 많을수록 디버깅 노이즈가 생기므로 주의해야 한다.
코드베이스의 흐름에서, 이진탐색 기법으로 버그 포인트를 찾아내자
디버깅 고고학이란 버전관리시스템으로부터 버그 시점을 알아내어 고치는 것이다.
단위테스트는 디버깅에 도움이된다.
테스트코드는 코드의 농약같은 역할을 한다. 버그가 살수 없도록 한다.
디버깅 툴을 적극 활용하라
성능측정 툴이나, 브레이크 포인트 등을 활용하라.
원인이 될만한 산재된 코드를 지워가며 테스트 하면 도움이 된다.
깨진 유리창의 법칙 - 청결은 감염을 막는다.
일이 잘 안풀릴때는 잠깐 휴식을 하면 새로운 관전을 얻는데 도움이 된다.
- 재현이 잘 안되는 간헐적 버그에 대처하는 방법
- 실패를 유발하는 요소들을 관찰하여 기록하기
- 테스트를 자동화하여 버그 확인빈도를 높이기
때로는 디버거가 개입하면서 버그의 양상이 달라지는 경우도 있으므로 주의하여야 한다. (아이젠버그 관찰자효과) 네트워크 속도나 저장장치의 다양한 반응속도 때문에 문제가 생기는 경우도 있으므로 유의하자.
전역변수나 싱글톤은 려러 부분에서 접근하는 코드이기 때문에 버그 예측이 힘들 수 있으므로, 이런 변수들을 주의깊게 다루자.
11. 테스트하기
테스트와 코드리뷰 피드백을 간과하지 말라.
이런 테스트를 피드백 테스트라고 하는데 이 과정이 간소화 될수록 효과적이다.
QA테스트나 스테이지 테스트 등을 활용하면 좋고. 이런 테스트는 테스트풀이 필요하다. 엔드포인트 테스트를 추가하면 과정을 더 간소화, 자동화할수 있어서 비용이 절약된다.
코드베이스를 직접 테스트 하는것은, 코더 자신이 자신에 코드에 대한 테스트를 작성하는 것이 가장 좋다.
테스트의 종류에는 단위테스트 , 통합테스트, (시스템테스트)종단간 테스트가 있고.
E2E테스트는 종단간 테스트에 속한다.
테스트 코드의 작성이 늦어질수록 테스트 효과는 더 안좋아지게 된다.
테스트코드는 그 자체로 훌륭한 문서다.
버그가 발생하면 그 버그가 재발하지 않도록 테스트코드를 작성하라.
테스트를 지속적 통합 프로세서에 일부로 통합하라.
나쁜 케스트코드는 오히려, 유지보스에 방해가 되니 주의하라.
함수단위의 테스트는 무용지물일 수도 있다. 앱의 행위 중심으로 BDD테스트를 하는게 더 효과적이다.
테스트도 유지보수가 필요하다.
글로벌 변수나 싱글톤객체는 독립된 테스트를 쉽게 만들기 어렵도록 하는 저주와 같다.
더미는 테스트를 위한 빈데이터를 말하면, 스텁은 약속된 응답을 내뱉는 객체, 그리고 목은 역속된 응답과 동시에 검증까지 도와주는 객체를 말한다.
12. 복잡도 다루기
프로그램은 쉽게 복잡해지고 미로가 되고 만다.
프로그램의 복잡도와 관련된요소는 블롭과 라인이다.
블롭은 파일이나 파일의 프로그래밍 문자열 덩어리와 같은 컴포넌트 모듈을 말한다. 블롭이 클수록 복잡해진다.
사실 크기는 중요하지 않다, 큰 코드들을 어떻게 의미있고 짜임새있게 가독성 있게 구성할지가 관건이다.
우리의 뇌는 계층을 나누고 추상화하여 추론하는데 최적화되어있다.
라인은 - 컴포넌트와 객체인 블롭들을 서로 연결해주는 역할을 한다.
의존성이 너무 강하면 시스템이 경직되므로 느슨하게 설계해야 하며, 객체나 블롭간의 상호 양방향 참조를 피하고 블롭간의 계층을 명확히 하여 상위에서 하위로 단방향 흐름을 유지하는게 좋다.
13. 두개의 시스템에대한 이야기
소프트웨어를 도시에 비유할수 있다. 지저분한도시 vs 깨끗한도시
나쁜설계는 더 나쁜 설계로 이어진다. 나쁜설계 위에서 기능추가는 더욱 힘들어진다.
개발자간의 관계도 앱에 영향을 준다.
결합도가 낮고 응집도는 높아야 한다.
나쁜도시에서는 설계가 없기때문에 쓸대없는 복붙이 많다 나쁜도시에서는 설계가 없기 때문에 쓸대없는 복붙이 많다.
지저분한 도시는 새로운 기능이 기획될때마다 엄청난 두려움이 생긴다. 그리고 점점 개발이 느려진다.
깨끗이 디자인된 도시는 더러운 도시와 정반대다.
가끔 설계원칙을 따르느라 힘들때도 있지만, 이후에 전반적인 삶은 더 쾌적하다.
필요할때까지 설계상의 결정을 미뤄라.
일정이 긴박할 때에는 설계원칙을 위배하는 유연함도 허용된다. 하지만 추후에는 수정된다. (기술부채는 허용될 수 있지만, 최대한 빨리 갚아야 한다.)
훌륭한 테스트코드는 앱의 핵심적인 부분을 부담없이 고칠 수 있게 해준다.
깨끗한 도시에서는, 개발자 구성원 모두가 설계에 대해 강한 책임감을 갖고 지속적으로 개선되길 원한다.
14. 소프트웨어 개발이란
소프트웨어 개발자는 어느정도는 예술가가 되어야 한다.
뛰어난 코드를 작성하고자 하는 사람에게는 좋은 취향과 미적 감각이 필요하다.
바보는 일을 크고 복잡하게 만들고, 천재의 손길은 모든일을 심플하게 만든다.
천재처럼 일을 잘하기 위해서는 상상력이 필요하다.
프로그래머는 아이처럼 겸손해야 한다(일부 프로그래머는 책 한권만 보고 자신이 전문가라고 착각한다).
훌륭한 프로그래머는 아이처럼 항상 호기심을 가져아하며, 아이가 놀이를 하듯 코딩을 즐겨야한다.
15. 규칙 가지고 놀기
팀의 코딩 문화에는 규칙이 있다. 이 규칙을 지키면 팀과 함께 재미있게 코딩 플레이를 즐길수 있다. 때때로 못난 프로그래머에게는 더 많은 규칙을 정해줘야 할 때도 있다.
이상적인 팀의 코딩 규칙은 아래와 같다.
- 간결하게 쓰라
- 머리를 쓰라
- 변하지 않는것은 없다(항상 고쳐라)
팀이 배우고 성장함에 따라 위 규칙은 언제나 바뀔 수 있다.
16. 간결하게 하기
간결한 코드는 가장 작은 크기로 이루어져 있으며, 사용이 간편하고 명확하여 오용이 방지된다.
너무 이른 최적화를 피하라
이런 코드의 특징은 맹목적인 코딩스킬이나 추상화에 얽매이지 않으며 꼭 필요한 경우에만 알맞는 스킬이 사용된다. 이걸 짧은코드경로 라고 부른다.
당장 필요하지 않은 기능이나 구조를 지례짐작하여 만들지마라. 되도록 가장 적은 코드량으로 문제를 해결하라.
17. 머리쓰기
어리석은 습관성 행동을 피하라
똑똑한 사람도 어리석을 수 있다.
간단한 배열로 해결될 문제를 독특한 자료구조를 만들어서 해결하려고 하지 마라(아무리 똑똑한 사람이라도 그러는 경우가 있다).
주의깊게 대안을 찾아보고 머리를 써서, 가장 쉬운길로 코딩하라.
18. 변하지 않는것은 없다
코딩한 후… 코드가 미라가 되게 방치하지 마라(자꾸 고치고 개선하라).
개발자는 아직 오나벽하게 알지 못하는걸 수정해야 할 때 두려움에 빠진다.
소프트웨어를 쉽게 바꿀수 있는 코드의 특성을 배우고, 그걸 내가 만드는 소프트웨어에 적용하라.
수정이 용이한 상태를 만들어라.
내 코드가 아니라 팀의 코드라고 생각하라.
부작용이 있는 코드와, 없는 코드를 명확히 분리하여 정리해 놓는게 도움이 된다.
한꺼번에 많이 수정하려들지 말고, 매일매일 조금씩 단편적으로 수정하라.
자동화 테스트 도구는 코드를 수정하는데 용기를 준다.
싸워야 할 때를 가리고, 유리한 시점에 싸우에 싸워라
지금 당장 모든걸 수정하지 말아라. 당장 코앞에 있는 중요한 일을하고, 다만 수정할께 보이면 표시해 두고 나중에 수정하라.
19. 코드 재사용 사례
코드를 복붙하는건 재사용이 아니다. 그냥 코드중복이다.
검증도 안하고 구글링한 코드를 복붙 하는것도 마찬가지다.
포괄적 라이브러리 설계도 좋지않다. 필요없는 api가 베이스로 깔리고 시작하여 복잡해진다.
처음에는 한곳에서 사용하는걸 만들고 여러곳에서 사용할 필요가 있을때 공통모듈로 옮기며 리팩토링하라.
라이브러리를 무분별하게 도입하지말고 현명하게 도입하라.
20. 효과적인 버전관리
21. 골키퍼있다고 골 안들어가랴
골키퍼 그들은 QA이다.
QA를 적대시해서는 안되며, 한팀으로 취급하고 서로 사랑하고 협업해야한다.
코드 작성자는 자신의 코드를 QA에 전달하기 전에 완벽하게 작업해야 한다. 그러지 않고 전달하는건 예의가 아니다.
모든거루자동화하라
테스트와 빌드에서 배포까지 모든걸 자동화 하면 삶이 편해진다 (QA 테스트도 자동화 도구가 있으면 편해진다).
QA로 부터의 오류보고는 경멸의 의미가 아니다. 개인적으로 받아들이지 마라.
22. 프리징된 코드의 신기한 사례
코드프리징은 코드 수정으로 인한 위험요소를 조정하겠다는 의미다.
코드프리징의 종류에는 크게 3가지가 있다. 1. 기능 프리징, 2. 코드 프리징, 3. 단단한 코드프리징
프로그램 실행중지와 맞먹는 긴급한 버그가 아니면 코드를 건드리지 않아야 하는 상태가 1. 코드 프리징이다.
3. 단단한 코드프리징은 릴리즈 일정이 코앞일 때 긴급한 버그도 수정하지 않으며, 배포 이후에 핫픽스로 수정한다.
전형적인 2. 코드프리징 기간은 2주다. 이 기간의 수정은 릴리즈 브랜치에 반영하지 않는다.
QA 자동화 테스트 도구가 있으면 코드 프리징 기간의 단축을 고려할 수 있다.
보통 배포하는데 많은 노력이 드는 프로젝트일수록 코드프리징 기간이 긴것이 유리하다.
23. 제발 저를 출시해주세요
24.배움을 시랑하며 살기
프로그래머는 계속 배우는 직업이며, 배움은 연습할수록 계속 효과가 좋아진다.
배움은 즐길수도 있으며, 심지어 남을 가르치며 배울수도 있다.
25. 테스트주도개발자
코딩 능력 시험같은건 없다. 하지만 개발자는 스스로 의심하고 더 좋은 개발자가 되기위해 항상 노력해야 한다.
프로그래밍은 운전과 같다. 연습하면 잘하게 되지만, 숙련됬다고 자만하고 보주의하면 사고를 부른다.
26. 도전 즐기기
프로그래머는 도전을 즐기고 동기부여를 잘 할줄 알아야 한다.
폭넓은 분야에 관심을 갖고 도전하라.
일에서 재미나 성장을 찾아라.
의미없고 가치없는 도전을 쫓지말고 가치있고 의미있는 도전을 찾아라.
일상적인 코딩 외에 흥미진진한 도전을 끼워 넣어 활력을 줘라.
27. 부진 피하기
안전지대란 유해한 영역이다. 삶의 함정이다.
의식적으로 자신의 기술에 투자하라.
기존에 쓰던 os나 ide, 익숙한 언어 대신 다른걸 사용해봐라.
매너리즘에 빠지느니 다른 곳으로 이직을 시도해보는것도 좋다.
28. 윤리적인 프로그래머
코드의 질은 기술보다는 태도에 달려있다.
대충 땜질하는 방식으로 버그를 수정하지 마라. 근본적인 부분을 수정하라.
페어프로그래밍이나 코드리뷰를 도입하라.
소프트웨어저작권을 준수하라.
동료들에게 정직하고 신뢰할 수 있는 사람이 되라.
속으로 틀리다고 생각하면서 겉으로만 동의하지마라. (팀원의 의무는 다양한 의견을 말하는 것이다)
프로젝트를 방해하는 이슈는 모두에게 공개하고 문제를 알려라.
예상시간보다 작업이 오래걸린다면 솔직히 인정하고 이를 팀에 알려라.
마무리를 할 수 없는 일을 떠맞지 마라.
나가 떨어질만큼 무리하지 마라. 나 자신에게도 윤리적으로 행동하라.
29. 언어에 대한 사랑
한가지 언어에 만족하면 한가지 재주를 익힌 강아지뿐이 되지 못한다.
함수형언어, 객체지향언어, 절차지향언어 여려가지 언어를 써봐라
각 언어의 특성과 장단점을 이해하면 더 좋은 소프트웨어를 만들 수 있게된다.
다양한 언어를 이해하면 사고가 확장되어 문제 해결 범위가 넓어진다.
완벽히 우월하거나 열등한 언어는 없다. 정단점만 존재할 뿐이다.
언어의 특성과 관습을 고려하여 코딩하고, 언어의 철학 안에서 코딩하며 그것의 장점을 배워라.
인내심을 가지고 언어를 배워라, 처음부터 너무 완벽해지려고 애쓰지 말고 느긋하게 배움을 즐겨라.
30. 프로그래머의 자세
건강을 잘 챙겨야 한다. 허리건강, 눈건강.
화면을 볼때 구부정한 자세로 보지마라. 허리를 펴고 개발자로서 자긍심을 가져라.
심각한 근육의 피로가 있으면, 잠시 일어나서 주변을 산책하라. 잠깐 산책한다고 회사에서 회고되진 않는다.
너무 모니터만 바라보지 말고 창 밖을 자주 바라봐라.
31. 더 열심히 보다는 더 현명하게
거칠더라도 빠르게 해결하라. (옛날방식이라도 지금 상황에 가장 적합한 해결책이라면 사용하라)
우선순위를 정하고, 한번에 하나씩 꼭 필요한 부분만 작고 간결하게 작업하라.
32. 끝내야 끝나는것
프로그래머는 개발중인 앱의 완료 진행 상태를 파악하고 있어야 한다.
일을 잘게 나누어 관리하면 완료상태를 파악하기 쉬워진다.
완료상태가 부정확하면 대충 일하게 될것이다. 어차피 열심히 해봤자 완료가 없기 때문이다.
완료상태가 정의되지 않았으면 일을 시작하지 말라.
완료상태를 정할때는 명확성, 가시성, 실현가능성을 파악하라.
더도 말고 완료 상태까지만 작업하라.
33. 교훈얻기
잘 안풀릴땐 누군가에게 문제점을 설명하고 의논하라.
동료에게 도움을 청할 타이밍을 놓치지 마라
당장은 편하지만 점점 힘들어지는 비효율로 해결하고 싶은 본능을 이겨내야 한다. (산을 오르기전에 한발짝 느긋하게 물러서서 계획부터 짜라.)
34. 사람의 힘
소프트웨어는 오로지 기술적 도전인 것만은 아니다. 사회적 도전이기도 하다.
좋은 소프트웨어 전문가들과 함께하면 그들과 비슷하게 좋은 전문가가되고, 그 반대라면 반대로 같이 허접해진다.
가장 훌륭한 프로그래머들을 찾아 그들과 함께해라.
신이 주신 모든 시간을 코드에만 바치며 야근하는 사람들에게 배우고 싶진 않을 것이다. 그들은 전문가가 아니다.
전문가와 같은 팀에서 일하며 그들이 어떻게 일하는지 배워라.
35. 생각이 중요하다
서로를 끌어주는 팀은, 구성원들이 의무감을 갖도록 유도한다.
프로그래머들이 의무감을 지니면 코드 품질이 향상된다.
강력한 절차나 프로세스는 독이될수도 있다. 그보다는 팀원들간의 의무감이나 태도가 중요하다.
서로 코드리뷰를 해라.
의무감이 있는 팀을 만드려면 어느정도 용기가 필요하다.
36. 말하기
프로그래머는 의사소통을 잘해야한다. 사실 코딩 자체가 개발자간의 의사소통의 일부다.
코딩은 기계외의 대화이기도 하고 동료와의 대화이기도 하다.
상황에 따라 대화를 위해 적합한 채널을 찾아라.
직적 대화를 할수 없는 상황이면 되도록 영상통화 채널을 사용해라.
표정이나 바디랭귀지를 포함한 채널은 좋은 의사소통이 되게 도와준다.
좋은 의사소통을 하는 팀은 좋은 코드를 만든다.
거창한 주간회의보다 짧은 일일 회의가 효과적이다.
문서작성, 블로그 작성 등도 의사소통 채널의 한 부분이다.
37. 선언문
소프트웨어 세계에는 많은 선언문이 있는데, 종류도 너무 많고 주관적이다.
유명한 선언문은 읽어보고 자신만에 의견을 만들어보며 생각해보는것도 좋다.
맹목적으로 특정 선언문을 따르거나 독단적으로 사용하지 마라.
38. 코드찬가
혼자 열심히 해봤자 소용없다. 팀을 개선해야 한다.
혼자 분노를 품고 엉망인 팀에 복수해봤자 아무것도 좋아지지 않는다.
바보같은 팀이라도 팀과 함께 개선해야 한다.
39. 태도가 핵심이다
아무리 고급 스킬을 배웠다고 해도 태도가 안좋으면 아무 소용도 없다.
태도는 그 프로그래머가 얼마나 더 발전할수 있는지 결정한다.
좋은 코드에 주의를 기울이고 더 나은 방법을 찾아라.
언제나 배워라. 더 좋게 설계하는 방법을 배우고 코드 작성하는 방법을 배우고, 다른사람들과 더 효율적으로 같이 일하는 방법을 배워라. 언제나 좋은 영향을주고 힘을 복돋아 주는 좋은 개발자들과 함께하려 애써라.
근면하고 양심작이며 전문적이 되도록하라.
프러그래밍을 즐기고 더 나아짐을 즐겨라.