Software Engineering에 대한 질문

저도 이런 고민을 많이 합니다.

제가 하는 일은 소스 코드를 분석하여 역공학적 도구와 테스팅 도구 그리고 품질에 관한 도구를 만드는 일을 합니다.

각 언어를 분석하는데는 그만한 언어의 깊이가 필요합니다. 그런 부분에 대한 이해를 하지 않고 접근하기가 애매합니다. 그렇다고 언어를 분석하는 시간을 따로 둘수 있는 형편이 아니기에,

현재 채택하고 있는 방법이 개략에서 상세하게 란 표현을 합니다. 그 개략으로 구현을 하고 좀더 상세하게 표현을 하는 것입니다.

여기는 장단점이 있습니다. 개략일때는 그 흐름을 판단하기 좋습니다. 하지만 상세해지면, 처음 보는 이는 이해하기 힘들다는 단점이 있습니다.

그래서 일의 방법을 UML의 use case로 일의 단위를 분리합니다. 이것으로 타인들을 이해시킵니다. 또는 초보자를 이해시킵니다. 그리고 Sequence Diagram이나 Class Daigram으로 설계의 형태를 잡아줍니다. 이것을 기반으로 코딩을 하고나서 문제점은 다시 설계문서에 반영합니다.

점진적 기법이라 볼수 있습니다. 이것을 기반으로 후에 완전하게 설계를 하고 코딩을 할수 있게끔하고 싶은데, 잘 될지는 모르겠습니다. 단지 실패를 최소화하려는 고민의 일부라 생각합니다.

이 기법은 MDA 로 가능할것으로 보여집니다. 하지만 세부적인 부분은 불가하지 않을까도 생각합니다. 또한 Software product Line 이란 것이 있나봅니다. 자세히는 모르지만, MDA와 유사한 행태인것 같습니다. 간단하게, 메타 모델을 만들어서 그것을 언어나 플렛폼에 종속적으로 변경하는 작업을 하는 일렬의 행동을 하는 것 같습니다.

신입사원의 문제는 일정 교육이 필요할것 같습니다. 일을 시키기 위해서는 어쩔수 없지 않을까 생각합니다.
특히, 코딩의 경우는 누가 해줄 수 있는 상황이 아니고 개인이 고민한
만큼 얻는 경험의 산물로 봅니다.

그래서, 저는 일의 특정시점(주간이든, 일의 단위별로든)에서 코드를 보아줍니다. 경험을 되살려 어느 지점에서 막힐것이다 라는 것을 인식합니다. 그리고 그부분에서 어떻게 처리하고 있는지를 인지하고, 같이 고민을 합니다.

단시간에 하면 무리가 따르기때문에, "~을 하면 좋다"라는 강요아닌 강요를 합니다.

전 방법론이 이론으로 나온것이 아니라, 경험을 정리하는 과정에서 방법론들이 나온것이 아닐까 생각합니다.

다른 분들은 어떻게 해결하고 있는지 궁금하군요.