소프트웨어를 개발노하우

완전 주저리주저리 두서없지만 나중에 퇴고하자.

 

<소프트웨어를 개발하면서 알게 된 노하우.>

직접 모든걸 개발하면야 너무 좋겠지만, 초보자인 나로서는 그럴수 없다.

따라서 협업을 할 수 밖에 없는 데 이 때 경험치로 알게된 주요한 원칙이 있다.

1. 의견 교신을 명확하게 해야한다.
 : 나는  A를 이야기 하면  그는 당연히 A를 이해한다. 하지만 이런 글들처럼 내가 원하는 내용을 A라고 쉽게 이야기할 수 없다. A라는 것은 A0 ~ A100까지 요소들의 합이다. 따라서 나도 당연히 A2, A24,A61,A57,A67,A88,A90,A91....나름 자세히 설명하려고 노력할 것이다. 여기서 말하는 A는 한페이지 또는 하나의 프로젝트를 일컫는 것이 아니다. 기능 하나를 말하는 것이다. 눈에 보이는 것은 설명하기 쉽다. 하지만 기능이나 개념은 상당히 명확해야한다. 어째든 말하고 싶은 것은 내가 이야기 하지 않은 A원소들의 나머지 부분들은 듣는 사람의 뇌가 전후관계를 따져서 요구한 사람의 의도와 일치되도록 자동처리된다. 우리의 뇌는 그렇게 되어 있다. 하지만 여기가 바로 아주 중요한 지점이다. 여기서 어긋남이 비롯된다.

요구자의 입장에서 당연하게 이야기 안해도 은연중에 머리속에서 자동 처리되는 그 A의 원소들은
만드는 사람입장에서는 텅 빈 A원소가 되거나 또는 그 빈 공간을 자신의 지금껏 경험한 어떤 스키마로 대체해버린다. 

자, 그럼 어떤 일이 발생하는 가? 이 문제를  재깍 알아차리면 쉽게 해결되지만 그걸 모른채 다른 기능이 덮어씌어지고 연결되는 개발이 이루어지고 나서 이것을 알게 되면 문제는 커지게 된다.

자, 바로 여기서 프로그래머와 의뢰인 혹은 기획자의 감정의 골이 깊어진다.

개발자는 개발자대로 어려운 개념을 이해하고 나름 열심히 만들었다. 하지만 기획자(의뢰인)입장에서는 분명 그렇게 말하지 않았는 데 개발자는 그렇게 이야기했다고 논쟁을 벌이게 된다. 이것은 누구의 잘못일까? 모두의 잘못이다. 의뢰인은 의도를 명확히 전달하고 반복하고 지속적으로 확인할 필요가 있다. 그것을 소흘히 했다. - 바르게 말했다는 전제하에.
개발자는 의뢰인이 이야기하지 않은 사실을 자기 스키마대로 미루어짐작하여 제작해버렸다. 완벽한 기획자가 아닌 이상에야 개발자는 수시로 이 방향이 맞는 지 의구심을 가져야 한다. 의뢰인 입장에서는 자꾸 간섭하는 게 될까봐 개발중간에는 말 걸기가 힘들다. 개발자도 한창 코드에 빠져있을 때는 중간에 스톱하고 묻기도 어렵다. 

협업이 이래서 어렵고 항상 모든 내용을 기록하고 남겨두는 게 좋을거 같다. 

따라서 결론 : 감정의 골이 깊어져서 일을 그르치기전에 명확히 이해했는 지 확인하고....사실 의뢰인도 뜬구름같은 바램만 있을 뿐이지 그것이 구현되기 전까지는 명확한 상상을 하기 힘들다. 하지만 그래도 최대한 명료해야한다. 건물도 명확한 설계도가 있어야 집을 짓듯이.....근데....설계도는 꼭 필요한 것이지만 그대로 일일이 집을 짓는다? 설계도가 그대로 가는 집은 본적이 없다. 시공업자가 바꾸든 집주인이 바꾸든...만물은 항상 변하게 마련이다.
하지만 기본적인 개념은 변하지 말아야 하기 때문에 화면구성 말고 흐름 및 기능은 진짜 명확히 해야한다.

2. DB설계 및 자료투입이 선행되어야 한다.

요구분석 - 화면설계 - DB설계 및 자료투입 - 제작

DB에 들어가는 자료에 따라 기능이 좌지 우지 될 수 있기 떄문에 제작하는 화면과 기능에 관련된 모든 DB는 사전에 설계하고 다양한 데이터를 꼭 넣어봐야 한다.

3. 완성되었다고 하면 면밀히 검토해야한다.