使えるモノと動くモノ


元開発屋からの下らない開発孝です
開発というのは、一般的に以下の順番で進むというのはReWiz's Prompterで書いている事ですが、今回はそれにいくつかののモノを追加して、現実味を帯びさせたモノを書いていきたいと思います

  1. 企画する
  2. 仕様を作る
  3. 仕様からアルゴリズムに起こす
  4. アルゴリズムからコードに起こす
  5. コードをコンパイル・リンクしてアプリケーション化する
  6. デバッグ作業を行う
  7. 完成

さて、これが、ReWiz's Prompterで書いている事ですが、現実世界では5〜7までの間に下記の二つが追加される事があります

これらは、開発上では必要ない事であったりしますが、使用者(基本的には「使用者」ではなく「クライアント」であったりしますが)の注文が入るので、発生する可能性が高くなります
 

さてここからが本題となります
「仕様通りのモノ」というのは、えてして使い物になりません
これは、パフォーマンステストで引っかかってしまいソフトウェアとしてはかなり低級なモノとなります
簡単に言えば、デバッグコードを大量に含んだα版の様な感じであると言えるでしょう
「使って使えない事はない」そういう感想が聞こえてきそうです
したがって「仕様通りのモノ」は論理バグ(理論的なミスや思考的に間違っているモノ)を潰すために必要なモノといえるでしょう
しかし、この先で起こるチューニングは他のモノを呼び起こします
論理バグではなく、コーディングバグです
この複合型バグは排除がとても難しく、この後様々な障害を巻き起こしていきます
この下らないバグ発生処置は、ある意味で必要であり、他の意味では必要のない行為であると言えるでしょう
 

論理バグの恐い所は見つけ辛い所でしょう、簡単に説明すれば人間というナマモノは考え方が間違っているという事をなかなか理解できません
それは、その考え方が自分にとって正しいと思えば思うほど顕著にあらわれます
したがって、「動くモノ」を作り上げる事すらが難しいのに、チューニングして「使えるモノ」に変えていく段階でさらに論理バグが生まれていきます
 

さて、もっとも簡単なチューニング方法はなんなのでしょうか、「コードの中の無駄を省く」ですか、それとも「より低級言語で再構築する」でしょうか、実は力業的でもあり、大企業が良くやるネタとしては「マシンスペックを上げる」という事をよくします
たとえば、ある程度「コードを最適化」すれば1.5倍ぐらいになるとしてもマシンスペックを2倍とかにして逃げる事がままあります(少なくとも私の知っている企業はこの方法で逃げていました……)
マシンスペックの向上に逃げて、コードの最適化を怠っていけばソフトウェアの実行スピードはいつになってもあまり変わらない事になります
悪く言えば、どんなに作りが雑魚であろうともマシンさえ良ければ動くのです(私自身が雑魚でないとは一言も書きませんし、雑魚である事を広言すらします)
 

考えうる「最低限のスペック(たとえばMS-Windows2000が動く最低限のスペック)」を基準にしろとは言いませんが、ある程度の低スペックマシンを規準にモノ作った方が、無駄なモノが削られる分だけコード自体も読み易くなると私は思うのですがそうではないのでしょうかね……
 

「使えるモノ」と「動くモノ」の差は、基本的に実行速度の差であると言えると思います
これは、今までの私の経験でしかありませんが、企業用のソフトウェアではそれが顕著にあらわれる様な気がしてなりません
細かく書くと、それをしている企業がどこかというのが特定されてしまいそうなので、書く気はありません
ですが、そういう事もありうるという事は心にとめておいてください
なぜなら、それをする事によって、クライアントや使用者を騙し、さもすごい事をしていると見せかける事もできるのですから…………

 

戻る