클린코드
코드를 읽으며 짐작했던 기능을 각 루틴이 그대로 수행한다면 클린코드라 불러도 되겠다. 코드가 그 문제를 풀기위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다. - 워드 커닝엄 p47
코드를 읽는 시간 대 코드를 짜는 시간 비율이 10:1을 훌쩍넘는다. 새코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. p50
함수선언부를 찾아보는 행위는 코드를 보다 주춤하는 행위와 동급이다. 인지적으로 거슬린다는 뜻이므로 피해야 한다 p87
일반적으로 출력인수는 피해야 한다. 함수에서 뭔가의 상태를 변경해야한다면 함수가 속한 객체의 상태를 변경하는 방법을 택한다. p87
오류코드보다 예외를 사용하라
... 오류코드를 반환하면 호출자는 오류코드를 곧바로 처리해야 한다는 문제에 부딪힌다. ... 반면 오류코드 대신 예외를 사용하면 오류처리코드가 원래 코드에서 분리되어 코드가 깔끔해진다. p89
try/catch 블록은 원래 추하다 코드구조에 혼란을 일으키며 정상적인 동작과 오류처리 동작을 섞는다. 그러므로 try. catch 블럭을 별도 함수로 뽑아내는 편이 낫다. p89
좋은주석 :
의도를 표현하라
결과를 경고하는 주석 // 실행이 오래걸린다, 스레드에 안전하지 못하다, todo 등
하지만 팀은 지저분한 테스트코드를 내놓으나 테스트를 안하나 오십보백보라는 아니 오히려 더 못하다는 사실을 깨닫지 못했다. 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다. 그런데 테스트코드가 지저분할 수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. 실제 코드를 변경해 기존 테스트 케이스를 점점 더 통과하기 어려워진다. 그래서 테스트 코드는 계속해서 늘어나는 부담이 되어버린다. p186
... 테스트 코드는 실제 코드 못지않게 중요하다. 테스트 코드는 이류시민이 아니다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지않게 깨끗하게 짜야한다. p186
클린 테스트코드를 만들려면? 세가지가 필요하다. 가독성, 가독성, 가독성 p187
build-operate-check pattern p190 ( acceptance test pattern)
가장 좋은 규칙은 개념당 assert 문수를 최소한 줄여라. 와 테스트함수 하나는 개념 하나만 테스트하라 라고 하겠다. p196
클린테스트의 다섯가지 규칙
fast : 테스트는 빨라야한다
independent : 각테스트는 서로 의존하면 안됨다
repeatable : 어떤환경에서도 반복가능해야한다
self-validating : 테스트가 스스로 결과를 판단해야한다
timely : 테스트는 적시에 작성해야한다. 실제 코드를 구현하기 직전에 작성한다.
단일책임원칙 : 클래스나 모듈을 변경할 이유가 단하나뿐이어야 한다 srp p203
지난 수십년동안 쌓아온 경험에서 얻은 교훈이라면,프로그램은 과학보다는 공예에 가깝다는 사실이다. 클린 코드를 짜려면 먼저 지저분한 코드를 짠뒤에 정리해야 한다는 의미다. p274
상수 인터페이스 대신 static import를 사용하라 p412
상수 대 enum 메소드와 필드도 사용가능하다
p 413
www.qualitytree.com
가끔 전자제품을 구입할때 설치기사의 행동에 관심을 가지게 된다. 가능한 주위환경이 손상가지않게 하면서 효율적인 도구를 사용한다.
그리고 설치결과를 설명하고 연락가능한 명함을 남기고 주변을 정리한 다음 자리를 뜬다.
우리도 이왕이면 돈받고 일하는 프로답게 일을 처리하면 좋겠다는 생각이 든다.
이 글은 스프링노트에서 작성되었습니다.
itistory-photo-1