해당 글은 백기선님의 [개발자로 살아남는 방법] EP02. 개발자에게 필요한 "기술력"이란?를 보고 정리한 내용입니다.
워딩이 다소 날카로울 수 있습니다. 나름 만족스러워서 그대로 정리했습니다.
Before we begin
나는 열정이 있다. 나는 책임감이 있다. 이런 주장들은 사실 별 의미가 없다.
"우리 집에 황금 송아지가 있다" 랑 차이가 없다.
내가 지금까지 만들어 낸 것과 지금 만들어 내고 있는 것으로 증명해보도록 하자.
나는 이렇게 이렇게 행동을 했다. 그래서 나는 협업에 신경을 썼다고 생각한다.
이렇게 주장하는 것이 훨씬 낫다.
동료 평가에도 마찬가지로 적용된다.
"너랑 일하기 싫어하는 사람이 OO 명이야."
이게 무슨 의미가 있는가? 이건 정말 병X같은 평가 방법이다. 차라리 직접적인 피드백을 주는게 낫지 않을까?
"당신이 회의에서 이러이러하게 행동하는 것이 다른사람들이 아이디어를 내는 데 꺼릴 수 있는 분위기를 조성한다. 내 생각에는 이렇게 하는 것도 좋을 것 같다."
제 1원칙: 꾸준히 수준 높은 해결책을 만들어 내는 능력
개발자로 일을 하다보면, 팀에서 맡고 있는 서비스나 플랫폼에 굉장히 다양한 이슈가 있다는 것을 깨닫게 된다.
왜 그런 문제가 발생하는가? 문제 인식부터가 시작이다. 이것도 능력이다.
여러가지 방법이 있을 것이다. 솔루션은 분명히 다양할 것.
그러면 이 다양한 솔루션들을 비교할 수 있어야 한다.
그 솔루션들을 비용으로 비교해야 한다.
비용은 시간도 될 수 있고, 운영 비용도 될 수 있을 것이다.
그러면 이 솔루션과 장단점들을 팀원들에게 제시하고, 이런 회의룰 주관해서 솔루션을 만들어 내고, 이걸 구현할 수 있는 게 바로 시니어 엔지니어다.
이렇게 솔루션을 고안해내다 보면 분명히 기술력은 증가할 수밖에 없다.
제 2원칙: 엔지니어링 원칙과 업계의 Best Practice를 받아들이기
오해의 소지가 좀 있는데, Best Practice라는게 결코 트렌드를 좇아라 라는 말이 아니다.
그럼 엔지니어링 원칙은 뭘까?
DRY: Don't Repeat Yourself- 중복 제거와 관련된 원칙.
KISS: Keep it Simple Stupid- 시스템을 최대한 단순하게 구현하기.
- 누구나 이해할 수 있는 코드를 작성하기.
YAGNI: You ain't gonna need it- 오버 엔지니어링에 관한 원칙.
SOLID: SRP, OCP, LSP, ISP, DIP- 객체지향원칙. 다들 알 것 같고...
업계에서 Best Practice라는 것은 refactoring, TDD까지는 아니더라도 테스트를 만드는 것.
이정도까지인 것 같다.
DDD 얘기가 계속 나오는데, DDD는 사실 쉽지 않다. 한번도 DDD로 설계된 프로젝트를 본적이 없다.
DDD 공부하고 싶으면 Get Your Hands Dirty on Clean Architecture 보면 좋을 듯.
트렌드니까 적용한다는 이유면 안된다.
이게 우리의 플랫폼에 적용했을 때, 어떤 이득이 있는지 계산이 떨어지고, 그때서 적용해야 한다.
위에서 말했듯, 솔루션의 장단점을 명확히 판별해야 한다.
잠깐 코드리뷰 얘기
리뷰가 되기 전 코드는 merge되면 안된다는 것도 Best Practice라고 생각한다.
코드 리뷰를 게을리 하면 안된다.
그의 Lazy loading
코드 리뷰 해달라. => 테스트 코드 있어? 없으면 짜와.
테스트 코드 짜왔다. 코드 리뷰 해달라. => 빌드 깨지네? 다시 해와.
이렇게 하면 부하가 좀 덜 걸린다ㅋㅋ.
제 3원칙: 지속적으로 개발 방법과 품질을 증진시키려는 노력
문제가 발생하면, 그걸 조기에 발견할 수 있게끔 개선하면 좋다.
배포할 때까지 문제가 발견이 안됐다. -> 이건 기회다.
이 문제를 어떻게 하면 배포 전에 발견할 수 있을 지 고민해 보는 것이다.
이렇게 계속 개발 방법과 품질을 증진시키려는 노력을 하다보면 기술력이 높아진다.
제 4원칙: 기술력을 증진시킬 수 있는 방법을 적극적으로 찾기
기술 컨퍼런스를 가는 것도 좋은 방법이다.
온라인도 뭐 볼 수도 있겠지만, 온라인은 확실히 집중력이 떨어진다.
컨퍼런스의 장점은 내가 오로지 그 시간동안 컨퍼런스에만 집중할 수 있다는 것.
컨퍼런스가 진행 중인데 놀러 나가지는 말자. 컨퍼런스는 휴가가 아니다. 그리고 꼴보기 싫다.
내가 어디 갔는데, 경치가 그렇게 좋더라. 이게 컨퍼런스의 목적일까? 정신 좀 차리자.
제 5원칙: 동료 또는 다른 개발자의 기술력을 증진시키는 것을 돕기
회사에서 이메일을 쓸 때 업무 뿐만 아니라 회사에서 쓰고 있는 기술과 관련한 새로운 기술에 대한 이메일도 쓸 수 있다.
내가 그걸 블로그에 잘 정리했거나 다른 사람이 정리한 내용(내가 검증은 한번 해봐야 한다.).
아니면 컨퍼런스 소식 같은 것을 공유해 주는 것. (백기선 유튜브를 공유해도 되고ㅋㅋ)
이게 바로 나의 기술력으로 이어지게 된다.
예를 들어 리액트에 나온 새로운 기능을 공유를 한다면, 내가 한번 써봐서 검증을 해보고 공유를 할 것이다.
이러면 나의 기술력과 팀의 기술력 모두 증진시킬 수 있다.
이게 바로 주니어와 시니어의 차이가 아닐까?
