책을 잘 읽지 않는 저를 반성하면서, 올해 들어 여러 책을 읽고 있습니다.
개발자의 원칙은 누구나 들어봤을 법한 회사에서 개발을 경험하고
현재 개발 조직을 리드하고 있는 분 9명이 집필한 책입니다.
각 저자 별로 가지는 개발자 원칙을 공유하는데, 대부분 공감이 되면서도
각기 너무 다른 관점으로 원칙을 가지고 있습니다.
예를 들어, 한 분은 디버깅 과정에서 원본 라이브러리를 뜯어보고 이해해서 PR을 올리는 걸 권합니다.
이 과정에서 많은 것을 배운다고 하죠.
또 다른 한 분은 “전문가가 되기 위해서 필요한 것은 어떤 것일까”라는 질문으로
태도에 관한 얘기를 하기도 합니다.
아마 집필하신 분들 모두 원칙이라고 정리하지 하지 않았더라도,
마음속 수많은 조건문이 있었을 거라고 생각합니다.
저 또한 마찬가지입니다.
마음속으로 수많은 조건문이 있습니다.
태도와 관련된 것도 있고, 성장하는 방법에 대한 생각도 어느 정도는 정해져있습니다.
이 책을 읽고 원칙을 정해보는 것도 좋을 것 같다고 생각했습니다.
LAH는 개발자가 많지 않은 스타트업이기 때문에, 저의 원칙과 방향이 개발팀에 영향을 끼칠 수 있어
더더욱 필요하다고 생각했습니다. 물론 팀의 원칙은 다른 얘기지만요.
다만, 미리 안전장치를 달자면.. 저도 성장하는 과정이기에 바뀔 수는 있겠죠..^^…
책에서 나온 많은 내용 중에 v0.3.0 개구리를 해부하지 말고, 직접 만들기 부분이 많이 공감됐습니다.
사실 소제목은 이렇게 썼지만, 실제 내용은 해부도 하고 만들기도 하라는 얘기입니다.
작년까지의 저는 온전히 저 소제목과 같이 일단 프로젝트로 만들면서 학습한다는 원칙이 있었습니다.
그랬던 이유는 라이브러리를 전부 뜯어보면서 학습하거나, 혹은 강의를 듣거나 책을 보면
내가 아는 내용과 모르는 내용을 같이 봐야 해서 답답하다고 생각했기 때문입니다.
지금도 사실 비슷하게 생각은 하지만, 최근 많은 개발자분들을 만나고 자료도 보다 보니,
조금 더 라이브러리 (또는 프레임워크)를 조금 더 원리와 내부 코드 중심으로
학습해야겠다는 생각을 하게 되었습니다.
그래서 정리해 보면, 저의 원칙이라고 하면
직접 만들면서 공부하고, 문제 해결은 코드와 레퍼런스 문서로 하기.
정도가 되겠네요.
프로젝트에 라이브러리나 프레임워크를 사용하다 보면 당연히 문제를 직면할 때가 있습니다.
기존에 사용해왔던 환경에서 문제를 직면하면, 당연히 같은 경험을 했던 개발자로부터 도움을 받습니다.
스택오버플로우가 대표적이죠.
하지만, 아직 내가 이 라이브러리나 프레임워크를 공부해야 하는 단계이고 온전히 이해를 못 했다는
생각이 있다면 문제를 만났을 때 라이브러리와 프레임워크가 제공하는 에러 메시지와 문서를 통해서
직접 문제를 확인하는 것이 필요하다고 생각했습니다.
가끔 제가 스스로 느끼는 부분 중에, 어딘가를 빠르게 가기 위해서 편법을 사용하다 보면 결국 정공법(?)이 가장 빠르다는 것이 있습니다.
하지만 작은 스타트업 조직에서 편법이나 지름길을 어쩔 수 없이 가야 할 때가 있는데,
앞서 말씀드린 원칙이 이러한 부분을 타협할 수 있으면서도 꽤나 (저에게) 합리적인 원칙이라고 생각합니다.
이러한 저 개인의 원칙이 팀에 어떤 영향을 줄지 조심스럽지만,
팀의 원칙은 또 다른 얘기니까, 팀원들과 조율해가면서 계속 나아질 거라고 기대합니다 🙂
