ソフトウェア

オブジェクト指向はすでに粒度が時代にあっていない

定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとして…

PM向けフィジカルの問題

4艘の小船があって、向こう岸を行き来するのにそれぞれ片道1分、3分、6分、9分かかるとする。 ひとりの漁師がこの4艘の小船を向こう岸に持っていこうと思っている。 漁師は一度に2艘の船を運ぶことができるが、そのときにかかる時間は遅い方の小船の所要時…

データベースカバレッジを考えたデータ作成

とりあえず、データベースカバレッジを考えたデータ作成を考えてみます。 まず、大きくわけて3つのカバレッジを考えます。 単一テーブルの条件カバレッジ 関連テーブルの行数カバレッジ 関連テーブルの条件カバレッジ 「単一テーブルの条件カバレッジ」とい…

データベースカバレッジという考え方

データベースアプリケーションのテストデータを用意するとき、どういうデータを用意しますか? 「注文があって出荷してないデータ」「注文があって出荷していて入金がないデータ」という風に業務の流れにそってデータを考えることが多いと思います。 ただ、…

オブジェクト指向とクラス指向

今、オブジェクト指向とよばれているものは、結局のところクラス指向です。 オブジェクトを見出して、そこからクラスを見出して、クラス同士の関連を見出すという流れになります。 その結果として、たとえば僕が今この文章を書いているパソコンと、あなたが…

イデアとしてのソフトウェア要求、そしてエロス

実装すべきソフトウェアの、理想的な、でも記述不可能な要求・仕様がイデア界にあるとすれば、仕様書やソフトウェアは、そのイデアの影ということになる。 で、完全な要求や完全な仕様を求めることがエロス。

さらに追っ手から逃げるシステム

われわれは、日夜ソースコードを書いている。 ソースコードはわれわれの仕事の証、われわれの生きてきた証と言ってもいい。 そのような大切なソースコードを、そうやすやすと修正変更をされるのは腹立たしいことこのうえない。 もちろん経営者も、コストをか…

開発プロセスと不完全性定理と人間の力

読むのが面倒な人は、最後の行だけ読んでください。 ゲーデルの不完全性定理によって、完全な開発プロセスを定義することはできないと何回か書いてます。 ゲーデルの不完全性定理というのは、要するに「数学が矛盾していないことを証明できない」という定理…

完全性定理

プロセスやシステムが完全であることは証明できないのだから、完全であることを求めるんじゃなくて正常であることを求めるようにするほうがいいのかな。

フレームワークの賽の河原

手法やフレームワークが枯れてきて、プログラムに手がかからなくなってきたと思ったら、それまでのフレームワークが使えないような新しい実行環境が流行りだす。 Ajax・・・。

自動生成

自動生成を考えるときに、生成したいものから単純に入力を考えて、単に自動的に生成することだけを考えると、その場限りになりやすい。 生成したいものが概念的に何を表しているのかを考えて、それを表現できるものを入力するようにすれば、ある程度息の長い…

開発しやすいソフトウェアプロセスではビジネスしにくい

上に書いたようなプロセス、人の確保とか見積もりとか考えると、ビジネスやりにくいと思います。 逆に、ビジネスやりやすいプロセスは、開発しにくい。 派遣はもはや必要悪としても、設計と実装が別の会社というのは百歩譲るとしても、概要設計と詳細設計が…

専任のテスト担当者がいないなら独立したテスト工程をしないほうがいい

ふと。 そう思った。 一般化して、すべての工程は専任の担当者がいないなら独立した工程にしないほうがいいといえるかも。 工程というか、債務を人に割り当てて、その人は割り当てられた債務をどんな順番でどんなタイミングで行ってもいいってことにする。同…

ソフトウェアの測定困難性とUFOの測定困難性は別物

未熟な科学と擬似科学を同列に論じるべきではありません。 ソフトウェア開発の完全なプロセスが構築できないのは、ゲーデルの不完全性定理によるもので、ソフトウェア技術者であればチューリングマシンの停止問題としてなじみのあるはずのものです。 また、…

ほんとに良いコードを書くために必要なことは

ほんとに良いコードを書くために必要なのは、一冊の本になったりブログでみんなが取り上げたりするようなハデな事柄ではなくて、例をあげようにもあげられないような些細で地道な工夫の積み重ねだと思います。 ほんとに良いコードは、何の工夫もしていないよ…