「作っては壊す」過程があってこそ良いものが作れる

iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが

[kiyo_hiko]

おれが思うにこの過程は議論に似てる。日本でウォーターフォールが愛されるのは、はじめに結論ありきという姿勢、上の人間は間違わないという間違った前提、手戻りを極端に恐れるチキンハートの賜物だ。

[fluoride]

「どんなに優秀なエンジニアでも、この「作っては壊す」という過程を経ずには良いソフトウェアは作れない。料理でも陶磁器でも同じだが、ソフトウェアには「作ってみて初めて分かる」ことがたくさんある」

[sylvan_l]

つくってこわす

[webmarksjp]

naka

[jummai]

『ソフトウェアには「作ってみて初めて分かる」ことがたくさんあるので、そこからのフィードバックを主任設計者が自らコードを書いて実感することがとても大切』

[bull2]

そろそろウォーターフォールをやった結果大事故が起きて、ソフトウェア開発プロセスを一から見直すようになってくれないかなぁ

[mon5ika]

良い詳細設計をするためには、実際に設計者自身が（ここが大切、他人に任せてはいけない）プロジェクト初期段階で、自分が考えた設計をコードに落とし込んで「作っては壊す」という作業を繰り返しながら

[tksmd]

同意/特に新規フレームワーク採択の場合は、最初の使い方間違ったり、よりよい使い方があったりするのに気づかない時もある/設計する人は手を動かすべし・汗を書くべし

[mamotena]

組み立てなおしてみてダメだったりすると憂鬱になりますねｗ壊す前にバックアップを！

[hiroponz]

設計段階でプロトタイプを作成して設計品質を練り上げていくことの重要性

[byoubu]

「とにかくメンテナンスのしやすいコードを生成すること」

[p_chopin]

『実際にプログラムを書かずに品質の高い詳細設計書など書けるエンジニアがいるはずがない』／一回きりの受託開発が目指す「動くもの」と、継続的な自社開発が目指す「残るもの」。

[hiroto-k]

“実際に料理を作らずにおいしい料理のレシピが書けるシェフはいない”どこかで使いたい名言

[mappuri]

work

[raimon49]

＞基盤さえしっかりしていれば、「その場しのぎコード」が多少混ざったところでなんとかなる。基盤がぐらぐらしていると、デスマーチあるのみだ。

[anemoto]

「作っては壊す」の先に標準化があるかな。ひとつセオリーができたら、またその周りを作っては壊す。根性（粘着質）が大変必要。

[walkinglint]

> 実際に料理を作らずにおいしい料理のレシピが書けるシェフがいないのと同様に、実際にプログラムを書かずに品質の高い詳細設計書など書けるエンジニアがいるはずがない。

[stch]

感覚的にはすごく良く分かるが「なんでその過程が必要なのか？」と言う点についてもう少し分析して把握しておく必要がありそう。常にすべてをやり直す必要が有るとは限らないだろう、逆に何をやり直すべきなのか？と

[sankaseki]

Life is beautiful: 「作っては壊す」過程があってこそ良いものが作れる

[nsta]

実際につくって見ないと欠点がわからないんだよね

[loungep]

「設計者自身が、プロジェクト初期段階で、自分が考えた設計をコードに落とし込んで「作っては壊す」という作業を繰り返しながら（コードではなく）設計そのものを「練り上げて行く」過程が必須」。

[T-miura]

　SIなんかだと:「作っては壊す」コストがかけられないのが泣き所。: 「作っては壊す」は必須だという実感はあるので、仕事を変えるべきか？

[wayaguchi]

私の経験から自信を持って言えるのだが、どんなに優秀なエンジニアでも、この「作っては壊す」という過程を

[uzuki-first]

作っては壊す。たしかに、中島さんの言うとおりだと思う。がんばります

[tasanobu]

設計　デザイン　プログラミング　アジャイル　Agile

[tm_z]

どんなに優秀なエンジニアでも、この「作っては壊す」という過程を経ずには良いソフトウェアは作れない。

[umiyosh]

"ソフトウェアには「作ってみて初めて分かる」ことがたくさんある"

[jar2]

スクラップ＆ビルド

[xmx3]

後半になるとどうしても大規模な書き直しはしにくくなるため、その場しのぎのコードでプログラムはどんどんと「きたなく」なって行く。その時に大きく影響してくるのが、プロジェクトの前半で書いたコードの品質。

[EvilGood]

「作っては壊す」が許される期間があればそうしたいところ。が、結局、金を出すセクションがそんなことを理解してくれるわけはない。そこまで見越した上で、スケジュールは3倍増しで提出し、2倍増しでOKをもらおう。