개발자 원칙

개발자 원칙 | 박성철 - 교보문고

챕터

• 덕업일치를 넘어서
• 오류를 만날 때가 가장 성장하기 좋을 때다
• 소프트웨어 디자인 원칙
• 나의 메이저 버전을 업그레이드하는 마이너 원칙들
• 이직, 분명한 이유가 필요해
• 목표를 달성하는 나만의 기준, GPAM
• 프로덕트 중심주의
• 제어할 수 없는 것에 의존하지 않기
• 달리는 기차의 바퀴를 갈아 끼우기

 

메모

덕업일치를 넘어서

많은 회사가 단위 조직을 팀이라고 부르지만 사실 팀워크가 올바로 동작하는 팀은 많지 않습니다.
흔히 좋은 팀워크는 좋은 분위기를 의미합니다.
그래서 회식이나 대화를 많이 하는 것이 팀워크를 좋게 만드는 방법이라고 말합니다.
물론 좋은 분위기는 정말 중요합니다.
하지만 팀워크는 그 이상입니다.
1+1이 2 이상이 되도록 만드는 것이 팀워크입니다.
팀워크가 좋은 팀은 의미 있는 성과를 지속적으로 내며 늘 더 높은 목표에 도전합니다.
공동의 목표를 위해 협력할 줄 알고, 서로 배우고 가르치며, 개인과 팀 모두 성장합니다.

-p44

오류를 만날 때가 가장 성장하기 좋을 때다

서비스를 운영하다 보면 많은 툴을 사용하고, 많은 에러를 마주치게 됩니다.
이때 해당 오류를 스택오버플로에서 검색하면 대부분은 손쉽게 해결책을 얻을 수 있습니다.
하지만 단순히 여기서 끝내버리면, 실제로 깊은 지식을 얻기가 어렵습니다.
한 발 더 나아가서 해당 툴의 소스 코드를 확인하는 것으로 관련 에러가 왜 발생하는지 해결하려면 어떻게 해야 하는지 같은 깊은 지식을 얻을 수가 있습니다.
파생되거나 비슷한 문제를 예방할 수도 있게 됩니다.
…
소스 레벨에서 이해한 내용을 이해했다면, 결과물로 남기는 것이 중요합니다.

-p55

제대로 된 정보를 확인하는 최선의 방법은 소스 코드를 확인하는 겁니다.
그래야 기본 지식이 탄탄한 개발자로 성장할 수 있습니다.

-p66

아무리 좋은 학습 방법이라도 나한테 안 맞으면 쓸모가 없는 거라고 생각합니다.
…
개발을 하며 순간마다 떠오르는 이런 의문들에 대해서 깊이 아는 것이 크게 도움이 안 될 수도 있습니다.
하지만 각 질문에 대한 해답을 근본에서 확인하면, 단 하나로는 별로 큰 도움이 안 될지라도 모으면 깊이 있는 기술력을 가질 수 있다고 생각합니다.

-p68

나의 메이저 버전을 업그레이드하는 마이너 원칙들

경로를 결정하고 가까운 역까지 걸어가는 동안 길 위에는 누군지 모르지만 같은 방향으로 가는 사람이 한두 명쯤 있습니다.
아는 사람이라면 속도를 맞춰서 함께 걸어갈 수도 있지만, 모르는 사람이라면 각자 속도로 각자 갈 길을 갈 겁니다.
…
대개는 옆 사람이 어디로 가는지, 얼마나 빨리 걷는지, 나보다 천천히 걷는지 신경 쓰지 않습니다.
오로지 내가 가는 속도만 중요할 뿐입니다.
저마다 걸음걸이가 다른 것처럼 책을 읽을 때도, 공부를 하거나 일을 할 때도, 심지어 밥을 먹을 때도 나만의 속도가 있습니다.
’공부는 엉덩이로 한다’라는 말이 무조건 들어맞지는 않습니다.
무작정 앉아서 공부한다고 저절로 체득이 되는 것이 아니기 때문입니다.
자신에게 알맞은 방향과 속력을 찾아야 공부도 제대로 되는 겁니다.

-p120

일을 하다보면 극단적으로 속도를 한계까지 올려야 하는 상황이 생깁니다.
나만의 한계 속력을 알아야 합니다.
예를 들어 하루를 기준으로 내가 할 수 있는 일, 읽을 수 있는 글, 처리할 수 있는 일감에도 한계가 있습니다. 평소 속력과 한계 속력은 분명히 다릅니다.
…
한계 속력에 다다르면 실수를 하기 마련입니다.
이런 상황에서 실수를 줄이는 최선의 방법은 평소에 자신을 성장시키는 방법밖에 없습니다.

-p122

내가 익숙하게 풀었던 문제나 코드를 새로 익히는 언어로 풀어보는 것도 좋습니다.
새로운 언어가 아니라면 함수를 작성할 때 10줄 이내로만 작성하려고 시도해 봐도 좋습니다.
객체지향 언어에 익숙하다면 함수형 표현으로 작성하려고 해봅시다.
익숙한 통합 개발 환경 대신에 터미널에서 CLI 명령만으로 빌드를 직접 해보는 것도 흥미로운 제약사항입니다.
마우스 없이 키보드만으로 단축키 쓰기에 도전해봅시다.
이렇게 제약사항을 추가하면서 의도적인 수련을 반복하면 형식지에 암묵지가 더해지는 기적을 만나게 될 것입니다.
만약 제약사항을 찾기 어렵거나, 자기 자신을 돌아보기 어렵다면 다른 개발자를 만나봅시다.

-p128

나를 업그레이드하려면 결과를 향하면서도 그 과정을 기록하는 습관을 갖추어야 합니다.

-p135

소프트웨어 개발자의 학습과 성장은 혼자서 묵묵히 학습하는 것보다는 비슷한 고민을 하는 동료가 함께 하는 것이 좋습니다.
다양한 배경을 가진 4~5명이 스터디 그룹을 구성하여 학습하면 서로 피드백을 하기 적당합니다.
옆에 다른 사람이 학습하는 과정을 살펴볼 수도 있고, 그러면 자신의 속도와 방향을 인지하기 쉽습니다.
다른 사람에게 내 생각을 설명하다 보면 무엇을 모르는지 깨닫는 데 도움이 됩니다.

-p144

목표를 달성하는 나만의 기준, GPAM

오랫동안 개발자 생활을 하면서 항상 염두에 둔 생각은 ‘오늘보다 내일 일을 더 잘하는 사람이 되자’였습니다. 이 말을 풀어 말하면 ‘지금 하는 일을 한 번 더 하게 되면, 그때는 훨씬 더 효율적으로 빠르게 그리고 더 좋은 결과물을 뽑아내자’입니다.

-p169

GPAM 원칙은 무척 단순합니다.
Goal(목표)을 정하고, Plan(계획)을 만들고, Action(실천)을 하고, Measure(평가)를 진행해 결과를 확인하면 됩니다.

-p170

작은 목표가 좋습니다.
비전은 커도 되지만, 목표는 작게 그리고 단계적으로 여러 개가 있어야 합니다.
그래야 성취감을 느끼며 한 걸음씩 비전에 다가갈 수 있습니다.

-p173

GPAM의 시작은 당연히 Goal, 목표입니다.
…
따라서 좋은 목표를 선정하는 데 노력을 기울여야 합니다.

💡SMART 방법론

Specific: 개선이 필요한 영역에 대한 구체적인 목표
Measurable: 진행 상황에 대한 수치화(측정)가 가능한지
Actionable: 실행이 가능한지
Realistic: 현재 리소스로 현실적으로 가능한지
Time-related: 결과가 언제 나올지 기한이 있는지

-p174

제어할 수 없는 것에 의존하지 않기

제어할 수 없는 값에 의존하는 코드들을 최대한 멀리한다.
주요 비즈니스 로직은 모두 제어할 수 없는 값만 의존하게 해 테스트 코드 작성이 쉬운 형태로 구성한다.

-p214

달리는 기차의 바퀴를 갈아 끼우기

Make it work then make it better - 켄트 백
일단 동작하게 만든 다음 더 좋게 만들어라

-p230

가독성은 좋은 코드의 필수 조건입니다.
…
가독성이 좋은 코드는 좋은 관행을 잘 따릅니다.
...
일관성 있는 코드가 읽기 좋습니다.
…
코멘트가 없는 코드가 읽기 좋습니다.
코멘트가 필요 없는 코드라면 분명 가독성이 좋은 코드일 테니 말입니다.
…
짧은 코드가 읽기 좋습니다.
함축적인 코드보다는 명시적인 코드가 읽기 좋습니다.
단순 명료한 코드가 읽기 좋습니다.

-p232 ~ p234

좋은 코드는 유연성이 있습니다.
그러나 유연성이 있고 어려운 코드보다는 유연성이 없더라도 쉬운 코드가 더 좋은 코드입니다.
유연성에는 추상화가 필요합니다.
유연성을 위해서 시작한 추상화가 재사용성과 잘못만나면 ‘추상화의 함정’에 빠지게 됩니다.
개발자들만 걸리는 직업병이자 난치병입니다.
막 중급에서 벗어나 고급으로 올라서려는 개발자(대개 7~10년차)들에게 자주 발생하는데, if문을 극단적으로 배제하고, Factory를 과도하게 사용하고, 클린 코드와 SOLID를 숭배합니다.

”duplication is far cheaper than the wrong abstraction”
”prefer duplication over the wrong abstraction”
잘못된 추상화보다는 중복이 훨씬 더 싸다.
잘못된 추상화보다는 중복이 낫다.

-p236

더 좋은 코드라면 가독성, 성능, 유연성 모두 중요합니다.
그중에서 하나를 골라야 한다면, 두 말할 것도 없이 가독성입니다.
더 좋은 코드와 잘 동작하는 코드 중에서 하나를 골라야 한다면, 잘 동작하는 코드입니다.
개발을 직업으로 삼는 개발자에게 잘 동작하는 코드는 ‘제때 제대로’ 동작하는 코드입니다.

-p237

문제가 있는 코드를 즉시 고치는 것이 최선입니다.

-p240