レビュー」タグアーカイブ

「React開発入門」レビュー

書籍について

タイトル WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用
著者 著: 柴田 文彦
発行日 2016/12/01
ページ数 231ページ
価格 2500円
Amazon https://www.amazon.co.jp/dp/4295000337
読了日 2017/03/15

評価

良い点

  • Reactに関して基本的なことが整理されている
  • コード例の構成が全体的に一貫しており、理解しやすい
  • コード例はWebでダウンロードできるので、コード写経もしやすかった
  • React用Chrome拡張の使い方も掲載されており、これがかなり使いやすい。巻末だったが最初に掲載するべき

悪い点

  • 説明が冗長。一度説明した内容をほぼ同じようにまた説明するということがチラホラ
  • 説明がコードの内容をそのまま和訳したようなモノが多い。コードと実行結果を見れば説明を読む必要がない感じ
  • 応用的な例がほぼ無い。Reactがどんなものかはわかったが、それによってどんな楽が出来るかが伝わらない
  • 元々ページ数が少ない上、説明が冗長的なので事実上のコンテンツ量はかなり少ない
  • それで2500円はちょっと

その他

  • 序盤はJSX不使用だが、中盤以降はJSXが必須
  • JSX自体の説明に結構なページ数を割いている
  • Fluxに関しては巻末で簡単に説明する程度

内容とメモなど

1. Reactとは

Reactに関する概要がズラッと書かれている。Reactにおけるキーワード、専門用語も一通り書かれているので、最初に一読、最後にもう一読すると良さそう

JavaScriptフレームワーク全体でのReactの位置付けについても触れているが、比較対象がAngularしか無いのは少し寂しい

2. Reactのコンポーネント

Reactの基本的な使い方全般。この章ではJSXは使われておらず、純粋なReactの機能だけでReactコンポーネントを構築している。

順を追って読んでいるとなんだか不便だなと感じるが、次章でJSXが登場すると突然便利さを感じることができるので、すぐにJSXに飛びつかずにこの章をしっかりやると良さそう

3. JSXの基本

JSXに関する説明、JSXの利用方法、JSXを用いたReactコードの書き方をそれなりのページ数を割いてまとめている。

基本的には前章で作成したコードをJSXを用いたものに書き換えることで、JSXがどれほど便利なのかを主張している。

個人的に、通読前はJavaScript内にXMLが突然あらわれることに強い抵抗を持っていたが、この章を読んでみるとJSXなしのReactは考えられないなと思った

4. Reactを使いこなす

本章では、フォーム要素を対象に、プロパティやステート、単方向データバインディングなど、Reactの具体的な部分に触れている。

Angularの双方向データバインディングに慣れていた自分にとってはすんなり受け入れられたが、そうでもない人にとってはかなり違和感のある章だと思う

5. Reactの一歩進んだ使い方

本章では、以下のようなReact本体ではない外側の要素について触れている

  • アドオン
  • React DeveloperTools
  • Flux

どれも触り程度で具体的な内容はほぼ書かれていないが、React自体に慣れ、ステップアップを詰むためのヒントとなる内容がかかれている。意欲のある人が本書をきっかけに次のステップに進むための足掛けになるとは思う。

所感

本書でなくReactを使ってみた感想

  • 全体的に「あ、この動き、Angularで見たやつだ」となる部分が多かった
  • その上でもReactはUI操作に特化しているので、Angularだけではできそうにない実装ができそう
  • JavaScript中にXMLを書くのに強い抵抗があったが、やってみると別に気にならなくなった
  • JavaScript中にXMLを書くため、デザイナとの作業の分離が難しくなる気はする
  • システム全体で使うよりも、システム内の、UI色の強い一部機能にのみ採用するという使い方ができそう
  • ReactというよりVirtualDOMの考えがスゴイんだ
  • サードパーティ製のアドオンが豊富なようなので、スタイリッシュなUIなど探せば沢山ありそう
  • ChromeのReact Developer Toolsがスゴイ。これはデバッグも捗るし使ってて楽しい
  • jQueryという闇を払拭できそう

「AngularJS アプリケーションプログラミング」レビュー

書籍について

タイトル AngularJS アプリケーションプログラミング
著者 著: 山田 祥寛
発行日 2015/09/20
ページ数 497ページ
価格 3700円
Amazon https://www.amazon.co.jp/dp/4774175684
読了日 2017/03/08

メモなど

  • 前提として、AngularJS(1.4.1)で小さなアプリを開発しつつ、並行して読み進めたため0からのスタートではない
  • AngularJSの全体像を体系的に整理した本
  • 約500ページのボリュームで、AngularJSでできることを一通り解説している
  • この分厚い本を読まずともAngularJSアプリは開発できるが、その原理やより便利な使い方を知るためには必須
  • AngularJSそのものだけでなく、テストフレームワークやビルドツール、Chromeのデベロッパツールなど、AngularJSアプリ開発の周辺技術についても取り上げている
  • いわゆるハンズオンな内容でもなく、電車内で読み進めるだけで理解を深められた
  • AngularJSに興味がなくとも、JavaScriptMVCについて述べられた第1章だけでも読む価値あり

構成と感想

※ 実際の目次から多少弄ってます

1.JavaScriptの歴史

JavaScript誕生の経緯から始まり、不遇の時代を乗り越えてAjaxの登場によって再ブームを起こし、MVCフレームワークが誕生するまでが述べられている。

AngularJSに関心がなくとも、この章だけでも読み物として面白い。何故MVCフレームワークが必要になったのか?そもそもライブラリとフレームワークの違いは何か?フロントエンジニアなら抑えておいて当たり前の内容を丁寧に説明してる。

2.AngularJSの基本的な使い方とそのしくみ

  • モジュール
  • コントローラ
  • サービス
  • ディレクティブ
  • 双方向データバインディング

といった、AngularJSの構成要素である専門用語について、簡単なサンプルコードを通じて解説している。この章を読むだけで、AngularJSがどんなフレームワークなのかが見えてくる。

ここまで読んで「面白そう」と思ったら続きを読めばいいし、興味が沸かなくてもここまで読めばAngularJSとは何なのかの説明ができる。

3.標準ディレクティブ

ディレクティブとは、

<input type="text" ng-model="name">

のように、HTMLを拡張するためのタグや属性のことである。
ディレクティブは自作することもできるが、AngularJSでは多くの便利なディレクティブが提供されている。それらについて、いくつかピックアップして紹介してる。

4.標準フィルター

ビュー側でデータを出力する際に特定の加工を行ってから出力する「ビュー」について。例えば、以下の場合はobjectをJSON化して出力する。

{{ object | json }}

JSONの他にも、数値を丸めたり、大文字小文字を切り替えたりと言った定番の加工を行うフィルタが標準で数多く存在する。それらについて、いくつかピックアップして紹介してる

5.標準サービス

AngularJSの中でも特にコアな部分であるサービス。サービスとはAngularJSにおける「ロジック」を提供する。
MVCで言うならばModelに該当する。(AngularJSはMVWを主張しているが)

6.スコープオブジェクト

スコープはビューとコントローラを結びつけるオブジェクト。AngularJSにおいて非常に重要な役割を持つスコープだが、その使い方と原理を詳細に解説している。

Angular2ではスコープもコントローラも廃止されているらしいのでちょっと残念。

7.自作フィルタ

フィルタの自作について。といっても、フィルタは受け取った値を何らかの加工をして戻すだけなので非常に簡単。

フィルタは高頻度で呼び出されるため、あまり複雑な加工を行うわけにもいかないし、標準フィルタに強力なモノが多いのであまり自作する機会は無いかなと思った。

8.自作サービス

AngularJSアプリの開発=サービスをどんどん自作していくことかなと思う。特にMVCを正確に分離するのであれば、モデルは全てサービスを自前で実装していく必要がある。

サービスには

  • value
  • constant
  • factory
  • service
  • provider

の5種類があり、どれも微妙に特徴が異なる。それぞれについて説明がされているが、まぁfactoryかserviceを使えば良いかなといった感じ。

9.自作ディレクティブ

小規模なアプリ開発であれば縁が無さそうなディレクティブの自作。これを使いこなせればAngularJSを使いこなせてると言っても過言じゃ無さそう。

ディレクティブは出来ることは非常に広く、その分自作に必要なノウハウも広く深い。その分ページ数もかなり割いているが、やはり「ここまでやる必要あるか」と思ってしまう。

よりAngularJSを使い倒したいと思ったらもう一度読んで見ると良さそう。(おそらくその前にAngular2にうつるが)

10. ユニットテスト

AngularJSアプリのユニットテストの行い方について。もちろんテストの手段は様々あるが、本書ではAngularJSでは定番となっている、Karma + jasmineを採用している。

通常のWebアプリケーションのユニットテストとは異なり、依存モジュールを注入したりするなど、AngularJSらしいテスト手法が書かれている。

11. モック

この場合の「モック」とは、ユニットテストを円滑に行うためのダミーオブジェクトである。例えばテスト対象が何らかの外部サービスに依存する時、テスト用の特定の機能のみを持ったダミーオブジェクトを置き換えることで、外部サービスが稼働していなかったり、未実装だった場合でもユニットテストを行うことができる。

AngularJSでは、この「モック」が数多く標準で提供されている。例えば、HTTPリクエストに対するレスポンスを返却するモックでは、テスト対象のコードを弄らずとも、ダミーのHTTPレスポンスを返却するモックをテストコード中で呼び出すことで、レスポンスが返却されたように振る舞うことができる。

12. E2Eテスト

E2Eテストは、実際のユーザがブラウザを操作したときにアプリケーションが正しい振る舞いを行うことを検査する総合的なテストである。

本書では、Protectorというテストランナーを採用し、AngularJSにおけるE2Eテストについて説明している。個人的にはVisualStudioが必要とか書かれているのを見て意欲を失ってしまった。

AngularJSアプリは、原則としてjQueryによるDOMツリーの操作が行われないので、E2Eテストは書きやすいのかなと思った。

13. 関連ライブラリ

AngularJSはそれだけで非常に強力なフルスタックフレームワークだが、局所的な実装を全てサポートしているわけではない。そこで、実装内容に応じて、各種AngularJSライブラリを利用することで、さらにAngularJSアプリの実装の幅を広げることができる。(jQueryにおけるjQueryライブラリのようなもの)

AngularJSでは、フィルタ/ディレクティブ/サービスを自作することができるので、それらを含んだライブラリが(公式/非公式問わず)数多く存在する。本書では以下の一部のみを紹介しているが、他の膨大なライブラリの調べ方なども書いてある。

  • UI Bootstrap
    — Bootstrapをディレクティブで利用できるようにする
  • UI Event
    — 標準以外のイベント処理をできるようにする
  • UI Validate
    — 標準以外の、自作の検証機能を実装できる
  • UI Router
    — 高度なルーティング処理を実装できる。SPAには必須
  • UI Grid
    — グリッド表を生成する
  • angular-translate
    — 国際化対応ページを実装する
  • Angular Google Maps
    — GoogleMapをAngularJSで利用する
  • angular google chart
    — GoogleChartをAngularJSで利用する

14. 関連ツール

AngularJSとは直接関係ないが、AngularJSアプリを開発する上で役立つ以下の関連ツールについて紹介している。もちろんツールの紹介だけでなく、AngularJSで活用するための利用方法についても説明している。

  • Yeoman
    — 様々なフレームワークに対応したアプリの雛形を生成するアプリ。つまりAngularJSアプリの雛形を生成してくれる
  • Grunt
    — タスクランナーツール。TypeScriptのコンパイル、テストの実行、ソースコードのミニファイなどを逐次自動で行ってくれる
  • Bower
    — クライアントサイドのJavaScriptパッケージ管理ツール。ちなみにサーバサイドはnpmが主流

なお、本書ではタスクランナーツールとしてGruntを採用していたが、私はGurpを採用しているのでほぼ飛ばした。

所感

AngularJSは本当に面白い。あと3年ぐらい早く出会っていればこれまでフロントエンドの実装にあんなに苦しまなかった気がする。

しかし、互換性の一切ない、というかアーキテクチャが一新されたAngular2の登場によって少しずつAngularJSが不要になっていくのがとても悲しい。

AngularJSのノウハウがそのままAngular2で生きてくれれば嬉しいが、それはAngular2をやってみないとわからない。

「Webを支える技術」レビュー

書籍について

タイトル Webを支える技術
より良いコードを書くためのシンプルで実践的なテクニック
著者 著: 山本 陽平
発行日 2010/05/01
ページ数 376ページ
価格 2570円
Amazon https://www.amazon.co.jp/dp/4774142042
読了日 2017/02/24

メモ

  • Webの根底となる技術(HTTP/URI/HTMLなど)を、歴史を辿りながら整理した本
  • あくまで「Webを支える技術」なので、具体的なWeb開発の技術を取り扱っているわけではない
  • 言ってしまえば、この根底技術を知らなくてもウェブアプリケーションフレームワーク(WAF)などを活用すればWebシステムは作れてしまう
  • しかし、WAFが裏側でやってくれるHTTPの動きやURIの理屈を知ることは開発する上でも重要だと思う
  • REST及びRestFullという言葉を曖昧に使っていたが、改めて理解を深めることができた
  • なかなかの分厚さがあるが、やや冗長に書かれている部分も多いので、自分の興味にあわせて読み進めると良い
  • microformat/atomの項は個人的にあまり興味がなかったので流し読みしてしまった
  • というかmicroformat/atomは本筋から逸れた無いような気がする

関連用語

以下の用語をきちんと説明できないなら読んでみると良さそう

  • REST/RestFull
  • SOAP
  • URI/URL/URN
  • ステートレス/ステートフル
  • HTTPメソッド
    — GET
    — POST
    — HEAD
    — PUT
    — DELETE
    — OPTIONS
  • 主要なステータスコード
    — 200 OK
    — 201 Created
    — 301 Moved Permanently
    — 303 See Other
    — 400 Bad request
    — 401 Unauthorized
    — 403 Not Found
    — 500 Internal Server Error
    — 503 Service Unavailable
  • 主要なHTTPヘッダ
    — Date
    — Server
    — Set-Cookie
    — Cookie
    — Referer
    — User-Argent
    — Content-Length
    — Content-Language
    — Content-Type
    — Last-Modified
    — Accept
  • 条件付きリクエスト
  • 部分的リクエスト
  • セマンティックWeb
  • RSS
  • microformats
  • Atom
  • リソース指向アーキテクチャ

「リーダブルコード」レビュー

書籍について

タイトル リーダブルコード
より良いコードを書くためのシンプルで実践的なテクニック
著者 著: Dustin Boswell/Trevor Foucher
訳: 角 征典
発行日 2012/06/22
ページ数 232ページ
価格 2400円
Amazon https://www.amazon.co.jp/dp/4873115655
読了日 2017/02/20

メモ

  • コード品質を高めるためのコーディングテクニックの決定版。プログラマ全員の必読書
  • 比較的難読書の多いオライリーにしては読みやすく、そして薄い
  • およそ200ページちょっとの中に大量のテクニックが含まれており、読んだだけで意識が高まった
  • 久しぶりに国外の本を読んだが、翻訳者さんの軽快でキャラの濃い翻訳のおかげで非常に読みやすい
  • コード例は、C++/Java/JavaScript/Ruby/Perl/Pythonと様々だが、言語に依存した内容は殆ど無いので、1言語以上知っていれば問題ない
  • 随所に挟まれる、アンチパターンを皮肉った風刺画のような挿絵がステキ。でもアメリカンジョークを理解できない故に挿絵の意味がわからないことも少なからずあった
  • コメントに関する考え方は個人的に合わないものが多かった。おそらく、英語を母国語とする人(及び得意な日本人)と、英語が苦手な日本人にとってはコードとコメントの関係性に対する考えが異なるんだと思う
  • 巻末の日本人による本書の解説も良かった。やはり日本人には日本人の解説が一番しっくり来る

要約とか

以降では、主に個人的に良いなと思ったものを列挙する。ただしコレだけ見ても説明が足りていないモノがほとんどなので、その場合は必要に応じて本を開くと良い

命名

  • 識別子はプログラムの最大の説明書。最適な名前をつけよう
  • 汎用的な名前(get/setなど)は避けるか使う状況を選ぶべき
  • サフィックスやプレフィックをつけて名前に付加情報を与える
  • 名前のフォーマットで情報を伝える
  • スコープが広い変数ほど、名前を長く正確につける

美しさ

  • 同じような処理は同じようなフォーマットで記述する
  • スペースを合わせたりする作業を躊躇わない。読む時間のほうが長いのだから
  • 同じようなコードは同じような順番で記述する
  • 空行による段落分けを行う

コメントすべきでないこと

  • コードからすぐに分かることをコメントにしない
  • コメントするためにコメントをしない(手段と目的の逆転)
  • コメントは識別子を補助するものではない。補助するぐらいなら識別子を変える

コメントするべきであること

  • プログラマのそのコードに対する考え
  • コードが特殊な意図で実装されていることについて
  • コードの問題点や注意すべきこと
  • 入出力のユースケース

制御フローを読みやすく

  • 比較式は、左側が変化するモノ、右側が変化しないモノ
  • ifの条件式はなるたけ肯定形を使う。if(!hoge)などは避けたい
  • 関数から早め早めにreturnする
  • ネストを浅くするように心がける

巨大な式を分割

  • 複数回登場する巨大な式は、変数で簡素な別名を付けておく

変数と読みやすさ

  • 変数のスコープは狭ければ狭いほど良い
  • 可能な限り、一つの変数には1回しか代入しない
  • 再代入するということの多くは、値の意味が変わるということ。それなら名前も変わってしかるべき

「コーディングを支える技術」レビュー

書籍について

タイトル コーディングを支える技術
成り立ちから学ぶプログラミング作法
著者 西尾 泰和
発行日 2013/05/25
ページ数 247ページ
価格 2470円
Amazon https://www.amazon.co.jp/dp/477415654X/
読了日 2017/02/14

メモ

  • プログラミング言語の構成要素(演算子、条件分岐、関数など)について、「何故生まれたのか」「それは何を目的としているのか」「どんな種類があるか」を体系的にまとめた書籍
  • プログラミング言語の誕生から現在までの歴史に関する読み物としても面白い
  • コード例はC++/Java/Ruby/Perl/Python/JavaScriptに加え、それらの先祖である言語まで多岐にわたる
  • と言っても、それぞれの言語を知らずとも雰囲気で理解できる上、コードに関する説明も十分されているので問題ない
  • 読み物として面白いと思ったが、これを読むことで一気にコーディングの技量を高められるというわけではない
  • 言語の構成要素の目的を知ることで、常に適した手段で実装できるようになるためのキッカケ程度にはなるかも
  • 個人的にはプログラマの必読本とまでは思わない。言語に興味関心があれば読んでみようといった感じ

要約とか感想とか

演算子

プログラミングにおける文法とは一体何か。以下の演算子に関する文法を例に、プログラミング言語の歴史について触れる。
– 中置記法(1 + 2)
– 後置記法(1 2 +)
– 前置記法(+ 1 2)

条件分岐

アセンブリ時代の条件分岐方法を元に、何故if文のような分岐命令が必要になったのか、C言語のif分はどのようにアセンブリに変換されるのかについて考える

繰り返し

アセンブリには繰り返しに関する命令はなく、C言語で言うgoto文と条件分岐を組みわせて繰り返しを実現している。それの問題点と、そこからwhileやfor文がどのように生まれたのかについて

関数

ひとまとまりの、再利用性のある処理をどのように記述するのか、関数を呼び出した後、どのように呼び出し元に戻ってくるのか

例外処理

例外処理の歴史、何故必要になるのか、言語ごとの例外処理に対する考え、実装及びそれぞれの問題点

識別子

データに対する名前付けはどのように行われているのか、何故名前付けが必要になったのか

スコープ

名前の影響範囲について。名前が常にグローバルな世界、動的スコープと静的スコープの違いなど

数値

コンピュータでは数値をどのように扱っているのか。固定小数点数と浮動小数点数など

データは全て0と1で構成されるが、同じバイト列でも型によってそれがどのようなデータなのかが異なる。型とは何か、データと合わせてどのように型を管理しているのか

配列/リスト

ひとまとまりのデータはどのように表現されているのか。配列とリストの違い及びそれぞれに対するデータの削除、追加時の計算量など

文字

文字コードの世界について。文字コードとは何なのか、何故文字コードは複数存在するのか。ビット列から文字への変換方法など

文字列

言語による文字列の表現方法の違い

並行処理

一つのCPUで複数の処理を同時に行う原理。リソースの競合に対する対策など

オブジェクト指向

そもそも「オブジェクト指向」とはなんなのか、オブジェクト指向の先祖であるSimuraから影響を受けたC++とSmallTalkでは、オブジェクト指向の定義がまったく違う。

継承

継承に関する言語ごとの様々な考え方。多重継承を許すのか、インタフェースやMIX-INによる擬似的な多重継承など

「プリンシプル オブ プログラミング」 レビュー

書籍について

タイトル プリンシプル オブ プログラミング
3年目までにみにつけたい一生役立つ101の原則原理
著者 上田 勲
発行日 2016/03/29
ページ数 303ページ
価格 2200円
Amazon https://www.amazon.co.jp/dp/4798046140/
読了日 2017/02/14

感想とかメモ

  • プリンシプル = 原則/原理
  • 良いコード(特に保守性、拡張性の優れた)コードを書くための原則、原理を集約した一冊
  • サブタイトルに「3年目まで」と書かれていたり、帯に「めざせ、脱・初心者」とアオリ文が書いてあったり、一件初心者向けの本にも見られるが、全体的に内容は難しめ
  • まるで洋書を訳したかのような言葉の選び方や言い回しが多く、それに加えて内容も難しいため、気軽に読むのが難しい項目も少なからずあった
  • 「3年目」とか関係なく、全てのプログラマが持つべき考え方が詰まっている
  • 逆に「3年目」程度では理解できない内容も多いため、経験を重ねる度に読み返すことで自分の立ち位置が把握できそう
  • 具体的なコードは一切掲載されていない。著者曰く「具体的な場面でしか使えないものと誤解されないように」とのことだが、具体的なコードが無いとそれはそれでイメージができない項目も多かった(コードは自分で書いてみようということか)
  • 当然特定の言語、環境に依存した内容ではない
  • 全体的にテストが整備されてる前提だと感じた。テストが整備されていない時点でキレイなコードを書くのは不可能なのか

要約とか備忘録

本項では、本書に記された101の原則・原理のうち、個人的に気に入ったものについて要約及び個人的な考えなどを整理する。基本的に最小限しか書いていないが、ページ数も併記しているので、気になった所だけでも読んでみよう。

1.2 コードは設計書である(P23)

  • 製造業に置ける「製造」は、システム開発におけるコーディングであるという考えは間違え
  • システムはソースコードという「設計図」に基づいて、コンパイラやビルドツールが「製造」する
  • 故にプログラミングは仕様を符号化する作業ではなく、設計という創造的行為である

1.3 コードは必ず変更される(P26)

  • 一度書いて終わるコードなどまず無い
  • コードが変更されるという事実を、コーディングする上での最重要事項として認識する必要がある。
  • 変更されることを意識すれば変更に強いコードが書ける
  • 変更に強いということは変更しやすいということであり、それは「読みやすいコード」であることだ。

2.4 PIE(意図を表現してプログラミングせよ)(P43)

  • 前提として、ソースコードはコンピュータが読むものではなく人間が読むものである
  • ソースコードは書く時間よりも読む時間のほうが圧倒的に長い
  • 一人でコードを書いたとしても、書いた直後時自ら読むことは避けられない。そしてそれは最早他人である。
  • ソースコードは、What/Howは記述されているが、Whyは記述されていない
  • つまりコメントに必要なのはWhatでもHowでも無く、Whyなのだ
  • WhatやHowをコメントで記述しなければ理解できないソースコードは設計、実装に誤りがある

2.7 名前重要(P57)

  • プログラミングにおいて、「命名」は最重要課題の一つである。
  • 名前はコードを読む人にとってのUIである
  • 名前が適切であれば、コードを読む人は名前から内容を推測することで、内容を読まずともコードリーディングを進めることができる。
  • 逆に名前が曖昧であったり、意味を成していない場合、内容まで追わなければコード全体を把握することができない。
  • 適切な名前がすぐに思いつかないのであれば、それは設計、実装に誤りがある

3.6 繰り返しの最小化(P73)

  • コード中に同じコードが繰り返し登場してはならない
  • 繰り返しのコードは、修正範囲を誇大化させる
  • さらに、繰り返し存在するコードそれぞれに同じ修正を適用して問題ないかの判断も必要になる
  • 繰り返しを排除するためには、コードを小さい部分に分割することを意識付ける。大きなコードは繰り返しが発生しても気づきにくくなるからだ

単一責任の原則(P79)

  • モジュールを変更する理由は2つ以上あってはならない
  • 理由が複数あるということは、そのモジュールが複数の責任(役割)を持っているからだ
  • モジュールは1つの1つのみの責任を持たせなければならない
  • 何故なら、2つの責任がある場合、片方の修正のためにもう片方が影響を受ける可能性があるからだ

3.18 ポリシーと実装の分離(P93)

  • ポリシー = ソフトウェアの前提に依存するビジネスロジックなど
  • 実装(メカニズム) = ソフトウェアに依存しない、再利用が可能なロジック
  • モジュール内でポリシーと実装が混在していると、ポリシーの変更に実装が影響を受けてしまうため
  • ポリシーが独立したモジュールである場合、それは再利用可能であり、単体テストも行いやすい良いモジュールである

3.20 参照の一点性(P97)

  • 定義は極力一度きりにする(再代入しない)
  • ロジックの流れを追うごとに、変数の中身が変わることは、コードを読む上での脳への負荷となりやすい
  • 単一代入を強制する言語、アーキテクチャも多く存在する

3.39 明確性の原則(P132)

  • コードの解読を3回以上繰り返してはいけない
  • 1回目は仕方ない
  • 2回目解読する機会が来たら、その場で改善しなければならない
  • 3回目を迎えることのないように改善する

3.44 透明性の原則(P132)

  • 随所にデバッグを簡単に行うための仕組みを入れておく
  • プログラマがその気になれば、どんなデバッグ情報もすぐに出せるようにする
  • 本番コードにデバッグ機能を搭載することを躊躇しない(もちろんON/OFFは切替可能に)

3.52 最適化の原則(P154)

  • 「速いコード」より「正しいコード」
  • 早い段階で「速いコード」を書こうとすると破綻する
  • まずは正しく読みやすいコード、テストを書き、ボトルネックと認められた場合に手を加える

3.58 即行プロトタイプ(P164)

  • できるだけ早くプロトタイプの開発に着手する
  • どんなに仕様を詰めても、ドキュメントを整備しても、動くものを見たら全てが変わる

3.62 シェルスクリプト活用(P173)

  • 繰り返し行なっている操作は可能な限り自動化する
  • シェルスクリプトは移植性が高い
  • シェルスクリプトはプラットフォームに依存しにくい
  • シェルスクリプトは他のソフトウェアと結合しやすい

4.5 コードの臭い(P205)

  • コードの臭い = コードから見られる理解しにくさ、修正しにくさ、拡張子に草
  • プログラマはコードの臭いに敏感である必要がある
  • いくら良いコードが書けるようになっても、悪いコードを見つける力が無ければリファクタリングはできない

5.1 プログラマの3代美徳(P214)

  • 怠慢
  • 短気
  • 傲慢

5.2 ボーイスカウトの規則(P218)

  • ボーイスカウトの規則 = ボーイスカウトは、自分のいた場所を自分が来る前よりも綺麗にして帰らなければならない
  • プログラマがソースコードを修正する時、その周辺のコードも綺麗にする必要がある

5.4 エゴレスプログラミング(P226)

  • 能力、年齢、立場に関係なく、皆でより良い物を作ることに価値を置く
  • コードを私物化せず、定期的に同僚にコードを見せたり、同僚のコードを見たりする

6.5 ラバーダッキング(P253)

  • 自分のコードについて声に出して説明すること
  • 説明相手は最悪無機物(ラバーダッキング=ゴムのアヒル)でも良い
  • 声に出して説明することで、自分が自分のコードをどれだけ理解できるかを図ることができる