[ Clean Code ] 클린코드 시리즈 (with Swift 가이드라인)

시작하게 된 계기

- 장인정신에 걸음마를 익히듯 다가갈 내 모습을 만든다.

- 예전 프로젝트를 방치하지 않고 다시 열어서 용기를 얻어 뜯어보자!

- 클린 아키텍쳐 이론을 사실 먼저 건드렸지만, 그 전에 기본이 되는 코드를 나는 잘 짜고 있는가에 대한 의문

Overview

장인정신을 익히는 과정

1단계 이론 ➡ 2단계 실전

- 원칙, 패턴, 기법, 경험이라는 지식 습득

- 열심히 일하고 연습해 지식을 몸과 마음으로 체득

열심히 독파해야하며, 단순히 코드 패턴을 익히는 것에 더 나아가 🐕고생 해야한다. 실패도 맛보고, 다른이들이 시도하다 실패하는 모습도 봐야한다.

클린코드 책의 전체적인 흐름

초반

깨끗한 코드 작성 원칙, 패턴, 실기 설명

두번째 파트

• 더 심화적이며, 여러 사례를 소개하며, 복잡도가 높아진다.
• 코드를 깨끗하게 고치며, 문제있는 코드가 문제가 더 적은 코드로 바꾸는 연습을 하는 것이다.
• 설명과 코드를 번갈아가며 이해
• ⇒ 코드 분석하고 이해하며, 코드에 가하는 변경과 이유를 납득해야 한다.

마지막 파트

• 사례 연구를 만들면서 수집한 경험, 휴리스틱함
• 사례 연구에서 코드를 정리하며 내린 각 결정과 휴리스틱 사이 관계 중요

⇒ 코드를 짜고, 읽고, 정리하는 관점에서 우리가 생각하는 방식을 묘사한 지식 기반을 구축

휴리스틱(heuristics) 또는 발견법
불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법 (출처: 위키백과)

 

코드의 존재

코드는 요구사항을 상세히 표현하는 수단

⇒ 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다.

나쁜 코드가 뭔지 파악하고 지양하자!!

나쁜 코드로 고생한 경험, 안 돌아가는 프로그램보다는 기능 구현이 어찌 저찌 하여 되는 쓰레기 코드가 낫지 않을까? 라는 착각!

르블랑법칙(le blanc's law)은 나중에 절대 오지 않는다.

• 갑자기 기발한 아이디어가 떠오릅니다.
  • 어쩌면 이는 일시적/암시적 종속성을 추가하는 것을 의미할 수도 있습니다.
  • 어쩌면 그것은 내년 1월 3일까지만 작동하는 마법의 끈을 던지는 것을 의미할 수도 있습니다.
  • 어쩌면 이는 디자인을 깨뜨리고 코드를 테스트할 수 없게 만드는 것을 의미할 수도 있습니다.
  • 어쩌면 간헐적인 버그와 함께 생활한다는 의미일 수도 있습니다.
  • 아마도 그것은 하나의 버그를 제거하고 다른 버그를 도입하는 것을 의미할 수도 있습니다.
• 이 결정의 실제 결과에 대해 생각해보십시오.
  • 나중에 정말 다시 돌아올 수 있을까요?
  • 그렇지 않으면 어떻게 될까요?
  • 당신이 도입하는 위험은 무엇입니까?
• "나중에 수정하겠습니다"라는 표현에는 여러 가지 인기 있는 변형이 있습니다.
  • 나중에 그 버그를 고치겠습니다.
  • 나중에 고객에게 실제로 필요한 것을 제가 구축했는지 확인하겠습니다.
  • 나중에 단위 테스트를 작성하겠습니다.
  • 나중에 단위 테스트에서 취약성을 제거하겠습니다.
  • 나중에 단위 테스트를 읽을 수 있게 만들겠습니다.
  • 나중에 단위 테스트를 빠르게 수행하겠습니다.
  • 나중에 통합 테스트를 해볼 예정입니다.
  • 나중에 사용성 테스트를 해볼 예정입니다.
  • 나중에 복사/붙여넣기 중복을 제거하겠습니다.
  • 나중에 다른 개발자에게 내 아이디어/디자인/코드를 적용하겠습니다.
  • 나중에 해당 해결 방법/핫픽스/완전한 해킹을 제거하겠습니다.
  • 나중에 코드를 읽기 쉽고 유지 관리 가능하게 만들겠습니다.
  • 나중에 성능/신뢰성에 대해 걱정하겠습니다.

https://yiming.dev/clipping/2019/03/21/le-blanc's-law-a-k-a-later-equals-never/

 

이 책에서 유명 개발자들의 깨끗한 코드에 대한 철학이 나온다. C++ 의 창시자 비야녜 스트롭스투룹, 그래디부치, 데이브토마스, 마이클 페더스, 론 제프리스 등 그들이 한 입모아 말하는 깨끗한 코드는 무엇일까? 그렇다면 깨끗하지 않은 나쁜 코드는?

• 우아하고 효율적 코드
• 의존성을 줄여야 유지보수가 쉬워진다.
• 오류는 전략에 의해 철저히 처리(해결)한다.

깨끗한코드: 세세한 사항까지 꼼꼼히 처리하는 코드

나쁜코드: 너무 많은 일을 하려 애쓰다 의도가 뒤섞이고 목적이 흐려진다.

 

그래디 부치

코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다.

깨끗한 코드 만드는 비결

1. 중복 줄이기
2. 표현력 높이기
3. 초반부터 간단한 추상화 고려

⇒ 한 가지 기능 수행, 제대로 표현, 작게 추상화

⇒ 주변코드를 읽지 못하면, 새 코드를 짜지 못한다.

급히, 서둘러 끝내야만 하고, 쉽게 짜고 싶은 것이라면  읽기 쉽게 만든다.

Chapter 2. 의미 있는 이름 

1. 의도를 분명히 밝혀라

2. 그릇된 정보를 피하라

코드에 그릇된 단서를 남겨선 안된다.

클래스 이름: 객체 이름은 명사나 명사구

메소드 이름: 메소드 이름은 동사나 동사구

한 개념에 한 단어: 일관성 있는 어휘는 중요

e.g. 동일 코드 기반에 controller, manager, driver 를 섞어쓰면 혼란스러움

3. 해법 영역에서 가져온 이름을 사용하라

기술개념에는 기술이름이 가장 적합한 선택이다.

4. 의미 있는 맥락을 추가

5. 접두어 추가

address 연관 변수 → addr 접두어 붙여서

addrFirstName, addrLastName, addrState

---

Swift 에서 적용해 볼 점은?

Swift 만의 가이드라인에서도 또한 우린 클린 코드를 지향해서 이렇게 짜! 라고는 대놓고 언급하지는 않았지만, 밀접하다고 느꼈기에 공식문서를 보고 정리한 것을 포스팅해보았다.

 

Swift 기본 가이드라인

Swift 기본 가이드라인 - part 1