참 오랜만에 글을 남깁니다. 우리의 이 망할 반면교사 오씨….
회사 일 외에도 요즘 강의자료 만드는 걸 좀 도와달라고 해서 그거 좀 같이 해주고 있다가 오랜만에 글쓰네요….ㅠㅠ 시작할께요.
오씨의 코드에서는 여러 치명적인 단점들이 엄청나게 있는데… 오늘은 코드 쪼개기, 모듈화에 대해서 이야기를 하려고 한다. 제대로 병신같은 형태로 과도하게 쪼개고 이상한 형태로 모아두면서 재사용성 강조한다면서 해놓은 짓이….
본인 스스로의 가독성을 떨어뜨려서 어디다가 구현했는지도 모르고 어떻게 수정해야 되는지도 모른다는 것이 말이 되냐?!!!?!!?!?!?
이런 쓰레기 구조를 일주일만에 싹 다 정리했다만… 여전히 이해는 안되는 코드 구조였다. 아니, 구조 설계 자체를 아예 못하는 놈이다.
근데 이 내용에 대해서는 욕은 최대한 삼가려고 한다. 왜냐면 이 오씨는 expert beginner, 즉 초심자라고 생각하면 아주 정확하게 납득되는 실수를 했기 때문이다. 그러니 어딘가에서 이 글 보고 내 이야기인가 하고 찔리는 분이 있다면 경력자라고 나대지 마시길 제발….
객체지향 좀 배우고 과제용으로 코드 좀 짜고 하다보면 이제 코드 짜는 양이 제법 좀 많아지게 된다. 그렇게 되면서 많은 사람들이 코드 설계에 대한 이야기나 디자인 패턴, 그리고 클린 코드 관련된 내용들을 열심히 공부하는데…. 문제는 이걸 제대로 적용하는 법에 대해서 계속 생각하고 계속 연구해야 하는데 그걸 안한다. 왜 안할까? 공부를 중간에 끊어서? 설마… 그런 식으로 해서 살아남는 프로그래머가 얼마나 된다고요….ㅡㅅㅡ
저 내용들에 대해서 가르치려고 적어놓은 책들도 첨에 가르치는 내용들은 심플하다. 이렇게 해라 이렇게 해라라는 내용들이 사실 명확하게 되어 있다. 하지만 그 후에 나오는 내용들은 상당히 추상적이다. 왜냐면 프로그래밍 언어론이나 방법론 관련되어 나오는 이야기들이 상당히 추상적인 내용들이고 그걸 이해하는 추상적 사람들의 이야기를 그나마 구체화해놓은 게 우리가 보는 책들이기 때문이다. 그래서 솔직히 머릿속에 바로 안그려지고…. 그게 정상입니다.
정의는 상당히 간단한 내용들이다. 일전에 강의자료들 만들어주는 작업 하다가 나왔던 내용들인데 그 중에서 기억 남는 것들만 좀 적어보자면 “특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. 명확하며 최소로 줄였다. 때로는 명확하게 드러내기 어려우므로 언어에 따라 문학적 표현도 필요하다” (실용주의 프로그래머인가…? 기억나는대로만 적었다..), “깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.” (이건 아마 객체지향 대가인 그래디 부티씨 말일껍니다.), “깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 아마 모든 사항을 고려했으므로 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.” (이건 마이클 페더즈씨의 책이었는데… working effectively with legacy code인가 하던 책이었을 겁니다.), “중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. 내게는 이 세 가지가 깨끗한 코드를 만드는 비결이다.” (이건 최근에 자료 참고용으로 뭐 있나 봤던 extreme programming installed에서 봤었습니다.) 등등 여러 자료들에서 많이 말 합니다…
내용 보면 참 추상적입니다. 그리고 이분들의 책들 또한 엄청나게 추상적이죠. 그리고 이걸로 학창시절에 머리 좀 싸메는데…. 다들 골때리는 상황들이 벌어집니다.
강의때 들은 내용하고 그 내용에 나온 예시대로 열심히 암기 잘 하고 이해 잘 하고 해서 난 A+도 받았었던 인간인데 왜 실무에서 개고생을 하는거지? 경험이 없어서? 삽질 안해도 우리는 충분히 요구를 이상화 할 수 있는데? 라고 생각하실 수 있겠죠….
근데 죄송하지만 현실의 어느 시스템도 이상적인 방식으로 개발되지 않고, 앞으로도 이상적인 것에 정확하게 맞아 떨어지는 시스템은 없을 겁니다.
심지어 여러분이 열심히 학창시절에 보시고 보신 교과서나 논문에 적힌 프로그램들조차도 이상화에만 매달린 코드입니다. 이상적인 내용에 대해서 계속 개선되고 그에 맞게 수정되는 과정을 처리면서 저자가 바라는 바를 보여주는 좋은 예시, 좋은 설명, 좋은 이해방법이 들어있지 현실적으로 어떤 걸 어떻게 개발해야 할지도 그리고 그에 따른 어떠한 과정도 보여주지 않습니다.
즉, 인생은 실전이다입니다!!!!
그래서 여려모로 노력해서 자신만의 노하우, 아니면 자기 팀만의, 자기 회사만의 노하우들이 공유되고 하면서 발전하는 것입니다. (그래서 오픈소스들이 대단한 것이죠.)
이게 코드 개발하면서 벌어지는 코드 구조에도 솔직히 엄청난 영향을 줍니다. 그 중에서도 코드 분량을 줄이고 재사용을 잘 하기 위해서 여러모로 쪼개놓는데….
어디서는 단 한번만 쓰이고 버려지는 코드까지도 쪼개놓습니다! 그리고 그걸 뒤지는 데 몇십단계를 거쳐야지만 겨우 찾습니다!! 근데 아무 동작도 안하는 쓸데없는 녀석입니다!!! 필요없어서 지워버리니깐 다른 곳에서도 쓰인다는 걸 확인합니다!!!!! 다른 코드들도 싹 다 건드립니다!!!!!!!! 그리고 또 다른 곳에서 터집니다!!!!!!!! (반복)
이 짓 땜에 쓸데없이 만들어놓기만 했는데 정작 기능에는 아예 쓰이지 않는 클래스, 인터페이스들만 해서 300개가 넘었습니다. ㅡㅅㅡ
이쯤되면 미친거죠.
저걸 싹 다 고쳐서 정리하느라 3일을 버렸습니다. 근데 진짜 저것들 없어도 본 기능에 아무 문제도 없습니다.
그리고 프레임워크, 라이브러리, API에서 표준으로 제공해주는 걸 최소한으로 이용해 보겠답시고 본인만의 코드들을 중간에 막 집어넣는데 이것도 또 쪼개고 쪼갰는데….
문제는 이 쪼개고 쪼갠 것들이 싹 다 꼬였습니다. ㅡㅅㅡ 이것들도 고칠만큼 고쳤는데… 나머진 진짜 시간이 진득하게 필요합니다.
그리고 이렇게 쪼개고 쪼갠 녀석들은 해당 기능에 대한 단위 테스트를 할 수 있어야 하는데… 쪼갠 녀석들이 결합도는 절차지향의 대명사인 C 코드 저리가라 할 정도로 강합니다. (…..)
그러니 밑에서 오류가 나서 이상을 하나 수정하면 그 위에 이상도 수정해야 되는 루프의 만남이….
미친겁니다.
전 팩토리, IoC, DI를 써보겠답시고 코드에 덕지덕지 썼으면서도 이런 분리 제대로 안되면서 파일하고 디렉터리만 몇십개 단위로 쓸데없이 쪼개서 코드 만들어내는 오씨한테 진짜 깊은 빡침과 깊은 반면교사를 배웠습니다.
설계 제대로 된 코드 정말 중요한 코드입니다…. 설계 아예 안된 코드보단 좋아요….
회사에서 코드로 협박하고 하던 녀석이 이런 걸로 협박을 하는 거였나요……
하 진짜….