신입 개발자 생존의 기술

https://kjw1313.tistory.com/51

신입 개발자 생존의 기술, 사회 초년생 개발자를 위한 안내서

1. 코드 품질을 보증하는 여러 가지 방법들이 나온다.   => 다른 프로그래머가 코드를 읽어보게 하거나, 단위 테스트, 부하 테스트 등 여러 가지 방법론을 통해 검토하는 방법이 있구나 알게 됐다.     2. 순수 코드와 순수하지 않은 코드를 떼어내는 일은 새로운 코드의 정확성을 테스트할 때도, 유지 보수 중인 레거시 코드의 정확성을 테스트할 때도 도움이 된다. 로직을 더 큰 코드의 본문에 넣기보다는 분리하는 것이 테스트하고 엄격히 증명하기에 훨씬 더 쉽다.    => 긴 코드는 이해하기 쉽게 함수로 나눠야겠다는 깨달음을 줬다.      3. 사람이 읽을 수 없는 코드는 유지 보수가 불가능하기 때문이다.    => 유지보수를 위해 기업의 스타일 가이드에 따르거나, 변수나 클래스 등에 왜 이름 짓기가 중요한지 알게 됐다.      4. 여러분이 사용하는 언어를 위한 스타일 가이드를 찾으라. 각 규칙에 대한 이유를 설명하는 가이드면 더 좋다. 규칙 대부분이 버그를 줄이거나 가독성을 향상하려는 목적이 있다. 규칙보다 그 규칙이 만들어진 이유에 집중하라.   => 회사는 협업이 필수이기 때문에 균일한 스타일 가이드가 중요한 걸 알게 됐다. 구글 자바 스타일 가이드를 한 번 봐야겠다.     5. 이상한 것들을 수정하려고 해선 안 된다고 하는 것은 아니다. 어떤 분명한 이유 때문에 코드가 이상할 수도 있다고 의식하고 있어야 한다. 멘토나 선임 프로그래머에게 물어보라. 최소한, 체크인 코멘트에 변경 사항을 기록해 두라.   => 내가 보기에 뭔가 이상한데 바꾸면 뭔가 싸한 기분이 들면 반드시 선임 프로그래머에게 바꿔도 되는지 물어봐야겠다.     6. 코드 리뷰를 피고인이 되는 재판이 아니라 공개 토론처럼 코드 검토를 받아 들어라.   => 코드 리뷰를 두려워하기보다는 나 자신의 잘못된 스타일을 고칠 수 있다는 자리로 생각해야겠다.     7. 어떻게 하면 한 줄 한 줄 검토를 피할 수 있을까? 쉽다. 코드를 일찍 자주 검토하라.   => 코드 리뷰 전에 먼저 잘못된 스타일이 있는지 확인하고, 그다음에 선배 프로그래머에게 검토를 받아야겠다.     8. 제품 코드는 지나치다 싶을 정도로 주의해야 한다. 개념을 증명할 때에도 지나칠 정도로 완벽해야 한다.   => 스스로에게 물어봐서. 이 가정들을 어떻게 해야 할지 자문자답해야겠다.      9. 코드를 다른 사람이 봐주기를 원할 때 부끄러워 말고 요청하라. 경험 많은 개발자는 언제나 검토해 준다. 신입 프로그래머가 검토를 요청하지 않는다면 문제가 자라나고 있다는 확실한 신호다.   => 혼자 코드를 개판 치기 전에 내가 올바른 길로 나아가고 있는지. 선배 프로그래머에게 코드 검토를 요청해야겠다.     10. 언어 또는 언어 관련 기술을 진정 잘 쓸 수 있는 수준이 되려면 1만 시간 정도는 들여야 한다. 지름길은 없다. 적어도 한 가지만은 1만 시간 넘게 익혀야 한다.   => 조급해하지 말고, 꾸준히 한 가지 언어를 계속 단련해야겠다.     11. 첫째, 한 언어에 대한 좋은 책이 있다면 그 책부터 시작하라. 둘째, 해당 언어로 작성된 오픈 소스 프로젝트를 찾아 공부하라.    => 회사에 다니더라도 내가 할 수 있는 언어의 오프소스 프로젝트에 참여해야겠다.      12. 모든 것을 혼자 할 필요는 없다. 관리자와 일대일로 만나는 정기적인 시간을 내려고 노력하고, 조언을 구하는 데 부끄러워하지 말라.    => 나 혼자 끙끙 앓는 것보다 관리자를 만나서 대화와 조언을 얻는 시간을 가져야겠다.      13. 멘토는 여러분이 성공한다고 해도 아무것도 잃을 게 없는 사람이어야 한다. 뭔가를 배워갈 수 있는 사람인지 반드시 확인하라. 멘토의 핵심 역할은 기록되지 않은 지식을 알려주는 것이다. 훌륭한 멘토는 그 조직에 오래 있어서, 회사 내 정치적인 관계에 대해 알며 팀과 회사 양쪽에서 인정을 받는 사람이어야 한다.   => 빠른 성장을 위해 멘토의 필요성을 느꼈다.       14. 멘토를 찾으라! 다른 방법이 없다면 비공식적으로 시작해도 괜찮다. 그러나 가급적이면 1년 넘게 공식적인 멘토 없이 지내지는 말라.    => 책의 저자가 이 말을 할 정도면 정말 멘토를 구해봐야겠다.     15. 회사의 코딩 스타일을 완벽하게 따르며, 기능성을 증명할 단위 테스트를 짜고, 정말 잘 만들어서 빨리 전달하라.   => 이 책의 주제가 담긴 문장이다. 회사에 주목받고 싶으면 코딩 스타일과 단위 테스트가 중요하다는 걸 강조한다.     16. 신입 개발자가 할 수 있는 가장 중요한 일은 몸을 낮추고 자신에게 주어진 일을 해내는 것이다. 회사의 건의 사항은 최소 한 번의 평가 주기를 겪은 후로 아껴두라.   => 항상 겸손하고 주어진 일은 무조건 한다는 마인드로 회사를 다녀야겠다.     17. 모든 관리자는 직원들의 등급을 매기는 것을 몹시 싫어한다. 관리자는 끝내주는 팀원들을 고용하려고 엄청나게 노력하는데 인사 팀에서 와서는 팀에 분명 게으름뱅이 몇 명이 있을 것이라고 주장하기 때문이다.   => 처음 안 사실이다. 윗사람이 평가하라 해서 관리자가 마지못해서 평가했었다니...     18. 신입 사원은 일을 완성하는 데 경험이 많은 개발자보다 시간이 더 많이 필요함을 인정하라. 방향을 완전히 잘못 잡는 일도 더 많을 것이고, 더 많은 실수를 할 것이고, 디버깅하는 데 시간을 더 많이 쓸 것이다. 그렇게 배워가는 것이고, 시간이 걸릴 수밖에 없다.   => 성장에는 편법이 없다. 많은 삽질을 통해 성장해 나가야겠다.     19. 항상 큰 프로젝트 중심에 있고 일주일 쉬면 뒤처질 것 같다는 생각이 든다. 솔직하게 얘기하면, 휴가 내기에 좋은 때는 없다. 그냥 가라.   => 스트레스 관리를 위해 푹 쉬는 것의 중요성을 알았다.     20. 세상에는 모든 일을 혼자서 해낼 줄 아는 개발자도 있다. 그러나 대다수 개발자는 다른 사람들과 어울려 지낼 필요가 있다.    => 나의 성향을 인정하고 회사 내에서 교류하는 방법이 적혀있다.      21. 내향적인 사람들과 외향적인 사람들은 서로의 장점을 인정할 경우에 같이 잘 지낼 수 있다.   => 그 사람의 성향을 이해하고, 잘 지내도록 노력해야겠다.     22. 완전 엉망이고, 아무도 건드리고 싶어 하지 않는 일이야말로 파고들어서 점수를 딸 수 있는 기회다. 귀찮고 어려운 일들을 맡는다는 것은 자신의 전문성을 키우는 것과 동시에 팀에서 신뢰도를 높이는 방법이다.   => 기피하는 일이 있으면 내가 먼저 나서서 해보겠다는 자세가 중요한 것 같다.     23. 어느 문제에 도전했는데 도저히 풀 수 없을 때가 있다. 괜찮다. 누구한테나 일어나는 일이다. 다른 개발자와 짝을 이뤄 다시 시도해보라. 대부분의 경우에 다른 사람의 눈과 신선한 시각이 필요한 돌파구를 제공한다. 하고 있는 일에 대해 경험이 있는 사람을 찾아보라. 절대 하지 말아야 하는 것은 도움을 청하지 않고 혼자서 헤매는 일이다. 아무리 해도 풀리지 않는다면 그때는 다른 사람이 같이 봐줄 타이밍이다.   => 어려운 문제가 있고, 도저히 못 풀 것 같으면 혼자서 헤매기보다는. 이 일에 경험이 있는 사람에게 조언과 방향성을 반드시 물어봐야겠다.     24. 동료가 집중하려고 노력하는 것처럼 보인다면 그를 귀찮게 하지 말라. 작업 공간 문이 닫혀 있고 헤드폰을 쓰고 있는 모습으로 그런 신호를 알아차릴 수 있을 것이다.   => 바쁜 사람에게 타이밍 맞지 않게 도움을 요청하지 말아야겠다.     25. 책에서는 회사에 다양한 직책과 포지션을 알려준다. 아키텍트, 테크 리더, 관리자 등의 프로그래머뿐만 아니라 마케팅, 고객 지원 등에게도 대화를 나눠보라고 조언을 해준다.     26. 단지 기능에 대해서만 이야기하지 말고, 고객과 그들의 요구 사항에 대해서도 이야기하라.   => 단지 소프트웨어의 성능과 기능에만 몰두하지 말고, 다양한 직책(개발자 이외)과 대화하며 그들에게 피드백을 얻어야겠다.      27. 유지 보수는 새로 채용된 사람들에게 흔히 주어지는 훈련 분야다. 버그가 일어나면 문제를 설명하면서 자세히 적어두라.   => 버그가 발생할 때마다 버그에 대한 문제 분석과 수정 사항에 대한 해설을 반드시 메모해둬야겠다.      28. 자신의 제품이 어느 단계인지 알아보려면 상사나 제품 관리자와 이야기해 보라. 자신의 적절한 역할도 다시 확인해 봐라.   => 회사에 취직하면 자신이 무엇을 맡게 되고, 무엇을 해야 하는지 물어봐야겠다.     29. 계속 공부하는 것은 자기 몫이다. 변화하는 업계에서 스스로를 가치가 높도록 유지하는 것이지만 사실 학습 능력을 유지하는 것이 가장 큰 목표다.   => 변화하는 개발 세상에서 살아남으려면 꾸준한 공부는 필수라고 본다.     30. 오픈 소스 프로젝트는 확실히 기술을 구축하지 못한 상태로는 프로젝트에 뛰어들기 어렵다. 그렇지만 초보적 기술 수준으로도 문서 작성 같이 기여하는 방법을 찾을 수 있다.    => 오픈 소스를 나와 먼 이야기라 생각하지 말고. 작은 일이라도 할 수 있는 오픈 소스 프로젝트를 찾아봐야겠다.