유지보수하기 좋은 코드를 구현하는 개발 문화 어떻게 만들 것인가?

사내 강연으로 포비(자바지기 박재성)가 오신다고 해서 참석 후 내용을 정리해보았다.
코드스쿼드 이후로 회사에서 뵈니까 신기한 기분이었다.

변화는 어떻게 만들 것인가?

어떻게 하면 내가 원하는 개발 문화를 만들어 갈 것인가?

1. 개인
2. 개인 (팀원 또는 주니어) -> 팀
3. 개인 (리더 또는 시니어) -> 팀

개인의 변화는 어떻게 만들 것인가?

• 의지력에 의존하는 것이 아닌 환경을 만들어라
  • 우리들이 가진 의지력에는 한계가 있다. 의지력에 의존하는 대신에 환경을 바꿔라.
  • 도서 추천
    • 해빗 - 핸디 우드 지음
    • 최고의 변화는 어디서 시작되는가
  • 주변 상황을 정리해 꾸준히 지속할 수 있는 환경을 구축
    • 꾸준히 학습에 투자하고 싶다.
      • 퇴근 후 스터디 카페로 퇴근한다.
    • 스마트폰 보는 시간을 줄이고 싶다.
      • 퇴근 후 스마트폰을 꺼놓는다.
    • 인스타그램과 같은 SNS 에 투자하는 시간이 많다.
      • 스마트폰에서 앱을 삭제한다.
    • TV를 보고 싶지 않다.
      • TV를 창고에 처박아 둔다. 리모콘을 버린다.

의식적인 연습

유지보수하기 좋은 코드를 구현하는 좋은 습관 중의 하나는 테스트 주도 개발 (TDD)
TDD 를 잘 하려면… 연습, 연습, 연습 ..?

무조건 연습을 많이 한다고 잘할 수 있을까?

프로그래밍 10년하면 10년 만큼의 역량이 쌓일까?
칫솔질을 30년 한다고 30년 만큼 칫솔질이 향상될까?

현실에 안주하는 순간 성장은 정체된다.

TDD 관련해 5, 6 년을 도전한 후에야
테스트하기 쉬운 코드와 테스트하기 어려운 코드를 보는 눈이 생김.

도서 추천

• 1만 시간의 재발견
  • 나의 역량을 끌어내려면 의식적인 연습을 해야한다.

의식적인 연습의 7가지 원칙

1. 효과적인 훈련 기법이 수립되어 있는 기술 연마
2. 개인의 컴포트 존을 벗어난 지점에서 진행. 자신의 현재 능력을 살짝 넘어가는 작업을 지속적으로 시도
3. 명확하고 구체적인 목표를 가지고 진행
4. 신중하고 계획적이다. 즉 개인이 온전히 집중하고 의식적으로 행동할 것을 요구
5. 피드백과 피드백에 따른 행동 변경을 수반
6. 효과적인 심적 표상을 만들어내는 한편으로 심적 표상에 의존
7. 기존에 습득한 기술의 특정 부분을 집중적으로 개선함으로써 발전시키고 수정하는 과정을 수반

의식적인 연습으로 효과적으로 연습하자.

회사에서 의식적인 연습?

• 이건 연습이 잘 안된다.
• 개발 후 바로 서비스로 나가야 함
• 개발 중 다른 업무요청이 급하게 들어오는 등..

이런 문제로 의식적인 연습은 근무 외의 시간에 하는게 맞다.

의식적인 연습으로 메소드 분리 연습

• 메서드가 한 가지 일만 하도록 구현하기
• compose method 패턴 적용
  • 메서드의 의도가 잘 드러나도록 동등한 추상화 레벨을 맞춰라

한번에 모든 원칙을 지키면서 리팩토링하려고 연습하지 마라.
한번에 한 가지 명확하고 구체적인 목표를 가지고 연습하라.

클래스 분리 연습을 위해 활용할 수 있는 원칙

• 모든 원시값과 문자열을 포장한다.
• 일급 콜렉션을 쓴다.
• 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
• 함수의 인자 수를 줄인다. 3개 이상은 가급적 피한다.

메서드 분리 연습 -> 클래스 분리 연습

도서 추천

• 엘레강트 오브젝트

변화를 시도할 때 생각해 볼 점

• 사람은 기본적으로 변화를 거부하는 성향이 있다.
• 팀은 변화를 거부하는 성향이 더 강함.
• 대부분의 사람들은 변화에 실패한 경험을 가지고 있음.

=> 다른 사람에게 전파하지 말고 묵묵히 나혼자 변화를 시도한다.
그 후 나에게 관심있는 사람이 생기면 전파한다.

리더가 하지 말라고 하면 TDD 또는 리팩터링 적용을 그만둔다.

• “너 뭐하는거니? 다 분리해버리면 읽기 어렵잖아.”
• -> 회사도 그만둔다.
  • 나는 많이 성장했기 때문에 갈 곳은 많다.
  • 걱정하지 마라. 절대 손해 보는 장사 아니다.

내가 구현한 코드 또는 동료의 관심에서 작은 성공 (small success) 을 맛본다.

레이어드 아키텍쳐

비즈니스 로직은 어디에 있는게 좋을까?
-> 도메인 영역

• 서비스 레이어에 비즈니스 로직이 있으면.. 비즈니스로직 + DB 로직이 같이 있어 테스트하기 어려워진다.
• 비즈니스 로직을 도메인에 넣으면 테스트하기 수월해진다.

서비스 레이어의 비즈니스 코드를 도메인 레이어로 옮기는 방법

수정 후 기도하기 VS 보호 후 수정하기

이것만 잘해도 TDD 하기가 수월해진다.
즉, 유지보수하기 좋은 코드가 된다.
서비스 레이어에 비즈니스 로직이 있다면 테스트하기가 어렵고 꺼려진다.
Mock 프레임워크 없이 테스트하는 것이 잘하는 개발자라고 생각한다.

리더 또는 시니어로서 만들고 싶은 개발 문화

지식을 공유하고, 같이 성장하면서 유지보수하기 좋은 코드를 구현하는 팀을 만들고 싶다.

팀의 변화를 만들려면 어디서부터 어떻게 시작하면 좋을까?

개발자의 역량을 키우고, 소스 코드 품질을 유지하기 위해 온라인 코드 리뷰와 짝 프로그래밍을 팀의 문화로 정착시키고 싶다.
-> 아웃사이드 인 접근 방식
* 외부에 어딘가에서 잘 되는 방법을 가져와서 적용시키려고 함
* == 실패의 지름길

팀을 어떻게 변화시킬 것인가?

리더가 되면 변화를 만들기 더 어렵다. (일단 리더가 뭐 하자고 하면 다 싫어함)

인사이드 아웃 접근 방식 (팀원들의 의견을 통해서 변화를 만드는 방식)

심리적 안정감을 만들며, 문화 만들기 시작

팀원들과의 신뢰 형성이 우선 (1:1 면담)

• 1:1 면담에서 한 가지만 기억하자.
• 문제점에 대한 해답을 제시하려하지 말고, 어떻게 하면 될까?, 너라면 어떻게 할 것 같아? 라는 반문을 통해 팀원들이 해답을 제시하도록 하라.
• 1:1 면담(코칭)에 관심이 있다면 ‘성과 향상을 위한 코칭 리더십’ 책을 꼭 읽어보기

한번에 한 가지에 집중하는 것이 문화(변화)를 만드는 가장 빠른 길이다.

새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심과 용기

• 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하
• 안정화하는 최소 1년 이상의 시간을 투자해야 한다는 마음으로 믿고 기다려주어야 함.

중요한 것은 어떤 Practice를 적용하느냐가 아니다.
현재보다 조금씩 나아지고 있다는 방향성이 중요하다.

문화를 만들고, 변화를 만드는 일은 리더만의 책임이 아니다.
누구도 대체할 수 없는 존재로 만들고 싶다면 지금 당장. 바로 도전하라.

실패해도 괜찮다

실패하기 전보다는 나는 한 단계 성장한다.
좋은 회사는 실패해도 같이 도전하는 사람을 원한다.
실패의 책임을 묻는다면 그만둔다.

가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기

Q & A

• 리더가 변하려고 하지 않는다면?
  • 우리가 부딫치는 문제들을 해결하려고 시도해보고 나서 그래도 안된다면
  • 그만둔다.
• 업무와 리팩토링 중 어떤게 더 중요할까?
  • 당연히 업무가 더 중요하다.
  • 데드라인 때문에 쓰레기 코드를 만들었다면, 일정이 끝나면 역량을 통해 리팩토링하는 시간을 확보해야한다.
  • 전문가의 입장에서 설득도 해야한다. (향후 유지보수를 위해서 리팩토링 일정도 잡아야한다)
• 코드 작성 시 유지보수를 위해 가장 고려하는 부분은 무엇일까?
  • 읽기 좋은 코드를 만드는 것
• 어드민 위주의 개발만 하는데 트래픽이 많은 서비스의 경험이 없는데 어떻게 해소할 수 있을까?
  • 리더가 해야할 역할이라고 생각한다. 이슈 제기를 하거나 전배를 하거나.. 리더와 고민 상담을 해야한다.
  • 관점을 바꿔서 꼭 대용량 트래픽의 경험이 1순위가 아닐 수 있다. 기존에는 시키는 일만 했다면 내 주도하에 최신 기술을 투입해서 새로운 방향으로 성장하는것도 좋을 것 같다.
  • 정 안된다면 이직을 해야한다.