プログラミング

情報処理の基本は現実化・規則化である。これが開発効率や品質等に直結する。十分な検討と整理の継続が必要である。またできるだけ実体的な環境下での開発やテストを行うべきである。

開発手法は問題がない限り反復型・スパイラル型を使うのが良い。

実行環境や言語は、制約がなければ一般的なものを用いるのが良い。現在の開発効率や目新しさよりも、将来の保障の方が重要である。一般的な環境や言語の方がツール等が充実しており開発しやすい場合も多い。

統合環境や高機能エディタ、検索、差分、置換等のツールを充実させるべきだ。これらの機能を最大限使用すれば開発効率も品質も上がる。

開発効率

十分な検討と整理の継続が情報処理の実務の根幹となる。これは特に規模が大きくなるにつれて開発効率に直結する。

高機能の外部ソフトを最初に検討すべきだ。各種業務ソフト、ツール、ミドルウェア、ライブラリ、API、フレームワークなどである。開発の前段階で、どんな外部ソフトがあるかを十分に探す必要がある。海外製の優秀な外部ソフトは非常に多く、うまく使えば開発効率が飛躍的に上がる。品質や将来の拡張性を考えれば、多少高くても外部ソフトを使うべきだ。作り込みは必要最小限にした方がいい。この作業は全体に影響するので最初に行わなければならない。高機能のソフトは使い方が難しい場合も多いが、簡単な低機能のソフトよりも最終的な効率は上がる。使い方が難しいからと言って避けていては仕事にならない。

優れた海外製品の機能に不満を持って作り込みを行う前に、その製品において現実化・規則化がどのように行われているかを考えるべきだ。それにより正しい使い方を理解する事ができ、無駄な作り込みを減らせる。

管理ツールの導入は比較的容易だが、大して開発効率は上がらない。開発する処理自体が減る訳ではないからだ。ライブラリのように明確に開発する処理を減らせるものを導入すべきだ。開発が楽になるから導入する、という考えは誤っている。楽になっても開発効率が上がるとは限らないし、実際には大して楽にもならない。

品質は高ければ高いほど作りやすくなり、特に開発が進んだ段階では開発効率に直結する。モジュール分割や可読性は非常に重要である。品質に問題がある場合は大規模に修正した方が効率が上がる可能性がある。

プログラムが動くのは当たり前であり、そのレベルの品質を求めても意味はない。いかに美しく高度なプログラムを早く作るかが重要になる。ここで言う美しさは見た目ではなく機能美であり、データや関数等を正しく整理して配置する美しさを理解しないと高品質なソフトは作れない。

ステップ数はできるだけ短い方が開発しやすい。同一の内容のソースをコピーペーストして同じプログラム内で使う事は絶対にしてはならず、必ず関数などでまとめる必要がある。

開発ツールは非常に重要である。統合環境があれば必ず使うべきだし、それ以外にも高機能エディタ、検索、差分、置換等のツールは時として圧倒的に開発効率を上げる。特に全体を再整理する際に重要である。必要ならばスクリプトを組んで開発ツールを自作すべきだ。私は秀丸とDFというソフトを常用している。

プログラムの開発は処理追加だけでなく既存処理修正を並行して行わなければならない。規模増加に伴い常に処理改善をしなければすぐに管理不能な状態になる。この際に上記の開発ツールは非常に重要になる。

開発とテストは並行して行うべきである。バグがあってもすぐに把握できるからだ。それができない場合は机上デバッグなどでバグを作らないように慎重に開発すべきである。

できる限り普通の方法で開発すべきである。普通の開発は安定性が高く、開発環境も整っている事が多い。普通から外れた開発方法は調査も困難になり、将来的な継続性にも劣る。

資料よりもソースの方が重要である。grep検索を使いこなせばソースの実態をすぐに把握できる。

資料の作り方も重要である。仕様書などは必要性が低い場合もあるが、プログラムの概要や構造や使い方などを説明する資料は他の開発者に引き渡す際に重要になる。ソース内のコメントも同じように重要である。重要なのは分かり易さでなく、後からの調べやすさである。分かりやすい資料は利用者が最初に触れる場合のみ必要で、開発者内では不要である。利用者ですら開発者が思うよりずっと難しい使い方をする事が多い。

見た目の美しさや簡潔さは必ずしも重要でない。これらは初心者や一般向けには重要だが、多くの利用者は初心者でも一般者でもなく業務の専門家である。専門家にとってはデータの詳細さや扱いやすさの方が重要になる。専門家が求めるのは作業速度の向上であって分かり易さではない。

テスト環境やテストデータも重要である。ソース管理ツールを使っても管理しやすくなるだけで開発効率は必ずしも上がらない。ソース管理ツールによりテスト環境が継続されないと開発効率が落ちる可能性もある。

アジャイル開発は開発効率を上げる手法ではなく、開発サイクルを短縮する手法である。アジャイル開発が上手くいって結果的に開発効率が上がる可能性もあるが、直接的に上がるものではない。カウボーイコーディングと呼ばれる乱雑な開発になってしまえば開発効率は落ちる。

処理を減らす方法

十分な検討と整理の継続が情報処理の実務の根幹となる。処理を減らす際も同様である。

開発効率や品質を上げるためには、できるだけ処理を減らした方がいい。ただ減らしすぎると可読性やメンテナンス性が悪くなるので注意が必要である。

基本方針として、同じ処理はできるだけ共通化する。これだけでも処理は短くなる。またデータと処理は統合的に扱う。うまく統合すれば可読性も良くなる。

特定の構造を持つデータに対して、同形の構造を持つ処理を最低限の数だけ用意する。何度も同じ形の処理を通さず、一つの処理の中で様々な機能を持たせる事で処理を減らせる。

データを命令的に扱う方法もある。多数のデータが数個の属性を持つ場合、属性をデータとして保存する。データごとでなく属性ごとに条件式を作れば済む。

順次や選択の代わりに、繰り返しをうまく使うと処理が減らせる場合がある。条件やデータが多量になる場合、すべてを配列などの繰り返しで扱ってしまう。データそれぞれの処理の代わりに、特定の属性を持つデータ配列を順番に処理する形にする。これは可読性もあまり悪くならず扱いやすい方法である。

関数型プログラミングも処理を減らせる場合がある。ただし可読性が悪くなる場合があるので、必須の場合だけにした方がいい。

C/C++言語の関数ポインタのような特殊な方法もあるが、可読性は非常に悪くなる。コールバックのように必須な場合だけ用いるべきだ。

開発費用をステップ数で判定してしまうと、無駄に長くて使えないプログラムが作成される可能性がある。ステップ数でなく機能により判定すべきである。

データの整理

処理を書く前にまずデータを整理すべきだ。処理よりもデータの方がずっと少ないので整理しやすい。データを整理すれば処理は自然に整理できる。モジュール分割でもデータの整理を先行させるのが良い。クラスや構造体やモジュール等で関連するデータをまとめると、その後の処理が作りやすくなる。

同一のデータがバラバラに存在する状況は避け、できるだけ一カ所にまとめるべきだ。

メモリと変数の性質は必ず理解しておく必要がある。誤用すると深刻なバグが発生する可能性がある。データ構造の理解も重要である。

外部的なデータファイルを使用する際も、データの整理は重要である。ソース上のデータ区分と合わせた形で整理すべきである。

まとめて処理作成

処理をだらだらと書くのは絶対に避けなければならない。データの整理を行うとある程度の構造が見えてくる。その上で処理全体をまとめて作成し、共通化やモジュール分割を同時に行うべきだ。後から修正するより最初から共通化やモジュール分割をしておいた方がずっと楽だ。

処理の階層（条件や繰り返しなど）が深くなると分かりにくいので、別ルーチンにして低くした方がいい。同一ルーチンや同一ファイルが非常に長い場合も分かりにくくなる。長くなりそうな場合は最初から分けておいた方がいい。同じ処理が何回も続くなら共通化すべきだ。

可読性を上げる事も重要だ。命名規則やコメントは、開発効率や品質に直結する。

プログラム構造の理解も重要である。上手く使えば開発効率を上げる事ができるが、過剰に高度なプログラム構造を使っても良い事はない。適切な選択が重要である。

全体を再整理

ある程度開発が進んだら、最初から全体を整理し直す。データの整理からやり直す必要がある。

開発が進むと同じ処理が多数できたり、同一ルーチンや同一ファイルが長くなったりするので、扱いにくくなる前に再整理が必要である。

整理は部分的でなく全体に対して行う必要がある。手作業で全部チェックするのは大変だが、検索、差分、置換等を最大限活用すれば大変ではない。命名規則が正しく行われていれば、検索や置換が容易になる。

この作業は何度も繰り返し行わなければならない。十分な検討と整理の継続が良いプログラムを作る鍵である。