대학 1~2학년이면 배우는 "자료구조(Data Structure)"라는 과목이 있다.
그 교과서의 핵심적인 문장 중 하나는 다음과 같다.
프로그램은 자료구조와 알고리즘의 조화에 달려 있다.
그 두 개는 프로그램을 지탱하는 두 기둥이다.
완전히 따로 떼어 놓을 수도 없고 가끔은 trade off도 해야 한다.
Module화 프로그래밍은 알고리즘을 중시한 것이고
OOP는 자료구조를 중시한 것이다.
물론 OOP에서도 알고리즘이 중요하지만 Module화에 비해 자료구조의 중요성을 강조하고 있다.
OOP가 만능은 아니지만 두 기둥 중 하나인 자료구조를 경시하지 않는 다는 면이 소프트웨어 공학적으로 멋진 것 같다.
Module화 프로그래밍에만 익숙한 과거의 C언어 개발자는 자료구조를 소홀히 하는 경향이 더 많은 것 같다.
시시한 개발자는 자신의 알고리즘만 설명하고(자료구조는 단지 보조적인 버퍼, 기억장소 정도로 생각한다.)
뛰어난 개발자는 자료구조와 알고리즘을 조화롭게 설명하는 것 같다.
그리고 알고리즘만 중시하는 개발자는 자료구조가 복잡하다.
리팩토링을 잘 안하는 개발자들과 함께 프로젝트를 할 때도 마찬가지 인 것 같다.
(그리고 언젠가는 그 모든 코드의 유지 보수를 떠맡게 된다면.)
그들과 소스코드, library, tool들을 interface로 공유하는 건 상당히 괴롭다.
그들은 자신들의 코드를 자신을 포함한 누구도 손댈 수 없을 만큼 복잡하게 만들어 버리고
나마저 그들은 source repository에 commit을 시도한다면 같이 난장판 전쟁 속에 휘말리게 된다.
그들과 약간의 거리를 두면서 data만 공유하는 것이 낫다.
(자료구조만 공유)
그럼으로써 그들의 복잡도도 낮춰주고(내가 난장판에 참여하지 않으므로써..)
자료구조를 하나씩 공유해 가면서 그 영역을 늘려가면서
자료구조 중심으로 Interface 등을 재편하면서 하나씩 흡수해가면서 refactoring하거나 다시 짜면된다.
일단 자료구조만 동일하게 된다면 어떤 식으로 짜도 되니까.
자료구조는 알고리즘의 input과 output. 즉 가장 가장자리의 문제이다.
그 안의 black box를 isolate시킬 수 있게 되니, 내가 쉽게 refactoring할 수 있다.
이렇게 해서 스파게티 C코드를 잘 정리해서 C++로 바꿔가야 할듯...;;
문제는 이미 서비스하고 있는 코드들 인데. C++로 개발버젼의 코드를 바꿔도
서비스는 보수적이라고 과거의 코드를 유지하기 마련이다.
서비스에 있는 코드는 내가 해결하던지, 경영의 측면에서 봤을 때는 재빨리 다른 사람 - 운영팀 - 등으로
넘겨서 책임을 회피하는 편이 나을 수도 있다. (처세술...)
음.. 갑자기 이야기가 C++로 넘어갔는 데.
C++로 짜기 시작하면 기존의 C 개발자들이 내 코드를 호출하거나 사용하지 못하게 되서 수정하려는 시도도
하지 않을 테고(쩝..) 그런면에서 편하다는..
댓글 없음:
댓글 쓰기