클린 코드 #19일차

 

TIL (Today I Learned)

 

• 2022.03.08

 

📕 오늘 읽은 범위

 

• 10장. 클래스

 

🙂 책에서 기억하고 싶은 내용

 

• '클래스는 작아야 한다!' (p.172)

 

• '단일 책임 원칙(Single Responsibility Principle, SRP)은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.' (p.175)

 

• '문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어’라는 다음 관심사로 전환하지 않는다. 프로그램 으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.' (p.176)

 

• '큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.' (p.179)

 

• 'OCP(Open-Closed Principle)란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다. (...) 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장 할 뿐 기존 코드를 변경하지는 않는다.' (p.188)

 

🤔 오늘 읽은 소감은?

 

   예전에 구직 중 신입면접때 정확하게는 기억이 안나지만 이런 비슷한 질문을 받은 적이 있었다. '우리가 프로젝트를 진행하면서 추상클래스를 작성하게 된다면 그 이유가 어떤 것들이 있을까요?' 허겁지겁 주입식으로 채워넣은 이론들과 긴장때문에 아마 면접관이 만족할만한 답변을 내놓지 못했고, 속으로 '차라리 알고리즘이나 코딩문제를 물어보지😂' 라며 한탄을 했었던 기억이 있었다. 면접관은 친절하게도 설명을 해줬었는데 그 중에 기억이 나는 것들은 '협업에 있어서 구성원들간 추상클래스를 확장하게 함으로써 표준을 제시할 수 있다.' 등이 있었다. 추상클래스를 자주 접하면서 막상 왜 사용할까 라는 부분은 깊게 생각을 못했던 것이다. 단순하게 '코드 반복을 줄이기 위한 재사용성?' 정도로만 생각했었지 의문을 가지진 않았다. 의문을 가지고 좀 더 구조와 필요성에 대해 생각을 해봤으면 면접관에게 적어도 내가 가진 생각과 기준을 자신있게 말할 수 있었을지도 모르겠다.

 

   그렇다면 클래스를 최대한 작게 잘게 쪼개는 이유는 무엇일까? 책에서는 독자의 가독성과 SRP(단일책임원칙)을 준수하여 추후 수정 등 유지보수의 용이함을 말하고 있다. 왜 SRP를 준수해야 유지보수 효율이 올라갈까? 수정함에 있어서 다른 기능이 연결되어 있다면 다른 부분도 수정을 해줘야 할수있고 놓친다면 오류가 발생할 수 있기 때문이다. 또 기능별로 분리가 되어있어야 테스트도 용이해진다.

 

   클래스의 기능을 쪼개고 기능별로 어떤 것들은 추후 확장 및 구현되도록 하여 유지보수 효율성을 증대시킨다. 막상 실천하려고 하면 쉬운 작은 아니다. 어떤 곳은 아예 클래스, 함수 별 권장 줄 수를 정해서 맞추기까지 한다. 우리는 이유를 알아야한다. 팀의 규칙을 정할때, 협업 내에서 틀을 맞출 때 이유를 알아야 목적에 따른 더 좋은 방안이 나올수도 있고 배를 산으로 옮기는 것을 방지할 수도 있다.