「リーダブルコード」の読書メモ２（第二部：ループとロジックの単純化、第三部：コードの再構成）

【結論】

・条件やループなどの制御フローは出来るだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く

・巨大な式を分割する為に「説明変数」を利用する

・標準ライブラリの関数などを定期的に読んで、ライブラリで可能な事を理解しておく

【目次】

【本題】

第７章：制御フローを読みやすくする

条件式の引数の並び順

・左側に調査対象（変化する）の式、右側に比較対象（変化しない）の式を配置する

#悪い例
if length == 10

#良い例
if 10 == length

if/elseブロックの並び順

・条件は否定形より肯定形を使う

・単純な条件や、関心を引く条件（目立つ条件）を先に書く

三項演算子は二者択一の条件でのみ用いる

ガード節を使って関数から早く返す

処理の対象外とする条件を、関数やループの先頭に集めて return や continue/break で抜ける方法。 ネストを減らし正常系の処理がわかりやすくなるメリットがある

ネストを浅くする

ネストが深くなると、読み手は条件を覚えておく必要があるので、負担が増える コードを変更する時にはコードを新鮮な目で見る。一歩下がって全体を見る。

第８章：巨大な式を分割する

式を表す変数「説明変数」を導入する事で、コードを文書化することが可能。コードの主要な概念も読み手が認識しやすくなる

第９章：変数の読みやすさ

役に立たない一時変数や中間結果は削除する

変数のスコープを縮める（グローバル変数は多用しない）

定数を使う（変数の変更箇所を出来るだけ少なくする）

第１０章：無関係の下位問題を抽出する

・プロジェクト固有のコードから汎用コードをを分離する

エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。

関数やコードブロックをみて「このコードの高レベルの目標は何か？」と自問する

コード各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」自問する

無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関するにする

第１１章：一度に１つのことを

コードは１つずづタスクを行うようにしなければいけない

読みにくいコードがあれば、タスクを全て列挙して、分割できるものがないか探る。

第１２章：コードに思いを込める

コードの動作を簡単な言葉で同僚にも分かるように説明する

その説明の中で使っているキーワードやフレーズに注目する

その説明に合わせてコードを書く

第１３章：短いコードを書く

・不要/過剰な機能はプロダクトから削除する

・最も簡単に問題を解決できるような方法を考える

・標準ライブラリの関数などを定期的に読んで、ライブラリで可能な事を理解しておく

但しやり過ぎると、逆に可読性が悪くなる原因になり得るので注意が必要。

参考情報

書籍「リーダブルコード: より良いコードを書くためのシンプルで実践的なテクニック」

《今日の学習進捗（3年以内に10000時間に向けて）》

現在開発中にサービスで、フォームや表示名など、かなりの箇所がユーザー側で任意に設定可能になった事で、拡張性に問題が出始めているように感じる。

原因としては、影響範囲が広範囲の為、個人の注意力だけ適用箇所を網羅するのが困難になっていると考えている。

情報漏洩やサービスが停止してしまうといったクリティカルなバグに繋がりにくいそうだが、サービスの信頼性を損なう結果に繋がりかねない為、軽視せずに対策を講じていきたい。

対策は、影響範囲を絞るような設計手法を取り入れる（全く検討付かないが・・・）か、チェックの観点をリストアップして、それに沿ってコードレビューを行うといった運用面でカバーする方法になると考えている。私自身、注意力散漫な方なので、出来るだけ設計の工夫で解決を図っていきたい。

なお、自社のサービスより圧倒的に規模が大きい有名なC向けのサービスなどで、こういった問題が頻発していないところを見ると、もっと良い対策があるかもしれない。どういった手法でこれらの問題に対処しているのか調べてみたい。

学習開始からの期間 ：194日
今日までの合計時間：1889h
一日あたりの平均学習時間：9.8h
今日までに到達すべき目標時間：1772h
目標との解離：117h
「10,000時間」まで、

残り・・・「8111時間！」