My kindle library and highlights

Follow @umihico Star Issue

cover_img

Author:上田勲

Title:プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

Date:金曜日 1月 4, 2019, 19 highlights

@520
コードには、「How」や「What」はよく表現されていますが、「Why」、つまり設計理由がありません。この設計理由をドキュメントに記述しておくと、保守担当者の修正の判断材料として、多くの機会で役に立ちます。
—-

@658
「定数リテラル」を直接コードに埋め込んであることも、コードの重複にあたります。同じ意味の定数が複数箇所で使われる場合、定数の指し示す情報が、重複して存在することになるからです。
—-

@765
まずテストを作成しましょう。エレガントでなくて構いません。どんな方法を使ってでも、まずテストを用意してから、修正を行います。
—-

@811
Do The Simplest Thing That Could Possibly Work」
—-

@832
コードの意図を伝える
—-

@881
コードはどこまで行っても「What」と「How」、つまり「何をしているか」「どのようにやっているか」までしか表現できません。「Why」、つまり「なぜそれをしているか」を表現するには、コメントを使用する必要があります。
—-

@967
各関数は、自身より1段低いレベルの関数を呼び出す処理が中心となります。
—-

@1052
モジュールの使用者「クライアント」が、モジュールの提供者「サーバー」を直接呼び出すと、「硬い」設計になります。別のサーバーを使用したい場合、クライアントを変更しなければならないからです。 そこで、クライアントとサーバーの間に、モジュール使用者のための「クライアントインタフェース」を設けます。サーバーは、クライアントインタフェースを実装することになります。
—-

@1085
不安定箇所の、不安定がゆえに多発する変更による影響を、インタフェースという防護壁を立てて守る戦略
—-

@1177
命名について、「名前可逆性」という考え方があります。これは、「名前は、その元となった内容の説明文を復元できなければならない」という命名指針のことです。
—-

@1417
データと操作は修正タイミングが同じ コードを修正する場合、ロジックとそのロジックが操作するデータは、たいてい同じタイミングで変更します。
—-

@1450
コードを書く時、同じ種類のことは、同じように表現しましょう。 例えば、以下のようにします。 ・「追加」メソッドがあれば、対になる「削除」メソッドを作成します。 ・あるグループにある関数は、同じ引数を取るようにします。 ・あるモジュール内のデータは、すべて生存期間が同じであるようにします。 ・ある関数内で、呼び出す関数の抽象度は同じレベルとします。
—-

@1492
変更理由を複数持っているコードは、脆いコードです。モジュールの中に、今回の変更に関係ある部分とない部分が混在し、関係がない部分まで、影響を受けてしまうからです。変更理由が多いので、変更機会もそれだけ多くなります。持っている役割も大きいので、コードも大きくなります。変更でさらに大きくなるので、砂上の楼閣のように壊れやすく、危ういコードになります。 逆に、変更理由が1つであるということは、関連性の高いコードが集合していることになります。これは、高い凝集性を満たしている、堅牢なコードです。変更対象範囲が狭く、影響範囲も狭くなるので、修正しやすいコードと言えます。
—-

@1513
「単一責任の原則(SRP: the Single Responsibility Principle)」とは、モジュールを変更する理由は、1つより多く存在してはならないという原則です。
—-

@1656
・モジュールの利用者には、そのモジュールを利用するために必要なすべての情報を与え、それ以外の情報はいっさい見せないこと。 ・モジュールの作成者には、そのモジュールを実装するために必要なすべての情報を与え、それ以外の情報はいっさい見せないこと。 モジュール同士は、最小かつ明快なつながりで結ばれていることが望ましいとされています。
—-

@1832
「単一代入」とは、変数に対して、値の再代入を行わないことです。副作用を「避けるべきもの」と考え、変数を「変わらないもの」と捉え、最初に一度代入した値は、後から変更しないようにします。
—-

@1840
障害が発生しやすいのは、必然性のない「可変(ミュータブル)な変数」の部分です。不要な可変性を排除して、「不変(イミュータブル)な変数」を増やすようにすると、品質が向上します。
—-

@1842
残った(必要な)可変な変数については、そこへアクセスするロジックやスコープを極力減らします。
—-

@2642
デバッグのための機能を、設計の最初の段階から組み込みましょう。 例えば、モジュール内変数の内容を書式文字列化するメソッドを組み込んだり、ログをふんだんに盛り込むなどです。 このような「動作の見える化」機能を、通常の機能のプログラミングと同時に、コードに組み込んでおきます。
—-