1. 클린코드와 그 첫걸음, 네이밍

in 클린코드



클린코드와 그 첫걸음, 네이밍


0. 들어가면서

난간에 부딪힐 때 옳은 문 뒤에 있으려면 어떻게 해야 할까? 답은 장인정신이다. 장인 정신을 익히는 과정은 이론과 실전으로 나뉜다.

  • 이론 : 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득해야 한다.
  • 실전 : 열심히 일하고 연습해 지식을 몸과 마음으로 체득해야 한다.


1. 깨끗한 코드

코드란 무엇일까?

  • 요구사항을 상세히 표현하는 수단이다.
  • 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업(=프로그래밍)
  • 이렇게 명시한 결과 = 코드
  • 궁극적으로 코드는 요구사항을 표현하는 언어임을 명심하자.


나쁜 코드

나쁜 코드란 무엇인가?

  • 성능이 나쁜 코드 : 불필요한 연산이 들어가서 개선의 여지가 있는 코드
  • 의미가 모호한 코드 : 이해하기 어려운 코드, 네이밍과 그 내용이 다른 코드
  • 중복된 코드 : 비슷한 내용인데 중복되는 코드들은 버그를 낳는다.


어째서 나쁜 코드를 짜는가?

  • 급해서, 서두르느라, 일정이 촉박해서
  • 제대로 짤 시간이 없다고 생각해서


우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로하는 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

  • 개발 속도를 크게 떨어뜨린다. (생산성이 떨어진다.)
  • 재설계를 하게 된다. (새로운 시스템을 만들어야 한다.)

깨진 유리창 법칙 : 나쁜 코드는 깨진 유리창처럼 계속 나쁜 코드가 만들어지도록 한다.

나쁜 코드에 대한 태도

코드가 왜 이렇게 쓰레기가 되었을까? 우리는 온갖 이유를 들이댄다.

  • 요구사항이 변했다고
  • 일정이 촉박해 제대로 할 시간이 없었다고
  • 멍청한 관리자와 쓸모없는 마케팅 인간들 때문에 아니다. 프로젝트 실패는 개발자에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

깨끗한 코드

  • 나는 우하하고 효율적인 코드를 좋아한다.
  • 논리가 간단해야 버그가 숨어들지 못한다.
  • 의존성을 최대한 줄여야 유지보수가 쉬워진다.
  • 오류는 명백한 전략에 의거해 철저히 처리한다.
  • 깨끗한 코드는 한 가지를 제대로 한다.
  • 깨끗한 코드는 단순하고 직접적이다.
  • 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
  • 중복이 없다.

클린코드란?

  • 성능이 좋은 코드
  • 의미가 명확한 코드 = 가독성이 좋은 코드
  • 중복이 제거된 코드

우리는 저자다.

우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.
우리는 새 코드를 짜기 위해 주변 코드를 읽는다. (이 시간 비율은 1:10) 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.

보이스카우트 규칙

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.

  • 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

2. 의미있는 이름

의도를 분명히 밝혀라

  • 무분별한 a, b, c 사용하지 않기
  • 루프 속 i j k 사용하지 않기 (advanced for문으로 대체 가능)
  • i j k 대신 맥락에 맞는 이름이 있다. (row, col, width, height)

그릇된 정보를 피해라

  • 서로 흡사한 이름을 사용하지 않도록 주의한다.
  • 유사한 개념은 유사한 표기법을 사용한다. (일관성이 떨어지는 표기법은 그릇된 정보다.)
    Member / Customer / User
Service / Manager
Repository / Dao


변수명에 타입 넣지 않기

String nameString 👎 > name
Int itemPriceAmount 👎 > itemPrice

Account[] accountArray 👎 > accounts
List<Account> accountList 👍 > accounts, accountList
Map<Account> accountMap 👍

public interface IShapeFactory 👎 > ShapeFactory
public class ShapeFactoryImpl 🤔 > CircleFactory


발음하기 쉬운 이름을 사용하라

private Date genymdhms;
private Date modymdhms;
👎

private Date generationTimestamp;
private Date modificationTimestamp;
👍


검색하기 쉬운 이름을 사용하라

MAX_CLASSES_PER_STUDENT는 grep으로 찾기 쉽지만 숫자 7은 은근히 까다롭다. 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문이다. 마찬가지로 e라는 문자도 변수 이름으로 적합하지 못하다.

클래스 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. 동사는 사용하지 않는다.

메서드 이름

메서드 이름은 동사나 동사구가 적합하다. 접근자, 변경자, 조건자는 값 앞에 get, set, is를 붙인다.

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택하라.

의미있는 맥락을 추가하라.

firstName, lastName, state 👎
addrFirstName, addrLastName, addrState 👍


Google Java Naming Guide

Package Naming Guide

All lower case, no underscores

com.example.deepspace 👍
com.example.deepSpace 👎
com.example.deep_space 👎


Class Namimg Guide

UpperCamelCase (대문자로 시작)

// 클래스는 명사, 명사구
Character, ImmutableList

// 인터페이스는 명사, 명사구, (형용사)
List, Readable

// 테스트 클래스는 Test 로 끝나기
HashTest, HashIntegrationTest


Method Naming Guide

LowerCamelCase (소문자로 시작)

// 메서드는 동사, 동사구
sendMessage, stop

// jUnit 테스트에 underscore 사용되기도 함
// <methodUnderTest>_<state> 패턴
pop_emptyStack


나의 회고

  • 코드 리뷰를 받을 때마다 ‘클린 코드’에 대한 지적을 많이 받았는데 어렴풋하게 ‘왜 깨끗한 코드를 짜야하는지 - 가독성이 편하게’ 라고 생각했던 부분들을 명확하게 짚고 넘어갈 수 있어서 즐거웠다.
  • 루프 속 i, j, k에 대한 부분은 한 번도 고려해본적이 없던 부분이라서 신선한 기분이 들었다.
  • 특히 보이스카웃트 규칙이 매우 인상 깊었는데, ‘전보다 더 깨끗한 코드를 만든다.’ 를 항상 생각하며 개발을 해나가야겠다.
  • 당장의 기능 개발을 위해 나쁜 코드를 짜는 것보다 크게 보았을 때 유지보수하기 좋고 가독성 좋은 코드를 만들기 위해 항상 클린 코드를 유념하며 개발을 해야겠다.
  • 또한 기존의 더러운 나의 코드를 클린코드로 만들기 위해 한번에 수정하려 하지 않고, 그때 그때 보이는 변수명부터 수정하면서 차근차근 해나갈 계획이다.
  • 나는 개발자이자 코드를 쓰는 작가이다! 독자를 배려하는 작가가 되자!🤩