시니어 개발자를 위한 조언

https://product.kyobobook.co.kr/detail/S000203107475

육각형 개발자: 시니어 개발자로 성장하기 위한 10가지 핵심 역량 | 최범균 - 교보문고

구현 기술과 학습

학습 전략

• 주력 기술 먼저 (당장 또는 가까운 미래에 경제적 이익을 얻는 데 필요한 기술)
  • Java, JavaScript, SQL
  • Spring, JPA, MyBatis
  • React, Vue, Thymeleaf
  • Kafka, Redis
  • Linux
  • Nginx, Tomcat
• 시장 점유율이 높은 기술
• 대세인 기술
• 여러 기술을 꾸준히 탐색

기술 학습

• POC (Proof Of Concept, 개념 증명)
• 스터디는 이유없이 좋다
• 뉴스레터 + 블로그 = 구현 기술을 주기적으로 탐색하고 학습
• 실용주의 프로그래머 (책 추천)
• 과거에 머물지 말고 과감하게 포기하기
  • 배운 기술을 버리는 것을 아까워하지 말라

유행과 상관없는 기술 학습

• HTTP 프로토콜
• 네트워크 프로그래밍 기초
• 동시성 처리
• 프로그래밍 언어

기술을 도입할 때 신경써야 하는 것들

• 신뢰 구축
• 함께할 동료
• 타당성
  • 본인이 사용하고 싶은 욕구를 숨기고 어떤 기술이 소개하는 장점만 내세워 이 기술을 도입해야 한다고 주장하지 말것!
  • 답이 아닌 질문 따라하기 → 사용한 기술 말고 사용한 이유 따라하기
• 점진적 적용
• 시장 상황 파악
• 주의 사항
  • 특정 기술을 사용해야 우월하거나 오래된 기술을 사용한다고 열등하다고 할수 없다
  • 기술 적용 전략에는 유연함이 필요하다
    • 비동기 연동에 카프카를 썼다고 해서 모든 비동기 연동에 카프카를 사용할 필요는 없다
      • MSA 도 마찬가지
    • 영웅주의 경계!
      • 모든 문제를 해결할 수 없다
      • 모든 기술을 잘 다룰 필요도 없다
    • 하지만, 공부는 꾸준히
      • 필요한 기술을 필요할 때 공부하면 된다
    • 과거에 경험했어도 오랜 기간 사용하지 않으면 더 이상 내가 보유한 기술이 아니다

소프트웨어 가치와 비용

• 소프트웨어 유지보수는 이전과 동일한 동작을 유지하는 것이 아니라 변화하는 세상에서 유용함을 유지하는 것 - 제시카 커
• 유지 보수와 개발 실력
  • 유지보수만 하다보면 실력이 안늘고 신규 프로젝트를 해야 실력이 는다?
    • 유지보수 → 소프트웨어 운영 경험, 리팩토링, 좋은 코드 고민
    • 신규 프로젝트 → 새로운 기술 사용

응집도와 결합도

응집도(cohesion)

• 응집도는 모듈 안에 있는 요소가 함께 모여 있는 정도
• 응집도는 한 모듈의 파트가 동일한 모듈안에 포함되어 있는 수준
• 응집도는 관련 요소가 얼마나 한 모듈에 모여 있는 지를 나타냄
• 작게는 메서드 수준부터 크게는 프로세스 수준에 이른다

응집도 예시

• 회원 관련 코드가 한 패키지(모듈)에 모여 있는가?
• 스택 관련 코드가 한 클래스에 모여 있는가?
• 폼 검증 로직이 한 함수에 모여 있는가?

코드가 한곳에 모여 있으면 응집도가 높다가 표현하고 반대로 관련 코드가 여러 곳에 분산되어 있으면 응집도가 낮다고 표현

왜 응집도를 높여야 할까? 유지보수 비용과 관련!

응집도와 단일 책임 원칙

단일 책임 원칙(Single Responsibility Principle)은 각 구성 요소는 하나의 책임만 가져야 한다는 원칙

구성 요소를 수정할 이유는 하나여야 한다는 것.

응집도가 높아지면 단일 책임 원칙을 따를 가능성이 올라간다.

캡슐화

객체 지향에서 캡슐화(Encapsulation)는 데이터와 함수를 한곳에 모은다.

데이터를 외부에 노출하지 않고 감추는 정보 은닉(information hiding)과 캡슐화를 구분해서 표현할 수도 있지만 흔히 말하는 캡슐화는 정보 은닉을 포함한다.

캡슐화는 응집도를 높이는 방법의 하나.

결합도(coupling)

한 요소를 수정할 때 다른 요소도 함께 수정해야 하면 두 요소 간 결합도가 높다고 표현.

종속성과 결합도의 차이

높은 결합도는 모듈 간의 강한 상호 의존성을 의미하며, 높은 종속성은 한 요소가 다른 요소에 강하게 의존하는 것을 의미합니다. 개발할 때는 이러한 결합도와 종속성을 최소화하여 소프트웨어의 유지 보수, 재사용성, 확장성을 향상시키는 것이 중요합니다.

유지보수 비용을 낮추기 위해서는 응집도는 포이고 결합도는 낮춰야 한다.

레거시와 리팩토링

레거시(Legacy)는 오래됐지만 여전히 사용하고 있는 코드

레거시 코드를 수정하기 싫은 이유

1. 긴 클래스, 긴 메서드
2. 복잡한 코드
3. 이상한 이름
4. 많은 중복
5. 테스트 코드 없음

레거시 코드 수정과 악순환

1. 레거시 코드를 이해하는데 많은 노력 필요
2. 이해 부족 상태에서 코드 수정
3. 변경에 대한 두려움 (사이드 이팩트)
4. 코드 덧대기로 문제 회피
5. 1번 심화

레거시는 마치

레거시 코드의 안좋은 수정은 공공장소의 쓰레기와도 같다

하나가 존재하면 전부다 그곳에 버린다

리팩토링을 해야하는 이유

리팩토링을 진행할 때는 항상 꼼꼼한 테스트 코드가 필수

썩은 이빨과 같다

고통과 비용이 두려워서 치과를 피하게 된다면

결국 더 큰 고통과 비용으로 나에게 돌아온다

주석 관리

주석 처리된 코드 삭제

• 왜 주석 처리했는 지 몰라서
• 혹시 또 사용될까봐

이렇게 하자

• //TODO 주석을 추가하자
• 내가 주석을 처리한다거나
• 지우고 싶은 주석이 있다면 todo 주석에 날짜와 이유를 추가하자
• 그리고 6개월이 지나도 동작에 문제가 없다면 과감하게 삭제하자

매직 넘버

의미를 가지는 숫자

enum 처리

네이밍의 어려움

이름 짓기가 힘들면 적당히 생각나는 단어로 짓고 주석으로 설명하자 이후에 변경해도 된다

리팩토링 vs 새로 만들기

일부 기능을 마이크로 서비스로 분리하는 것

전체를 새로 만들기보다 위험 부담이 적다

하지만, MSA 구성이나 서비스간 통신같은 문제가 발생할 수 있다

새로 만들 때의 단점보다 이 점이 더 클 때 개선의 방식으로 MSA를 선택해야 한다

테스트

자동화된 테스트는 개발자에게 안정감을 가져다 준다

테스트 커버리지는 70~80% 정도만 돼도 충분하다

코드 수정에 많은 압박을 느낀다면 테스트 코드를 잘 짜서 해방되자

TDD는 기능 설계에도 도움을 준다

아키텍쳐/패턴

주니어 개발자와 시니어 개발자를 구준 짓는 요소 중 하나로 아키텍처 설계 역량을 꼽을 수 있다.

MSA는 아키텍처의 한 종류 (시스템 수준)

MVC, MVP 또한 아키텍처 (클래스 수준)

업무 관리

기억할 것들

• 추정과 보정
  • 기간을 대략적으로 추정하고 주기적으로 보정한다
• 일 잘하는 방법도 공부해야 한다
  • 개발자이기 전에 직장인!
• 거의 다 했어요 금지
  • 기능 개발을 완전히 마치고 개발자 테스트까지 마쳐야 ‘거의 다 했어요’ 가능
• 위험 신호를 감지하면 빠르게 공유
  • 관리자도 체크하지 못할 수 있다
  • 피드백이 없으면 신뢰를 잃을 수 있다

요구 사항과 변경 사항

요구사항 변경은 막을 수 없다

요구사항 변경을 막기위하여 노력하기보다

변동을 최소화 하기 위해서 노력해야 한다

기획자와 충분한 대화가 필수!

어떤 이유로 변경하려는 지 목적이 뭔지 파악

‘할 수 없다’라고 말 할 수 있어야 하며 이유를 제시할 수 있어야 한다

점진적 반복적 개발

• 점진적
  • 애자일
  • 조금씩 개발
• 반복적
  • 성능을 점점 높혀서 개발
  • 50% → 80%
  • 80% → 100%

이유와 목적

상급자로부터 업무 시지를 받으면 어떤 이유 또는 어떤 목적으로 지시를 받았는지 알아내야 한다.

상급자는 이유와 목적을 설명할 수 있어야 한다.

회사 생활

• 변화가 필요하다면 사람이 아닌 프로세스와 시스템 변화에 집중하자
  • 어차피 사람은 안바뀐다
  • 사람들이 프로세스와 시스템을 따르도록 하자
• 영웅 대접을 받고 싶어하는 개발자와는 함께 일하고 싶지 않다
  • 겸손이 필요하다
• 동료의 부족함을 지적할때는 정중해야 한다
  • 동료가 날 지적할때도 날 비난한다고 생각할 필요 없다

기술력 상실의 두려움 없애기

리더나 관리자가 되면 코드로 부터 멀어진다.

이전과 같은 기술력을 유지할 수 있을 지에 대한 두려움이 생긴다.

코딩이 기술력의 전부는 아니다.

아키텍처를 설계하고 복잡한 시스템을 분해하고 일정을 계획하는 역량 역시 개발자의 중요한 역량이다.

주니어를 벗어나야 할 개발자가 이런 다양한 역량을 키우지 않고 구현 기술만 공부하고 있다면 그게 더 문제다!

주니어 개발자를 대하는 시니어 개발자

• 대신하지 않기
  • 내가 하는 게 더 빠를 거 같다는 생각이 든다
  • 하지만, 그게 사실이라고 해도 그래선 안된다
  • 주니어 개발자의 성장 기회를 뺏은 것과 같다
  • 돕고 싶다면 함께 검토하거나 함께 개발해라
• 자율성
  • 마이크로 매니징은 자율성을 뺏고 부담을 준다
  • 주도성도 잃는다
  • 충분한 시간과 자율성이 필요하다
  • 일단 맡겼다면 간섭을 최소화하고 기다리자
  • 최소한의 가이드만 해주자
• 도움 요청
  • 리더라고 해서 혼자서 모든 걸 하지 않아도 된다
  • 필요하다면 도움을 요청하라
  • 제때 도움을 요청해서 어려움에서 빠져 나와라