Archive of posts from yyyy-06-05
— デザインレシピ「デザインレシピ」という言葉は、浅井健一先生の『プログラミングの基礎』ではじめて知りました。ソフトウェア(特に関数)の設計方法は体系化できるという考えです。
元ネタは有名な「How to Design Programs: An Introduction to Programming and Computing」だそうです。使用している言語はSchemeですけども、考え方は同じです。
- 問題分析(Problem Analysis)
- シグニチャ、目的文、ヘッダ(Signature, Purpose Statement, Header)
- 関数の例(Functional Examples)
- 関数のテンプレート(Function Template)
- 関数の定義(Function Definition)
- テスト(Testing)
ペンシルバニア大学の授業の講義ノートにも似たようなものがありました。上記のデザインレシピを参考にしたと書いてあります。こちらの使用言語はOCamlです。
- 問題の理解(Understand the problem.)
- インターフェイスの形式化(Formalize the interface.)
- テストケースの記述(Write the test case.)
- 求められる挙動の実装(Implement the required behavior.)
浅井先生のスライドでは以下の表記でした。
- 目的:関数の目的を考え、ヘッダを作成する。
- 例:関数の入出力の例を作成する。
- 本体:関数本体を作成する。
- テスト:作った関数の動作を確認する。
デザインレシピ、入力ページというものもあります。
テストを作るところはTDDと同じですが、その前後の思考過程についても考えられているところが有益だなあと思います。
あわせて読みたい
- プログラミングの基礎 (Computer Science Library)
- How to Design Programs: An Introduction to Programming and Computing (The MIT Press)
日本に基盤を置いている限り結局、客観的な基準でモノを言えなくなる可能性がある。
— [本] 『初めてでもわかる!システム開発発注入門―悩める担当者がシステム開発で成功するには?』1対1のコミュニケーションの手段は提供すべきではない
発注側で困ったことがあるという経験から会社(サイト)を作ったそうだけど、その結論が、見積書や契約書をちゃんとしろっていうのは残念だなぁ。重要なのはそこじゃなくて、ゼロから一緒に作り上げるという協業モデルだよ。信頼関係さえ築ければ、○○書に注力する時間は最低限でいいもの。
まあ、全体的に自社の広告本。この会社の事情は分かるけど、一般的な話としてはどうなんだろう。たとえば、受託開発では「半額前払いが一般的」とか言っちゃってるけど、本当???本当に一般的なの???個人的にはサンプルの見積書に「製造」という言葉を使っていたので、あまり信じられないなーという印象があったなあ。
サイトをバカバカ作るのも、SEO的にはいいのかもしれないけど、節操無い印象を受けたりする。まあ、発注側の目線で見ると違うのかもしれないが。