はじめに
こんにちは。テクノロジー本部 エンジニアリング統括部 サービス開発部 22卒エンジニアの上野です。 この記事では「プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則」を読んだ私が個人的に気に入ったプリンシプル（原則）を紹介させていただきます。少しでも「なるほど」と思っていただけたり、書籍に興味を持っていただけたら嬉しいです！
どういう書籍か
プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
amazonの紹介では以下のように書かれています。
一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！
なので研修を終えた新卒エンジニアにはピッタリの書籍かと思います（私はプロジェクトにアサインされてから2ヶ月ほど経った頃に購入しました）。
この書籍では各プリンシプルを「どういうこと？」「どうして？」「どうすれば？」の３つのセクションで説明しています。
- どういうこと？: そのプリンシプルがどういうものなのか(What)を説明します。
- どうして？: そのプリンシプルがなぜ必要なのか(Why)を説明します。
- どうすれば？: そのプリンシプルをどのようにすれば活用できるか(How)を説明します。
今回の記事ではこの３つを簡潔に説明し、なぜ私がこれらのプリンシプルを選んだのかを書いていきます。
気に入ったプリンシプル
コミュニケーション
どういうこと？
コードも人に見せるものであるため、コミュニケーションの場であると言えます。
どうして？
コードは、書く時間よりも読む時間の方が圧倒的に多くなります。自分が以前書いたコードを読むことも多いです。そのため読み手が理解しやすいコード、つまり円滑なコミュニケーションを意識する必要があります。
どうすれば？
コードで良好なコミュニケーションを取るには、コードを書いてる時に他の人のことを考えましょう。他の人に説明するつもりでコードを書きましょう。
なぜ気に入ったか
チーム開発の場合（個人開発でもコードを公開する場合は）、必要なマインドだと思ったからです。 チーム開発に携わるようになってから日々他のメンバーに自分が書いたコードを見てもらっています。なので必ず見られることを意識し、「この変数名はわかりやすいか？」「このロジックは複雑すぎないか？」「コメントは必要か？」などを考えながらコーディングしています。 コードはコミュニケーションということを意識することが良いコードを書く第一歩だと思いました。
分割統治
どういうこと？
そのままでは解決することが難しい「大きな問題」は、いくつかの「小さな問題」に分割して個別に解決します。小さくした各個の問題は、元の問題に比べて格段に容易になり、すぐに解決に至ります。
どうして？
大きな問題を大きなまま解決しようとすると、解決が困難になり、解決が遅くなります。最悪の場合、解決できないということもあります。そのため分割して取り組むことが必要となります。
どうすれば？
例えば、アルゴリズムを設計する時は、マージソートのように、ボトムアップで分割してから問題解決できないかどうか検討します。
なぜ気に入ったか
この考え方はプログラミングだけでなく、生きていく上でも重要です。 大きなタスクや複雑な申請を行う必要がある時、あまりの大変さに頭を抱えてしまうかもしれません。しかしそれらを小さなタスクに分割し一つ一つに集中すれば大抵の場合大したことはないでしょう。 大きなタスクが降りかかってきた時はまず分割しましょう。
アーキテクチャ非機能要件
どういうこと？
非機能要件とは機能面以外の要件のことで、ソフトウェアが高品質であるためには非機能要件を満たさなければなりません。非機能要件の観点には以下があります。
- 変更容易性
- 相互運用性
- 効率性
- 信頼性
- テスト容易性
- 再利用性
どうして？
非機能はリリース後に影響が大きくなります。リリース後の運用の「大きな」トラブルのほとんどが、パフォーマンスやシステムダウンなど、非機能的な特性に起因しています。
どうすれば？
設計の段階で非機能要件について考慮します。ソフトウェアが単独で動くことはまずないので、他から呼び出されることを考えます。
なぜ気に入ったか
多くの場面で自分に足りていなかった考え方だったからです。 難しいコンポーネントを開発する時、ついつい機能と見た目さえ合っていれば良いだろうと考えていました。しかし、そうすると後々不具合が起こる可能性が高かったり使いづらいコンポーネントになってしまいます。
1歩ずつ少しずつ
どういうこと？
小さな作業を1つ行い、それをしっかり確認し、次の作業に移る、というサイクルを繰り返します。
どうして？
複数の作業を一度に行うとそれらの作業が混線し、どれも失敗する可能性が高くなります。問題が発生して、修正のため一旦元に戻したい時、ステップ・バイ・ステップで進んでいれば、後戻りが楽になります。
どうすれば？
一歩ずつ作業を行います。 例えば、リファクタリングであれば、モジュール間で関数を移動する時に関数名の不備に気付いたとしても、移動と名前変更を同時に行なってはいけません。関数を移動した後に動作を確認してから、関数名の変更を行うべきです。
なぜ気に入ったか
コミットの粒度を下げることはまさにこの考え方に基づいていると思います。 何か失敗した時に後戻りする一歩を小さくするためにコミットを細かくする必要があります。
おわりに
どんなプログラミング言語でも、フロントエンドでもバックエンドでも通じる有用なプリンシプル、原則が多く載っている素晴らしい書籍でした。この書籍からインプットした知識を、良いコーディングだけでなく良いレビューにも繋げられるよう今後とも精進していきたいです。
読んでいただきありがとうございました！
上野 司 Tsukasa Ueno
エンジニアリング統括部 サービス開発部 第1グループ
2022年に新卒入社。現在は HR forecaster でフロントエンド開発を担当している。趣味はボクシング、ゲーム、アニメなど。
※2022年12月現在の情報です。
