'육각형 개발자' 책에서 배운점

최근 감사하게도 출판사에서 '육각형 개발자' 라는 책을 보내주셔서 읽었습니다. 작가 본인 경험에 의해 작성된 책인지라 생각보다 제 경험과 맞닿은 부분도 꽤 있었고, 제가 이전에 가지고 있던 잘못된 개발자의 생각, 제가 생각하는 이상적인 시니어 개발자란 무엇인가에 대해 다시 한번 정리하고 확립할 수 있었던 책이였습니다. + 아..! 추가로 출판사쪽에서 책도 3권 더 보내주셨습니다. 팔로워님 분들중에 책이 필요하신 분 있으시면 댓글부탁드려요! 무료로 보내드리겠습니다 🏃🏻‍♀️(23.08.14 책 드릴 3분께 별도 연락 후 택배 배송완료!) 책 내용 중 개인적으로 인상깊었던 부분을 요약해서 공유드립니다. 🧘🏻‍♂️ 개발은 단순히 코드를 작성하거나 특정 구현 기술을 사용하는 것 '이상' 을 의미합니다. 코딩과 구현 기술은 개발의 일부 일 뿐 전부가 아닙니다. 개발을 막 시작할 무렵 프로덕트를 시작 할 때에 새로운 기술을 사용하기도 했지만, 좋은 결과로 연결되지 않고 단지 새로운 기술을 써봤다는 데 그칠 때가 많았습니다. 오히려 새로운 기술을 적용해서 유지보수를 어렵게 만들기도 했습니다. 회사 업무를 하면서 성장한다는 느낌을 받지 못한 이유 중 하나는 개발과 성장을 동일시했기 때문입니다. 코드를 작성하고 새로운 기술을 써야 개발 능력이 향상된다고 여겼기에 어느 정도 익숙해진 회사의 개발 업무로는 더 이상 성장할 수 없다고 생각했습니다. 구현 기술 외적으로도 프로젝트 일정, 요구 사항, 위험 관리 등 개발자라면 성장시켜야 할 역량이 매우 많다는 사실을 깨달았고, 이전에 내가 생각했던 개발은 전체에서 아주 일부라는 사실을 깨달았습니다. 🏋️ 어떤 기술을 학습하면 당장 현업에 쓰고 싶다는 마음은 생기기 마련입니다. 기술은 상황과 조건에 맞게 사용해야 합니다. 특히나 현업에서는 기술 도입 시 보수적으로 고민하고 다양한 부분을 신경 써야 합니다 1. 동료와 신뢰구축이 되어있는지? (기술 도입에 떼쓰는 개발자 처럼 보이진 않는지?) 2. 새로 적용할 기술에 대해 함께 논의하고 공감대를 형성할 수 있는 동료가 있는지? 3. 익숙하지 않은 기술을 적용해야 할 이유가 회사차원에서 타당한지? 4. 현재 동작하고 있는 서비스에 점진적으로 도입이 가능한지 ? (안전성 검증이 가능한지?) 5. 시장 상황을 고려했는지 ? (도입할 기술에 대해 능숙한 인력을 원활히 채용할 수 있을지?) 구현 기술을 선택할 때에는 조직 상황도 함께 고려해야 하고, 조직의 구성원이 새로운 기술을 경험할 수 있도록 시간을 주고 참여시켜야 추후 유지보수 할 때 심각한 문제가 생기지 않습니다. 🏄🏻‍♂️ 특정 기술을 사용한다고 우월해지는 것은 아닙니다. 가끔 특정 기술을 사용해야 우월하다는 생각을 가진 개발자를 마주칠 때가 있습니다. 우월함을 느끼다 못해 다른 기술을 사용하면 무시하거나 경멸하는 모습을 볼 때도 있습니다. 오래된 기술을 사용한다고 해서 열등하다고 말할 수는 없습니다. 기술은 단지 기술일 뿐입니다. 기술 적용 전략에는 유연함이 필요합니다. 🤾 유지보수만 하다보면 실력이 안 늘고 신규 프로젝트를 해야 실력이 향상된다고 생각하는 건 잘못된 생각입니다. 소프트웨어의 가치는 세상에 맞춘 변화에 있는데 그 가치를 지속하기 위해서 하는 활동은 유지보수 입니다. 유지보수를 제대로 하지 않으면 소프트웨어는 가치를 유지하는 데 어려움을 겪습니다. 소프트웨어를 출시하기 위한 개발도 중요하지만 출시한 소프트웨어의 가치를 유지하기 위한 유지보수도 중요합니다. 유지보수를 하면 소프트웨어의 운영 과정에 필요한 역량을 쌓을 수 있고, 신규 프로젝트를 진행할 때에는 새로운 기술을 적용할 수 있는 역량을 쌓을 수 있습니다. 👣 레거시는 폄하 대상이 아닙니다. 가끔 레거시 코드를 무시하는 개발자를 만날 때가 있습니다. 회사 코드가 최악이라거나 다시 만들면 그거보다 더 잘 만들 수 있다는 식으로 말입니다. 물론 틀린 말이 아닐 수도 있지만, 이런 말을 하는 개발자 중 기존 코드를 더 낫게 개선할 수 있는 사람은 많지 않습니다. 복잡하고 수정하기 힘든 레거시 코드를 만나면 당연히 투덜댈 수는 있지만, 레거시가 있었기에 서비스가 굴러가고 수익이 난 것입니다. 그리고 모든 레거시 코드는 과거에 상황에 맞는 최선의 코드였습니다. 레거시를 만났다면 "개선할 거리가 있다. 해보자!" 로 생각해보세요. 🧑‍💻 개발자는 항상 압박 속에 삽니다. 코드를 잘못 만지면 심각한 문제가 발생할 수도 있기 때문입니다. 이러한 부담을 줄이기 위해 테스트 코드를 작성해야 합니다. 테스트 코드가 검증하는 범위가 넓어질 수록 내가 만든 코드가 문제를 일으키지 않는다는 확신이 커지고 코드를 수정할 때에 안정감을 느끼게 됩니다. (+ 코드 변경에 대한 스트레스도 감소합니다.) 💆🏽‍♂️개발자는 요구 사항의 변동 폭을 줄이는데 초점을 맞춰야 합니다. 개발자는 구현한 결과물을 바꿔야 하기에 요구 사항이 바뀌면 힘들어집니다. 문서로 볼 때와 실제 동작하는 소프트웨어를 볼 때 본인이 기대한 것과 다른 지점을 발견하거나, 시간이 지나 다른 정보가 쌓이면서 처음에 정리한 내용에 오류가 있을 수도 있기에 이런저런 이유로 요구 사항은 바뀌게 됩니다. 요구 사항이 바뀐다는 사실을 인정하고 요구 사항을 대하는 방식을 바꿔야 합니다. 초반에 요구 사항을 고정하기 위해 많은 노력을 기울이기보다는 요구 사항의 변동 폭을 줄이는 데에 초점을 맞춰야 합니다. (왜 이런 요구 사항을 원하는지 이해하려는 노력이 필요합니다.) 왜 그런 요구가 생겼는지 고민하기 시작하면 구현하기 전에 이해관계자가 실제로 원하는 결과에 가까운 산출물을 얻을 가능성이 커집니다.