내 코드가 그렇게 이상한가요

독서 기간

2023.08.12~2023.09.25

독서 모임

2023.09.26

 

간만에 책을 읽었다.

회사 큰 칭구와 다른 칭구와 같이 읽고 독서모임 하기로 해서 다 읽고 같은 책을 읽은 칭구와 이야기를 나눴는데 정말 잘한다.

어린이 때 독서 토론을 다녔다고 한다.

나도 독서 토론 하는 법을 배워야겠다.

 

독서 모임 소감 정리

어휴 리팩토링 파트는 우현하게도 현재 리팩토링 작업을 진행하고 있는 나의 업무와 연관이 많구나

 

덕분에 가이드도 몇가지 얻엇다.

1. 논리 부정 연산자도 !도 자주 사용하고 있었지만 굳이 메서드로 한번 분리해서 더 가독성잇게 더 친절하게

!customer.isEnabled -> customer.isDisabled()..

 

2. 리팩터링 작은단위로 실시하기. 커밋은 어떻게 리팩토링 했는지 차이를 알 수 있는 단위....

단위가 작은게 좋다는건 늘 알고 있지만 다시 한번 찍어주니 현재와 오버랩되며 반성을 하게 되었다.

커밋 몇 번하면 PR작성을 생활화

 

3. 변경을 빠르게 할 수 있으면 소프트웨어의 가치가 빠른 속도로 높아집니다. 소프트웨어가 성장하는 것입니다.

이것이 애자일의 가치와 연결 되는 것이었을까

 

4. 마이너스가치 버그 기술 부채 -> 이상적 설계와 현재 설계를 비교하여 기술부채를 인식한다.

 

5. 나 혼자만이 설계에 중요성을 가질 때 영향력을 갖는 규모까지 동료를 모아라 -> 쿠프만 목표치 -> 10.9% 

 

6. 설계에 베스트는 없습니다. 항상 Better를 목표로 할 뿐입니다.

 

 

실제 방법을 사용하곤 있지만 용어를 모르고 있는 부분도 있었는데 이런 용어를 집어준 내용도 종종 있어 도움이 되었다.

1. 스크래치 리팩토링

-> 사양을 잘 모를때, 테스트 코드 작성하기 어려울 때 리팩토링을 위한 방법 문서화 테스트

 

2. 변경용이성은 미래의 사양 변경 시 비용을 절감하는 품질. 사양변경도 없는데 비용 들여 변경 용이성 늘이는 것은 낭비.. 비용대비 효과가 높은 부분을 노려라 고로 gov는 고쳐야한다

 

 

책을 읽고 이해는 되지만 이상적 말고 현실적 답변을 아직 내지 못한 부분도 있다.

생선성 나쁨 Start

-> 새기능 릴리즈 오래걸림

-> 수익 내기 힘듬

-> 성과 엄씀

-> 따라서 릴리즈 기일 맞추기 위해 어떻게든 일단 작동하게 만들어냄 구현 수정

-> 어쨋거나 열심히 일했다

-> 생선성 나빠 결과 안남

-> 성과 안남 열심히 일했다고 말할 수 있으까?

어떻게 해야할까?? 일정을 미뤄야하는가 죽이 되든 밥이 되든 밤을 새서라도 깔끔하게 짜야하나 적당한 타협이 필요한가

최선의 정답은 있다. 일정이 밀려도 무리가 없을 정도로 사전 공지 후 미룸. 어느정도의 생산성이 보장이되는 개발 완료. 이게 이상적인건 너무나도 당연하다

하지만 이상적말고 현실적으로 아직도 무엇이 정답인지는 모르겠다. 늘 개발하면서 느꼈던 부분인데 더 좋은 정답은 없는건감..ㅎㅎ

그렇다면 이해는 하지만 재미가 없다.

 

 

 

공감 되고 재미 있었던 부분

 

1. 기술부채가 예산 10분의 일정도의 수준이나 된다고 함

꽤나 높은 것인가 낮은 것인가

 

2. 엔지니어에게 자산은 기술력입니다. 레거시는 자산의 축적, 기술력의 성장을 방해하는 무서운 존재다 -> 레거시는 다음 사람으로 하여금 레거시를 작성하게 함

ㅋㅋ신입사원과 선배 사원의 사연 사람 사는거 다 똑같구나

 

3. 커뮤니케이션

심리적 안정성 커뮤니케이션에 문제가 있을때는 일단 심리적 안정성 향상에 힘을쓰라

요즘 일보다도 커뮤니케이션이 참 어렵구나라는 생각을 많이 하게 되었는데 책에서 얘기하던 내용들도 도움을 받았던것 같았다.

 

4. 설계 / 개발 시 

- 클래스 설계와 구현 피드백 사이클 돌리기 사양 변경시 최소한 메모로라도 클래스 다이어그램 그리고, 책무 응집도 등의 관점에서 문제가 없는지 팀 리뷰 후 구현 시작 구현중 이슈들 발견. 이때마다 다이어그램에 반영 -> 설계 품질 향상

- 설계규칙을 만들 때 다수결 보다는 시니어 엔지니어처럼 설계 역량이 뛰어난 팀원이 중심이 되어 규칙을 만들어라

ex) 중첩 3미만, 같은 조건분기 여러번 -> 인터페이스, 메서드 클래스 이름 목적 표현 ...etc

 

5. 기존의 코드를 믿지 말고 냉정하게 파악하라. 레거시를 박멸하려면 기존의 코드를 맹신하지 않는 마음가짐이 중요하다.

 

 

책을 읽고 전반적으로 느꼈던 부분은

일단 앞 부분보단 뒷 부분이 더 재미있었다.

원론적인 설명은 여기저기서 많이 보기도 듣기도 했고,  현재 업무랑 엮이고 약간의 조언적 파트가 개인적으로는 좀 더 흥미가 있었다. 책에게 가끔 뼈도 맞고 잘하고 있구나도 있고 공감도 있고 조언도 얻었고(16.2)

하지만 2회독보다는 다른 비슷한 유형의 책이 많을테니 세로운걸 읽으면서 동일한 개념 다시 한번 복기하도록 해야겠다.

 

그리고 책읽으며 고쳐야할 점 

밑줄은 핵심만 간단히! 

죄다 중요하고 죄다 다시보고 싶어 밑줄을 죽죽 긋는데.. 결국 다시보기 더 힘들다. 핵심만 간단히~