TIL (Today I Learned)

// 2022.02.19

오늘 읽은 범위

// 추천사 ~ 1장. 깨끗한 코드

책에서 기억하고 싶은 내용을 써보세요.

• 소프트웨어는 80% 이상이 소위 “유지보수”다. 고치는 활동 말이다. 좋은 소프트웨어를 만드는 데 치중하는 전형적인 서양식 사고를 포용하는 대신, 우리는 좀 더 건축 업계의 수리공이나 자동차 업계의 수리공처럼 소프트웨어 개발자를 생각해야 한다. - xxiii (추천사)

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

• 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다. 추상화도 불가능하다. 정확히 명시하는 수밖에 없다. 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다. - 2p (1장. 깨끗한 코드)

• 나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어 지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. - 7p (1장. 깨끗한 코드)

• 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 ‘집중’한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다. - 10p (1장. 깨끗한 코드)

• 좋은 소설과 마찬가지로 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다. 긴장을 쌓으며 클라이맥스에 이르렀다가 명백한 해법을 제시하며 긴장과 문제를 풀어야 한다. 독자가 “아! 당연하지!”라며 무릎을 탁 치도록! - 11p (1장. 깨끗한 코드)

• 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 이 책을 읽으면서, 이제껏 코드를 짤 때 디테일이 아닌 모양새에만 너무 신경을 쓰지 않았나하는 생각이 들었다. 글을 쓸 때는 독자의 가독성을 고려하면서 쓰면서, 왜 코딩을 할 때는 그러지 않았을까하는 반성을 했다. "깨끗한 코드는 잘 쓴 문장처럼 읽힌다."라는 문장을 읽고 꽤나 찔렸다.

• IT 업계 뿐 아니라, 산업 전반에서 고객의 요구를 경청하고, 이를 신속, 유연하게 제품에 적용하는 과정을 계속해서 반복하는 것은 매우 중요한 문제가 되었다. '클린 코드'는 그런 흐름에 발맞추기 위해 꼭 필요한 개념이라는 생각이 들었다. 저자의 말마따나, 코드는 작성하는 시간보다 읽는 시간이 훨씬 많이 소요되는데, 당장 구현해야하는 기능에만 초점을 맞춰 코드를 작성한다면 당장은 시간이 적게 걸릴지 몰라도, 매번 수정을 거듭할 때마다 그 시간은 기하급수적으로 늘어날 것이고, 나중에는 손을 쓰지 못할 지경에 이를 것이다. 협업의 비용을 줄이기 위해서, 프로그램을 운용하면서 손 쓸 수 없는 없는 문제를 만들지 않기 위해서 내가 좀 더 시간을 들이고, 더 신경을 써야겠다는 생각이 들었다.

• 중복을 피하고, 표현에 신경쓰고, 코드를 작성하는 초반부부터 간단한 추상화를 구현함으로써 클린 코드를 만들 수 있다는 론 제프리스의 말은 향후 코드를 작성할 때 내게 새로운 지침서가 될 것 같다.

• 앞으로 글을 작성할 때 독자들을 고려하는 것처럼, 코드를 작성할 때도 독자를 고려해야겠다는 다짐을 할 수 있었던 것이 이번 시간의 가장 큰 수확이었던 것 같다. 앞으로 클린 코드를 작성하기 위한 요령들을 이 책을 읽으며 배우는 것도 중요하겠지만, '깨끗한' 코드를 작성하기 위한 습관을 들이고, 그 습관을 일상 속에 스며들도록 하는 것이 더욱 중요하다는 생각이 들었고, 그러기 위해 계속 '주의'하면서 코드를 작성해야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 처음, 추천사 부분에서 애자일과 스크럼에 관해 언급했는데, 스크럼이란 개념을 처음 접했다. - 스크럼이란 애자일 방법론에 잘 부합하는 개발 방법으로, 소규모의 팀을 구성하여 스프린트라고 불리는 업무 주기를 반복하는 것이다.

• 집합의 추상화에 관해 설명하는 대목이 명확하게 이해되지 않은 것 같다. - 추상화란, 고통의 속성이나 기능을 묶어 새로운 이름을 부여하는 것. 사이즈가 큰 코드를 다룰 때, 추상화는 책에서 언급했듯이, 진짜 문제에 집중할 수 있게끔 해줄 수 있을 것 같다. 얼마 전까지 군대에 있는 동안 코딩을 한 적이 없어서, 다시 경험을 쌓아가는 과정이 필요할 것 같다...