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

回答の条件
  • 1人10回まで
  • 13歳以上
  • 登録:2010/08/18 11:54:25
  • 終了:2010/08/23 13:37:53

ベストアンサー

id:australiagc No.2

australiagc回答回数467ベストアンサー獲得回数902010/08/18 14:49:53

ポイント60pt

漠然とした質問ですが・・・自分が気をつけていることは;

  • 常に最新技術を取り入れる。(i.e.既存の規格やツールは使わず、発表されたばかりの新規格やツール、場合によっては将来性があると思われるβ版のものを積極的に採用します。)
  • 全ての値はコンパイルをせずに変更可能としておく。(i.e.インストーラーや設定専用のプログラム、データベース、XMLファイルなどを通して全ての値は変更できるようにしておき、ハードコードは一切しない。)
  • セキュリティを念頭において設計する。(i.e.簡単な設定で、エンコーディングやアクセス規制が掛けられるようにしておく。)
  • ローカライゼーションを念頭において設計する。(i.e.技術的な知識を要さずに翻訳が行え、翻訳された内容をすぐにプログラムへ反映できる構造にしておく。)
  • 例外処理を念頭において設計する。(i.e.全ての起こりうるエラーは、例えコード上で検証されているとしても、万が一発生した場合にプログラムがクラッシュしないようにしておく。エラーメッセージを表示し、すぐにデバグができるようエラーログも残るようにする。)
  • 開発行程では随時ログを残す。(i.e.ソースコードには一行一行丁寧にコメントを入れ、変更を加える際にはバージョンログを残す。ユーザ、開発者双方の為の仕様書やマニュアルを残す。)
  • 容量制限を先に調べておく。(i.e.HDDやメモリの容量、通信の帯域幅、データタイプやデータベースの容量制限などに気をつけています。)

他にもいくつかありますが、上記が最も気をつけている点ですね。

id:masa193

ご回答ありがとうございます。参考になります。

>常に最新技術とあります。

確かに最新技術を積極的に取り入れる姿勢は、素晴らしいとお考えだと思います。私も同意見です。

ただ一方で、最新技術は、何かしらの不安要素を抱えているのも事実かと思います。(ex.突然、統合開発環境が起動できなくなった)

なにかしらのトラブルがあった場合、どのように対処されてきたのでしょうか?

お話が有ればお聞かせ下さい。

>全ての値はコンパイルをせずに変更可能としておく。

かつて、defineで定義したものです。

言語定義における仕様変更・追加が多々あるので、XMLは便利。

2010/08/18 19:35:53

その他の回答(8件)

id:yamaneroom No.1

yamaneroom回答回数1040ベストアンサー獲得回数612010/08/18 12:40:36

ポイント5pt

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

id:masa193

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

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

2010/08/18 15:42:32
id:australiagc No.2

australiagc回答回数467ベストアンサー獲得回数902010/08/18 14:49:53ここでベストアンサー

ポイント60pt

漠然とした質問ですが・・・自分が気をつけていることは;

  • 常に最新技術を取り入れる。(i.e.既存の規格やツールは使わず、発表されたばかりの新規格やツール、場合によっては将来性があると思われるβ版のものを積極的に採用します。)
  • 全ての値はコンパイルをせずに変更可能としておく。(i.e.インストーラーや設定専用のプログラム、データベース、XMLファイルなどを通して全ての値は変更できるようにしておき、ハードコードは一切しない。)
  • セキュリティを念頭において設計する。(i.e.簡単な設定で、エンコーディングやアクセス規制が掛けられるようにしておく。)
  • ローカライゼーションを念頭において設計する。(i.e.技術的な知識を要さずに翻訳が行え、翻訳された内容をすぐにプログラムへ反映できる構造にしておく。)
  • 例外処理を念頭において設計する。(i.e.全ての起こりうるエラーは、例えコード上で検証されているとしても、万が一発生した場合にプログラムがクラッシュしないようにしておく。エラーメッセージを表示し、すぐにデバグができるようエラーログも残るようにする。)
  • 開発行程では随時ログを残す。(i.e.ソースコードには一行一行丁寧にコメントを入れ、変更を加える際にはバージョンログを残す。ユーザ、開発者双方の為の仕様書やマニュアルを残す。)
  • 容量制限を先に調べておく。(i.e.HDDやメモリの容量、通信の帯域幅、データタイプやデータベースの容量制限などに気をつけています。)

他にもいくつかありますが、上記が最も気をつけている点ですね。

id:masa193

ご回答ありがとうございます。参考になります。

>常に最新技術とあります。

確かに最新技術を積極的に取り入れる姿勢は、素晴らしいとお考えだと思います。私も同意見です。

ただ一方で、最新技術は、何かしらの不安要素を抱えているのも事実かと思います。(ex.突然、統合開発環境が起動できなくなった)

なにかしらのトラブルがあった場合、どのように対処されてきたのでしょうか?

お話が有ればお聞かせ下さい。

>全ての値はコンパイルをせずに変更可能としておく。

かつて、defineで定義したものです。

言語定義における仕様変更・追加が多々あるので、XMLは便利。

2010/08/18 19:35:53
id:Mathusala No.3

サディア・ラボン回答回数259ベストアンサー獲得回数42010/08/18 16:25:19

ポイント5pt

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

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

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

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

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

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

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

 

 

ソフトウェアも同様で、

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

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

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

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

id:achan774 No.4

achan774回答回数9ベストアンサー獲得回数02010/08/18 16:40:43

ポイント5pt

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

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

id:masa193
2010/08/18 19:43:13
id:yamaneroom No.5

yamaneroom回答回数1040ベストアンサー獲得回数612010/08/18 16:41:29

ポイント5pt

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

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

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

id:bushimichi No.6

ぶしみち回答回数12ベストアンサー獲得回数12010/08/19 14:22:31

ポイント5pt

1.難しいことはやらない(複雑なことをしない)

2.ソフトウェア開発者以外にも理解できる(説明できる)仕組みを心がける

3.なるべく誰でも使える技術を選ぶ(オープンソースや市販品)

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

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

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

id:masa193

全般的にもう少し具体的に踏み込んで頂けないでしょうか?

例えば、

>2.ソフトウェア開発者以外にも理解できる(説明できる)仕組みを心がける

共通理解を深めるには、どのような基準が要るとお考えですか?

その上で、どのような仕組みを手掛けてきたのか、お聞かせ下さい。

2010/08/19 23:34:21
id:lvbestbbs No.7

⒉o⒑ャ宅釹回答回数129ベストアンサー獲得回数02010/08/19 18:49:31

(はてなにより削除しました)
id:MAS3 No.8

MAS3回答回数40ベストアンサー獲得回数22010/08/19 22:31:43

ポイント15pt

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


■名前に妥協しない

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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

id:t-wata No.9

t-wata回答回数82ベストアンサー獲得回数132010/08/20 08:45:30

ポイント40pt

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

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

  • 自動ユニットテストをビルドに組み込む(自動的にテストしやすい設計をする)。コンポーネント化、アブストラクト化し、外部リソースの変更を伴うような箇所を極小化する。
  • 明示的に渡すメッセージ以外の要素への依存を必要最小限に(静的な要素、例えばコンフィグファイルの設定内容とかは別だけど)
  • 全体の大部分はコードを修正してから10分以内にそのコードを手動でユニットテスト/デバッグできる(ようにSDKやフレームワーク設計の段階から考慮する)
  • フルビルドや時間のかかるステップを踏まないとテストできないようなコンポーネントを必要最小限におさえ、バグの温床化しそうな箇所を極小化する。
  • 状態数を必要最小限にする。AだけどBでは無い場合、AでないけどBの場合、AでもBでもない場合、Aで且つBの場合の4つの異なる状態をそれぞれ別々に処理する必要があるときに、Cの場合、またはCで無い場合という新しい要素が加わると状態数が倍の8通りになりソフトウェアは複雑になりテスト項目も一気に増えます。状態数を増やす必要がある要求があった場合は、状態間の依存を断ち切るための代替案など提案/交渉します
  • 例外的な処理(通常はこうだど、この場合だけはこう、みたいなもの)を極力避ける。
  • id:dev_zer0
    simple is best
  • id:garyo
    Keep it simple, stupid
  • id:windofjuly
    うぃんど 2010/08/18 13:08:49
    realistic
  • id:standard_one
    ざっくりした質問ですなぁ
    設計といわれてデータ設計を思い浮かべる人、コード設計を思い浮かべる人、UI設計を思い浮かべる人etc居ましょうに
  • id:masa193
    >standard_one
    思い浮かんだものをお聞かせ頂ければ幸いです。
    それが、あなたのポリシーの一部になっている筈です。
  • id:hathi
    ソフトウェア開発、特にユーザーが一般人のシステム開発・設計をしてくれる人に希望するのは次のことです。
    ①他のシステムとできるだけ似ている設計(構造、アーキテクチャ、使い方)
    ②利用者が使用方法を簡単に理解できで、理解放棄や誤解が起きにくいシステムと説明の充実
    ③希望要件が変わって条件・仕様を追加して欲しいときに、短期間で対応できる設計
    ④他のシステムと連携等をさせる必要ができたとき、第三者にわかりやすい構造と仕組み
    ⑤ハードウエアや通信環境の変更に対応させる必要が生じたときに、簡単に対応できる設計
    ⑥誤操作、誤入力などに対して、前に復帰させることが可能な仕組みの組み込み
    ⑦専用システムでない場合。OSや常駐ソフト、他のソフトとの切替利用、途中での強制シャットダウンなど(不規則、不適当な操作)に対して、データの安全が確保され、システムが完全に破壊されないことへの十分な配慮
    ⑧当たり前かもしれませんが、設計時に扱うデータの限界(量と値)を含めた検証をすべてステップ毎に行い、その記録を残して下さい。各ステップの設計開始前に、その設計を済ませる前に何をどのような方法で検証するのかを見込んで設計をして下さい。
  • id:australiagc
    >> 最新技術は、何かしらの不安要素を抱えているのも事実

    まさに仰る通り、諸刃の剣ですね。
    yamaneroomさんの仰る、バグが取り尽くされた枯れた技術の方が手堅いとは思います。
    これは好みの問題かもしれませんが、僕自身は不安要素を抱えた最新技術の方が長期的に考えて手間が少ないと思っています。

    ・バグの無い旧来の規格でシステム開発⇒数年後に安定した最新規格へ全移行
    ・バグの無い旧来の規格でシステム開発⇒数年かけて安定してきた部分から徐々に最新規格へ以降
    ・バグの有る新規の規格でシステム開発⇒数年かけて安定してきた部分を微調整

    この三つの選択肢を比べた場合、個人的には最後のオプションが一番楽だと感じるのです。
    もちろん、クライアント側が最新規格に対応していない場合は旧来の規格にも互換性があるように開発しておき、
    新規格が普及するに連れて旧来の規格との互換に割くコストを減らしていきます。
    新旧両方の環境へ互換性を持たせなくてはならないので初期コストはかかりますが、後は楽になる一方です。
    逆に、はじめから旧来の規格だけでシステムを設計してしまうと、新規格の普及に連れてコストがかさんできます。

    また、最近の規格は状況に応じてダイナミックに開発ができるものが多い点も魅力ですね。
    例えばウェブ開発で言うと、プラグイン無しで色々な事ができるHTML5、色々な言語が使えるASP.NET、
    どんなデータベースにでも簡単に対応できるLinq、インターフェイスのデザイン転用が容易なMVCなどですか。
  • id:longicorn
    汎用性ですね。
    これが無いと修正や機能追加などが非常にしづらいです。

    ただし、やりすぎずにシンプルにしておくこと。
    汎用性を求めすぎると、逆に使いにくく、理解しにくく、コストが膨大になるので。
  • id:dev_zer0
    > ・バグの有る新規の規格でシステム開発⇒数年かけて安定してきた部分を微調整
    そして、数年後に新規規格が出来た場合、
    > ・バグの無い旧来の規格でシステム開発⇒数年かけて安定してきた部分から徐々に最新規格へ以降
    ということになります。
    その時の「微調整」がバグの温床になることが多々あります。
     
    例えばwebが普及した当時(1997年頃)、HTMLは3.2が主流で
    CSSがサポートされていないブラウザしかありませんでした。
    よって、見栄えを重視する場合はタグで調整というのが一般的でした。
     
    今(2010年)はHTML4が主流で、レイアウトの調整の為にCSSを使わずに
    タグで調整する方法は今は邪道となってます。
     
    そして、今後HTML5が主流となっていくと私は考えていますが、
    古いブラウザ(今はIE6が癌になってます)のサポートや
    現在の大量のHTML4はどうするのでしょうか?
     
    あと、個人的な偏見ですが、Win系の最新技術って死に技術が多い気が...
  • id:australiagc
    dev_zer0さん、ご意見ありがとうございます。

    「数年後に新規規格が出来た場合」に関してですが、
    僕は膨大なコストをかけてでも、その規格でシステムを再構築しますね。なので、
    > ・バグの無い旧来の規格でシステム開発⇒数年かけて安定してきた部分から徐々に最新規格へ以降
    ではなく、
    > ・バグの有る新規の規格でシステム開発⇒数年かけて安定してきた部分を微調整
    を繰り返します。
    幸い、年々新規格へのコンバージョンも楽になりつつあるので。

    もちろん、旧来の規格(数年前の新規格)を即刻破棄するわけには行かないので、
    両方のバージョンを平行に共存させ、クライアントに合わせてバージョンを振り分けます。
    HTMLなんかは良い例でしょう。
    ユーザーエージェントによって新旧、クライアントが対応しているバージョンへ振り分ければ言い訳ですから。
    ASPやPHPでこれは簡単(むしろ当たり前?)にできますし。
    極端な話、HTML3~5全てに対応できるようにしておくというわけです。
    例えば、HTML3と4が普及している時代は全ページを両方に対応できるように。
    HTML5が普及してきたら、全ページをHTML5にも対応させます。
    HTML3が衰退したら、その後新たに開発/変更するページはHTML3比対応にする。
    といったカンジですね。

    Win系の技術に死に技術が多いというのは、同感ですね。
    逆に観れば、MSにしろGoogleにしろ、新しい技術を大量に排出している以上は半分以上死に技術であって当然でしょう。
    どれが死に安いか見分けるにはやはり普段から最新技術に目を光らせておき、目を養っておく必要があります。
    死んでしまった技術はその場で廃棄です。ハード本体同様、ソフトの賞味期限は3年だと思ってますので。

    何故旧来の規格を毛嫌いするかと言うと、社内保守で五年以上前の規格を掴まされて辟易した経験が多くって・・・。
    部分的に移行していく方法をはじめは取っていましたが、それだと旧来のシステムとの折り合い上、
    妥協しなくてはならない点が出てきてしまい、結果的には状態がどんどん悪化するというパターンに何度も見舞われました。
    結局、全システムを一から再構築して、旧来のシステムと平行で共存させる方がすぐに事が済んだので。
    これは理屈以上に、トラウマですかね・・・。
    性格の問題もあると思います。僕は保守よりも開発向けの性格みたいなんで。
  • id:Beirii
    郷に入りては郷に従え

    メンバー同士のポリシーの衝突とか不毛ですよねぇという。
  • id:masa193
    >hathi
    ご回答ありがとうございます。

    >利用者が使用方法を簡単に理解できで、理解放棄や誤解が起きにくいシステムと説明の充実
    人が介する部分は、語弊や誤解はつき易く、難しい問題です。
    「理解がしやすさ」、「誤解がおきにくい」等の基準については、いつも頭を悩ませるところです。
  • id:Mathusala
    サディア・ラボン 2010/08/20 12:39:28
    計算をするソフトを作る場合、
    2の3乗は8
    8の3乗根は2
    2を底とした真数8の対数は3 (関数電卓だと、log8÷log2で計算できます)
    みたいに、
    答えから元の数字も求められるように、
    逆の操作を出来るようにしたいです。
  • id:garyo
    不具合の修正で、時間のかかる根本的な対策と、すぐ済む対処療法があった場合、根本的な対策を選ぶ。結局そっちの方がトータル時間は短くなる。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません