최근 트위터에서 많은 개발자 분들이 보시기도 하고 리디 북스 내에서 책 순위도 높았던 육각형 개발자라는 책을 보게 되었다.
해당 책을 보면서 느꼈던 점들에 대해서 리뷰 글로 남겨보려고 한다.
10가지 역량
시니어 개발자로 성장하기 위한 10가지 핵심 역량
위 책은 훌륭한 시니어가 되기 위해서 10가지 핵심 역량을 갖춰야 한다는 것으로 시작한다.
그중에서 공감이 됐고 좋았던 챕터들만 간단 요약하며 해당 책에 대한 마지막 리뷰 문장을 작성하면서 끝맺음하려고 한다.
유지 비용 낮추기
개발자라면 유지보수를 피해 갈 수는 없다.
유지보수 비용이 아에 발생하지 않을 수는 없으며 해당 비용을 최대한 줄이는 방식으로 개발을 진행해야 한다.
결국 유지보수 비용이 적게 들려면 코어는 두가지라고 생각한다.
1. 변경으로 인한 영향에 범위를 줄이는 것.
2. 코드 동작 방식을 이해하기 쉽게 만드는것.
위 두 가지를 중점으로 유지보수 비용에 대해 고민하고 코드를 짤 것을 권장한다.
코드 이해영역에 대해서는 요즘 읽기 좋은 코드가 좋은 코드다 를 다 읽었고, 내 코드가 그렇게 이상한가요 라는 책을 시작했기 때문에 리더블한 코드에 대해서 크게 도움이 되지는 않았으나 많은 공감이 되는 부분이었다.
코드 이해의 시간을 줄이는 법
시각화 UML을 활용할 것을 추천한다.
실제로 UML을 많이 활용하고 있으며 notion과 옵시디언에서 임베딩이 되는 mermaid를 잘 활용하고 있기 때문에 끄덕끄덕하면서 넘겼던 것 같다.
코드가 길다면 출력해서 보는 것을 권장하는데 해당 방식도 한번 해보도록 해야겠다.
이해하기 좋은 코드, 응집도, 결합도
해당 책은 리더블한 코드와 응집도와 결합도에 대해서 다루기는 하지만 깊이 있게 많은 상황에 대해서 다루지는 않고 설명하고 약간의 예제를 보여주는 방식으로 진행한다.
해당 주제로 학습을 하려면, 클린 코드, 읽기 좋은 코드가 좋은 코드다 , 조용호 님의 오브젝트 등 별도의 책을 참조하는 게 더 좋아 보인다.
리팩터링
해당 항목도 위항목과 합칠 수 있는 부분이지만 몇 가지 내용에 크게 공감을 해서 적어두었다.
1. 레거시란 수정하기 어려운 코드는 전부 레거시이며 리팩터링은 기존 동작을 그대로 유지하되 내부 구조를 바꾸는 방법이다.
2. 리팩터링을 할지 MSA로 분리를 할지 고민해 보자.
2번은 좀 조심해야 한다 해당 서비스 크기와 실제 사용되는 리소스를 확인하고 MSA로 확장하는 방식을 고려해야 한다 아니면 유지보수와 복잡도만 증가한다.
해당 주제에 대해서는 예전에 한창훈 님 블로그에서 정말 좋은 글을 본 적이 있어서 링크를 걸어 둔다.
이전 팀에서도 규모와 비즈니스 모델에 맞지 않은 MSA 구조를 진행한 적이 있었으며 해당 제품을 유지보수하는 과정에서 상당 부분 리스소가 들었고 힘들었던 경험이 있어서 손뼉 치면서 본 기억이 있다.
https://shirohoo.github.io/diary/2022-10-19-diary-46/
대기업들이 시장에 MSA라는 독을 풀었다
대부분의 기업들에게 MSA는 신기루와 같다. MSA에서 모듈형 모놀리식 아키텍처로의 전환 이유.
shirohoo.github.io
테스트
자동화된 테스트 자체를 회귀 테스트로 활용 가능하며 코드 변경에 대한 스트레스를 줄여 준다.
TDD와 테스트의 중요성에 대해서 알려준다.
나도 주니어지만 개발을 시작하는 분들이 보면 좋을 정말 좋은 부분은
개발 시간 -> 코드 작성시간, 테스트시간, 디버깅 시간
개발시간에 대한 정의이다.
구현 및 통과 : 구현 시간 감소, 즉각적 테스트로 디버깅 시간 감소
리팩터링 : 미래 코딩 시간 감소
테스트 코드 작성 : 테스트 시간 감소
나는 코드 작성시간 즉 구현 시간에 대해서 줄이려고 많이 노력을 하나 사실상 테스트 시간과 디버깅 시간에 대해서 줄일 생각을 크게 하지 않았던 것 같다.
테스트와 디버깅 시간을 줄이는 부분에 대해서 다시 한번 생각하게 되었고 지금은
https://product.kyobobook.co.kr/detail/S000001805070
단위 테스트 | 블라디미르 코리코프 - 교보문고
단위 테스트 | 소프트웨어 개발에 있어 단위 테스트는 이제 선택이 아니라 필수가 됐다. 단위 테스트에 대한 오해를 바로잡고, 올바른 단위 테스트에 대한 원칙, 테스트를 작성하는 스타일과 효
product.kyobobook.co.kr
위 책을 보면서 단위테스트에 대해서 다시 학습하고 있다.
Csharp 코드이나 Java를 할 줄 안다면 사실 크게 문제없이 볼 수 있으며 챕터 3장도 보고 있는데 책이 매우 좋다.
아키텍처
아키텍처를 결정하는 요인은 크게 2가지이며
기능 요구사항, 품질 속성(비기능 요구사항)이다.
사용성이 크지 않은 경우에 덜컥 MSA로 설계할 필요가 없음.
모놀리식으로 시작 -> 하드웨어 스펙 업 -> 이후 확장
모놀리식에서 기능단위로 분리 후 점진적으로 디비를 분리하는 식으로 기능단위로 분리해 보자.
매우 매우 공감했다.
모놀리식으로 시작해서 해당 서비스가 구동되는 하드웨어 리소스를 늘려서 스펙업 즉 스케일 업을 먼저 진행한 뒤 스케일 업으로도 벅차게 된다면 분산처리를 최대한 활용해 보고 그거마저도 안된다면 MSA 환경을 도입하는 방식이 좋은 방식의 서비스 확장 방식 같다.
그렇지 않고 사용성도 적은 상황에서 무턱대고 MSA 구조로 실행을 하게 되는 경우 복잡도와 유지보수는 물론이거니와 실제 사용되는 사용비용도 감당하기 힘들 수도 있다.
리더와 팔로워
MOI 모델
Motivaion, Organization , Idea innovation
리더 연습하기.
규모의 비경제 이해하기.(브룩스의 법칩)
"기한을 지키기 위해 프로젝트에 인력을 더 투입하면 오히려 지연될 것이다"
아직은 3년 차가 안된 개발자로서 일정에 있어서 개발과 유지보수를 진행하다 보니 리더로서 무언가를 생각해본 적이 크게 있지 않았다.
하지만 책을 보면서 어떤 부분을 짚어야 할지 다시 한번 생각해 보는 좋은 계기가 된 것 같다.
리뷰
코드 리팩터링과 리더블한 코드들에 대해서는 별도의 책을 참조하는 것이 좋은 것 같으나 여러 부분에 대해서 리마인드 해주고 작가분의 실제 경험담을 통해서 시니어로 가기 전에 눈여겨보면 좋은 부분들을 잘 짚어주는 참 좋은 책인 것 같다.
특히나 회사에 입사한 지 얼마 되지 않은 주니어 분들이 보시면 다방면으로 많은 도움이 되고 서비스를 만들어내는데 시야를 넓혀줄 수 있는 좋은 책이라고 생각된다.
댓글