「プログラマが知るべき 97 のこと」を読了しました．
まとめと感想について書いていきます．
感想
- 個人的に印象に残ったのは，以下のことです．
- 関数型プログラミング
- 自動化
- テスト
- 学習方法
- DRY 原則
- 働く姿勢
- デザインパターン
- 読みやすいコード
- フロー状態
- これらは繰り返し記述されていて，本に掲載されるようなプログラマはその発想に至るまでの経緯は違えど共通認識を持っていると思いました．
「達人プログラマー」という書籍を薦めている人物が複数いたので，今度読みたいと思います．
今後も覚えておきたいことをまとめに記述していきたいと思います．
まとめ
関数型プログラミング
- 参照透過性の向上が大事
- クラスを用いることはミュータブルな変数が増加することに繋がる
- 関数型プログラミングのパラダイムを学ぶことで他の状況でも役にたつ
ボーイスカウトルール
- 「自分が最初に見た時よりも，世界を良い場所にすべく努力しよう」(ベーデン=パウエル）
- 「モジュールをチェックインする際には，必ずチェックアウト時よりも美しくする」
コードレイアウトの重要性
- 目立たない部分を作る．人間は他と異なっている箇所を一瞬で見つけられる．
- レイアウトに語らせる．自動フォーマッタを使う．
- コンパクトにまとめる
コメントのコメント
- コードは，次に見る人がすぐに理解できるように書く．
- 読むのに苦労するコードは，コメントも書かずに放置すれば，顧客にも，会社の同僚にも，自分にも害を及ぼす．
学び続ける姿勢
- 書籍や雑誌，ブログなどを読む
- 本当に身に付けたい技術は，コードを自ら書き，手を動かして学ぶ
- 常に自分よりレベルの高い人と仕事をするようにする．
- 自分の「良き師」になり得る人をネット上で探す．
- 自分の利用しているフレームワークやライブラリに対する知識を深める．オープンソースならデバッガを使って逐一確認し，中でどういうことが行われているのか確認する．
- ミス，バグ，問題について，解決するだけでなく，深く理解する．
- 自分が学びたいことを人に教えたり，話したりする．
- 自分が興味をもっている言語，技術，分野に関連する勉強会に参加したり，立ち上げたりする．
- カンファレンスに積極的に参加する．オンラインなら無料提供されていることがある
- 自分のコードスペースに対して，静的分析ツールを実行する．警告がだされる場合に理由を深く追求する．
- 「達人プログラマー」を読み，学んだことを実践する．本の教えに従い，毎年一つ新しい言語を学ぶ．
- 新しく学ぶのは，必ずしもコンピュータ関連でなくてもよい．システムが応用されるドメインについて学ぶと良い．「生産性を高める」ものについても学ぶと良い．
- 学校に通う
言語だけでなく文化も学ぶ
- 「言語を学ぶということは，ただ文法，構文を学ぶことではなく，その背景にある文化も学ぶこと」
- 新しい言語を学び，勘所をつかんだら，前から知っていた言語の使い方がそれまでと変わることがある．
- 新しい言語から新たな発送をえて，同じ問題に対して違った解決策を見つけられるようになることが大事
DRY 原則
- 重複は無駄である：コードベースが大きくなることを防ぐ
- 作業の重複は自動化で防ぐ：テストの自動化
- ロジックの重複は抽象化で防ぐ：デザインパターンを利用する．
- 関連する原則：OAOO(Once and Only Once：一度，ただ一度）
オープンソースプロジェクトで夢を実現する．
- 本当に自分の希望通りのソフトウェアを作っている人は少ない
- 「オープンソースプロジェクト」への参加は希望に近く方法．
- オープンソースプロジェクトに参加することによるチャンス
- 多くの人の仕事ぶりを目の当たりにできる
- 同じ問題を解決するにしてもいろいろな方法があり得ることをしる
- 他人の書いたコードから多くを学ぶことができる
- プロジェクトに自分のコードやアイデアを提供できること
- プロジェクトに大きく貢献できれば「実務経験」になる
- 他人の作ったソフトウェアについて学ぶのに，テストコードを書くほど効果的な方法はない．
ハードワークは報われない
- ソフトウェア開発プロジェクトは通常，オリエンテーリングをしながらマラソンをするもの．
- プロには，備えるための時間，知識と技術を高める時間が必要 ．
- 仕事には長い時間をかけず，集中して短い時間で終わらせるように心がける．
プログラミング言語は複数取得すべき
- パラダイムは大きく，手続き型，オブジェクト指向型，関数型，論理型，データフロー型などに分類できる，
- 違うパラダイムの言語を学ぶことによって，同様のアルゴリズムを実装するにしても，色々なやり方があることに気づく．この体験がプログラマの技術を大きく向上させる．
- また，一つのパラダイムしか知らなければ思いつかないような表現を使用することができる．
- 最低でも二つのパラダイムの言語を使いこなせるようになるべき．五つのパラダイムの言語を使いこなせるのが理想．
いろいろな言葉を学ぶ
- 一人でこつこつプログラムを書く「職人仕事」の部分はとても小さい．
- 他人と話し合いながら進めるチームワークの部分が大きい．
- 話す際に自分の思考を抽象化する力はかかせない．
- 抽象化こそがプログラミングの核心．
ポリモーフィズムの利用機会を見逃さない
- 「ポリモーフィズム」は，オブジェクト指向の基礎を成す重要な概念．
- 元々はギリシャ語で「多数」を意味する"poly"と「形」を意味する"morph"に由来する．
- ポリモーフィズムをうまく使えば，オブジェクトやメソッドの特製，動きを，コンテキストに応じて細かく変えることができる．
- if-then-else を使うよりもポリモーフィズムを使うことで，コードを読みやすく，またバグ少なくなる可能性が高い．
真実を語るのはコードのみ
- 「プログラムの動作を完全に性格に知るには，結局ソースコードを見るしかない」
- 「では自分の書いているソースコードは果てしてどうだろうか」と自問する
- 「このコードはコメントがなければわかりにくい」と感じたらのなら，コメントを書くよりも，リファクタリングを検討した方がいい．
- 以下の点でわかりやすくする
- 見てすぐに機能がわかるような名前をつける
- 部分同士ができるだけ依存関係を持たないようにすること
- 自動テストを書いてインタフェースのチェックをする
- シンプルにする方法がわかった時，現状より少しでも良いソリューションが見つかった時には，即座にリファクタリングする
プロのプログラマとは
- プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度，責任感
- キャリアに責任を責任を持つというのは，自分の力で自分の価値を高め，成長していくこと
- プロのプログラマは自分の書いたコードに責任を持つ
- プロのプログラマはチームプレイヤー．一人一人が自分の仕事だけでなく，チーム全体のアウトプットに責任を持つ
- プロのプログラマは，バグリストが一定以上の規模にならないよう，常に注意を怠らない
- プロのプログラマは，絶対に，間に合わせのいい加減な仕事をしない．
コードを読む
- プログラミングの技術を本気で磨きたいと思っているのなら，本を読むのもいいが，一番いいのは，他人が書いたものでも自分の書いたものでも，とにかくコードを読むこと
シンプルさは捨てることによって得られる
- コードはシンプルなものであるべき．
- 変数や関数，宣言といった構成要素はできる限り減らすべき．
- 良い部分だけを残して悪い部分は消す，ということも困難なくらいひどいコードであれば，全部消して，はじめから書き直す方がいい．
- せっかく書いたものを結局全部消したという記憶が頭のどこかにあれば，次からは無駄なコードは書かないでおこうと無意識に気をつけるようになる．
「イエス」から始める
- 「ノー」ではなく「イエス」という返答から始めるようにすれば，それだけ物の見方は大きく変わり，仕事の進め方も変わる．「イエス」から始めることは，テクニカルリーダーに不可欠な態度だと考える．
- 「イエス」という返事の仕方には多くの種類がある．
- 要望が出されたコンテキストがわかれば，新しい可能性が広がることが多い．実は既存の製品にはまったく手を加えなくても，方法によっては要望に応えられる場合も珍しくない．最終的には要望に応えないとしても，なぜその要望が製品に合致しないのか，きちんとした説明をすれば，実りのある会話ができる．
- 「イエス」から始めれば，人との対立は生まれず，協力関係が生まれる
面倒でも自動化できることは自動化する
- 自動化はテストだけのものではなく，バージョン管理，コンパイル，JAR ファイルのビルド，ドキュメント生成，デプロイ，レポート生成などがある．
- IDE を使っていれば自動化の必要がなくなるわけではない．個人の IDE の環境を統合することは不可能．
- 自動化のために特殊なツールを学ぶ必要はない．よく知られたシェル言語(bash や PowerShell など)さえ使えれば自動化システムの作成は十分にできる．
- 扱うファイルの形式によっては自動化ができないこともある，ことはない．形式によっては，自動化は難しいがプレーンな形式にすることで自動化しやすくなる
- 自動化を進めながら勉強をするということでかまわない．自動化できる，自動化すべし，と思う作業が見つかる旅に，その自動化に十分なだけの知識を身につければ良い．
テストのないソフトウェア開発はあり得ない
- 説明するときの比喩として”土木作業”を用いることがあるが，根本を突き詰めると破綻する．
- "ソフトウェア開発"の世界では"土木作業”でいう「橋を作ってから重い物を上にのせてみて，耐えられるかどうかを見る」ようなことをする（土木作業ではしない）
- テストが，品質保証のための第一の手段．
- テストは，ソフトウェアの品質，再現性を保証するためにどうしても必要．
WET なシステムはボトルネックが見つかりにくい
- DRY 原則(Don't Repeat Yourself：同じことを繰り返すな）
- WET(Write Every Time：必要なものをその都度書く）
- DRY 原則を守ことで，パフォーマンスのボトルネックの発見と解消が，WET なコードの場合より容易になる
コードを見る人のためのテストを書く
- 「自分は誰のためにテストを書いているのか」を考えたとき，「自分のため，バグ修正の労力を少しでも減らすため」あるいは「コンパイラのため．コンパイル作業を円滑に進める」だったとしたら，良いテストが書けている可能性は低い．
- 「コードを見る人のため」に書く
良いプログラマになるには
- どんな場合でも，「とりあえず動きそう」というだけのコードは決して書かない．だれが見ても間違いなく正しいとわかる，美しいコードを書く
- わかりやすいコード，保守しやすいコード，正しいコードを書く
- 他のプログラマと協調する．
- 自分が扱ったコードは，必ず，自分が最初に見た時よりも少しでも良いコードにする
- 絶えず積極的に新しい言語，イディオム，テクニックを学ぶ．ただし，学んだことをむやみには使わない．適切と判断した場合にのみ使う．
ペアプログラミングと「フロー」
- フロー状態の維持には「ペアプログラミング」が非常に役立つ．
- フロー状態の維持に役立つ理由は以下
- 不慮の事態の影響を最小限に抑えることができる
- 問題解決が容易
- 統合がスムーズ
- 割り込みの影響を緩和できる
- 新人が早くプロジェクトに馴染む
ステートに注目する
- ステートは非常に重要．何か操作をしようとすれば，まず現在どのステートにいるかを確認する必要がある．
- 「ステートマシン」という考え方を理解する．
- コードを書くときには，テスト駆動開発で個々の操作に適合するステート，適合しないステート，ステート間の適切さを確かめながら開発し，実行時に常にステートが正しく保たれるようにする．
- ステートが不適切になる時があるならそれはバグ．
ルーチンワークをフローのきっかけ
- 「フロー状態」の助走となるルーチンワークを少しだけ用意する．
プログラマが持つべき 3 つのスキル
- コードを読むスキル
- テストをするスキル
- デバッグをするスキル
快適な環境を追求する
- 身の回りの環境を改善することで毎日の作業が効率良くなり，時間を有効に活用できるようにな，快適にコーディングすることができる
育ちのよいコード
- まとまりの良いパッチを作ることで，高凝集と疎結合をすぐに確認できるメリットがある．
- リファクタリングによって確認しずらくなる．
- リファクタリングとそれ以外の変更を別パッチとしてチェックインすることで折り合いをつける．
No といえることの大事さ
- ごく一部であるにもかぎらず，声の大きいユーザからの要望に答えることで，FeatureCreep なソフトウェアになってしまうことがある．
- それを避けるために，「No」という勇気が必要である．
名前重要
- 事物の名前には，理屈では説明しきれない不思議なパワーがあるときがある．
- ソフトウェアアプローチとして，「まず名前から入る」
