プリンシプル オブ プログラミング
３年目までに身につけたい一生役立つ１０１の原理原則
著者：上田勲（2016）秀和システム出版
プログラマー界隈では言わずと知れた、読んでおくべき有名良書の一冊
本書を一言で表すなら
「できる人が普段から行っていることをまとめた本」
である。
本書概要
本書は、様々な出典から得られたプロジェクトの原理原則が箇条書き形式でまとめられている。
そのため、辞書のような感覚で利用することができる。
タイトル通り、専門的な話も多いが、プログラミングをあまり知らなくても役に立つ知識や考え方も集約されています。
プロジェクトを管理するような人には、専門問わず読んで欲しい内容が多く含まれた、言わばバイブル系書物です。
紹介したい内容は山ほどあるが、万人向け、エンジニア向けに分けて要点のみ抜粋します。
え、なぜ万人向けから先にやるかって？それは、エンジニア向けなんて誰も興味がないからだよ！！
万人向け
臭いに敏感であれ
不吉な臭いや違和感などとも言う。
プロジェクトを進行する上で「嗅覚」はとても重要である。
たった一度のまあこのくらいあとで直せばいいだろうは、別の人のクオリティレベルも連鎖的に下げるため、結果的にプロジェクト全体のクオリティを低下させます。
臭いの元
- 長すぎる
- 大きすぎる
- 名前と内容が一致していない
- 同じ内容をよく見る
- etc...
いつかは必ず、全体の修正を行う日が来ると思いませんか？
その時になって、把握できない量の修正に時間を浪費するのか、最初の一回を起こさない努力をするのか、どちらが良いかは明白です。
命名の意味
今いるメンバーだけがわかる暗黙の了解は腐敗臭がする。
新しい人に暗黙の了解を理解してもらう時間（教育コスト）と言う大きな無駄が発生するからだ。
悪いことは言わないから、命名に時間をかけよう。
名前から考えられる性質＝性質から考えられる名前となる命名がベストだ。
Ex.
性質：音声認識によって文字を入力する機能
名前：音声入力機能悪い例：
音声機能（合成音声を発声する機能など様々な別の答えが想像できてしまう）
音声言語機能（音声を認識してどの言語か判別する機能とも取れる）
入力音声機能（入力されたテキストを合成音声として発声する機能とも取れる）
暫定ソリューション
忙しいから一旦、よく分からないから一旦、とりあえずこのお客様のだけ一旦、、、
暫定で作られるソリューションはいっぱいありますが、
一度でも暫定を直したことはありますか？
長く生き残っている「暫定」から腐敗臭を感じませんか？
暫定、ダメ、絶対
できる３大美徳：「怠慢」「短期」「傲慢」
３大悪徳の間違いじゃないかとツッコミたくなるのはわかる。
- 怠慢
- 怠慢と言っても、やる気がなく怠けると言う意味ではない。
何度も繰り返す作業をコンピューターにやらせ、自分を怠惰にすると言う意味だ。
自動化は、単に作業を楽にするだけでなく、作業スピードや正確性も向上させる。 - 短気
- 短気と言っても、怒鳴り散らせと言うわけではない。
何か新しい事をする時に、思うようにうまく行かないことはよくあります。
そんな時は無駄に我慢などせず、さっさと別の方法を検討しましょう。 - 傲慢
- 傲慢と言っt...(以下略)
自分が導入したプロセスは他人の目に届くように見せびらかしましょう。
見せびらかしても恥ずかしくないように責任を持って深く考え抜く。
色々な人からの意見は貴重です。技術提供も大切です。
ハードワークは報われない
日本には、「我武者羅」「一生懸命」が美徳になる世界観がある。
一方で、IT大国アメリカではハードワークを行う従業員は使えないリストラ対象者です。
決められた時間内に決められた以上の成果を出す。
これは存外難しいことです。
だから、思考停止気味に「とにかく」「無心に」「ひたすら」頑張ってしまうものです。
ですが、果たして、アナタの知っている本当にできる人達って残業してますか？
ITで生きていくと決めたそこの君へ、
正しく「がんばる」ことを頑張ってください。
ステップ・バイ・ステップ
「できる人」は一瞬で正解を導き出しているように見えます。
確かにできる人は答えるのが早い上に正確なので、何か特別な発想や閃きで答えがわかっているようにも見えます。が、これは大きな誤解です。
できる人の思考と普通の人の思考に違いはありません。
どんな人もわかることから一つずつコツコツと思考して答えにたどり着いています。
できる人は日々の鍛錬でコツコツの高速化をしているだけです。
思考もスポーツと一緒で慣れが必要なだけです。
論理的思考のコツ
-
瞬時に答えを得ようとするのは誤りです。できる人も最初から速く考えられるわけではありません。むしろ、よく考える分普通の人より遅くなることさえあります。 -
最初に出た答えを盲信するのは誤りです。答えが一つ見つかったからと言って思考停止しはいけません。思い込みを排除して、他の可能性も検討しましょう。 -
思考の無限ループを防ぎましょう。一度考えたことは覚えておきます。とはいえ脳内で覚えるのは難しいので、書いて情報整理しましょう。 -
直感と論理は反対の概念ではありません。コツコツの高速化が極限に達した時、脳内の思考よりも速く来る感覚的な思考が直感です。
ちなみに、直感は脳科学の世界でも研究されています。
が、所謂「なんとなくわかるんだよね〜的直感」と上記の直感は違います。
言うなれば将棋やスポーツの世界の「条件反射」と近いものです。
エンジニア向け
KISS (Keep It Simple, Stupid: シンプルにしておけ、バカ野郎)
コードはシンプルに保ちましょう。
余計なことはしない。
- 新しく覚えた技術を無駄に使わない
例えばこんな風にね
無意味な機能の主張は見にくいだけ。
新しいアウトプットは個人の練習開発で行い、人に見せるときは自信を持って- 将来の必要に備えたい
- やり過ぎは禁物。説明し過ぎもね。
なぜなら今必要なことは今後も必要とは限らず、今回の開発を元に依頼者が新しい開発を思いつく可能性がある。当然依頼前と依頼後の依頼者は別の視点を持つことになるので、、、
- 勝手に要件を変えてしまう
- 独りよがり禁物。見つめ直そう己の心。
DRY (Don't Repeat Yourself: 同じことを繰り返すな)
コードのコピペ厳禁です。
どうしてもコピぺしてしまう時、心に問いかけましょう。
コピーしなくても済む方法は本当に世の中に存在していなかったのだろうか...？
そうでなければあなたは、
- 〇〇さんのコードは読むのに時間がかかる
- 〇〇さんのコードの修正は難しい
- 〇〇さんのコードはテストが複雑だ
- etc...
など後輩からレガシーコードの産みの親として蔑まれ、会社の歴史に刻まれてしまいます。
あの先輩はWET (Write Everything Twice)だね、なんて洒落た事を後輩に言わせてはいけません。
ポリシーと実装の分離
コードをポリシーと実装に分けましょう
ビジネスロジックやデータの選択など、システムの前提条件に依存する内容
Ex. 営業代理店へのフィーの計算方法
ポリシーはプロジェクトの状態に依存して変わる可能性を大いに秘めています。
むしろポリシーが変わらないと思うのは製作者の慢心に他なりません。
システムの前提条件に依存せず、独立したロジック部で、システム外でも利用可能なもの
Ex. 計算されたデータをオブジェクト形式でSpreadsheetAppへリクエストするロジック
実装はプロジェクトに関わらず不変であることが多いです。
そのため、安定的でバグを起こすことも少ないです。
みなさんがいつも目にする色々なAPIは各機能がすべて直交関係で、独立に設計されていませんか？
見方を知ると見えてくるものも変わります。
できる人は日常に潜む達人の知を感じるために、日々新しい見方を実践し続けているだけなのです。
コードの柔軟性
コードに完璧はありえません。コードは必ず変更されます。
人間の欲望は無限大です。
要件通りに作成したプロダクトでも、それを見た依頼者は必ず新しい要望を出してきます。
プログラミングをする際は、変更が入ることを予期して直しやすいコードを作りましょう。
柔軟なコードとは
インプットとしてデータを受け取り、データを整形し、データをアウトプットするだけのコードです。
受け取るデータと、整形後のデータの形さえ変わらなければ中身のコードにいくら変更を加えても、周りのコードは影響を受けません。
コードは入口と出口さえ決まっていれば中身はブラックボックスでもいいのです。
そして、ポリシーと実装を分けましょう。
これだけでも大きく安定したコードが書けるようになります。