개발자 원칙 책 정리

담쟁이

저것은 넘을 수 없는 벽이라고 고개를 떨구고 있을 때 담쟁이 잎 하나는 담쟁이 잎 수 천 개를 이끌고 결국 그 벽을 넘는다

전문가 = (전문 역량 + 일반 역량) X 동기 X cos X 연대

뛰어난 팀 없이 뛰어난 소프트웨어는 얻을 수 없다. 그리고 대부분의 소프트웨어 팀은 역기능가정 같이 움직인다. - 존 맥카시 -

나는 내가 관문을 지키는 사람임을 안다. 권위에 복종하기보다 내가 만든 기술의 결과에 훨씬 더 관심을 둔다. 내가 이 선서를 어기지 않는다면, 나는 삶과 내 기술을 즐기며, 내가 사는 동안 존중받고 그 후에는 기억될 것이다.

오류가 발생하면 소스 코드 레벨에서 이해하자.

알아낸 지식을 글로 공개하라

오류를 만나면 관련 자료들을 찾아보고, 소스코드를 확인하고, 오픈 소스에 기여하고, 블로깅을 하자.

배우는 일, 그것은 즐겁다 생각하는 일은 더 즐겁다 창조하는 인생이야말로 최고의 인생이다. - 학문의 즐거움 -

SOLID 원칙

• SRP : 단일 책임 원칙
• OCP : 개방 폐쇄 원칙
• LSP : 리스코프 치환 원칙
• ISP : 인터페이스 분리 원칙
• DIP : 의존 역전 원칙

코드와 객체지향 수준의 원칙을 넘어 설계를 원칙을 익히자

두리번거리며 속력과 방향을 자주 확인하기 (메타인지) 낯선 방식으로 해결하기 개구리를 해부하지말고 직접 만들기 남을 향한 자존심을 버리고, 나를 향한 자존감 채우기 결과를 향하면서 과정을 기록하기 의도한 실수를 반복하면서 작은 부분을 개선하기 기준을 정하기 전에 여러 답을 찾아서 공유하기 배포하기 그리고 다음버전 준비하기

항상 기존 조직에서 내 성장을 위한 변화를 시도할 수 있는지 찾기 기존 환경에서 변화를 모색하기, 먼저 책임감 있는 마무리를 할 것

목표(Goal)를 정하고, 계획(Plan)을 세우고, 행동(Action)을 하고, 평가(Measure)를 하자

목표를 선정하는데 유용한 SMART 방법론

Specific : 구체적인 목표 Measurable : 측정 가능한 목표 Actionalble: 실행 가능한 목표 Realistic : 현재 리소스로 현실적으로 가능한지 Time-related : 결과가 언제 나올지 기한이 있는지

사이드 프젝을 할 때 어떤 기술을 사용해야지 보다는 어떤 프로젝트를 어떤 기술 기반으로 만들어야지가 되어야함

이터레이션을 돌며 프로젝트를 개선시키자

항상 협업모드로 생각하기

깃헙 공개 레포를 사용하거나, 온라인 오프라인 세미나에 자주 참석하자

프로그래머에게 요구되는 것은 100점이 아닌 80~90점 짜리 프로그램을 기한 내에 완성하는 일이다. - 나카지마 사토시 -

DRY : 똑같은 기능, 코드를 반복하지 마라 YAGNI : 그 기능이 필요하기 전까지는 미리 만들지 마라 KISS : 최대한 단순함을 유지하라

현실 세계의 변화와 설계 사이의 결합도를 줄여야한다. 전화번호를 식별자로 사용하는가? 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. - 실용주의 프로그래머 -

Make it work, then make it better - 켄트 백 -

작은 효율성에 대해서는, 말하자면 97% 정도에 대해서는 잊어버려라. 섣부른 최적화는 모든 악의 근원이다. - 도널드 커누스 -

잘못된 추상화보다는 중복이 낫다. - 샌디 메츠 -

Always leave the campground cleaner than you found it. - 로버트 베이든 포우엘 -

바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점입니다. - 더글락스 크락포드 -