내가 생각하는 클린코드란?
간결해야하고 잘 읽혀야한다.
즉, 각 객체가 자신이 맡은 일'만' 충실해야하고 이 일 저 일 뒤죽박죽 하면 안된다.
하나의 클래스는 하나의 업무를 하나의 메소드는 하나의 작업만을 해야한다.
변수명, 클래스명 작명에 힘을 써야한다.
비즈니스 예외를 잘 처리해야한다.
테스트하기 쉬워야한다.
클린한 코드는 하는일이 명확해야하고 한가지일에 집중해야하고 부수효과가 없을수록 좋다.
부수효과가 없을수록 좋다는건 맡은일에 관한 일만 처리하고 그 외에 다른부분에 영향이 없다는 것이다.
부수효과가 없으면 테스트하기도 덩달아 쉬워진다.
간결하게 잘 분리된 클래스, 메서드는 읽기가 쉽다. 복잡하지 않다. 복잡하지 않으면 실수가 발생할 확률이 줄어든다.
코드가 간결하면 논리적인 파악이 잘되고 코드를 지속적으로 개선하기 쉬워진다.
반면 길고 복잡하고 여러가지 일을 하는 코드는 방치되기 쉽다. 왜냐하면 어느부분에서 사이드이펙트가 발생할지 무섭기도 하고, 코드가 너무 길고 복잡해서 읽고 손댈 엄두가 안나기 때문이다.
예외를 잘 처리하지 않으면 의도치 않은 오류나 데이터가 생성될 수 있다.
비즈니스 예외는 적절히 잡아서 사전에 정의된 예외에 대한 처리를 한 후 예외코드를 리턴하고
복구불가능한 프로그래밍 예외는 롤백하고 마찬가지로 사전에 정의된 예외에 대한 처리를 한 후 예외코드를 리턴한다.
클라이언트에서는 예외코드에 따른 적절한 예외 메세지를 표현한다.
그리고 객체와 메소드를 분리하다보면 너무 잘게 쪼개져서 오히려 복잡도와 실수를 유발시키는 경우도 있으므로 그럴 경우 적절한 응집도 필요하다.
맡은바 역할에 충실하고 간결하고 뚜렷한 이름을 가진 객체를 만들고 지속적 관심을 가져야한다.
------------------------------
요즘에는 보면 많은 개발자가 비즈니스 개발에만 집중하기 위한 설계에만 집중하고 있는 것 같다.
이게 무슨말이냐면 수많은 프레임웍, 디자인패턴, 설계원칙의 탄생배경과 궁극적으로 추구하는 목적의 꼭짓점은 결국 '개발자가 비즈니스로직에만 집중할 수 있도록 도와준다' 는 것이다. 결국 개발의 핵심은 비즈니스, 도메인, 업무를 코드로 정확히 표현해서 빈틈없이 깔끔하게 작동하는 것이라고 나는 생각한다. (어찌보면 너무 당연한 말인가..)
헌데 최근 많은 개발자의 주요 관심사는 디자인패턴, 설계원칙 그 자체다. 우아하고 세련되게 설계하는 것을 개발의 최우선 과제로 여기며 거기에 너무 매몰돼있다는 느낌을 많이 받는다.
즉, 설계의 멋에 너무 빠져있다는 뜻이다. 개발을 하다보면 분명 설계의 우아함에 빠지는 경우가 있고 그런 시기도 당연히 필요하며 거쳐가야하는 시기라고 생각한다. 나 또한 그랬었고..
하지만 결국 본질은 비즈니스 개발이란걸 깨닫고 비즈니스 개발을 깔끔하고 명쾌하게 해내는게 중요하다.
설계가 중요하지 않다는 것이 아니라 설계의 멋에 지나치게 빠지는걸 주의하라는 뜻이다.
무슨 아키텍처, 무슨 프레임웍 레퍼런스 문서를 보면 '이걸 쓰면 비즈니스로직 개발에만 집중할 수 있도록 도와준다.' 라는 내용을 자주 접하곤 하는데 그 말처럼 집중해야하는건 비즈니스 로직이다.
때론 코드가 우아한 것만을 추구해야하지 않을 때도 있다. 프로젝트에 따라서, 일정에 따라서, 요구에 따라서 개판으로 휘갈기는 경우도 생길 수 있다. 훗날 다른사람이 봤을때 의아할 수 있지만 코드에는 그 프로젝트의 여러가지 히스토리가 녹아있을 수 있음을 이해해야 한다.
피튀기는 전쟁터에서는 모범적인 사격 자세를 취하고 총을 쏘는게 아니라 고개는 숙이고 총을 머리위로 들어서 마구잡이로 갈겨대야하는 경우도 있다는 것이다.
이벤트주도, 도메인주도, 책임주도 등등.. 수많은 주도개발방법론들 역시 비즈니스 개발을 효율적으로 하기 위한 방법론이다. 방법론 그 자체가 중요한게 아니고 내가 만들어야할 비즈니스가 핵심 그 자체라는 것이다. 방법론은 내가 만들어야할 비즈니스에 적합한 걸 선택해야 할 일이지, 방법론 자체가 최우선이 되면 안된다.