[goorm COMMIT] 더 나은 코드를 위한 켄트 벡의 Tidy First?

요약 노트

• 유기체적 공진화

서로 상호작용하며 함께 진화하는 현상
 
 

• 리팩토링 vs 코드 정리

형태 같으나 의미, 목적 다름 (리팩토링 : 확장성, 유지보수성 등 구조 개선 / 코드 정리 : 가독성 개선에 중점)
 
structure / behavior 변경 둘 중에 하나 선택해서 하기 (동시 x)
1시간 이상 소요되면 관련해서 갈등 발생할 수도 있어 문제가 됨
 
 

• 소프트웨어 = fractal하게, 점진적으로

 
 

• 소프트웨어 = 동작(외부, 현재 가치) + 설계(내부, 미래 가치)

 
 

• 결합 ⬆️ => 변화 발생 시 예상치 못한 결과 초래

일대다, 연쇄 작용 유의해야 함
의존성이나 관계는 피할 수 없음
=> 결합도 줄이고 응집도 높이는 방법 계속 익히기
 
 

• 개발 문화 - 코딩 기술력 밀접한 연관 있음

문화가 상명하복인데 좋은 기술, 코드이기 어려움
 
 

• 낮은 결합도 (코드~아키텍처 범주)

DI (ex. 인터페이스)
Restful API
MSA 아키텍처
BFF 또는 포트와 어댑터
 
 
 

후기

가장 인상깊었고 공감갔던 소주제는 유기체적 공진화, 따로 또 같이(=낮은 결합도)였다. 

개발을 처음 시작했을 때 코드나 지식을 공유하고 함께 성장하는 분위기에 감명받았었고 지금도 너무 만족하고 있다. 현 회사에서도 부장님과 새로 알게 된 기술들이나 협업 방식들을 서로 공유하면서 많이 배우고 있다. 또 가끔 내가 기초적인 질문(ex. 프로세서..? 프로세스 아닌가요? 와 같은 ㅎ) 하면 아시는 분들은 신나게 설명하셔서 질문하는 것에 대한 두려움도 안 생긴듯 하다. 나도 새로 오신 신입 분들께 컨퍼런스나 클린 코드 팁들을 공유하고 함께 기초 cs나 도메인 지식을 학습하고 있다. 이런 경험들이 곧 유기체적 공진화의 과정 일부가 아닐까 생각이 든다.

 저번에 봤던 클린 아키텍처 관련 강연에서 결국 코드에서나 아키텍처에서나 핵심은 같은 관심사는 응집시키고 다른 관심사는 분리하는 것이라고 느꼈었다. 켄트 벡도 ’따로 또 같이‘라는 개념으로 비슷하게 말한 것을 보고 다시 한번 응집도, 결합도의 중요성을 깨달았다. 이제 알아낸 것에 멈추지 않고 실행해서 구조적으로 완벽에 가까운 서비스를 만들어보고 싶다. 마침 멀티스레드 방식을 구현하고 직접 동작방식을 체감하기 위해 채팅 애플리케이션을 만들 계획이었다. aws로 확장 가능한 아키텍처를 만들고 코드 면에서도 구조적으로 구상한 후 코딩해야겠다.