Hatena::ブログ(Diary)

senzogawaのNな日々 このページをアンテナに追加 RSSフィード

2004 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 |
2011 | 01 | 03 | 04 | 05 | 06 |
2012 | 01 | 08 | 09 |
2013 | 02 |

2008-07-21

フローチャートは無益

| フローチャートは無益を含むブックマーク フローチャートは無益のブックマークコメント

 その投資は割りに合うのかねとかよりリンクを辿って、フローチャートが盛り上がっていることを知ったが、技術者の研修に今更フローチャートはないよなあ。


 自分なら研修ではテストファーストを教える。

 自動テストをペアプログラミングしたり、他にはスクリプトでのツール作成とか、本読ませるとか。

 実務に入ってしまっている場合、一緒にバグを追ったり見解を話し合ったりしながらコーディングするとか。


 何にしても、フローチャートは削ぎ落とした内容が致命的で、技術を習得するのに一番まずい「理解した気になる」という状態を作りやすいから、技術者の研修には最も不向きと言える。「余計なところを見せない」意味で技術者以外には有効だとしても。

 もっと具体的な理由は既に語られ尽くしたので引用で。


フローチャートは禁止しましょう。フローチャートは制御の流れを「もろ」に書けてしまうので良くありません。プログラムは、データを処理するためにあり、データの違いによって制御の流れが変更されます。あくまでも、データが主体です。変数、引数などのデータをどう定義するかで、プログラムの組易さは大幅に改良されます。データ構造がどうなっているかの図の方が、フローチャートよりはるかに役立ちます。データの意味だけはしっかり書きましょう。

 Cプログラミング診断室―うつくしく健康なプログラムのために「第3章 上司が問題」より

 Web版


プログラムはアルゴリズムとデータ構造の両方が重要だが、データ構造の方が重要なケースも多い。だが、データ構造が記述できないフローチャートでは、データ構造主体のプログラムはまともに記述できない。

 フローチャートはソフトウェア設計を阻害する


ネコでも読めそうな簡単なフローチャートのほうがわかりやすいのだが、

そんな貧弱なフローで業務は表現できない。

業務は、まっとうな流れと幾多数多の例外処理で成り立っている。

重要な例外をフローで表現できるのか?

しきれるのか?

否である。

フローチャート通りにプログラムを作ったとしても

そこで保障されそうなのはまっとうな流れのか細い一本だけで、

例外対処もなんにもできない貧弱な実装になるのがオチである。

 http://d.hatena.ne.jp/tonotonotono/20080721/1216594828


なぜそんなにフローチャートが嫌われているかというと,単なる時間の浪費というだけでなく,フローチャートプログラマの思考を阻害するからだ.フローチャートに書くことを強要された時点で,良いプログラムができる可能性は0になる.

 フローチャートの呪い


ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。

動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。

 システムエンジニア不要説


 まとめると、データ構造が表現できずに肝心のデータの意味はわからないし、考慮されるべき例外も表現できてないし、そもそも思考の妨げになるし、もっと根本的に、動かなくて検証できないようなものを有難がって一体何になるのか、ということだろうか。


 どうでもいいけど、ウォーターフォールフローチャートって妙に支持者が一致するような気がする。

 フローチャートは「設計工程」だけでの成果物である「設計書」を必要とするようなケース、要はウォーターフォールでの金儲け用にしか使えないからだろうか。

 少なくとも技術的な要求ではないのは、熟練技術者がこぞって否定するという点で明らかだ。


 ところで、UMLはあくまでスケッチツールであって、概念の関連の記録や1対多のコミュニケーションには使える面もあるので、仕様として厳密に描くものではないという前提で、供養しないで欲しい。まさか、オブジェクト指向における再利用のためのデザインパターン のクラス図やシーケンス図とかも不要だから削除しろってことではないだろうし。

ついでにUMLも供養して欲しい


 まず元凶であるウォーターフォール人月を供養すべき。

トラックバック - http://d.hatena.ne.jp/senzogawa/20080721

2008-07-10

レベルが下がりました

| レベルが下がりましたを含むブックマーク レベルが下がりましたのブックマークコメント

 なんとなくITスキル調査をそろそろ受けようかと思い至った。7/31までやっているらしいけど、忘れる前にということで。

http://www.isrf.jp/chousa/2008/zgnkv.asp


 以前は組み込み技術者を受けたけど、今回はIT技術者スキル調査の方を受けてみた。

 結果はレベル3.3、信頼度72%だったので、0.7レベルドレイン。


 ちょっと増長気味に回答したせいか「コアスキル」のレベルが5.7でやたら高かったけど、「プロフェッショナル貢献レベル」が2.1って、これじゃアマチュア同然だな。

 まだ一ヶ月だし、いかんせん経験が足りなすぎるか。


 コアスキルに関しては相変わらず「パートナーシップ」が平均より低く、弱点は以前のまま。克服する気が余り無いのが一番の問題だろうけど。


 そういやこの前受けた情報処理試験は、感触通り落ちてた。

 今の仕事はSQLを読み書きする機会が多く、理解不足を埋められそうなので、来年は受かる程度の実力になっているはず。もっとレベルを上げねば。


昼ベロ

 イルベロはALLとった人の画面みて思ったけど鍵50個は無理そう。裏面でエクステンドアイテムが出やすいみたいなので毎回集めてはいるけど、パターンを覚えきれなく、取れたり取れなかったりを繰り返している。


 鍵集めを程々にボスを叩くことに集中してみているが、4,5面が厳しい。攻撃が激しいので防戦に回ると結構あっさり逃げられてしまう。かといって攻撃主体にすると即やられる・・・ちょっと煮詰まり気味。

Connection: close