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

技術関連の覚書

案件でやったり自宅で試したことの覚書、自宅Redmineから移行

システム開発のアンチパターン

システム開発をする上でやってはいけないことがいくつかあると思う

開発過程での御法度

  • ファイルの紛失
  • デグレーション(先祖返り)

コーディングでの御法度

  • 同一処理の分散
  • 変更対応範囲の拡大

テストでの御法度

  • 未実施

しかし、これらはどこかしらで今も行われていると言う現実もある

その原因は

開発過程

ファイルの紛失
  • 共有ドライブでの管理での操作ミス

** 間違って消す、上書き、バックアップフォルダの間違い等で行方不明などによって引き起こされる これに関してはバージョン管理ツール(gitなど)でほぼ解決できる内容だが、使わない現場も多い 紛失等による修正コストと運用のための学習コストとの比較をすれば明らかに学習コストの方が低いはずと言うのが説得のポイントになる まずは、ファイルが無くなってもすぐに復旧できると言うところから説得していくしかなさそう

デグレーション(デグレ)

フォルダで管理しているが別々に作業していた人が誤って上書きする、古い物をバックアップから戻すなどで引き起こされる これもバージョン管理ツールで解決可能だが、これについては運用ルールも正しくないと同じ事が起こる 今まで見た中では、

  • 共有フォルダとバージョン管理ツールの平行運用 → 共有フォルダでの管理はどれが最新なのか、正しく日付等が管理されているかという問題で人的ミスが原因で起こる このデメリットをそのまま持ってきてしまってるので意味がない

  • コミットのタイミングがレビュー後でないとできない → 最終成果物しか管理されないため途中経過でのデグレの発生リスクはそのままとなり、デグレが発生しても最悪気づくのはレビュー時になる

  • ブランチの使用禁止(競合が発生するため) 上記コミットのタイミングのためブランチを使わない方針は少なくない

対策としては、競合しても簡単にマージできますアピールかな…

コーディング

コーディングでのアンチパターンは既に設計段階から始まります。

  • 共通化するもの、しないものの振り分け、処理パターンの洗い出しなどが不十分の場合

  • コーディング規約が曖昧な場合

  • そもそもアーキテクチャがおかしい場合

従来から行われている共通化の方法としては、共通関数を作る、それぞれの処理から呼び出すが一般的でした。 オブジェクト指向になって親クラスで共通処理をして、個別のメソッドは抽象クラスにして、それぞれの子で実装するが一般的になるでしょう。 DIを放り込んでおくなど、コーディング量を少なくすることが目的です。

しかし、中には昔ながらのコーディングが好きな人もいて、1ファイル1処理主義の方も未だに存在します(そろそろ絶滅したかな?)。 こういう人の説得が一番厄介ですが、根気よく共通化のメリットを説明しましょう。

共通関数呼び出しに行く人はまだ理解してくれることが多く、テンプレートパターンのように理解しやすいところから順序立てて説明していけば納得してくれることが多いようです。

ドキュメントとの整合性

設計書を書いてコードを書いて、誤りがあったらどちらを修正するかというと、どちらかというとコードから直す方が現実には多いです。 そのためドキュメントの修正が後回しになり、時には修正されずコードとの整合性が取られなくなることも多いです。 この際、ドキュメントを作らずRedmineのチケットなどで管理してドキュメント代わりにするところもあるようです。

しかし、まだドキュメントを作成するところの方が多いのは事実なのでこれは、なるべく忘れないうちにすぐに反映するしかないです。 そのためには、ドキュメントは極力簡略化することではないかと思います。 それから、コード一覧とか、画面項目一覧などは、一覧から画面HTMLの生成できるツールにするなど工夫することで作るメリットも生まれます。 ドキュメントを面倒な書き物にせずに便利なツールにすることでみんなが書きたくなる工夫も必要かな。

オンコード主義

接続情報の設定値や使用するSQLをソース上に記述するプロジェクトもありますが、これらはただの値であるためコンパイルは問題なく通ります。 しかし、それを検出するのは最悪テストの段階なのでそこまで検出できないことがよくあります。

設定値の場合は環境によって変わるものもあるのでソースを入れ換えなければならない場面も出てきます。 propertyファイルやxmlなどで管理しておくことで外部ファイルにできるのでそのようにしましょう。 環境で変化するものはgradleにちょっと書くだけで自動切り替えができます。 使ってない場合はそれぞれの環境用にファイルを用意してbuild.xmlMakefileにコピーを配置する記述を追加して切り替える方法もあります。

自動テストを使わない

画面の入力項目が多いものなどは動作確認だけでも入力に時間をとられます。 入力項目入れるべき値が正しいかという観点もあるので正しいテストを行うためにも自動化は必要です。 JUnitTestNGのようなメソッドを直接検査するツールとSeleniumような画面の動作を自動実行するツールがあるので用途に応じて使い分けましょう。 そして、テストは1度では終わらないということを管理者に認識してもらうことが導入許可への第一歩になります。

まとめ

システム開発は一人でするものではないため、設計書の書き方、コードの書き方、テストの方法などのルールを決めて行います。 そのため、規模が大きくなるほど、整合性を取ることが難しくなるためあまり、変わったことをせず従来どおりの方式を取ることが多くなります。 方式の決定は自分ではどうしようもないことも多いので、それに従うしかありませんが、ツールが無くてもバッチなどはテストプログラムを作成することもできます。

工数とのバランスを取りながら工夫していけると制約のある中でも効率をあげる方法はあると思います。