개발 서적을 열심히 읽기로 결심을 해서 구매하게 된 읽기 좋은 코드가 좋은 코드다 라는 책이다.
여태 정리를 할 수 없어서 한번에 여러 장을 올려야 할 것 같다.
개발 직무에 흥미를 느낄때부터 뭔가 사람들에게 가독성이 좋은 코드를 만들어야 한다는 생각이 많이 들었었다.
그리고 변수를 설정함에 있어서도 혼자 개발할때는 대충 그때만 알 수 있게 여태껏 짜왔던것 같다.😅
그리고 그 변수위에 주석으로 어떤 일을 처리하는지 조금씩 적어서 개발을 진행했었는데 실무를 들어와서는 협업을 항상 하기 때문에 변수, 메소드, 클래스 등등.. 코딩 컨벤션에 맞춰감과 동시에 그 안에서 이름으로 내가 짠 코드를 다른사람이 읽을 때 어떤 기능을 하는 것인지 알 수 있게 가독성을 높여야 한다고 생각했다.
그래서 이 책을 먼저 읽어보자 해서 구매하게 됐다.

1장 - 코드는 이해하기 쉬워야 한다.

코드를 작성할 때 가장 중요한 지침을 제공하는 원리가 바로 이것이어야 한다.
간결하게 짜는것이 가독성에는 굉장히 좋지만서도 길어지는 조건식에 대해서는 논리정연하게 if-else구문을 사용했을때 더 친숙하게 느껴질수 있다.

가독성의 기본 정리

• 코드는 다른 사람이 그것을 이해하는데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.
  • 내가 작성한 코드를 읽고 이해하는데에 걸리는 시간 = '이해를 위한 시간' 이다.
    내가 쓴 코드 남이 이해하든 말든 상관없다 → 여기서 남은 내가 될 수도 있다. 이 글 최상단에서 내가 혼자 개발할 때 대충 그때만 알 수 있게 짜왔다고 얘기를 했다. 예를 들어 6개월정도 뒤에 다시 그 소스를 열어봤을 때 시간을 최소화 하여 이해가 가능할까? 라는 생각이 여기서 많이 들게 되었다.
  • 결론 → 어떤 일이 일어날지 누구도 모른다. 그렇기 때문에 항상 남을 위해 배려하는 코드를 짜자.
• 분량이 적으면 항상 더 좋은가?
  • 분량이 더 적은 코드로 똑같은 문제를 해결한다면 좋다 하지만 아까도 말했듯, 이해하기 힘든 람다식 또는 조건이 긴 삼항연산자를 사용하기 보다는 주석을 사용해서 이해를 돕거나 조건식을 짧게 여러개를 사용하는 것이 이해를 위한 시간을 최소화 할 수도 있다.
• 이해를 위한 시간은 다른 목표와 충돌하는지
  • 코드의 효율성, 잘 구성된 아키텍쳐, 테스트의 용이성 다른 제약 조건도 고려해야 하나? ❌
    코드를 읽기 쉽게 만든다면 테스트하기 쉬운 코드를 작성하게 할 수 있고, 잘 구성된 아키텍쳐를 만들 수도 있을 것이다.

1장에서 느낀 것은 코드를 항상 내가 이해하는 것도 중요하지만 무엇보다 혼자 가 아니다. 그래서 항상 특정 누군가를 정하지는 않지만 다른 사람들을 위해 이해하기 쉽고 그 이해하는 시간을 최소화 하며 가독성을 높이는 코드를 짜서 배려하는 개발이 생활화 되어야 한다고 느꼈다.

이 노력과 더불어 코드 리뷰를 다 같이 적극적으로 시간을 투자한다면 아키텍쳐의 구성은 엄청 좋아질 것이라고 생각한다.
이상 1장 - 코드는 이해하기 쉬워야 한다 포스팅을 마친다.