정신없이 일하고 개발하다보니 기초를 잊어버릴 때가 종종 있는 것 같다. 다시 한번 내 상태를 점검하고 review하기 위해 도서관을 구경하다가 꽂힌 책을 읽어보았다.

육각형개발자 책

개발이란

똑같은 패턴? 어디까지가 개발인가?

• 코딩-구현 기술은 개발의 일부
• 새로운 구현기술 != 성장
• 서비스 회사
  - 고객 경험이 좋아야 수익-투자가 높다. 그래서 지속가능성이 높음

개발에 필요한 것(역량)

• 구현 기술
• 설계 역량 -> 시장 변화에 쉽게 해당하는 구조 -> 이게 결정적이다.
• 업무 관리와 요구 분석, 공유, 리드&팔로우

구현 기술

• 학습 전략, 유행 상관없는 기초

• 학습대상 기준
  1. 현재 사용중인 기술
  2. 문제를 해결하기위한 기술

• ex)
  - 스프링으로 된 API 지식 - Controller, Json 변환 처리, 트랜잭션 처리(원하는 대로 롤백이 안됨)
  - Database: 최대 커넥션 유지시간, 개수, 계정 권한과 같은 주요 설정 수정
  - 메시징 프로그램: kafka 사용 시 주요 구성 요소인 파티션, 레플리카, 프로듀서, 컨슈머의 동작 이해 => 데이터 손실과 서비스 중단 최소화 가능
  - 운영체제: 부팅 시 자동으로 PG 시작하기, 권한 설정, 스케줄링, 운영체제 상태보기 등

• 구현기술 학습에는 끝이 없다. 주기적으로 탐색하고 학습하자

• 유행 상관없는 개발 기초
  - HTTP 프로토콜, 네트워크 프로그래밍 기초, 동시성 처리, 프로그래밍 언어 등

구현 기술 적용

• 기술 도입 시 고려사항
  1. 신뢰 구축: 신뢰받아야한다.
  2. 함께 할 동료: 기술에 대해 함께 논의하고 공감대를 형성하는 동료
  3. 타당성: 답이 아닌 질문을 따라하라. 즉, 다른 곳에서 해당 기술 사용하는 맥락을 따라해야!
  4. 점진적 적용
  5. 시장 상황: 해당 기술에 능숙한 인력풀이 많은가?

• POC: 개념 증명

소프트웨어 가치와 비용

• SW 버전이 올라가면 개발 비용이 올라간다.
  - 세상의 변화에 맞춰 같이 변해야하기 때문
  - 이게 유지보수의 중요!
  => SW의 가치를 유지한다. 유지보수를 지루하다고만 보지말라

유지보수 비용 낮추기

• 코드품질은 유지보수 비용과 관련이 있다.
  1. 프로그래밍 패러다임을 알맞게 적용
  2. 코드 가독성 높이고 전형적인 디자인패턴 사용, 요구에 알맞은 아키텍처 적용
  3. 프로세스와 문화

코드 이해

• 코드 개발-변경에는 코드 이해 시간이 많이 요구된다. 그래서 이를 줄이려면
  1. 코드 제대로 이해하는 역량
  - 코드 시각화 ex) UML
  - 클래스 다이어그램
  - Activity 다이어그램: 논리적 단위
  - 시퀀스 다이어그램: 런타임. 시간 흐름에 따라 구성요소 간 연동 과정
  - 상태 다이어그램
  - 스크래치 리팩토링: 이해용 리팩토링. 끝나면 원복
  2. 이해하기 쉬운 코드 작성 역량
  - 가독성 ex) 켄트백의 구현코드, 클린 코드 => 규칙을 만든 상황을 이해하자
  - 작성법
  - 이름, if 줄이기, 변수 줄이기, 값 변경 최소화, 길지않은 코드
  - 알맞은 파라미터 사용
  ex) MAP: 코드양 적고, 초기에는 좋으나 개발 생산성이 점점... 자동완성x, 코드 수정 시..
  - 추상화 수준 맞추기
  - 메서드 추출할때. 즉 depth를 맞추라.
  - 메서드 계속 이동하는 것도 흐름이 끊긴다.

응집도와 결합도

• 응집도: 관련 도메인이 얼마나 같은 모듈에 존재 => 수정시 같은 곳에서만 수정되도록!
  - 목표
  1. 가독성
  2. 수정 비용 낮추기
  3. 단일 책임: 구성요소를 수정할 이유는 하나여야한다. 캡슐화를 통해 충족된다!

• 결합도: 두 모듈이 서로 의존하는 정도 => 한 쪽 수정하면 다른 쪽도 수정해야하면 결합도가 높아지는 것
  - 수정대상이 많으면 가독성 저하, 수정비용 증가
  - 해결 방법: 추상화 타입(구현체 별도), 이벤트, 상속보다는 조립

리팩토링

• legacy에 대한 정의: 정의는 다양하나, 공통점은 수정이 어렵다는 것
• 참고책: 리팩터링 2판(2020)
• 리팩토링의 목표: 코드 수정 비용 낮추기 위해 코드를 수정하기 쉬운 구조로 변경
  - 기존 동작 유지, 내부 구조 변경
  - Test Code 필요
  - 미사용코드는 todo 삭제예정(날짜)로 주석 처리하자
• 리팩토링 방법: 미사용 삭제, 매직넘버, 이름 변경, 메서드 추출(가독성-응집도), 클래스 추출, 클래스 분리, 메서드 분리, 파라미터값 정리
  +같은 for문 내 작업 분리
  - for문 더 돈다고 걱정하지만 대부분 성능문제 상관없다. 문제가 될 때에 최적화하면 되는 것. 오히려 이해하기 좋은 코드로서의 이점이 더 있다.

테스트

• 테스트 코드 작성이 어려우면 테스트 카능성 높이기만이라도 해야한다.
• 리팩토링을 위한 Test Code
• 다양한 테스트 코드를 작성하면서 업무에 대한 이해도가 높아진다!
• TDD: 코드 작성 - 구현 - 코드 정리의 과정을 반복
  - 예외 case 먼저. 그리고 정상 case
  - 테스트 코드는 다른 테스트 추가를 쉽게한다.
  - edge case를 분별하기 쉽다.
  - TDD는 설계 지원
  - 테스트 대상의 이름, 메서드, 파미터 등을 결정해야한다. 또한 테스트 대상이 직접 기능을 구현하는 게 아니라면 다른 타입에 구현을 구현을 미루는 형태로 역할 분리 => 이게 설계 과정
  
  - 처음에는 코드 작성시간이 높지만 반복되는 테스트 시간이 줄어든다. 추가로, 일부만 검증하면 되기 때문에 디버깅 시간이 줄어든다.
• 외부 연동은 별도 타입으로 분리하자

아키텍처 - 패턴

• 아키텍처 역량: 주니어-시니어 구분 기준
• 아키텍처: SW 추상적인 구조
  - 결정요소
  1. 기능 요구사항: SW로 해결하고자하는 문제
  2. 품질 속성(비기능 요구사항): 성능, 확장성, 도메인 준수, 가용성, 보안, 유지보수성
  - 품질 속성의 trade off: 품질속성이 높아지면 시스템 복잡도가 높아진다.
• 품질 속성
  

=> 아키텍처에 따라 적합, 부적합 case 구분하기!

빅뱅방식: 아키텍처를 바꾸기 위해 모든 걸 다시 개발 ex) 차세대 프로젝트

• 최신 장비와 최신 SW를 사용해서 기존 시스템을 새로 구현하는 것
• 단점: to-be 신규 요구사항. as-is 기능 누락. 시간이 오래 걸린다.
  => 점진적으로 구조 변경: 모놀리식 1개 -> 모놀리식 2개 등 서비스 분리 + 비동기 연동 by 메시징 시스템

패턴 익히기

• 패턴: 특정 맥락에서 반복되는 문제해결법
• 패턴의 종류: 아키텍처 패턴, 디자인 패턴, 기업 통합 패턴, 결함 허용 패턴
  - 아키텍처 패턴: 아키텍처 수준에서의 패턴
  ex) 포트-어댑터, 마이크로서비스, 이벤트 기반
  - 이벤트 기반은 탄력성과 성능에 장점 but 트랜잭션 처리 복잡, 테스트 어려움
  - 디자인 패턴: ex) GoF 디자인 패턴 - 전략, 커맨드, 싱글톤, 템플릿, 팩토리 메서드, 프록시 등
  - 기업 통합 패턴: 파일 전송부터 메시징에 이르기까지 시스템 간 통합을 위한 패턴
  - 최근에는 기업 간 연동뿐 아니라 내부 시스템 간 연동도 증가하는 추세이기 때문
  - 결함 허용 패턴 ex) 하트비트, 재시작, 재시도 제한, 서킷 브레이커 등 => 주로 MSA
  

업무 관리

• 업무 관리의 기초: 업무 나누기, 위험 관리, 요구 사항
• 점진적-반복적 개발, 수작업 줄이기, 이유와 목적

업무 나누기

• 개발 계획
  - 업무의 크기에 따라 일하자. 일은 하루에서 수일 이내로 끝낼 수 있는 크기로 나누자.
  - 계획이 있어야 진행상태 파악. 변화에 대응.
  - 계획을 세우려면 일의 규모를 파악해야한다.
  - 규모를 파악하려면 작업 목록이 필요하다.
  - 완료는 개발 + 검증까지

위험 관리

• 스스로 위험 신호 감지시 즉시 공유
• 겪었던 경험으로 나중에 시니어가 되면 주니어 개발자가 놓치기 쉬운 위험요소를 확인하고 해소 필요
• 미리 위험 목록 작성 + 등급 매김

변경되는 요구사항

• 바뀌는 요구사항 단계 : 초기 > 중간 > QA 과정에서
• 요구사항의 변동 폭을 줄이려면
  1. 왜 이런 요구사항을 원하는지 이해하려는 노력 필요
  => 이를 고민하면 이해관계자가 원하는 결과에 가까운 산출물을 얻기 쉬워진다.
  2. 요구사항을 나눠서 분석하자
  - 초반에 모든 것을 세세하게 분석 x. 개략적으로.
  - 전체 요구사항 중 절반을 초반에 집중 개발. 그 다음에 나머지 요구사항 정리
  - agile 역시 비슷하다. 스크럼에서 스프린트를 진행할 때 앞으로 진행할 2~3번의 스프린트에서 개발할 요구사항만 자세하게 도출. 다른 요구사항은 상세하게 기술하지않고 이름과 개요 정도만 도출. 필요한 시점에 세부 요구사항을 만들면 불필요한 시간 낭비 줄여준다.
• 우선 순위 세우기 ex) 이번 오픈은 어디까지. 다음 오픈 때 이걸 하자는 둥

점진적 - 반복적 개발

• 점진적 개발: 결과물을 구분되는 조각으로 나누고 각 조각을 점진적으로 완성하는 방식 ex) 스크럼의 스프린트
  - 스프린트: 고정된 기간을 정하고 그 기간에 선택한 작업을 완료하는 것을 목표로 진행하는 작업 단위
  - 개발 기간동안 이런 스프린트를 지속하며 하나의 스프린트가 끝나면 출시할 수 있는 결과물이 나온다.
  => 스프린트마다 가치를 만든다.
  - 점진적 개발의 핵심은 작업을 분할해서 더 빨리 가치를 제공하는 데 있다.
• 반복적 개발: 사용자 요구사항 또는 제품 일부분을 반복해서 개발하여 목표로 하는 결과를 만드는 방식
  - 주로 난이도가 높은 개발 진행시에 주로 사용 ex) 60% -> 80% -> 100% 수준

이유와 목적 생각하기

• 요청 시에 이유와 목적을 설명해야 목표한 것을 이루기 쉽다.
• 뿐만 아니라 맡은 업무에 대해서도 이유와 목적을 알아야!

정리하고 공유하기

• 글로 정리해서 공유하기, 발표하기

글로 정리해서 공유하기

• 글의 주제, 개요, 목적, 대상 => 목차
• SCQA 프레임워크
  - Situation, Complication, Question, Answer
• 모호한 표현 줄이기
• 배경, 정보 제공하기(Context)
• 5가지 글쓰기 팁
  - 문장 짧게 쓰기
  - 글머리 기호 목록-번호 목록 사용하기
  - 표나 그래프 사용하기
  - 그림 사용하기
  - 시각적 효과 사용하기
• 평소 실천
  - 출퇴근 이동 시간: 글의 주제나 내용 흐름 등을 정리한다.
  - 저녁: 자기 전에 20분~1시간 정도 시간을 내서 글을 쓴다.
  - 점심시간: 점심을 먹고나서는 남는 시간을 활용해서 글을 쓴다.
• 글쓰기 연습 주제
  - 일기: 그 날 있었던 일 중에서 기억나는 일을 기록한다.
  - 시스템 구조 설명: 담당하는 시스템 구조를 설명하는 글을 써본다. 시스템을 시각적으로 표시하는 연습도
  - 문제 해결 방안: 운영 중인 시스템의 문제 해결방안을 글로 적어본다.
• 마인드맵 ex) XMind

발표하기

• 사내에 도입하고 싶은 기술 또는 프로세스가 있다면 설득하기위해, 내 의견에 동조하기위해서도 발표
• 외래어 남용 x

리더와 팔로워

리더 연습하기

• 우리는 서로에게 영향을 주기 때문에 직위, 직급 상관없이 언제든 리더가 될 수 있다.
• 문제 해결 리더십
• 사람이 아닌 프로세스-시스템 변화시키기
  - 사람은 쉽게 바뀌지않으므로
  - 프로세스, 시스템도 마찬가지다. 그러니 본인이 모범 사례로
• 기술력 상실의 두려움 없애기
  - 리더, 관리자가 되면 코딩에서 멀어진다. 하지만 넓은 시야, 깊은 수준 또한 중요한 역량
  ex)아키텍처 설계, 복잡한 시스템을 알맞은 단위로 분해, 진행계획 세우기, 적합한 기술 선택
• 리더로서 대신하지않기, 자율성 보장, 요청하기
• SW의 규모의 비경제(사공이 많으면 배가 산으로 간다)
  - 대규모 프로젝트는 반드시 여러 개의 프로젝트로 나눠야 생산성이 높다. 인력이 많다고 빨리 끝나는 게 아니다. 독립성에 중점을 둬서 프로젝트를 나눈다.
  - 도메인: SW로 해결하고자 하는 문제 영역

팔로워십

• 리더를 따르는 것만이 아니라 리더와 조화를 이루고 능동적으로 일을 수행하면서 리더가 성공할 수 있도록 지원하는 것. 리더와 소통하고 공감하며 문제를 발견하고 의견을 제시해서 리더와 함께 조직의 목표를 달성하는데 기여한다.
• 좋은 팔로워가 되려면 전문성 + 리더의 결정에 대한 맥락 파악

겸손, 존중, 신뢰