こんにちは!ケイマエです。
本日は「プリンシプルオブプログラミング」という本を紹介したいと思います。
プリンシプルの英語表記はprincipleで原理という意味になります。
プログラミングの原理原則が学べる本となっています。
テックキャンプからエンジニアになった自分にとっては、プログラミングの原理やコードを書く考え方が欠如していたので、かなりためになる内容でした!
同じような境遇の方や未経験からエンジニアに転職した方におすすめできる本です!
本記事を見ていただくだけでも学べることはあります!
概要
プログラミングの101個の原理原則が以下の7つのカテゴリーに分かれて紹介されている本です。
⒈前提〜プログラミングの変わらぬ真実〜
⒉原則〜プログラミングのガイドライン〜
⒊思想〜プログラミングのイデオロギー〜
⒋視点〜プログラマの観る角度〜
⒌習慣〜プログラマのルーティーン〜
⒍手法〜プログラマの道具箱〜
⒎法則〜プログラミングのアンチパターン〜
カテゴリーだけ見てもどんな原理があるのか気になってこないでしょうか?!
本記事では各カテゴリーから1つの原理を抜粋して紹介しようと思います!
さっそくいきましょう!
コードは必ず変更される
Code will be changed.
⒈前提〜プログラミングの変わらぬ真実〜
コードは修正されるもの
コードは、一度書いてそれで終わりということはありません。その後、必ず変更されます。1回きりの「作り捨て」ということは、まずありません。
コードが変更されるという事実は、コードを書くときの、様々な「判断」「選択」「決断」において、最大優先度で考慮するべきです。
コードが必ず変更されるということは、「変更に強いコードを書く」必要があるということですね。そのためには「コードが読みやすい」ということがもっとも大切になってきます。
DRY
Don’t Repeat Yourself. 繰り返すな。
⒉原則〜プログラミングのガイドライン〜
コードのコピペ厳禁
同じコードを重複して書いてはいけません。コードの重複で多いのは、ひとまとまりのロジックを、安易に別の部分にコピー&ペーストして使用した場合です。これにより、同じロジックが複数箇所にばら撒かれてしまいます。
定数リテラルを直接コードに埋め込んであることも、コードの重複にあたります。同じ意味の定数が複数箇所で使われる場合、定数の指し示す情報が、重複して存在することになるからです。
なぜダメ? A.コードが改善できなくなる
コードに重複があると、障害修正や機能追加など、コードを改善していくことが困難になります。
どうすれば? A.コードを抽象化する
処理のまとまりに名前をつけて、「関数化」「モジュール化」することで、コードのロジックを抽象化します。
DRYはテックキャンプでも勉強して存在は覚えていたのですが、実務でコピペしちゃってました・・・。コードレビュー時に指摘され、モジュール化して対応しました。
初心者はコードのコピペをやりがちなので気をつけていきたいですね。
小は美なり
Small is beautiful.
⒊思想〜プログラミングのイデオロギー〜
小さいソフトウェアは美しい
小さいソフトウェアは美しいものです。美しいとは「価値が高い」ということです。
小さいソフトウェアは、シンプルで、扱いやすく、大きいソフトウェアよりも遥かに優れています。したがって、ソフトウェアは小さく作り、小さく保つようにします。
メリットは?
理解が容易、保守が容易、マシンリソースに負担をかけない、他のソフトウェアと組み合わせやすいなどがあります。
どうすれば?
ソフトウェアを設計する時は、小さく設計して、1つの仕事に専念するようにします。機能が足りなければ、他のソフトウェアと連携すればよいのです。
小さいソフトウェアというとイメージがしにくいと思いますが、一つの機能で複数の仕事をしないように気をつけていけばいいかと思います!
コードの臭い
Bad smell in code.
⒋視点〜プログラマの観る角度〜
コードの凶兆を見逃すな
「コードの臭い」とは、コードの中で、理解しにくい、修正しにくい、拡張しにくい、と感じられる部分のことです。このコードの問題点の嫌疑を、不吉な兆候として、怪しいサインとして、「臭い」と呼びます。
プログラマは、その匂いを嗅ぎ分け、適切なコードに改善していかなければなりません。
臭いの傾向を知る
・よく見る そっくりなコードがそこかしこに散らばっている状態など。
・長すぎる 関数が長すぎて、スクロールを何回もする必要があるなど。
・大きすぎる モジュールが大きすぎて管理不能な状態など。
・多すぎる モジュールが多すぎて管理不能な状態など。
・名前が合わない 名前と実際のコードが合っていない状態など。
どうすれば? A.リファクタリング
リファクタリングとは、外部から見たコードの振る舞いを買えずに、コード内部の構造を改善する技法です。コードの体質改善と呼ばれることもあります。
上記の臭いの傾向を参考に改善します。
コードの臭いは経験者でないと分からないかもしれませんが、冗長なコードを短くできないかと一旦考えてみることが大切かと思います。
プログラマの3大美徳
Three great virtues of a programmer
⒌習慣〜プログラマのルーティーン〜
プログラマは「怠慢」「短気」「傲慢」であれ
・怠慢 全体の労力を減らすために、手間を惜しまない気質です。あとで皆が楽できるように、今役立つコードを書きます。
・短気 コンピュータがサボっている時に、怒りを感じる気質です。コンピュータが十分効率的に働いてなかったり、意図通りに働いていなかったら、直ちにコードを書き直します。
・傲慢 神罰が下るほどの、過剰な自尊心を持つ気質です。高いプライドを持ち、人様に対して恥ずかしくないコードを書きます。
具体的な行動は?
・怠慢 繰り返しの仕事を自動化する。自分の仕事の中にある繰り返しを見つけたら、ツールで自動化することを考えましょう。
・短気 起こりうる問題を想定して仕事をしましょう。先回りして、要望が出てきそうな部分を考え、クレームが出る前に対応できるようにしましょう。
・傲慢 人様に対して恥ずかしくない仕事をして、保守していきましょう。作成したソフトウェアは機能ごとにモジュール化して管理しておくことがポイントです。
え、これが美徳!?と思って印象に残ったのでピックアップしました(笑)
説明を読んでみると納得しました。意外とめんどくさがりの人とかがプログラミングに向いているんですよね〜。自分も含め(笑)
ドッグフーディング
Dogfooding. Eating your own dog food.
⒍手法〜プログラマの道具箱〜
ソフトウェアの味見
自分で開発したソフトウェアは、自ら使用するようにします。作り途中だったり、リリースから間もなかったりすれば、まだ洗練されておらず、完璧なソフトウェアではないかもしれません。
人に使ってもらうものなので、自らが率先して味見して、その塩梅を確かめる責任があります。
ユーザーの視点を手に入れる
開発チームは、自身の開発したものについては、無意識に障害を避けてしまう傾向があります。(うんうん)
ユーザーが使うように使うことで、障害を事前に発見し、修正してソフトウェアの安定性を向上させることができます。また、全く使わない機能や、逆に欲しい機能なども見つかります。
自分でユーザーのように使う
自らが本当のユーザーになってソフトウェアを使用しましょう。普段の仕事の邪魔になるリスクはありますが、ユーザーに見放されるリスクに比べたら、問題になりません。
自分で作ったアプリは自分で使ってみるということが大事ということですね。予期せぬ操作なども考えて使ってみるといいと思います。僕も実務3ヶ月くらいに不具合を見つけるためにユーザーとして使ってみるという仕事をしました。
車輪の再発明
Reinventing the wheel.
⒎法則〜プログラミングのアンチパターン〜
すでにあるのに作る
ある機能について、既にそれを実現しているコードやライブラリがあるのに、自分で改めて同じ機能をプログラミングしてしまうことがあります。これは、既に世の中にある「車輪」のようなものを、わざわざ手間をかけてもう一度発明してしまうような無駄な作業です。しかも、再発明したものより、すでにあるものの方が、大抵の場合品質は優れています。
車輪を知らない
プログラマの知識不足、勉強不足により、車輪を知らなかったために再開発してしまうことが考えられます。コードを書く前に、同じ機能が標準ライブラリにないか、オープンソースにないかなどチェックするようにしましょう。
僕も車輪を知らなかったため、実務でやってしまいました。Javascriptのlodashライブラリにあるchunkメソッドを、自分でプログミングして冗長なコードになっていました(汗)
一度ライブラリがないか調べてみることが大事ですね。ここら辺も経験が必要になってくると思います。
おわり
以上、101個の原理の中から7個ピックアップして紹介しました。
これだけでも未経験者にとってはためになる情報ではないかと思います。
もっと知りたいという方は、実際に本を手にとってみてください。
kindle版1,960円、本2,420円で、ちょっとお高めですね(^-^;)
ただ、これからエンジニアとして働いていく方にとっては、早めに知っておいた方が良い内容だと思います。
Amazonレビューも星4.4と高評価です。
僕もまだまだなので頑張っていきたいと思います!
最後まで読んでいただきありがとうございました!
それではまたの記事でノシ