開発速度が上がる順序を考慮して実装を行っていこう

開発のしやすさを重視した仕様を作成しように書き足してきた内容が多くなったので、別記事にいたしました。

実装の状況によっては、開発速度に影響する項目があります。そのような項目は早い段階で実装していきましょう。

• 「現時点での実装の完了比率」よりも「開発速度」に関心があります。

開発速度を上げきれていない要因がある場合、それらの要因を解決することを強く、マネージャーに要望したいと思います。
「個々の実装の完成度」と「個々の実装とそれを利用する側のコードとの間で原因の切り分けのできる設計」だったら、切り分けのできる設計に変更することの方こそ重要と考えます。個々の実装の完成度は、開発の産物にしか過ぎません。しかし、原因の切り分けのできる設計というのは、チームとしての開発の進め方（いわば制御方法）です。
あなたの抱えているプロジェクトにそのような開発速度を落としている要因があったら、立ち向かい続けることが大切です。
「分かる人が注意深くデバッグすれば、正しいか問題があるかどうかわかる」よりは「ログに書き残された情報を見れば誰でも簡単に確認できる」ことを希望します。「数値を電卓をたたけば妥当性をチェックできる」よりは、「図を見れば分かる」の方を希望します。

• 「設計の完成度」よりも、「設計と実装の改善の速度」に関心があります。

　人は最初から完成度が高い設計などできやしないものだから、「設計と実装の改善の速度」に関心があります。設計の完成度を机上で上げきれることには限界があります（そうでない人もいるかもしれませんが）。実装しやすい仕様で実装して早めに課題を出すことです。「○○というすばらしい手法ではとても高速に高精度で処理できます。ただし、そのためには△△の期間がかかります」よりは、「hogehogeという ほどほどの手法では、限界がありますが、そこそこ動きます。しかも使い出すのは簡単です。」の方をまずは選びたいと思います。その手法が最終品には使わないものであっても、少しでも早い段階で動き出すことは開発への見通しを立てやすくするものです。」

• 少しずつのリファクタリングも、開発しやすさにつながります。

コードに機能を追加しようと思ったら、その前に該当部分をリファクタリングできないかどうかを考えることにしています。アジャイルな開発手法をとっていることもあって、そのような改変の自由度は持ち合わせています。リファクタリングをしないままに機能を追加しようとすると、ほぼ同じ機能のインタフェースが違う関数の存在によって、一方だけ機能を追加したのに、もう一方には追加していないために、バグを誘発する原因を埋め込んでしまったりします。単一責務の原理(single responsibility principle)を満たしていないコードは、開発のしやすさをそこなうものです。コードを書き、コードをリファクタリングする経験を積むと、どのようなクラス設計や関数の仕様をすべきかがわかってきます。リファクタリングも開発のしやすさに対して重要な項目です。

• 不要なコードを削除しよう
  　過去のしがらみのために使われていないコードが残ったままになっていませんか。そのようなコードは、ソフトウェア開発の見通しを悪くします。ソースコード中で検索したときに、そのコードが見つかることで、ある関数の実装を変更したときの変更が及ぶ範囲を必要以上に見積もることになります。ある要因をさぐっていくときに、本筋ではない部分に迷い込むこともなくなります。そのような要因が開発のしやすさにつながります。
  あるソフトウェアを別のOSや別のターゲットボードに移植しようと考えているなら、まず不要なコードを削除することです。OpenCVなどのライブラリを新しいバージョンにそろえるように開発中のソースコードを改変していく場合も、まず不要なコードを削除することです。それによって、メンテナンスする必要のあるコードが減ることで、開発がしやすくなります。

• 本筋じゃないことでの厄介ごとを減らしていこう。
  ある機能のデバッグには、その状況を生じるまでメインのプログラムの実行をすすめる必要がある。そうすると、その機能をデバッグするには、その状況を作るまでの手順を毎回行う必要を生じたりする。そこに、ちょっとした厄介ごとのために、プログラムがうまく動かない状況におちいることを減らそう。開発のしやすさを損なっているならば、対策をとろう。不便さを我慢するのはよくない。

• 誤解をまねく変数名・関数名を直そう
  　変数名や関数名が誤解をまねく名前を使っていると、その名前が引き金になって、バグを引き起こすことがある。コードを読む際の理解に時間がかかるようになります。だからよりよい名前をつけることでコードの利用がしやすくなっていきます。そのような修正はリファクタリングの常套です。ただ、チームとして開発をしている場合には、その改変をするタイミングをチームメンバーと意見交換して進めていくのがよいでしょう。

• 楽しいと開発メンバーが感じる開発をしよう。

　開発速度が改善するのは、開発メンバーが自分の仕事を楽しいと感じられるときです。自分の仕事が楽しいと少しでも感じられるように、開発環境を整えること、開発の方向性を設定すること、1人で課題を抱え込まないで済むように、楽しく開発ができるように工夫をすることです。

付記：
　不便さを我慢するのは美徳ではない。
　Ratforという言語を聞いたことがありますか。
FORTRAN77やそれ以前の規格のFORTRAN66では制御構文上の制約が多かった。ループ構文はDO ループしかなかった。そのような制限の強い処理系でも、C言語風の制御構文
if-else, while, for, do, repeat-until, break, next
が「C言語から恥知らずにも盗まれ」て持ち込まれています。
　この例を見ると、制限が強くて不便な処理系でも、wrapperやpreprocessorを導入することで、使い勝手のよい処理系に変えてしまうことが可能な場合があることが分かります。この方式の利点は、既存の処理系の仕様を変える必要がないため、自分の権限の及ばない部分に由来する不便さを解消できるという点です。
　開発速度が上がるようにしていくこと。それこそが開発を成功させる重要な要因の１つです。