[책] 백세코딩, 신현묵, 프리렉

Summary

• 링크: http://www.yes24.com/24/goods/13895529?scode=032&OzSrank=1
• 블로그: http://zetlos.tistory.com/

• 느낌: SW 개발자의 삶에 대한 이런저런 주변이야기를 쉽게 읽히도록 모아놓았다. 글쓴이의 경험이나 같은 이야기가 여러번 중복되기도 하지만, 술 한잔 같이 하면서 듣는 느낌으로 읽어 볼 만 하다.
• 주제: "행복하게 삶을 사는 소프트웨어 개발자" = '실패'를 적게 하는 방법

Note

• p41. 프로그래밍의 기본 = 자료 선언 + 크기 비교 및 분기 + 정해진 자료를 이동
• p47. 취미와 본업 : 나를 위한 SW를 만들면 재밌고 즐겁지만, 남을 위한 개발은 매우 두려운 일의 연속
• p124. SW공학은 왜 현실에서 사용되지 않는가? : 고객에게 제공되는 SW가 지속적인 유지보수성을 가지기 시작할 때 필요성 인지됨. "필요하지만, 필요하지 않은 곳에서는 필요없다. 하지만 필요한 곳으로 가려면 꼭 필요한 것이다."
• p138. 조직이란 공간에서 특정한 사람에게 중요한 업무나 종속적인 업무를 만들지 않는다.
• 따라서, 자신의 정체성을 확고하게 확보하지 않는 한 40대 이후의 권고사직은 언제나 두려움처럼 다가올 것이다.
• - 하나의 도메인에 충실하게 매달린 소프트웨어 개발자
• - 소프트웨어 개발을 쉽게하여 기업에서 밀려나더라도, 자신만의 브랜드를 확립한 개발자 (광고수입?)

• p181. 이력서 - 프로젝트 기술서
• '5명으로 이루어진 팀에서 대용량 이미지 파일 전송을 위한 서버를 구현했다'
• - 회사 업무와의 연관성, 문제나 난이도
• - 사용한 프로그래밍 언어나 프레임워크, 일의 범위, 기여도, 수치
• p201. 성공은 ... 해서 가능하지 않다. 실패는 ... 해서 피할수 있다.
• - 공부는 성공하기 위해서가 아니라, '실패하지 않기' 위해서..

• p206. 사업계획서가 최선은 아니다. 하지만, 최소의 실패를 줄이기 위한 체크리스트는 될 수 있다.
• p213. 평생직장은 없다; 자신의 이름을 브랜드로 삼아라; 트렌드와 앞으로의 미래를 관찰하라

• p224. 안 좋은 회사를 피하는 방법
• 1) (존경받고 대우받는) 고급 개발자가 있는가?
• 2) 개발자들이 오랫동안 근무한 사람들이 있는가?
• 3) 사무실의 환경을 살펴라. (실제 일하는 사람들이 있는가?)
• 4) 신입 연수나 트레이닝 프로그램이 있는가?

• p229. 이직의 요건
• - 자신만의 장점; 전문성; 절대 다수는 하지 못하는 희소성; 내 경력을 증명할 프로젝트; 포트폴리오; 외부활동과 내 브랜드

• p244. 에레네시스토 시롤리: 누군가를 돕고 싶다면 입다물고 그냥 들어주어라.

• p248. 내 인맥은 나에게 활용하라: 인맥은 나에게 도움을 요청하는 사람들이 정말 인맥이다.

• p248. 소프트웨어 복잡도: McCabe's Cyclomatic Complexity
• - SonarCube
• - Junit(단위시험), Findbugs(정적분석), PMD(정적분석), Cobertura(커버리지), CheckStyle(컨벤션), CPD(코드 중복검사), JavaNCSS(코드복잡도 검사)

• p262. 언제나 새로운 언어를 찾아라
• - Ceylon, Clojure, Egison, Groovy, Hack, Jeeves, Julia, Nimrod, Ocaml, Scratch
• p276. 공개 소프트웨어 포털 - 소프트웨어 품질 검증 분야

• p321. 코드리뷰
• - 리뷰는 언제나 상호 합의가 된 상황에서 진행
• - 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지
• * 기본적인 규칙들은 가능한 자동화 및 권장
• - 1시간 이내로. 200라인 이상을 한 번에 검토하지 말 것

• p336. OOP 5대 원칙 ==> 유지보수가 쉬운 소스의 개발
• -SRP: Single Responsibility Principle, 하나의 객체는 하나의 책임
• -OCP: Open Closed Principle, 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 함
• -LSP: Liskov Substitution Principle, 상위 클래스는 파생클래스를 대체 가능해야 함
• -DIP: Dependency Inversion, 클라이언트는 상세 클래스가 아닌 추상화(인터페이스, 추상클래스) 계층에 의존해야 함
• -ISP: Interface Segregation, 클라이언트에 특화된 단일화된 기능과 책임

• p353. 추천도서
• - 소프트웨어 아키텍트가 알아야 할 97가지
• - 소프트웨어 누가 이렇게 개떡같이 만드는 거야(Why Software Sucks), 데이비드 S. 플랫 // 그 닥 재밌지는 않음
• - 위대한 게임의 탄생

• p373. SE 탑 저널
• - TSE: IEEE Transactions on SE
• - TOSEM: ACM Transactions on SE and Methodology