コード・コンストラクション等に関して

to home

 コード・コンストラクションに限った話題ではありませんが、 それに関連する項目も挙げています。これまで私が読んだ書籍の中から 共感、感銘したものを取り上げています(引用)。  なお、タイトルは私が勝手につけたものです。


権限委譲

「自分の仕事を積極的に単純化(Simplificatioin)し、専門化(Specialization)し、 そして標準化(Standardization)して、極力権限の委譲をすべきである。これは 有能な要員を育成し、後継者を計画的に育成するための常道である。」

菅野文友, "ソフトウェア開発におけるプロジェクト・リーダーの条件", ソフト・ リサーチ・センター,1998


コーディング症候群
「ところで、今日のソフトウェア開発における主要な問題の1つは、多くの プロジェクトがプログラミングを早くから始めすぎること、そして、コーディング に労力を集中しすぎることにある。そうなる理由は、1つには、管理者が ソフトウェア開発プロセスを理解しておらず、その結果、プログラミング・チーム がコードを書かないので心配になってしまうということであろう。」

H.E.エルリクソン & M.ペンカー, "UML ガイドブック", トッパン, 1998


CASEツールの価値
「CASEツールをケチるな!」

"オブジェクト指向開発の落とし穴"


教育の優先
 (株)滋賀ダイハツ販売会長の後藤昌幸氏の言葉に、「教育より仕事を 優先する会社はつぶれる」というのがあります。社員の教育こそ企業繁栄の 大本ですが、情報産業界のすべてとはいいませんが、それを怠ってきた ことは確かでしょう。そのツケをいま払わされているのではないでしょうか。

上級SE教育研究会編, "上級SE心得ノート", 日刊工業新聞社, 1996


コンピュータサイエンス単位取得者
 毎年100,000人の新人プログラマが仕事に就く(Boehm and Passaccio 1988)が、 コンピュータサイエンスの単位を取得しているのは1年 に 40,000人に過ぎない(NCES 1991)。

STEAVE McCONNELL, "CODE COMPLETE", アスキー出版局, 1998


コンストラクションの軽視
 ソフトウェア開発とコーディングとは一体のもの、同じものと考えられていた。 しかし、ソフトウェア開発のライフサイクルの中の個別の活動であるということが 認識されてからは、この分野での話題は、プロジェクト管理の解析および検討、 要求解析、設計、そして検査に集中してきた。そうした新たに認識された分野 への研究熱の高まりが、コードコンストラクションをソフトウェア開発に おける無学の輩としておきざりにしてきた。  コードコンストラクションを無視することは、コーディングはソフトウェア開発 における最も汚い作業であるとの認識から、ますます助長されてきた。

STEAVE McCONNELL, "CODE COMPLETE", アスキー出版局, 1998


コンストラクションの重要性
 コンストラクションは小規模プロジェクトでは全体の80%を占め、中規模 プロジェクトでは50%を占める。小規模プロジェクトのエラーの75%が コンストラクションにおけるエラーであり、中・大規模プロジェクトでは50%から 75%である。エラーの50%から75%を占める活動は、当然改善の対象になる。

STEAVE McCONNELL, "CODE COMPLETE", アスキー出版局, 1998


開発資料なし症候群の落とし穴
 IBMによって企画された6ヶ月にわたる調査で保守プログラマが「最も たいへんな問題点はプログラムの原作者の意図を理解することであった」 とわかった(Fjelastad and Hamlen 1979)。

STEAVE McCONNELL, "CODE COMPLETE", アスキー出版局, 1998


WISCA症候群
 コンピュータに向って過ごす時間が少ないプログラマほど実際には プロジェクトを早く完遂することとが示されている。それが暗示する ことは、コンピュータを使う時間の長いプログラマーほどコーディング や検査の前に計画を立てないということである(Card, McGarry, and Page 1987; Card 1987)
 WISCA: Why Isn't Sam Coding Anything? Symdrom
 WIMP: Why Isn't Mary Programming? Syndrom

STEAVE McCONNELL, "CODE COMPLETE", アスキー出版局, 1998


不要雑務
 会社が小さな家族経営的店舗から大きな企業体へと成長すると、不幸にも プログラマは開発以外に劇的に発生する大量の日常業務を負うこととなる。

STEAVE MAGUIRE, "DEBUGGING THE DEVELOPMENT PROCESS", アスキー出版局, 1995


凡人プロジェクトリーダー
 幸いなことに、ソフトウェアプロジェクトリーダーのほとんどは、未知の 領域に挑むべく、新しい会社を始めたりベンチャーを興したりはしない。典型的 なリーダーは普通ならアプリケーションのバージョン4.21の開発に乗り出したり、 皆が基本的に合意している将来に向けてまっすぐ線が引かれている他のいくつか のプロジェクトに従事する。典型的なプロジェクトリーダーは、チームメンバー に変わったことをあえてやらせるような、過激なひらめきを持ったリーダーに なる必要がない。典型的なソフトウェアリーダーは実践的であればいいだけである。

STEAVE MAGUIRE, "DEBUGGING THE DEVELOPMENT PROCESS", アスキー出版局, 1995


徒労
 プログラマたちはすでに存在しているプログラムを使おうとせず、応用ごとに 新しくプログラムを作りたがる。プログラミングが家内工業の域を脱し得ていない のはそのためだ。

Brian W.Kernighan and P.J.Plauger, "ソフトウェア作法", 共立出版, 1981


ツール
 他のプログラムを開発するのに役立つプログラムに注意を集中する。

Brian W.Kernighan and P.J.Plauger, "ソフトウェア作法", 共立出版, 1981


ドキュメントの必要性
 プログラマたちが毎日やっていることの大きな部分は、原プログラムを編集し、 入力データを作り、出力を調べ、解説文書を作るといったことによって占められて おり、それはまさに文書処理そのものなのだ。これらの活動はプログラミング にとって中心的である。それゆえそれは可能な範囲で、機械化すべきである。

Brian W.Kernighan and P.J.Plauger, "ソフトウェア作法", 共立出版, 1981


ダメなプログラムの処方
 だめなプログラムを修正するのはやめて、全部書き直そう。
 だめなプログラムに注釈をつけるのはよそう。プログラムの方を書き換えよう。

Brian W.Kernighan and P.J.Plauger, "プログラム書法 第2版", 共立出版, 1982


継承し過ぎ
 我々の経験からすると、設計者は再利用技術として継承を使いすぎである。

Erich Gammna他, "オブジェクト指向における再利用のための デザインパターン 改訂版", SOFTBANK, 1999


真実の悲劇
 企業におけるソフトウェアの開発/導入を数百例調査した結果によると、ソフトウェア プロジェクトの6つの内5つは失敗と見なされており(*1)、また約1/3のプロジェクトが 途中で中止されている。残る2/3のプロジェクトは、予算の倍を投じ、予定の倍の 時間を費やして、やっとのことでソフトウェアを完成させている。

(*1)Johnson,Johnny,"Creating Chaos," American Programmer,July 1995.
Wiliam J.Brown他、岩谷 宏訳,"アンチパターン ソフトウェア危機患者の救出",SOFTBANK, 1999


標準化と文書化
 XMLは標準として提案されており、標準は何よりもドキュメンテーションを 必要とするのです。

Web Workshop - XMLの基礎 ( http://www.asia.micorosoft.com/japan/developer/workshop/xml/articles/elxml.asp)


便利な言葉OJT
 (前略)ところが、注意しないと自分のところで社員を育てる能力のない会社が 社員を放し飼いしてるだけなのに OJT だとうそぶいている結果になりかねません。

真紀俊男,C MAGAZINE "プログラミングの禁じ手", SOFTBANK,2000.4


軟弱地盤
 ほとんど経験もなく、より良い結果を得る方法についての考えも持たない企業が、 いったいどうやってオブジェクト指向の重要なプロジェクトに乗り出そうというのか 驚くばかりです。

Martin Fowler、羽生田栄一監訳,"UMLモデリングのエッセンス 第2版",翔泳社, 2000


Brooksの法則
 遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ

Frederick P.Brooks,Jr.、滝沢 徹他訳,"人月の神話 狼人間を撃つ銀の弾はない",ピアソン・エデュケーション, 1996


修正するのは別人
どうしてもっときれいに欠陥を修正できないのだろうか。第一に..(中略)
第二に、通常修正するのはコードを書いた本人ではなく、しばしば若手の プログラマあるいは見習いである。

Frederick P.Brooks,Jr.、滝沢 徹他訳,"人月の神話 狼人間を撃つ銀の弾はない",ピアソン・エデュケーション, 1996


CからC++へ
Cプログラミングは C++によって不要になったさまざまなテクニックや トリックを助長する。

Bjarne Stroustrup,"プログラミング言語C++ 第3版",ASCII, 1998.11


愚 弄
適切な技術がなければ組織的な基準を設定したとしてもほとんど 役に立たない。

Meyer B.,"オブジェクト指向入門",ASCII, 1990


IT錯誤
ITで重要なのは、ITそのものへの投資ではなく−ITという道具を使いこなせ るための− 人材への投資です。

岩谷宏,Software Design "岩谷宏のOpen Noises Mining", 技術評論社,2000.9


簡単に出来ると思うなよ、フレームワーク
優れたフレームワーク設計者は、フレームワークが最初から正しいもの にはならないことを知っています。それは経験を重ねて進化して いくものだからです。

マーチン・ファウラー,"リファクタリング", ピアソン・エデュケーション,2000.5
中の「本書に寄せて」に執筆された Erich Gamma


ソフトウェアエンジニアリング錯誤
また、このオーバーヘッド(コミュニケーション・オーバーヘッドのこと)を避けがたい ものとして受け入れる人もいます。その結果、オーバーヘッドを取り扱う複雑な システムができあがります。しかし、結局は オーバーヘッドが秩序正しくなるだけで、なくなるということはない ようです。オーバーヘッドはきちんと箱やチャートに納められ、理解しやすくは なっていても、ちゃんとそこにはあるのです。このオーバーヘッドを 楽しむ人もいます。

Andrew Koenig & Barbara E.Moo ,"C++再考",アジソン・ウェスレイ, 1998


問題錯誤。いや逃避。
A:「おい、こんなところで何をしてるんだい?」
B:「鍵を落とした所が暗くてね。明るい所で探しているんだよ」

Tom DeMarco & Timothy Lister ,"ピープルウエア 第2版",日経BP社, 2001.11


「ギルブの法則」
 どんなものでも、計測しようと思えば必ずできるし、測定しないでいるよりもずっとよい。

Tom DeMarco & Timothy Lister ,"ピープルウエア 第2版",日経BP社, 2001.11


考えない葦
今日では、コンピュータ技術の急速な発展のおかげで、コーディングを してからあっという間にコンパイルができ、すぐに実行することが可能です。 その結果、書いたコードにエラーがあると、「なぜエラーになったのか」を考える ことなく、ちょっとだけソースを修正して、すぐにまたコンパイルと実行を行ったり する人が少なくありません。さらに、動作させて上手くいかないと、その理由をじっくり 考えることなく、またちょっとソースコードを修正して、同じサイクルを繰り返したり します。つまり、ソースコードをじっくりと読んで考えることなく、試行錯誤を 繰り返すのです。

柴田芳樹, Software People Vol.1 "ソフトウェアエンジニアの心得",技術評論社, 2002.9



to home

by masu
e-mail: massun.masumoto@nifty.ne.jp
URL : http://member.nifty.ne.jp/~masumoto/