Post

Clean Code ~Ch.8

8장의 내용이 짧기도 할 뿐더러 좁은 내용을 설명해서 내용이 많이 짧다.

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다.

개발자만의 특별한 문화가 있다. 바로 오픈 소스다. 기술자들이 자기만의 기술을 숨기는 것은 흔히 볼 수 있다. 당장 건설 현장 기술자(타일, 샤시 등) 얘기만 보아도이기술을 배우기 위해 일을 시작했지만 잡일만 하다가 그만 두었다는 말이 종종 들린다.

본인이 밥 벌어 먹고 사는 기술은 숨기는 것이 생존 본능인데 개발자는 반대로 (전부는 아니지만) 본인의 기술을 오히려 드러낸다. 이런 문화덕에 우리는 쉽게 개발을 시작할 수 있다. 개발 도중에 막히는 부분이 있다면 (특정 조건하에) 라이브러리를 수정할 수도 있다.

그래서 더더욱 경계가 중요해진다. 내가 만든 프로그램은 내 코드뿐만 아니라 다른 사람의 코드에도 영향을 받는다. 만약 내 코드와 타인의 코드가 프로그램 전반에 뒤섞여 있다면 타인의 코드 수정에 프로그램 전체를 수정해야할 수도 있다.

하지만 7장에서도 얘기했듯, 나는 성공하지 못 했다.. 클린 코드를 읽으며 꼭 잘 분리해서 코드를 작성하고 싶다..

Map(혹은 유사한 경계 인터페이스를) 여기저기 넘기지 말라

책에서는 Map은 어디서나 수정이 가능한 인터페이스이기 때문에 인자로 넘겼다가 예상치 못 한 곳에서 수정이 생겨 오류가 생길 수 있다고 한다. 이 부분에 대해서는 딱히 생각해본 적 없었는데 깨닫게 된 계기가 되었다. 사고 실험만으로도 큰 사고가 일어날 것 같다.

1학년때 C언어를 배우면 컴파일 에러를 수없이 많이 겪게 된다. 될 것 같은 코드는 컴파일 조차 안 된다. 알고나면 정말 사소한 에러지만 조금 시간이 지나면 이 때가 좋았다고 생각하게 된다. 포인터를 배우기 시작하면서 컴파일 에러보다 로직 에러가 더 많이 난다. 엄밀히 말하면 둘은 정말 다른 문제이지만 적어도 컴파일이 되고 실행은 되지만 프로그램이 예상대로 돌아가지 않는다는 점에서 비슷하다. 이 순간은 정말 미칠 것 같고 다 때려치고 싶었을 것이다. 후에 포인터에 익숙해지면서 정말 (여전히 어렵지만 우리가 배운 수준에서는) 별거 아니었구나고 알게 되겠지만…

근데 이것이 경계 인터페이스를 사용하면 겪게 될 것이라 생각하니 벌써 아찔하다. 이것만으로 충분히 와닿았다.

먼저 간단한 학습 테스트를 작성해서 외부 코드를 익혀라

의도한 것은 아니었지만 어느정도 이것을 지키고 있었다.

나는 개발을 할 때, test 폴더를 만들어두고 여기에 온갖 잡다한 라이브러리 테스트 코드를 작성하면서 사용해본다. 개발을 할 때 필요한 기능이 라이브러리를 사용한다면, 딱 그 부분을 라이브러리로 비슷하게 구현해본다. 라이브러리 업데이트 때마다 실행하며 확인해보진 않았지만 이제부터 해보면 될 것 같다.

또한 이것이 어느정도 개발실력에 도움을 줬다고 생각을 한다. 기능을 구현할 때, 내가 필요한 기능단위를 구분하는 능력이 생긴 것 같다.

우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.

감싸기 기법과 어느정도 비슷하면서 다른 것인지 모르겠다. 내가 생각하기는 비슷한 것 같은데 차이가 있으니 밥 아저씨가 구분을 해둔 것이라 생각한다. 이 문장을 선택한 이유는 이 의문에 대해 생각해보고 답을 내보았으면 하는 생각에 적어두었다.

This post is licensed under CC BY 4.0 by the author.

Trending Tags