設計とか...
気になったって話でそれ以上のオチは無い
色んな人と話をしていると、プログラミングは出来る。 しかしテーブル設計が出来ないとか、設計技法はあまり知らないって人が一定数居ることに気がついた (居ること自体は個人的にはどうでも良いんだけど...知らない事があるなら勉強すれば良いのでは？って思ってるだけなので)
プログラムには必ず裏にデータモデルがあって、どっちが重要って事もないし プログラムを楽に作るには必ずデータモデルの設計があって データモデルの設計の一つにテーブル設計があって それらを手順化して組み合わせたのが設計技法だったりするわけで...
プログラムが出来るのに設計が出来ないってどういうことだろう・・・というか出来るってなに？って思ったｗ
最近の設計・実装のながれ
随分前とだいぶ変わったのでメモ代わりに
# 原則
- 処理で2次元を超えるのデータは可能な限り設計段階で避ける
- 処理で2次元を超えるのデータは可能な限り実装段階でも避ける
- 次元数は可能な限りあげないように設計段階で避ける
- どう頑張っても2次元を超えるなら漏れないルールを作る
# メモ
1次元のデータを扱う実装は簡単に作れてあんまりミスが起きない
2次元までは人が頑張れば作れる
3次元以上は能力的に圧倒的な差が生まれる
なので、1次元〜2次元のデータを扱うようにすると・・・一部がだいぶ多次元にならざるを得ないので、そこをルールでがんばって押さえ込む
「なに」と「どう」
何を作るのか
どう仕組みを作るのか
何で作るのか
どういう手順で作るのか
何で運用するのか
どう運用するのか
っていうのがバラバラに存在してて、個別に議論されてて
でも、議論してる人達がみんなそれぞれ別の「なに」と「どう」を抱えてるのがうっすら透けて見えてて、それを認識できてなさそうな人達がいろんな形で絡んだりしてて
世の中はなかなか難しいな
って思ったお昼のひと時
手法とか技術力とかの差異をぼんやり考えてたら...
前提として
ある人が可能なことと、他の人が可能なことは一致しない
ただし、色々と学習や経験をしていくと可能になったりする
何を考えたか
作るべきソフトウェアは実際には形状の決まってない 何か である
それを各自の持つフィルターを通してみることで形状が見える
フィルターの形と大きさと透明度は各自に差がある
この各自の差が能力的な差に繋がる
あるエンジニアJは
ABCっていうフィルターを使えるエンジニアは
ABCっていうフィルターでソフトウェアを理解しようとする
その結果、ABCっていうフィルターを通した形ソフトウェアが完成する
あるエンジニアIはABCとCDEっていうフィルターを直感的に適切に使い分けている
ただし、通常はABCっていうフィルターが好きなのでABCを使おうってみんなに言う
ABCしか使えないエンジニアJは、エンジニアIの言うことに従えば同じ事が出来ると思い込んで、CDEのフィルターを学習せずにやってみる
結果的に上手くいったり、上手くいかなかったりする
これはABCっていうフィルターの問題ではなく、フィルターは複数を使い分けるべき事があるって事を指してる
エンジニアの初期の頃はフィルターの大きさは小さく透明度も低い
それが経験を通して大きく、透明度が上がる
結果的に作るべきソフトウェアがよく見えるようになる
これが容易に超えられない経験の差として見えるようになる
単なる経験年数を積み重ねたところでフィルターの大きさとか透明度は上がらないので、フィルターを大きくして透明度を上げる努力が必要になる
そもそもの作るべきソフトウェアは形状の決まってなく観測したフィルターによって見える形が変わるのなら、単独のフィルターの優劣はそこまで影響はなくて
いくつのフィルターを使えるのか、それぞれの大きさと透明度はどのくらいなのかが実はエンジニアとチームの優秀さの決定ポイントなのでは？って思った
要件を考えるときにぼんやりやってること
発生元の分析
発生元(要件を言ってる人)が何を考えて、どのレベルのことを言っているのかを把握する
大体発生元から流れてくる情報はこの3つ(とその組み合わせ)に分類される
- 目的を言っている
- 解決策を言っている(目的は言ってない)
- 現状の問題点を言っている
目的だけを言ってる場合
頻度は高くないけど、目的だけを提示してくる場合がある
目的だけなので、そこから解決策の決定とか色々検討が必要になる
ただ、自由度は非常に高いけど自由度が高いから難しい
この場合は現状の調査と目的との差を探って解決策を練るっていう理想的な工程を踏めるので、個人的には楽しい
解決策を言ってくる(目的は言ってない)
このパターンは楽そうに見えて結構面倒なので要注意
発生元がちゃんと目的を持って検討した上で解決策を提示しているのか、それとも思いつきのように解決策を提示したのかの判断が必要
場合によっては目的の再構成から始める方が良い
ここをミスると無駄な作業が増える
現状の問題点を言っている
現状が問題だということをひたすら言ってくるパターン
そもそもの目的がないので理想的には問題解決をするために目的を作る所からスタートして、解決策を練るのが良い。
このパターンしか言わない人も多いので慣れるしかない
発生元の分析の後の作業
発生元の分析の結果はこの4つを作る事
- 現状
- 目的
- 課題（目的と現状の差）
- 解決案（課題をクリアするための方策）
解決案で目的が達成できるならその解決案を実現するという工程に入る
解決案の実現の時の判断基準として必要なので、目的を常に認識しておくこと
自分は普通にやってたけど、意外と知らない人も多いみたいなのでメモとして...
最近よくやる設計方針
設計対象を真っ先に大きく3つに分ける。
基本方針はこれだけ
3つの基準
L1 最小単位で意味があるもの
L2 L1を利用しつつ、価値を生み出すための物
L3 外部も含めて連動する
L1は最小単位で意味がある。
全体として構築する内容が何かによっても違うけど、これ以上細かくすると意味が無くなる単位
機能要件を満たすより中身がシンプルになる様に気をつける
L2は価値を生み出すためにL1を利用するもの
複数のL1が関係したりするけど、機能要件を満たしたりする為の単位
L1との連動方法が結構色々あるのでそこは考えるポイントになりそう
L3は外部と連動したりする
L1だったりL2の情報を集めて外部連携用の機能を作ったりする
機能要件を実現する部分だけど、集計だったり外部連携だったり色々
L1,L2,L3は単なる分類だけど、依存関係があることに注意
メリットとか
普通に設計してると全体的に機能が複雑化したりするのを回避できる。
複雑なポイントを集約できるので量産しやすくなる。
重要なテストもポイントを絞れる
わりと仕様変更の影響場所を特定しやすくなる
デメリットとか
良さを理解してもらえない
ランチで気になってること
相変わらず色んなお店のランチを楽しんでる今日この頃
だいぶ前から気になってるお店毎の特徴を思い出した
タイプ1：客層が男性客(主にスーツ着用)が多い
居酒屋的なメニューのランチ。
比較的安めなお店が多い印象
喫煙可のお店が多い印象。全部のお店が不味いわけじゃ無いので喫煙可は困るｗ
タイプ2：客層が男性客と女性客が混在
メニュー自体はありきたりな感じだけど少しこだわりがある
値段はそんなに高くない
いつも行くにはちょうど良い感じ
タイプ3：客層が女性客(仕事して無さそうな人含む)が多い
こだわりのメニューで構成されたランチ
値段はチョット高め
大体美味しいのでオススメ（でも高い
タイプ4：ガラガラ
味がいいのに値段はそこそこなのに謎なガラガラのお店とか
この値段でこれか〜っていう理由のわかるガラガラなお店とか
色々ｗ
一番当たり外れが大きい
タイプ5：ちゃんとした格好の叔父様方が多い
値段が高くて敷居も高い
ランチなのに精算の時に領収書どうしますか？って聞かれるｗ
美味しいけど、なにか無いと行くのは厳しい
客層でお店のお気に入り度合いが把握できることに気がついた2019年でした
そんな2019年もあと2ヶ月か〜
