Tags: software-engineering Date: November 24, 2023 Score: ★★★★☆
- 필독! 개발자 온보딩 가이드
- ★★★★☆ July 2, 2023 제목이 책의 내용을 다 담지 못하는 느낌. 그만큼 다양한 분야의 이야기들을 깊이가 조금은 부족하지만 잘 설명한다. 개발자가 회사에 적응하는 데 필요한 이야기를 넘어 software engineering의 전반을 다룬다. 내가 management를 하기로 생각한 이후 필요로 하거나 구축해야겠다고 생각하는 대부분의 주제들을 담고 있다. 매우 좋은, 추천할만한 책
- ★★★★☆ November 24, 2023 다시 한 번 읽어봐도 참 좋은 책
- 탐라 문005.1-리825ㅍ
- 독서광 필독! 개발자 온보딩 가이드
- The Missing README: A Guide for the New Software Engineer: Riccomini, Chris, Ryaboy, Dmitriy: 9781718501836: Amazon.com: Books
코드를 처음부터 다시 작성하려 한다거나 표준을 무시하는 행동은 위험대부분의 엔지니어는 규칙의 가치에 대해서는 과소평가하고 규칙을 무시하는 행위의 가치는 과대평가하는 경향이 있다- management를 하면서 점점 생각이 바뀌었고, 피닉스 프로젝트 를 읽으면서 내가 어렴풋이 느끼고 있던 제조업의 관행이나 엄격한 규칙의 중요성을 확실히 깨닫게 되었다. 물론 맞지 않는 부분도 많기에 적절한 도입이 필요하지만 규칙의 중요성 그 자체만큼은 확실하다
스칼라는 그만큼 성숙한 언어가 아니었던 것- 물론 오래 전의 일이긴 하지만 시사하는 바는 확실하다
표준에서 벗어난다면 곧 그에 따른 비용이 발생… 그 방법이 표준으로 채택된 이유를 이해해야… 실용주의적 사고에 입각해 대처해야
- pp89~90
코드를 새로 작성하는 것은 최후의 수단코드 재작성은 그에 들어가는 비용보다 장점이 클 때만 시도해야 한다. 코드 재작성은 위험할 뿐더러 소요 비용도 높기 때문- e.g. Twitter의 Duck Duck Goose migration 사례
- 필수 체크리스트의 내용은 모두 정말 중요한 이야기들
- pp121~122
DSL은 표준 도구를 이용해 파싱하기가 어려워서 다른 도구와의 상호운용성이 떨어진다설정 시스템은 단순해야 한다지나치게 창의적인 설정은 금물… 원하는 동작을 할 수 있는 가장 간단한 방법을 채택하자. 단일한 표준 형식을 채택한 정적 설정 static configuration 파일이 가장 이상적동적 설정은 그 복잡성 때문에 대부분의 경우에는 권장하지 않는다… 설정이 바뀔 수 있다는 가능성을 생각해야 하기 때문… 언제 누가 설정을 바꿨는지 여부는 운영 이슈를 디버깅하는 데 매우 중요한 반면, 실제로 그 정보를 추적하기는 어렵다… 다른 분산 시스템에 대한 의존성도
- 필수 체크리스트의 내용은 모두 정말 중요한 이야기들 (2)
릴리스 과정에서 릴리스 노트와 변경 로그도 업데이트하며 그런 다음에는 패키지를 중앙식 리포지토리로 발행한다. 발행된 릴리스 산출물은 반드시 테스트 환경이나 프로덕션 환경에 배포해야 한다.올바른 브랜칭 전략을 구축하면 예측 가능한 소프트웨어 전달이 가능하지만, 잘못된 전략을 택하면 프로세스 자체가 소프트웨어 전달에 걸림돌
- pp290~291
복잡도의 비용은 시간이 지나면서 누적되므로 관성이 높고 변경이 잦은 시스템은 반드시 간소화해야… 관성이 낮고 변경이 드문 시스템은 복잡한 상태 그대로 남겨둬도 무방미래에 발생할 요구사항을 알 수는 없으므로 엔지니어는 대체로 두 가지 전략 중 한 가지… 나중에 어떤 필요가 발생할지 예측… 나중에 좀 더 쉽게 코드를 변경할 수 있는 추상화를 구현… 두 전략은 모두 복잡도를 증가… 최대한 간단하게 구현하자 Keep things simple- 그러나 마치 MSA라는 명목하에 쓸데없이 service를 나누듯 abstraction이나 design pattern이라는 명목하에 쓸데없는 architecture를 사용하려는 경우가 많다
그건 필요하지 않을 거야 You ain’t gonna need it (YAGNI)
최소 충격 원칙 principle of least astonishment… 사용자를 놀라게 하지 말라… 마찬가지로 개발자를 놀라게 하지도 말자암묵적 요소 implicit knowledge를 포함하는 API는 개발자의 예상을 빗나가게 되며 버그를 유발할 뿐 아니라 학습 곡선도 높아진다- 약간 다른 이야기지만, scala의 implicit을 내가 싫어했던 이유와도 연결
크기를 작게 유지하고 명확하게 정의하며 버전을 도입하면 훨씬 더 쉽게 사용하고 진화시킬 수 있는 API를 구현할 수 있다… API에도 YAGNI 철학을 적용하자
스프린트를 진행하는 동안 새로운 업무가 등장해도 현재 스프린트에 억지로 끼워넣지 않는다- 현실에서는 이렇게 하기 정말 어려운데…
리뷰는 스프린트 동안 완료한 업무를 논의하는 시간이며, 회고는 절차와 도구를 논의하는 시간- 나는 간단하게 전달하기 위해 주로 product에 대해 돌아보는 시간과 process에 대해 돌아보는 시간으로 구분하곤 했다
- 하지만 많은 사람들이 이 부분을 혼동하는 경우가 많다. 심지어는 scrum을 담당하는 PO라는 역할을 하는 사람이 둘의 차이가 뭐냐고 왜 구분해야 하냐고 하는 경우도 직접 경험해봤다
팀장들은 늘 회의 중인 것처럼 보이지만 정확히 무슨 일을 하는지는 명확하지 않다.