소프트웨어의 설계 심사를 해야한다

문제점 의 프로세스에 대해서 소프트웨어 개수의 길잡이 - 그 제조 공정에 하고는 별로 언급할 예정은 없습니다만 한가지 인상적인 출신일에 대해서 적어 보고 싶습니다.

현상의 파악

이전에 릴리스 후에생하는 문제점을 한없이 줄여보자는 생각으로 임한 적이 있었습니다. 우선 진행된 일은 일어나고 있는 일의 정확한 파악입니다. 일어나고 있는 일이라는 것은 문제점 자신의 일이 아닌 문제점을 만들고 있는 일인 것입니다.즉 어떤 실수에 의해 문제점을 만들어낸 격>>하는지를 밝힌다는 것입니다.일어나고 있는 일을 알면책도 저절로 알 수 있을 겁니다. 원래 문제점을 해서 릴리스 할 때에는 자에게용의를명받아 심사하고 승인했더니 처음 릴리스라는 프로세스가 되어 있었기 때문에, 문제점용에 대해서는 모두 파악은 하고 있었습니다.그러나 해묵은 문제점의 방법이 타당한지를 판하는 취지였기 때문에, 어떤 실수에 의한 것인지를 상세하게 분석하는 데는 정보가 부족했습니다.거기서 생각할 수 있는 실수를 유형화해 리스트업하고 체크하면 실수의 종류가 명확해지는 서류를 만들었습니다.예를 들면 이하의 이상한 느낌입니다.

□기술 오류 　예:=의 점을 =로 잘못 찍었다. 문법 착각 　연산자의 우선순위를 오해했다. 　　　　

이들의뭐냐 순진한 실수 이외에 알고리즘이 잘못된 패턴이나 설계에 기인하는 패턴 등 되도록이면 누락이 없도록 많은 패턴을 리스트로 만들었습니다.이것을, 문제점을 하여 릴리스 할 때의 심사의 서류로서 추가하여 운용하기로 하였습니다.

 

 

 

 

드러난 거니

운용을 시작한지 얼마 지나지 않아 서류가 점점 쌓이기 시작하니 전혀 예상 밖의 추세로 돌아섰습니다.몇 십여장의 서류 중에 제조에 기인하는 문제점은 하나도 없었습니다.모두 설계에 기인하는 문제점이었습니다. 설계에 기인하는 문제는 설계를 고치지 않는 한해도해도 다시 나오고하는 성질의한 것이기도 하므로, 릴리스 후에 시로 나오는 것 같은 것은 제조의순수한 실수라고 생각하고 있었습니다.게다가 애초에 그때까지 심사 때의 명나라에서 설계 문제로 들린 적은 없었습니다.명색이 용모가 합리적이고사실의 방법에 납득이 갔을 때만 승인해 왔기 때문에 제 자신도 타당한 것으로 판별한 것들 뿐이었습니다.이 결과는 전혀 예상외로 매우 놀랐습니다.

 

 

설계 심사

이 결과를 받아 심사 때의 서류에 설계서를 의무화했습니다 (다만 전부가 아닌 문제점에 관련된 부분만) 책에 문제의 원인이 설계에 기인한다면 설계 수정이 필요하고 그 용모를 레뷰할 필요가 있기 때문입니다. 설계서를 의무화하고 운용을 시작하면서 더 놀랐습니다. 용모가 자주 틀렸던 것입니다. 그때까지 자가 밝혀온 문제점 의 방법에 틀렸다고 생각한 적은 거의 없었습니다.그것이 설계서 베이스로 심사하기 시작했으면 그 외모가 종종 틀렸던 것입니다.아무래도 설계의 관점에서 방법을 알아낸 것이 아니라, 코드의 수정이 선행되어 그 내용을 설계서에 반영한 것 같았습니다.즉 설계의 문제를 제조에서 하고 있어로 틀린 것도 그렇습니다.지금까지 눈치채지 못한것만으로 오랫동안 그런 로 릴리스했던 일이 됩니다.자기 생각에는 코드에 손을 넣을 경우에는, 그 개소 뿐만 아니라 주도 포함해서 조금 정리해서 깨끗하게 할 정도의 가지고 손을 넣지 않으면 자꾸 코드가 더러워져서 썩어버립니다.설계의 문제를 제조에서 했다는 것은 바로 그런 것이기 때문에, 지금까지 없이 점점 코드를 썩혀 가고 있었다는 것이었습니다.

원인

왜 그렇게 되어버렸나 생각하면많은 프로그램은 한 본인이 만든 것이 아니라 남이 만든 것을 인용한 것이었습니다.또 오래된 것은 설계서의 질이 좋은 설계서를 보고 방법을 터득할 수 있는 수준의 것이 아니었습니다.그러한 복의 사정 때문에, 원인을 조사하는 과정에서 먼저 코드를 쫓기 시작해서 그대로 설계에 되돌리는 일 없이 코드를 수정하고 끝난 것으로 생각됩니다. 그리고 최대의 원인은 문제점의 에 빗대어 심사를 하는 프로세스가용 간단한 것이 되어있던 것입니다.신규로 여는 경우나 버젼앱에서 수정하는 경우 등은 각종 문서의 출력이나 레뷰 등의 품질을 확보하는 프로세스가 갖추어져 있었는데, 릴리스 후의 문제점 의 경우는 극히 간략화된 프로세스가 되어 있었습니다.결국 그곳을 박차고 갔다는 것이 됩니다. 한 결과 즉 프로그램 동작의 품질에는 심사가 제대로 부과되어 있었기 때문에, 그쪽에 주력한 나머지방법 측이 허술해졌다고 할 수도 있습니다.그러나 설계를 잘못한다는 것은 빚을 진다는 것이니 장기적으로 서서히 목을 조르기로 되어 있었던 것이겠죠.