클린 코드 : 애자일 소프트웨어 장인 정신

(1)

'클린 코드 : 애자일 소프트웨어 장인 정신' 은 개발자 필독서로 뽑히는 여러 책 중 한 권입니다. 클린 코드를 짜기 위해 여러 정석적인 내용이 많이 들어있습니다.

----

"핵심은 팀이나 공동체에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통에 있다."

"사소한 곳에서 발휘하는 정직은 사소하지 않다."
 - 코드를 하나의 단어, 문장, 함수로만 생각하면 모든 코드가 사소해 보입니다. 하지만 이 사소한 코드들이 뭉쳐 아키텍처를 이루고 시스템을 만듭니다. 그리고 고객에게 배포되죠. 그러니 애초에 코드를 쓸 때 한 단어, 한 문장을 쓰는 손짓에 집중하고 정직하게 작성해라 라는 느낌으로 받아들이면 될 것 같습니다.

"품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다."

"품질을 개선하기 위한 사소한 활동이 간단하다고 해서 단순하다는 뜻은 아니다. 쉽다는 의미는 더더욱 아니다."
 - 어디가서 "버그가 발생할 리 없습니다." / "좋은 품질을 어렵지 않습니다." 이런 얘기를 함부로 하는 개발자가 있다면 거리를 멀리 둘 것..

"주석은 나쁜 코드를 보완하지 못 한다."

"나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못 하다"
 - 간혹 다른 운영팀에서의 요청이 시스템에 안 좋은 영향을 미칠 수 있다면 우리는 STOP을 외치고 충분히 고민해야 할 필요가 있고 논쟁을 통해 좋은 방향을 만들어낼 책임이 있습니다.

"나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못 하면 개발 조직은 기어간다. 매년 지저분한 코드로 수많은 시간과 상당한 자원이 낭비된다."

----

역시나 거듭 빠지지 않던 내용은

 - "설계에 가장 많은 시간을 쏟아야 한다."
 - "믿음 있는 테스트와 함께해야 한다." (TDD 와 테스트 코드)

개개인의 성장이 뒷받침되어 서비스의 품질도 향상되고 이러한 개발팀의 노고가 고객들에게 이어졌으면 좋겠습니다.

(2)

"코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 어쩌면 '돌아가는 코드'가 전문 개발자의 일차적인 의무라 여길지도 모르겠다. 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 대해 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기  어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다."
 - 개발에 대해 잘 모르시는 분들이 가장 간과하는 것 중 하나 입니다. 왜 가독성을 위한 리팩토링을 하는 것이고, 왜 스타일에 집중하는지? 우리 팀원들은 공감하고 있어서 정말 다행입니다.

"좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이뤄진다는 사실을 기억하자, 스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다."

개념적 유사성을 기반으로 세로 순서, 세로 밀집도, 수직 거리, 가로 공백과 밀집도, 가로 정렬과 같이 제가 미처 많이 생각하지 못 했던 것 또한 나름의 이유와 함께 설명되어있는 부분도 많이 인상적이었습니다. 또 코드의 가독성을 단순 개선이 아닌 목적과 이유를 말하고 설득시킬 수 있게끔 발전시킬 수 있는 가능성을 책에서 찾을 수 있는 것이 매우 기분이 좋았..고..

저번과 마찬가지로 옳은 말씀만 많았지만 그래도 좋았습니다. 이제부터는 추상화, 클래스, 객체, 동시성, 테스트 코드, 휴리스틱 등의 어려운 말씀을 하시려고 하는 느낌이 들어 마음의 준비를.. 하려고 하고 저번 독서 공유 때 썼던 "사소한 곳에서 발휘하는 정직은 사소하지 않다."을 다시 한번 다짐하며 마무리!

(3)

“소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다”

“깨끗한 테스트의 다섯가지 규칙
 - 빠르게: 테스트는 자주 돌려야 하기 때문에 빨라야 한다, 자주 돌려야지 초반에 문제를 찾아내고 고치고 정리를 빨리 할 수 있다. 빠르지 못하면 사람이 지친다.
 - 독립적으로: 각 테스트는 독립적으로 어떤 순서로 실행해도 괜찮아야 한다.
 - 반복가능하게: 테스트가 돌아가지 않는 환경은 없어야 한다.
 - 자가검증하는: 결과는 무조건 성공 아니면 실패다. 스스로 가늠이 되어야 하며 핑계는 필요 없다.
 - 적시에: 테스트가 불가능하도록 실제 코드를 설계하지 않도록 적시에 단위 테스트를 고려하며 설계한다."

"테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 가끔 실제 코드보다 더 중요하다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.”

“좋은 리팩토링
 - 좀 더 길고 서술적인 변수 이름
 - 핑계 주석을 추가하지 말고 함수 선언과 클래스 선언부를 주석이라 생각하고 설계에 집착해보자
 - 공백과 형식 맞춤은 가독성을 위한 중요한 수단이다.”