設計
設計に関するナレッジやノウハウ。
設計ナレッジ
雑多なメモ
トピックにまとめられそうになったらまとめます。
- ドイッチュ限界
- ビジュアルプログラミングは、画面上に一度に50を超える要素を表示できない、という警句
- No is temporary, Yes is forever.
- 機能要求を断るのは一時的なことだが、一度 Yes と言ってしまうと開発から保守までのコストをかけることになる
- なんでもかんでも機能を追加するだけでは価値は出ない、本当に必要な機能を見極め、そこから外れた要求に対しては No と返し続けないといけない
- No is temporary, Yes is forever - kidooom's Scrapbox
- 「ソースコードがドキュメント」は一理あると思ってるけど、経験上ドキュメントが存在しないシステムのソースコードがきれいだった試しがない。人にぐちゃぐちゃなものを読ませて「ソースコードがドキュメント」とか言うのは本当にやめてほしい
- 品質の観点
- 機能性
- 目的性 : 目的に合っている
- 信頼性
- 障害許容性 : 障害影響が少ない
- 回復性 : すぐ復旧できる
- 使用性
- 理解性 : 分かりやすい
- 習得性 : すぐ覚えられる
- 運用性 : 使いやすい
- 効率性
- 時間効率性 : 速い
- 資源効率性 : 省資源
- 保守性
- 解析性 : 中身が分かりやすい
- 変更性 : 簡単に変更できる
- 安定性 : 障害が発生しにくい
- 試験性 : テストしやすい
- 移植性 : 移植しやすい
- 設置性 : インストールが容易
- 置換性 : 他のシステムに置き換えやすい
- アクセス制御性
- アクセス監査性
- 堅固性 : 誤った操作をしてもデータが破壊されない
- 整合性 : 異常が発生してもデータが破壊されない
- モジュール性 : 局所的な変更で済む
- 自己包含性 : 他のモノに依存しない
- 機能性
- magicant/language-design: プログラミング言語設計のメモ
- わかりやすいシステム構成図の書き方 - Qiita
- 製品名ではなく役割を書く
- データと処理を書き分ける : 処理は四角で囲み、DB・テーブル・ファイル・キューなどは図形を描き分ける
- データの流れと制御の流れを書き分ける : データの流れは「処理」を起点にする、制御の流れは「処理」と「処理」を繋ぐ、それぞれの矢印線は実線と点線などで描き分ける
- API越しでタイムスタンプをやりとりする時のフォーマットをどうするべきか - その手の平は尻もつかめるさ
- 文字列型で RFC 3339 (ISO 8601) のみ扱えるようにすると、バリデータの作り込みが問題になる
- Unix Time を使えば UTC であることが担保できる。時間の単位を
_secや_msといったフィールド名で示せば良い double型 (小数) のフィールドなら単位は sec (秒) で、細かい精度を小数で示せば良い、と表明できるかも (JS 界隈では浮動小数点の誤差が出るのであまり扱いたくないが…)
- コンテクストメニューの役割 (agenda)
- コンテクストメニューは、ポイントされているオブジェクト、または位置に関する操作を行う為のメニューに絞るべき
- 「何故コンテクストメニューなのか」を全く考えないまま、直感的に便利だからという理由でコンテクストメニューに機能を詰め込んでいると思われるアドオンが多すぎ。「ポイントしなくても良い操作なら、コンテクストメニューにしてはならない」くらいの制約をまず課して考えてほしい
- 0.1秒：ユーザは、自分がシステムを「直接」操作していると感じる。
1秒：ユーザの思考を止めない限界。反応に時間がかかっていることに気づき、システムの存在を意識する。
10秒：ユーザが操作に集中できる限界。待っている間に何らかの形で処理の途中であることを伝えないと、容易に他のことに興味が移る（離脱する）。
つまり、Webサイトの反応速度（ページの表示速度）は、理想は0.1秒、可能な限り1秒以内に収めるべきで、それ以上ユーザを待たせると離脱が増えるばかり、ということが言えるでしょう - システムエラー出たとき、何種類かのネコのgif画像をエラー内容に合わせて表示するようにしたんだけど、
問い合わせが基本「猫ちゃんが出てきた」になったし
猫ちゃん見てるからクレームの温度感も温くなったし
こっちもとりあえず「画面にどんな猫ちゃん出てますか？」って聞けばいいし楽 - Excelのサポートを10年間やってきた経験から最も頻出の助言は「データベースファーストの原則」であり、この原則には「1セル1データの原則」「1列1データ型の原則」「セル結合禁止の原則」の3つが含まれる
- 要件定義～システム設計ができる人材になれる記事 - Qiita
- 多い日も安心設計 - Qiita
- 工数見積もりは日数×10時間でいいんじゃないかな - Qiita
- 似て非なる文字の扱い方、名寄せについて考慮すべきこと … 入力チェック、自動統一変換をどの程度行うか
- 似て非なる「ハイフン」文字をどう扱うか
- 似て非なる「スペース」文字の扱い方。プログラミング (実装工程) でも注意が必要