반응형
육각형 개발자 - 최범균 저
1. 들어가며
개발 ⊃ 코딩
개발은 코딩과 동의어가 아니며, 개발은 코딩 외적인 활동들이 포함되는 더 큰 개념이다. 개발의 핵심은 사용자에게 매력적인 기능을 만들어서 가치를 창출하는 것.
이 책에서 다루는 역량은 다음과 같은 3가지 범주에 속한다.
- 구현 기술
- 설계 역량
- 업무 관리, 요구 분석, 공유, 리드&팔로우
구현 기술 : 동작하는 소프트웨어를 만드는, 가장 기초 역량
2. 구현 기술과 학습
어떤 기준으로 구현 기술을 선택하고 학습해야 하는가
- 현재 사용 중인 기술
- 문제를 해결하기 위한 기술
특정 구현 기술에 상관 없는 CS의 기초 지식은 반드시 습득하고 있어야 한다.(HTTP프로토콜, 네트워크 프로그래밍 기초, 동시성 처리, 프로그래밍 언어 등)
신규 구현 기술 도입의 기준
- 신뢰 구축 : 내가 현 조직에서 동료에게 신뢰받고 있는 입지인가
- 함께 할 동료 : 함께 논의하고 공감대를 형성할 동료가 필요
- 타당성 : 기술 적용의 이유가 타당해야 한다. "답이 아닌 질문을 따라 하라(Copy the question, not the answer)". 어떤 답을 그대로 생각 없이 따르지 말고, 그 답이 나오게 된 질문을 분석함으로써 답의 이유와 목적을 습득하라.
- 점진적 적용 : 비핵심 영역에서 일부 먼저 검증한 후, 핵심 영역에 적용한다.
- 시장 상황 : 해당 기술에 능숙한 인력을 원활하게 채용할 수 있는가
설계 역량 : 변화에 대응하기 좋은 구조를 짤 수 있는가
3. 소프트웨어 가치와 비용
소프트웨어 유지보수는 이전과 동일한 동작을 유지하는 것이 아니다. 변화하는 세상에서 유용함을 유지하는 것이다.
세상은 빠르게 변하고, 세상의 변화에 맞춰 소프트웨어가 생존하려면 소프트웨어도 변해야 한다. 하지만 규모가 커질수록 유지보수에 비용이 많이 든다. 기존 코드를 수정하는 것이 새로 만드는 것보다 필연적으로 더 오래 걸린다. 유지보수 비용을 낮추려면 코드 품질이 좋아야 하며 아래와 같은 방법들로 코드 품질을 좋게 만들어야 한다.
- 프로그래밍 패러다임 : 객체 지향 프로그래밍의 캡슐화, 다형성 / 함수형 프로그래밍의 참조 투명성
- 패턴, 아키텍쳐 : 전형적인 디자인 패턴을 익히고 요구에 맞는 아키텍쳐 사용
- 프로세스, 문화 : CD(Continuous Delivery)도입
4. 코드 이해
코드를 이해하는 시간이 개발 시간의 반 이상을 차지함. 이 시간을 줄이기 위해서는 내가 코드를 제대로 이해할 수 있는 역량과, 이해하기 쉬운 코드를 작성하는 역량이 필요하다.
코드 시각화 - UML(Unified Modeling Language)을 활용하면 의사소통에서도 도움이 된다.
- 액티비티 다이어그램 : 실행 흐름 이해
- 시퀀스 다이어그램 : 구성 요소 간 상호작용 이해
- 클래스 다이어그램 : 코드의 정적인 구조 이해. 어떤 클래스가 존재하고, 서로 어떻게 연결되어 있는지 파악
- 상태 다이어그램 : 상태 변화 로직 이해
- UML은 아니지만 데이터 간의 영향 관계를 그래프로 표시하기도 함. 의존 관계를 시각적으로 표시해서 변경이 어디까지 영향을 주는지 파악하기 위함
이해하기 좋은 코드 작성법
- 이름 : 표기한 이름이 실제 역할을 최대한 반영하도록 신중하게 작성. 필드 이름은 클래스 이름의 맥락을 고려하여 짧게 지어도 된다.
- 중첩 if 최소화 : 중첩될수록 이전 맥락을 기억하고 있어야 해서 좋지 않은 코드이다. 특정 조건일때 아무것도 수행하지 않는다면, 그 조건을 위로 올려서 코드를 깔끔하게 작성 가능
- 변수 줄이기 : 변수가 반드시 필요한지 고민(하지만 가끔은 변수를 추가로 선언함으로써 의미를 명확히 할 수도 있음 - ex. 특정 계산 결과를 age 라는 변수에 저장), 변수를 사용되기 직전에 정의하고, 특정 블록 내부에서만 사용하도록 제한(외부에 선언 시 블록 수행이 끝난 후에도 해당 변수가 사용되는지 확인이 필요하여 부하가 걸림)
- 값 변경 최소화하기 : 변수값이 중간에 바뀌면 모든 값을 추적해야 해서 코드 분석이 어려움. const, final 같은 키워드로 불변성을 보장하는 것이 좋다.
- 알맞은 파라미터 타입 사용하기 : 여러 역할의 메서드에 공통 타입의 파라미터를 적용하는 것을 지양. 해당 타입 클래스의 역할이 너무 커지게 되어 분석이 어렵다. 각 메서드를 실행하는 데에 필요한 값만 파라미터로 넘겨야 한다.
- 길지 않은 코드와 메서드 추출 : 코드가 길어지는 경우 특정 역할을 별도 메서드나 객체로 분리.
- 추상화 수준 맞추기 : 한 호출 흐름 내의 메소드들은 추상화 수준을 맞추는 것이 좋다.(추상화 수준이란 코드를 읽으면서 파악할 수 있는 정보의 수준 - 얼마나 구체적인지, 추상적인지로 분류할 수 있다)
다음편에 이어서..
반응형
'개발자의 노하우' 카테고리의 다른 글
시니어 개발자로 성장하기 위한 핵심 역량 - '육각형 개발자' 책 리뷰 - 2 (0) | 2023.09.06 |
---|---|
[실전개발] Git, Github(깃, 깃허브)의 기초 (0) | 2022.07.17 |