プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
プログラム言語はユニットテスト可能かどうかの観点で考えてみよう - プログラマでありたい
面白いエントリーがありました。 Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ 私も正直、オブジェクト指向だから生産性が高いとか、最新のフレームワークを使えばハッピーになれると言った言説には疑問があります。ということで上記エントリーについては基本的には同意なのですが、そこに至った過程が違います。 私にとって大切なのは、ユニットテストが出来るかどうか。また、ユニットテストを継続的に自動実行を出来る環境があるかどうかです。この2点です。ユニットテストのメリットは、色々なところで語られているので詳しくは書きませんが、次の3点に集約できるかと思います。 ・テストの再現性がある。（退行テストが用意） ・プログラム変更の予期せぬ影響が発見される可能性が高い ・プログラムの構造が洗練され、ソースが綺麗になる 1番目の再現性ですが、一度テストプログラムを書いておけば何度でも実行で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
