뭐… 이 친구의 뭣같은 이야기도 조금씩 쓰다보니 뭐 여러모로 많다만…. 이건 좀 아주 제대로 초짜짓을 해놓고 나간지라 맘 속 깊이 우러나는 맘으로 욕을 적고 시작한다.
코드 재사용… 좋은 이야기다. OOP 배우면서 누구나 다 들은 이야기이다. 맞는 이야기이기도 하고… 근데 이놈의 코드 재사용 관련된 이야기로 내 개발자 인생에서 미친듯이 욕을 하는 인간이 둘이 있는데, 지금 글쓰는 반면교사 녀석이랑 커스텀 컨트롤러 개발하면서 여러 관련된 컨트롤을 전부 상속 7번을 해서 7개의 각각의 컨트롤을 만들었는데, 중간에 이상한 논리로 만들어서 3번째 이하의 모든 컨트롤러들이 다 꼬였는데 전체적인 디자인상으로 맞는 코드인데 오류가 난다고 나한테 박박 우겨먹다가 나랑 대판 싸웠던 S군이 있다. (S군은 내가 온라인으로는 이번에 처음 이야기한다. 오프라인 사석에 있을 때 어쩌다가 연관된 이야기 나오면 이야기 많이 하는 편이다. 근데 이 친구 아이러니하게도 한국에선 지금 유명한 개발자 중 하나다.)
개발하면서 새로운 클래스나 커스텀한 클래스들을 만들어서 이용하는 경우가 많이 있다. 당연한 것이기도 하다. 근데 이게 분석상에 여러모로 문제가 있어서 제대로 된 재사용 가능한 코드를 만들어내지 못하는 경우가 많다.
이 오씨 친구의 경우에는 그냥 한 화면에 하나의 테이블 구조만 가지고 이용하면서 CRUD를 할 것이니깐, 이 테이블을 간단하게 보여주면서 CRUD의 서브 동작을 하는 하는 Detail 도큐먼트, 딱 두개만 이용하는 구조로 프로그램 뷰 모델 구조를 짜면 되겠지? 라고 해서 프로그램을 개발했다. 실제로도 고객 정보 관리하는 곳에 고객의 정보를 간략하게 보여주는 리스트 형태의 뷰와 CRUD 동작에 필요한 테이블 내용을 보여주면서 이용할 Detail 화면이 한 쌍으로 동작한다. 그리고 다른 관리, 예를 들어 직원 관리에도 이런 식으로 작업을 했고, 아이템 관리에도 이런 식으로 작업을 했다.
문제는 다른 화면들에서는 더 이상 이런 구조로 이용되는 곳이 설계상에 한곳도 없었다. 심지어 기본적으로 이용하는 고객조차도 고객과 연관된 다른 포인트 정보라던가 또 다른 정보가 있을 경우에는 여러 테이블이 당연하게 엮이게 되었다. 그런데도 불구하고 그런 걸 신경 안쓰고 그냥 테이블 개체 하나만 끌고와서 이용하는 식으로 개발을 했다. 요구사항에도 기본적으로 있던 작업인데 그걸 나중에 확인하고는 이렇게 개발했으니 수정 못한다 이러고 배짱질을 부렸다.
그리고 이런 식의 구조 프로그램이 여러 곳에 있었다.
개발 사항에 열전사 프린터(흔히 말하는 영수능 프린터) 장비가 몇 대나 지원 될 예정이었는데도 불구하고 출력할 내용에 대해서 공통화 하는 작업을 진행하고 그걸 프린터별로 하나하나 다 구현하는 멍청한 짓을 해놨는데 자기는 출력 내용에 대해서 공통적으로 했으니 이게 최선이라고 지랄한다. 어디서든 똑같은 환경으로 재사용성이 되어있는 운영체제 라이브러리를 갖다 버리고는 말이지…. 아주 그냥 전 세계 모든 열전사 프린터들을 전부 일일이 하나하나 전부 다 SDK 맞춰서 다 구현할 패기가 있었나봄. ㅡㅅㅡ
UI 모듈화도 요즘 추세이긴 하다만 한번 쓰고 다른 곳에서 똑같이 안쓰이는 모듈화는 해봤자 노가다인 작업일 수 있다. 그 모듈이 다른 곳에서 똑같이 쓰인다는 보장이 있어야지만 모듈화를 하는 것이지 그렇지 않다면 그냥 UI 이쁜 컨트롤만 알아서 만들어서 이용하는 거 외에는 그냥 시간만 버리는 짓이기 때문이다. 실제로 재사용성 하나도 없는 코드인데도 불구하고 그놈의 재사용성에 틀에 맞춰서 처음 요구사항과 다르게 나온 코드를 가지고 “그냥 다른 곳에서도 이렇게 하니깐 이렇게 해봤어요.” 라고 하면 대체 뭐하잔 건지….
이러다가 한곳 터지거나 요구사항과 다른 부분들이라서 수정하려고 건들면 다른 곳에서도 막 다 터지고 아주 개난리 부르스가 나서 오씨가 수정 못한다고 빡빡 우기는 바람에 회사 사람들이 그냥 포기해야 되나 싶었다고 했다고…… (그리고 그걸 내가 다 수정하고..ㅠㅠ)
그리고 이 병신짓 땜에 요구사항을 바꿔야 했던 미친 이야기를 듣고 말도 안되는 짓이라 내가 다시 원래대로 돌려놨다는 건 안비밀…..
아우 씨….
뭐… 재사용성이라는 말에 꼬여서 실제로 사용 되지도 않을 재사용성을 강조한 코드 만들고, 나중에는 거기에 눌려서 수정 못한다고 만들어 버리고, 나중에 다시 개발해야 되는 그런 경우 진짜 많다. 근데 그걸 충분히 알려주지 않은 윗분들이나 요구사항 잘못이라고 하면… 책임론 물고 싸우자는 거지.
재사용성의 강조는 솔직히 해야 한다. 해서 나쁠 거 없는 이야기다만… 제대로 모르는 상태에서 막연하게 이렇게 설계하면 재사용성 OK임 이렇게 하면 진짜 미친 짓이다. 엄청 무모하다. 특히 어디로 가야 할 지도 모르는 백지상태에서의 초기 개발에서는 그냥 짜놓고 나서 나중에 리펙토링 하는 게 낫다고 말할 수 있다.
그리고 의외로 신입 개발자들이나 아직 학생 단계에서 못벗어나는 개발자들이 많이 하는 짓이기도 한데, 자기들이 수업시간에 배운 디자인들의 경우에는 이게 이론 배운 거 생각하고 그냥 들어보니 아 이거네 하고 단순하게 생각하는 경우가 많다. 실제로 하나하나 제대로 요구된 내용을 생각해 보면서 오랜 경험이 있는 개발자와 이야기를 나누다 보면서 일반적인 디자인에 가깝게 가는 것이지 그냥 몇 안되는 예시로만 대충 배워놓은 거 그대로 적용하면 되겠지 하고 하다가 이러는 경우 무지 많은데….
쉬운 거 아니다. 그렇게 막연하게 만든 코드 나중에 재사용이고 나발이고 그냥 버그 버그 코드다.
그리고 이런 똥질 지랄같이 해보고 나서 나중에 자신만의 코드들이 하나 하나 만들어지는 건데…. 어정쩡하게 자신이 만든 코드 안버리고 그러면 진짜 죽어난다.
p.s. ….오늘 글 제대로 썼는지 모르겠다.. 이놈의 오씨가 재사용성 강조하면서 나온 이야기들 중에 재사용성하고 거리가 엄청 먼데도 불구하고 재사용 재사용 강조한 녀석의 예시가 너무 많아서 진짜….
하… 이 글 아직 쓸 거 많은데 도중에 삐걱거리는 거 같다 진짜…ㅠㅠ