- 저자
- 박성철, 강대명, 공용준, 김정, 박미정, 박종천
- 출판
- 골든래빗(주)
- 출판일
- 2022.12.20
원칙 : 쓸모 있는 소프트웨어를 만들자
- 26, 박성철
저는 개발자를 두고 공장에 자기만의 생산 선비를 들고 들어가서 일하는 노동자라고 표현합니다.
- 39, 박성철
최종적인 전문간에 대한 나의 정의: 전문가 = (전문 역량 + 일반 역량) * 동기 * cos θ * 연대
- 44, 박성철
백엔드 엔지니어로서 저는 "백엔드 엔지니어의 실력은 얼마나 많은 오류와 장애를 만나고 이를 해결했는지 여부에 따라 갈린다"라고 말합니다.
- 53, 강대명
첫 번째 원칙은 '오류가 발생하면 소스 코드 레벨에서 이해하자'입니다.
- 53, 강대명
두 번째 원칙은 알아낸 지식을 글로 공개하라는 겁니다.
- 55, 강대명
제품 관점에서 설계를 다시 정의해보면 '설계란 제품이 요구사항을 만족시키는 것을 증명하는 조건을 정의하는 행위'로 볼 수 있습니다.
- 85, 공용준
배워야 할 지식을 저처럼 현재 업무량 관련된 것에 50%, 앞으로 관련될 것에 30%, 관련 없지만 관심 있는 것에 20% 정도만 시간을 투자해보세요.
- 122, 김정
학습하는 과정에서 자신의 학습 방식, 이해하는 방식, 설명하는 방식, 학습 과정을 개선하는 방식까지 학습해야 합니다. ... 의도적으로 익숙한 방식을 멀리하고, 의도적으로 낯선 방식을 선택해보세요.
- 128, 김정
개구리를 해부하지 말고, 직접 만들기
- 129, 김정
"내가 무언가를 잘합니다"라는 표현에는 다른 누군가보다 잘한다는 맥락이 숨겨져 있습니다. 숨겨진 의미는 그대로 감춰둡시다. 자신을 다른 누군가와 비교하면 그 순간부터 괴로울 뿐입니다. 비교하는 대상을 다른 사람으로 향하지 말고, 스스로 내면을 향하도록 해야 합니다. 몇 시간 전에 몰랐던 것을 깨닫거나 하루 이틀 전에 작성한 코드를 개선할 점을 찾을 수 있으면 조금씩 자신만의 속도로 성장한다는 증거입니다.
- 133, 김정
문제 해결 과정에서 만든 결과물에는 문제 해결 코드뿐만 아니라 개발 과정에서 이루어지는 가정, 추론, 논리적인 판단, 비교, 분류, 설득, 전달 과정이 포함되어야 합니다. 모든 것을 코드로 표현하지 않아도 됩니다. 요구사항 분석, 설계부터 테스트, 코드 리뷰 과정, 이슈 관리, 협업 과정 전체가 소프트웨어 개발 과정입니다. 그렇기 때문에 소프트웨어는 코드가 전부가 아닙니다.
- 136, 김정
짝 프로그래밍 흐름에서 중요한 것은 공유하는 코드가 아니라, 과정을 기록하고 주고받는 맥락 그 자체입니다.
- 138, 김정
기준을 정하기 전에 여러 답을 찾아서 공유하기
- 141, 김정
소프트웨어 개발자의 학습과 성장은 혼자서 묵ㅁ구히 학습하는 것보다는 비슷한 고민을 하는 동료가 함께 하는 것이 좋습니다. 다양한 배경을 가진 4~5명이 스터디 그룹을 구성하여 학습하면 서로 피드백을 하기 적당합니다.
- 144, 김정
개발자에게는 개념이나 동작 방식에 대한 형식지와 지식을 직접 구현하고 코드로 표현해서 만드는 과정에서 습득하는 암묵지가 모두 필요합니다. 어느 하나만 잘해서는 성장하지 못합니다.
- 145, 김정
학습과 성장을 위한 다양한 방법이 있겠지만 '환경의 변화'는 학습과 성장을 위한 효과적인 게기가 됩니다. 그리고 '이직'은 이러한 환경 변화 중 하나임을 부인할 수 없죠.
- 153, 박미정
주니어 입장에서 기술 교류를 통한 성장만큼 나에게 중요했던 것은 내가 만드는 제품에 대한 주인의식이었습니다.
- 156, 박미정
서비스 규모도 커지고, 더불어 함께 일하는 동료도 많아지는 환경 속에서 체계적으로 일을 진행하는 경험은 '일이 되게끔 하는 것'이 무엇인지를 제대로 경험할 기회입니다. 개발자는 경험이 쌓일수록 필요한 기능을 개발하는 역할에서 필요한 일을 찾아내는 역할로 시야를 확장해가야 합니다.
- 158, 박미정
단순한 의미의 '개발'이 아닌 '개발을 통해 일'을 하는 주체로서 자리잡기 시작합니다. 이 시기에는 개발/조직 문화 개선에 기여하고 싶다는 생각이 들었습니다.
- 159, 박미정
'개발자는 무엇인가? 수많은 개발자 중에서 박미정이라는 개발자는 무엇을 잘하는 개발자인가?'라는 질문이 계속되었습니다. 이쯤에서 그 해답을 찾았습니다. 기술이라는 범주 안에 갇혀서 스스로를 정의하기 보다 '서비스를 만들고 성장시키는 일이 즐거운 사람', '서비스를 위해 기술이라는 도구를 잘 다루는 사람'으로 저를 정의했습니다.
- 161, 박미정
제가 오랜 기간 동안 유지한 목표이자, 가장 기본이 되는 제1 원칙은 바로 '프로덕트에 집중하자'입니다.
- 191, 이동욱(네피림)
프로덕트가 생략된 목표를 설정한 사례는 많습니다.
1. 스프링 프레임워크를 공부해야겠다. 내일부터 온라인 강의를 들어야지
2. 모바일 개발에서 주목받는 플러터 프레임워크를 공부하겠어.
둘다 성장을 위해 충분히 선택할 수 있는 목표입니다. 하지만 같은 목표여도 프로덕트가 목적일 때는 실제로 만들 대상이 구체적으로 명시되어야 합니다.
1. 간단한 API 서버를 스프링 기반으로 만들어보겠어
2. 플러터로 여행 기록용 모바일 어플을 만들어보겠어
- 192, 이동욱(네피림)
망설일 바에는 실패하자
-199, 이동욱(네피림)
어떤 방법으로든 '프로덕트를 잘 만들겠다'는 목표를 계속 유지한다면, 무언가를 만드는 일에 참여하는 기쁨을 계속 누릴 수 있습니다.
- 203, 이동욱(네피림)
제어할 수 없는 것에 의존하지 않기
- 205, 이동욱(향로)
당시에 제가 제어할 수 없는 것은 다음과 같습니다.
- 개발팀 전체의 연봉 테이블
- 개발팀 규모의 확장
- 기존에 같이 일해본 혹은 전 직장 분들의 합류
- 기존 서비스의 기술 스택 교체
- 218, 이동욱(향로)
제어할 수 없는 것에 집중하다 보면 그 무엇도 해결하지 못할 수 있습니다. 제어할 수 있는 것에 의존하고 집중해야만 어떤 일과 상황을 만나더라도 앞으로 전진할 수 있습니다. 제어할 수 있는 것과 제어할 수 없는 것을 구분한 뒤 제어할 수 없는 것을 멀리하고, 제어할 수 있는 것에 집중하면 됩니다. 외부의 요소, 이미 발생한 사건, 결정권이 없는 일 등은 제어할 수 없습니다. 이들에 의존해선 안 됩니다. 제어할 수 있는 것들에만 의존하도록 해야 합니다.
- 225, 이동욱(향로)
행동강령
1. 일단 동작하게 만든 다음 더 좋게 만들어라
2. 언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라
3. 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점입니다.
- 229, 장동수
제약조건을 극복하고 제대로 동작하는 코드를 제때 만들어야 합니다. 개인적으로 이를 '밥값'이라고 부릅니다. 밥값은 개발자 개인과 개발 조직 모두에게 중요합니다.
- 231, 장동수
그렇게 알려진 수천 가지의 조건 중에서도 거의 모든 책에서 공통적으로 제시하는 조건이 있습니다. 바로 가독성, 성능, 유연성입니다.
- 232, 장동수
좋은 코드는 유연성이 있습니다. 그러나 유연성이 있고 어려운 코드보다는 유연성이 없더라도 쉬운 코드가 더 좋은 코드입니다.
- 236, 장동수
클린 코드와 SOLID는 좋은 출발점입니다. 그러나 그것이 전부는 아닙니다. SOLID는 도구일 뿐 목표가 아닙니다. 클린 코드도 부수효과일 뿐 목표가 아닙니다.
- 236, 장동수
더 좋은 코드라면 가독성, 성능, 유연성 모두 중요합니다. 그중에서 하나를 골라야 한다면, 두 말할 것도 없이 가독성입니다. 더 좋은 코드와 잘 동작하는 코드 중에서 하나를 골라야 한다면, 잘 동작하는 코드입니다. 개발을 직업으로 삼는 개발자에게 잘 동작하는 코드는 '제때 제대로' 동작하는 코드입니다.
- 237, 장동수
레거시는 해결해야 할 기술적인 과제인 '기술 부채'도 포함하고 있지만, 많은 문제를 해결한 그리고 해결할 유용한 '기술 자산'도 포함하고 있습니다.
- 240, 장동수
부채 청산의 시작은 자동화된 테스트를 확보하는 겁니다. 테스트 작성이 어렵다면 명백한 기술 부채입니다.
- 241, 장동수
단언컨대, 기술 부채가 없는 개발은 불가능합니다. 큰 마음 먹고 한 번에 탕감할 순 있겠지만, 금세 새로운 부채가 쌓입니다. 처음부터 새로 만들어도 기술 부채를 피할 수 없습니다. 기술 부채를 절대 허용하지 않겠다는 욕심이 더 큰 기술 부채를 만듭니다. 우리가 할 수 있는 일은 기술 부채를 식별하고, 기술 파산에 이르지 않도록 관리 가능한 수준으로 유지하고, 가능하다면 자산으로 물려주는 겁니다.
- 243, 장동수
은탄환은 없다. 많이 읽고, 많이 쓰고, 많이 생각하자.
- 246, 장동수
코드 리뷰는 다른 개발자(혹은 본인)의 코드를 읽고, 생각하고, 토론하는 행위인 다독과 다상량입니다.
- 247, 장동수
"코딩을 잘 하려면 많이 읽어야 합니다. 코드를 많이 읽어도 코딩을 잘 못할 수는 있습니다. 그러나 많이 코드를 많이 읽지 않고도 코딩을 잘하는 것은 불가능합니다. 코딩을 많이 할수록 더 잘하게 됩니다. 축구나 수영이나 글쓰기가 그런 것처럼 코드도 근육이 있어야 쓸 수 있습니다. 코딩 근육을 만드는 유일한 방법은 코딩을 하는 것입니다."
- 249, 장동수
'Book' 카테고리의 다른 글
| [독서 기록] 개발자를 위한 글쓰기 가이드(유영경 지음, 로드북) (0) | 2023.08.20 |
|---|---|
| [독서 기록] 기술문서 작성 완벽 가이드(자레드 바티 외 지음, 하성창 옮김, 한빛미디어) (0) | 2023.08.17 |
| [독서 기록] 디깅, 박치은 지음 (0) | 2023.07.07 |
| [독서 기록] 아주 작은 습관의 힘, 제임스 클리어 지음, 이한이 옮김, 비즈니스 북스 (0) | 2023.06.29 |
| [독서 기록] 도메인 주도 설계로 시작하는 마이크로서비스 개발, 5장 (0) | 2023.05.30 |
