Fearless Change の歩き方Developers' Summit 2014 OpenJam
Specification by Example
The document discusses specification by example (SBE) as an approach to software development. It outlines key aspects of SBE including deriving scope from business goals, specifying collaboratively through examples, refining specifications, automating examples, and validating frequently through living documentation. An example is provided showing how SBE can be implemented using Cucumber features,
KISSの原則 - Wikipedia
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。 この言葉は、ロッキードスカンクワークスの技術者のケリー・ジョンソン（1910-1990）によって造られた。 この言葉は、一般には Keep it simple, stupid.（シンプルにしておけ！この間抜け） と解釈されるが、ジョンソン自身は「simple」と「stupi
YAGNI - Wikipedia
英: You ain't gonna need it[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 YAGNI原則を提唱する人々は、その理由として以下を挙げている。 後で使うだろうという予測の元に作ったものは、実際には10%程度しか使われない。したがって、それに費やした時間の90%は無駄になる[2]。 余計な機能があると、仕事が遅くなり、リソースを浪費する[2]。 予期しない変更に対しては、設計を単純にすることが備えとなる。そして、必要以上の機能を追加すると、設計が複雑になってしまう[2]。 人生の時間は、貴重である。したがって、人間の能力は、ただコードを書くためではなく、現実の問題に集中するために使うべきである[3]。 結局は、その機能は必要ないかもしれない。もしそうなったら、あなたがその機能を実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
