개발 방법론과 나름의 제안

아래 내용은 주관적인 의견임을 밝힙니다.



S/W개발에 있어 여러개발 방법론이 있어왔고, 앞으로도 있을 예정입니다. 그런데 내가 작업하는 방식이 뭔가에 대한 정체성 혼란이 올때가 있습니다. 흔희들 그것을 좋은 말로는 hybrid 방식 또는 기술을 받아 자신들의 방식에 접한해서 토착화 되었다고들 말합니다.

개발 방법론은 이론적이고 인간이 행해야 하는 행동들의 내용들도 포함되어있다보니, 막상 해보면 시간이 부족해지고 귀찮아 지기 때문에 해당 규칙을 따라하기가 상당히 까다롭고 행하다 보면 이렇게 안해도 될것 같은데 같은 생각이 들기 때문입니다.

결과물만 놓고 보면 어떤 개발 방법론을 사용한 것인지 알 수는 없습니다.  그렇기 때문에 과정상 편리한 점만 가져다 쓰는 형태를 많이 이용하게 됩니다. 특히 소규모 개발의 경우 이런 경우가 더더욱 빈번하며, 이것은 프로젝트를 엉뚱한 방향으로 가게 만드는 초석이 되기도 합니다.

그렇다면 개발 방법론을 처음부터 그대로 따라가야 하는걸까요? 원론적인 문제이지만, 가장 좋은건 시스템적으로 다른 방법이 없도록 만드는것 입니다. 사회주의 시스템의 통제와 비슷하다고 보는게 좋습니다. 개발 방법론은 아니지만 Python 언어의 들여 쓰기가 좋은 예가 될것 같습니다. 들여쓰기 규칙을 만족 하지 않으면 build 오류가 발생하는 시스템이라 들여 쓰기를 맞출수 밖에 없는 구조로 되어 있습니다.

여기에서 저도 새로운 개발 방법론을 제안 해보겠습니다. TDD와 비슷하면서도 조금 다른 개발 방법론을 제안 합니다.

TDD에서는 입력과 출력을 예상하여 testcase를 먼저 만드는 것에 촛점을 두고 있습니다. 제가 생각하는 방법은 여기에 입력과 출력 포함하여 실행 시간 측정 부분과 multi-thread에서 안전한지 등을 포함하여 좀 더 검사하는 항목이 많아지고, 이 함수를 만드는 coder들과 어떠한 함수가 필요한지와 함수의 시간 개념을 총괄하는 매니저를 분리하고 매니저가 coder들이 만든 함수들을 조합하는 개념입니다. coder들은 커다란 숲을 볼 수 없고 앞에 있는 나무만 보게 되고 최적화를 하게됩니다.

갑자기 이론적인 부분에 대해서 정리해보았습니다. 2020