「達人プログラマ」第六章：コーディング段階 の内容紹介｜株式会社 フラッツ
こんにちは、森です。前回に引き続き、「達人プログラマ」の紹介を行います。今日は、「第6章 コーディング段階」です。 偶発的プログラミング 開発者は心の中に多くの仮定を作って作業するが、それらは共有されていなかったり、他者と矛盾していたりする。そのことに意識的にならずにたまたま動いたコードを積み重ねると、突然動かなくなることがある。これは偶発的プログラミングの典型例です。このような、「とにかく今動いているんだから触らないほうがいいな」という発想ではなく、以下の事柄に注意して偶発的プログラミングを行わないようにするべきである、とのことでした。 ドキュメント化されている振る舞いだけを前提とする。それが不可能なら自分の想定した仮定をドキュメント化しておく 自分が前提としていることが保証されているのかを確認する（例えば GUI アプリなのか CUI アプリなのかなど） そして、慎重なプログラミングの
「達人プログラマ」の第4章:妄想の達人 の要約｜株式会社 フラッツ
こんにちは、森です。前回の記事に続き、達人プログラマの第4章「妄想の達人」を要約します。 この章では、「完璧なソフトウェアを作ることはできない」ということを前提とし、それならどう設計すればいいのかが書いてありました。 契約による設計 まず、「契約による設計」という考え方が紹介されていました。「契約による設計」とは、大まかにいうと、「契約」として事前条件、事後条件、不変条件をつくり、それらを満たさなかった場合に例外を発生させるという設計方法です。 Eiffel などでは組み込み機能としてサポートされているものの、他の言語ならこれらの契約はコメントとして記述しておくだけでもよいそうです。メリットとして、 偶発的プログラミング（第6章で紹介される）を避けられる 問題の早期発見・診断できる（=早めにプログラムを停止できる） といったことが挙げられていました。 以降の節 次の節以降でも、「死んだ
「達人プログラマ」第2章の要約｜株式会社 フラッツ
こんにちは、森です。 今日は、「達人プログラマ」第2章 達人のアプローチ の要約・内容紹介をつくりました。 第2章はソフトウェア開発で役立つアイディアが紹介されていました。 DRY 原則に従う DRY 原則とは、「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」というもので、同じ知識を2箇所以上に記述する「二重化の過ち」を防ぐことができます。 様々な二重化のパターンを紹介しているなかで、コード中のコメントについて言及がありました。DRY 原則に従うなら、「低水準の知識はコードに任せて、高水準な解説をコメントで記述する」とのことでした。ここでの、低水準/高水準という見方とは違いますが、FLATｚのコーディング規約には「コメントには Why に対する解説を書き、Whatに該当する内容はコードに書く」というものあります。この基準でも、コメント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「達人プログラマ」第五章 の内容紹介｜株式会社 フラッツ
「達人プログラマ」の第3章：基本的なツール の要約｜株式会社 フラッツ
『達人プログラマ 第1章 達人の哲学』 のまとめ｜株式会社 フラッツ
はてなブログ | 無料ブログを作成しよう
