トップ > 20220305_プリンシプルオブプログラミング

20220305_プリンシプルオブプログラミング

アプトプット画像

読んだ本

www.amazon.co.jp/dp/4798046140

どういう本なのか？

  • コードは一切ででこない。
  • プリンシプルとは本質的な知識のこと。
  • 「優れた方法」のエッセンスが凝縮された本だった☺️

元気をもらった言葉

まず抽象を学び、それから具体的なコードの技術を学んだ方が効率的に確かな技術が身につくのです。

  • 半年前に比べると、抽象的な概念を知ることで、技術記事などを読むときに「設計思想で大事と言われている中のこの辺りの話かな」と最近、繋がることが増えてきた。
  • ここから抽象を具体に繋げるための道具（PHP,Symfony等）を吸収していけばいいんだって前向きになれた。

なるほど！知識のアップデートに繋がったこと

単一責任の原則（＝役割は1個にする原則）

  • コードを修正する理由あるいはタイミングで分けるという意味でもある

🌷責任という言葉で悩んだ時は、修正時どうなるかという思考も一つの手なのかと思った。

信頼性（機能を維持する能力）には2つの側面がある

1. 正常な動作を保ち続ける：フォールトトレランス（fault障害 tolerance忍耐）

2. もともと頑丈か：（robustness堅牢性）ロバストネス

  • 障害時にその部分だけ切り離す設計：フェールセーフ
    • 例　石油ストーブ転倒したら勝手にストップ
  • あらかじめユーザーが誤操作しない設計：フールプルーフ
    • 例　座った時だけウォシュレット使用OK、電池+-逆だと入らない

🌷フェールほにゃららで混乱しがち😅維持するための機能と元々頑丈にしとこうとする2つの側面があるのね。

新しく知ったこと

  • 再利用(全体あるいは一部を別のソフトウェアでも再利用できること）の「3の法則」
    • 難易度3倍の法則
      • 再利用可能なモジュールを作るには「一般化したらどうなるかな」と想像力＆考慮が増えるため3倍難しいと言われている
    • テスト3倍の法則
      • 共有化する前に3つの異なるソフトウェアで使えるかテストする必要がある

🌷知らなかった。確かにピンポイントで解決しようとするよりも、一般化するの難しい。

7つの設計原理（コードレビューする時にこの観点持つといいよ）

  1. 単純原理‥シンプルで読みやすいか？
  2. 同型原理..同じものは同じに表現しているか？（単位、引数の数、使用順序等）
  3. 対称原理..対称性がとれているか？（beginがあったらendがある等）
  4. 階層原理..階層が整理整頓されているか？（抽象／具体、同じ処理は同じ層等）
  5. 線形原理..処理の流れは直線か？（反復・分岐を避け、上から下に向かった一筆書きGood）
  6. 明証原理..一見して明らかに正しいか？（不明瞭さを潰し、ロジックや変数名が直感的でわかりやすいとGood）
  7. 安全原理..ありえないという条件をあえて考慮しているか？（ある変数に対してNULLチェック、あるcase文に対してdefaoult句を考慮）

🌷レビューの業務も少しずつ増えてきたためナイスタイミング！と思った。

UNIX思想の一部「修復の原則」

  • エラー検知は「けたたましく」w
  • 修復が成功していないのに処理を継続してしまうと、どこで起きたのか失敗した影響範囲はどれくらいなのか特定しづらくなる
  • ソフトウェアの使われ方にもよるが動作中に失敗したら、処理はストップし、エラーについてはできるだけ目立つ（早く気づいて判断できるように）するとGood

🌷さっきの信頼性の話あったものの（ソフトウェアの使われ方にもよるけど）おかしくなったら一旦ストップして、それにどれだけ早く多くの人が気づいて、復旧に取り組めるか大事だなって思った。

UNIX哲学の一部「即行プロトタイプ」

  • まずは試作品を小さく早く作ろう、なぜならば下記の3を目指すため！ 
     1. 性能こそ非常に高いが必要な機能が欠けている
 2. 機能は多くなるが、性能が犠牲になっている
 3. 両者の間に最適なバランスが模索され、本当に必要な機能だけ残して、適正なリソースで多くの事を達成できる

🌷試作品を作る目的が「3.」の部分であること知らなかった。たしかに「3.」に到達するには「1.2.」をどれだけスムーズに回せるかなのか。「なぜ」なのか知れたー💡

UNIX哲学の一部「フィルタ化」

  • フィルタとは、入力ストリームをデータとして受け取り、何らかの加工を施し、加工したデータを出力ストリームに送り出すこと
  • つまりソフトウェアは入出力のこと

🌷「ソフトウェア＝目的のサービスを提供するもの」と思っていたけれど入力から出力までの一連の流れと捉える視点したことなかったので面白かった。また、その事を「フィルタ」っていうんだ。

UNIX小さな定理の一部

  • 沈黙は金（極力表示出力を抑えるようにする）
  • ファイルが見つからなかった時..何も表示しない
  • 画面上意味のあるデータだけ表示して無意味な情報が並ばないようにする

🌷最初、黒画面うんともすんともいわず「？！」と思う事多かったけれど、こういう設計思想が元なのかーって納得。

この単語、自分理解してないなーと気づけたこと

  • 非機能要件
    • 「機能にしないことを決める」「機能じゃないけれどサービスとして提供する上で考慮する大事なこと」っていう認識であっているのかな🤔
    • 機能ってどこまでなんだろう🤔（ロジックのことだけ？それともソフトウェアによる？） 　- いざ自分が機能要件と非機能要件を書こうとしたときに区分けできない（わかってない）ことに気づけた。
  • 自己記述型
    • 拡張性で「自己記述型」だと優れているっていう文脈で出てきた🤔
    • 自己記述型？？？🤔（ぐぐっても）
    • 言葉の通り「自分で完結して一個の部品として使いやすい」ってことなのか？
    • プロトコルやファイル形式を設計するときに使うらしい。具体的に想像できなかったので、知識深めていこうと思った。