ソフトウェア開発において、あなたの設計に対するポリシーを教えて下さい。

枯れた技術を中心に設計する

ソフトウェアじゃなくてブログですが、

使いやすさを第一にしているつもりです。

http://ameblo.jp/taddy-frog/

「数式コレクション」、「イノゴ8世(日本語)」と「Inogo VIII(英語)」の、

各記事間の相互リンクを張って、見たいページが探しやすいようにしています。

「マトゥサラ(日本語)」と「Mathusala(英語)」の相互リンクは、まだ完成していません。

(はてなで使っているIDと同じ題名ですが、昔はブログ主とは別人を演じていて、ぼくが和訳を投稿しているふりをしていました)

ソフトウェアも同様で、

ヘルプを見たら、関連キーワードをすぐ見られるようにしたらいいです。

Ameba Picoは、「お出かけ」→「SHOP」をクリックすると、

全部の店が表示されて、更に「ファッション」や「アクション」などをクリックすると、

洋服屋だけが表示されたりして便利ですから、アメーバピグにも取り入れて欲しいです。

ユーザーの希望を鵜呑みにしてそのまま実装するのではなく、

本当にやりたいこと、目的を聞き出し、それを実現するのに必要なことを考え、提案することを心がけています

>なぜ、枯れた技術を中心にお使いになるのでしょうか？

>メリットをお聞かせ下さい。

バグが取り尽くされているから。

１．難しいことはやらない（複雑なことをしない）

２．ソフトウェア開発者以外にも理解できる（説明できる）仕組みを心がける

３．なるべく誰でも使える技術を選ぶ（オープンソースや市販品）

４．小さな簡潔な仕組みを組み合わせて、大きな仕組みを作るようにする。

あんまり、特別なことはしないですね。

オーソドックスな感じだと思います。

ポリシーというよりかはもう少し具体的な気をつけていることになりますけど、こんな感じです。

■名前に妥協しない

一口に名前と言っても画面名・項目名・メソッド名・変数名などいろいろありますね。お客様やプロジェクトメンバーがなかなか覚えられなかったり、意味を勘違いした場合にはもっと良い名前があるのではないかと考えて、できれば変えてしまいます。

関係者が固定化されればそのシステムの方言として普通に使われることになるのですけど、必ず新しい関係者は出てくるのでその際のコミュニケーションロスを防ぐ目的です。

■画面や帳票にはプライマリキーを含める

伝票に伝票番号を入れるのは当たり前でしょうけど、それ以外のシステムが内部的にしか使わないような番号でもできるだけ人の目に触れるようにします。

これは、何か問い合わせや不具合があった時に該当データを特定しやすくするためです。ですので目立つところに置いておく必要はありません。

ただしお客様によっては直接関係ない情報は出したくないということもあるので、こちらの目的を説明してそれでも納得していただけないのであればあきらめざるを得ないということもあります。

■備考やメモという項目を用意しておく(ことを検討する)

将来項目が増えるかもしれないのであらかじめ作っておく、ということではありません。そういう時は素直に増やせばよいので。

そうではなくて、例外的なことをしないといけない時などにこういった何でもありの項目を使って人間系の運用でカバーするという選択肢を残しておくためです。

何かの名称マスタで名称の変更が発生して、普通はそのまま更新してしまえばよいのですけどある項目に関しては以前の名称を備忘録的に残しておきたいということがたまたま発生した場合に使ったりします。

あんまり積極的には使って欲しくない項目ですけど。

■エラーログには値も出力する

例えば「ファイルが見つかりません」だけではなくて「ファイルが見つかりません(hoge.xml)」という感じです。

現象の把握をしやすくするためですね。

そんなの当たり前という人も多いと思います。高機能なIDEでの開発が当たり前で開発だけしてあまり運用に関わらないような人ですと、そういう値はデバッガで見れば分かるでしょうという考えなのか、ログに無関心な場合もあります。

理解しやすい設計を心がけてます。

そして設計で重視する項目で他の人と異なるのはテストについてですかね。個人的にテスト性について明確にポリシーをもってます。

• 自動ユニットテストをビルドに組み込む(自動的にテストしやすい設計をする)。コンポーネント化、アブストラクト化し、外部リソースの変更を伴うような箇所を極小化する。
• 明示的に渡すメッセージ以外の要素への依存を必要最小限に（静的な要素、例えばコンフィグファイルの設定内容とかは別だけど）
• 全体の大部分はコードを修正してから10分以内にそのコードを手動でユニットテスト／デバッグできる（ようにSDKやフレームワーク設計の段階から考慮する）
• フルビルドや時間のかかるステップを踏まないとテストできないようなコンポーネントを必要最小限におさえ、バグの温床化しそうな箇所を極小化する。
• 状態数を必要最小限にする。AだけどBでは無い場合、AでないけどBの場合、AでもBでもない場合、Aで且つBの場合の4つの異なる状態をそれぞれ別々に処理する必要があるときに、Cの場合、またはCで無い場合という新しい要素が加わると状態数が倍の8通りになりソフトウェアは複雑になりテスト項目も一気に増えます。状態数を増やす必要がある要求があった場合は、状態間の依存を断ち切るための代替案など提案／交渉します
• 例外的な処理（通常はこうだど、この場合だけはこう、みたいなもの）を極力避ける。