読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

設計書からコードを自動生成して起こることメモ

チーム 生産性 プログラミング

問題

分業できない

自動生成にロックインしてしまい、自動生成の仕組みを理解してないとレビューができない。
設計書にどう書くかが問題になり、なかなか話が前に進まない。
大機能単位で、別々の会社に分割すると、設計がやりづらくなるだけで終わる。

問題が先送りされる

設計ばかりに注目され、問題がなかなか現出しない。
単体レベルの問題が出せない。
さらに、自動生成するツールができていない場合、製造に落とす作業ができず、暗中模索してしまう。
いざ、製造になって、根本的問題が発症する可能性が高い。

開発者が軽視される

製造の問題点を指摘しても、自動生成でどうにかなるからで終わる。
こうあるべき論を述べても、どうにもできない。
コードが成長しても、ずっと同じ構成を続ける。
リファクタリングが受け入れられず、設計の改良ができても、コードへの改善が行えない。

設計書が人のためではない

読む人のために作るような設計ができない。
すべてなんらかのフォーマットで書かないといけない。
柔軟な表現にかけるため、理解がしづらくなる。
表現の幅が減ると言ったほうが正しいかも?

どうあるべきだったか

定型的データ構造

適用するなら、定型的なデータ構造のコード生成だけだと思いました。
変更がすくない箇所への自動生成は有効。

仕様書は、変更が入ること前提なことがおおいので、自動生成の対象にすべきではない。
区分値とか、コード定義とかが有効なのかもしれない。

それ以外は

やったらダメだと思う。
知的創造の分野と、単純な繰り返し項目(自動化できる場所)は、きっちり分けるべきだと思います。
知的創造の分野を自動化した結果、人が分からなくなるでは意味がない。 知的創造の分野を自動生成するのは、早すぎる分野かとおもう。