ちゃんなるぶろぐ

社会人1年生が、日々の学びをアウトプット〜読書・遊び・プログラミング〜

「プログラマが知るべき97のこと」〜日本人プログラマによる知っておくべき10のこと〜

読み終えるまで約10~15分

 

 

どうも、ちゃんなるです! 

今日も”デキる”プログラマになるべく勉強していきましょう!

 

今回が最後の、下記書籍要約の投稿です。

プログラマが知るべき97のこと』

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

今回の内容

本書はタイトル通り97のことについて書かれています。

そして最後には、『日本人プログラマによる知っておくべき10のこと』が書かれています。

今回はこの『10のこと』についてです。

  1. 命を吹き込む魔法
  2. ロールプレイングゲーム
  3. ルーチンワークをフローのきっかけに
  4. プログラマが持つべき3つのスキル
  5. 快適な環境を追求する
  6. 見知らぬ人ともうまくやるには
  7. 不具合にテストを書いて立ち向かう
  8. 育ちのよいコード
  9. Noといえることの大事さ
  10. 名前重要

①命を吹き込む魔法

このテーマで述べられていたことは、

「プロジェクトに『コードネーム』をつけて愛着を持とう。」

ということです。

 

以下、要約です。

あなたのプロジェクトにはコードネームがありますか?

「開発一課でやってるやつ」「A社向け」などその場限りの指示後で呼んでませんか?

呼び名のないプロジェクトをどう愛せるでしょう。

素敵なコードネームをつけ、その名前を何度も口にしましょう。

コードネームによってプロジェクトに愛着が湧き、チームの結束力が高まるはずです!

 

ロールプレイングゲーム

このテーマで述べられていたことは、

「理想のプログラマに「なる」のではなく、「演じてみる」。」

ということです。

 

以下、要約です。

「理想のプログラマのような「理想の○○」になるには、本来の自分を変える必要があります。

しかし、変化は痛みや苦難を伴います。

「理想のプログラマになる」のではなく、「理想のプログラマを演じてみる」と考えてみるといいです。

 

あなたの想像する「理想のプログラマだったら、今この局面でどう振る舞うだろう、この問題に気づいたらどうするだろう、同僚のあの態度に対してどう発言するだろう、と想像をしながら「理想のプログラマを演じるのです。

本来のあなたなら気づかなかったことに気づけ、やらなかった行動をとるようになるかもしれません。

 

ルーチンワークをフローのきっかけに

このテーマで述べられていたことは、

「エディタを開いたら必ずやる『ルーチンワーク』を設定し、『フロー状態』に入る準備をしよう。」

ということです。

 

以下、要約です。

周りの妨げがなくコーディングに没頭してる状態を「フロー状態」と呼びます。

エディタやターミナルを開いても、いきなりコードを書き始めるというのもなかなか難しく、その準備としてルーチンワークを利用すると便利です。

例えば、エディタを開き、「今日1日着手することを書き出す」とか「1日の終わりに、翌日最初に着手することをメモする」とか、「ふと思いついた変更のアイデアをコードのコメントとして残しておく」とか。

 

ルーチンワークとしてやってるものが自動化できるならするべきです。

しかし、手動でやる余地が少しでもあるのなら、それをルーチンワークとして着手し、「フロー状態」への準備運動とするのがいいでしょう。

 

プログラマが持つべき3つのスキル

このテーマで述べられていたことは、

「コードを読む・テストを実行する・デバッグをするの3つのスキルが重要。」

ということです。

 

以下、要約です。

3つのスキルとは、下記のものです。

①コードを読むスキル

②テストをするスキル

デバッグをするスキル

これらのスキルは、知っているではなく実践できるという意味です。

 

これらのスキルをバランスよく訓練できるのは、バグ修正です。

まず、そのバグを再現できるテストスクリプトを準備します。

そして、デバッガを使って期待する結果と実際の値の差分などを調査します。

もし実際の値と期待する結果が異なるのであれば、なぜそうなったかを遡っていき、当該コードまわりをよく読んで理解します。

 

⑤快適な環境を追求する

このテーマで述べられていたことは、

「少し時間を割いて快適な環境づくりをすることで、今後のコーディングの時間をより効率的に行うことができる。」

ということです。

 

以下、要約です。

我々はコーディングをしてる際、コードを書く以外にも様々なことをしています。

エディタの操作・ビルド・テスト・ドキュメントの閲覧・ライブラリのインストール・キーボードを叩く・画面を見る・椅子に座る、、、細かく挙げるとキリがありません。

 

それぞれの作業一つ一つを効率化してみてはどうでしょうか?

例えばエディタを操作するなら、有効なプラグインを導入してみる。

例えば何度もテストを実行するなら、テスト自体をより高速に実行させる環境を整える。

例えば画面を見ることなら、文字や配色、フォント、背景色やテーマを変更してみる。

 

身の回りの環境を改善することで、毎回の作業の効率がよくなり、時間を有効活用でき、快適にコーディングすることができるようになります。

新たな言語やプログラミング手法を取り入れ、プログラマとしてスキルアップすることももちろん大切です。

ですが、少しだけ時間を割いて快適な環境づくりをしてみてはどうでしょう。

今後のコーディング時間がずっと快適なものになります!

 

⑥見知らぬ人ともうまくやるには

このテーマで述べられていたことは、

「『できていいことだけをできるようにする』をデフォルトにすることで、予期せぬ問題を予防する。」

ということです。

 

以下、要約です。

バグには2種類、できるはずのことができないことできてはならないことができてしまうこと、があります。

SQLインジェクションCSRF…いわゆる脆弱性と言うのは全て後者に属するバグです。

プログラマが、「できなかったことをできるようにすること」は一生懸命でも、そこで力尽きてしまい、「できてはならないことができないこと」をチェックする余裕がないのかもしれません。

 

これを防ぐにはどうしたらいいのでしょうか?

 

それは、「できてはいけないことをできなくする」のではなく「できていいことだけをできるようにする」のです。

 

見知らぬ人とうまくやる一番のコツは、見知らぬことをしないこと。

(213ページより)

我々の問題解決において、「いつ・誰に・何を許可するのか」というのは永遠の課題です。

「できていいことだけをできるようにする」だけで、問題解決への考え方が少しでも楽になるでしょう。

 

⑦不具合にテストを書いて立ち向かう

このテーマで述べられていたことは、

「テストを書くことは、患部の絞り込み・修正箇所の確認・他の部分への影響の確認・再発防止などを考慮した、合理的で効率的な開発方法である。」

ということです。

 

以下、要約です。

テスト駆動開発(TDD: Test Driven Development)は、プログラマが自分の描くコードに自信を持ちながら一歩一歩プロジェクトを開発する手法です。

具体的には、コードを修正するたびに既存のテストを通ることを確認し、既存のプロジェクトが壊れてないことを保証しながら開発を進める手法です。

しかし、品質保証チームや顧客から不具合の報告を受けた際、どのようにそれに立ち向かうのでしょうか?

やはりテストを書いて立ち向かうのです。

やるべきことは「不具合の修正時には、必ず先に不具合を再現する自動テストを書いてから修正すること」です。

不具合修正時のテストは、下記の手順で行うべきです。

  1. 手元で不具合を再現させる
  2. 不具合を発生させている最小単位を見つけ出す
  3. 最小レベルで不具合を再現し、不具合が修正されたら通る自動テストコードを書く
  4. 3で書いたテストコードが失敗することを確認する
  5. 不具合を修正する
  6. 3で書いたテストコードが通ることを確認する
  7. 既存の全てのテストを実行し、不具合修正が他の部分を壊してないことを確認する

「テストを書いてる時間はない」と言われたり、テストを書くことを回り道であると感じるかもしれません。

しかし、テストを書くことは、患部の絞り込み・修正箇所の確認・他の部分への影響の確認・再発防止などを考慮した、合理的で効率的な開発方法なのです!

 

⑧育ちのよいコード

このテーマで述べられていたことは、

リファクタリングと振る舞いの修正は別のパッチとして分けよう。」

ということです。

 

以下、要約です。

コードのリポジトリをチェックアウトし、それまでにチェックインされた変更、パッチをみてみましょう。

パッチ単位の変更がファイルを跨がず、1つのファイルの同じ場所にまとまっていますか?

そのようなパッチが多いなら、高凝集疎結合であることに期待を持てそうです。

このような『まとまりの良いパッチ』で育ったコードは、優れた設計といえます。

また、『まとまりの良いパッチ』には、レビューの負担が小さく、マージや取り消しも楽といったメリットもあります。

 

既存のコードをよりよくするためには、振る舞いの修正だけでなくリファクタリングもあります。

しかし前者に比べ後者は、名前の変更やクラスの引き上げといった構造上の変更を行う場合があり、一見『まとまりの悪いパッチ』、複数のファイルにまたがる小さな変更を生み出すことが多いです。

そのため、リファクタリングとそれ以外の変更を別のパッチとしてチェックインするようにしましょう。

振る舞いを変更しないリファクタリングの原則は、読み手が振る舞い自体の正しさを確認しなくて良いということを意味します。

 

『振る舞いの修正』リファクタリングはどちらも、より良いコードを作るために必要不可欠です。

しかし、それらを独立したパッチに追い出すことによって優れた設計が実現するのです。

 

⑨Noといえることの大事さ

このテーマで述べられていたことは、

「良いデザインやシンプルさを表現するには、時には、顧客からの要望や依頼に「No!」と言う勇気が大切である。」

ということです。

 

以下、要約です。

自分の開発したソフトウェアを公開し、使ってもらうことは幸せです。

また、利用ユーザからのフィードバックは、ソフトウェアを改善するためにとても重要です。

 

UNIX哲学では、"Write programs that do one thing and do it well"と言われるように、複数の機能を詰め込まず、単一の機能を持ったプログラムを組み合わせて使うことが美しいとされます。

 

ここで問題になるのが、ソフトウェアが人気になればなるほど、ユーザからのフィードバックが増えて、ソフトウェアに様々な機能の追加を強いられるということです。

一部の声の大きいユーザの要望に応え続けようとするあまり、ほとんどのユーザが使わないようなニッチな機能や画面を持ったソフトウェアになってしまうことも少なくないでしょう。

それによりメンテナンスしにくく、バグの発生しやすいソフトウェアになり、そしていつかは使われなくなってしまうかもしれないのです。

 

こうした悲劇を避けるには、ユーザの要望に「No!」と言う勇気が必要です。

Noと言えることで、結果として良いデザインやシンプルさを達成できます。

顧客からの要望で、なかなかNoと言えない場合もあるでしょう。

その場合にも、ソフトウェア本体を改善するのではなく、拡張の形やプラグインとして実装する方法を取るべきです。

 

⑩名前重要

このテーマで述べられていたことは、

「「まず命名する」というのが、ソフトウェア設計における有効なアプローチの1つである。」

ということです。

 

以下、要約です。

名前は非常に重要です。

適切に命名できると言うことは、その機能が正しく理解できていて、正しく設計されているということを意味します。

逆に、ふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分に理解できてないと言えるでしょう。

 

ソフトウェア設計のアプローチとして、「まず名前から入る」というのは、有効なアプローチの一つなのです。

 

まとめ

①プロジェクトに『コードネーム』をつけて愛着を持とう!

理想のプログラマに「なる」のではなく、「演じてみる」

③エディタを開いたら必ずやるルーチンワークを設定し、『フロー状態』に入る準備をしよう。

コードを読む・テストを実行する・デバッグをするの3つのスキルが重要。

⑤少し時間を割いて快適な環境づくりをすることで、今後のコーディングの時間をより効率的に行うことができる。

⑥「できてはいけないことをできなくする」のではなく「できていいことだけをできるようにする」

⑦テストを書くことは、患部の絞り込み・修正箇所の確認・他の部分への影響の確認・再発防止などを考慮した、合理的で効率的な開発方法である!

リファクタリング『振る舞いの修正』は別のパッチとして分けよう。

⑨良いデザインやシンプルさを表現するには、時には、顧客からの要望や依頼に「No!」と言う勇気が大切である。

「まず命名する」というのが、ソフトウェア設計における有効なアプローチの1つである。

 

かなり長期の連続投稿となりましたが、完読できてよかったです。

今後は別の書籍の内容で、さらに洗練された文章をアウトプットしていきたいです。

 

*より深く知りたい方は、ぜひ本書を手にとってみてください!

書籍情報

プログラマが知るべき97のこと [ ケブリン・ヘニー ]

価格:2,090円
(2021/5/13 11:12時点)
感想(1件)

【中古】 プログラマが知るべき97のこと /ケブリンヘニー【編】,和田卓人【監修】,夏目大【訳】 【中古】afb

価格:825円
(2021/5/13 11:12時点)
感想(0件)

【書籍名】プログラマが知るべき97のこと

【著者名】ケブリン・へニー、夏目大(訳)

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

 

関連記事

chan-naru.hatenablog.com

chan-naru.hatenablog.com

chan-naru.hatenablog.com