有名な「達人プログラマー」という本がありますが、最近、新装版として再出版されたこともあり、もう一度読み返すとともに、印象的な部分をまとめてみました。
こういった本を読むと、ふとした瞬間に自分の意思決定を左右する材料となって良い指針となり、方向性が定まるものです。
知識への投資
一番初めに語られているこの分野。
学ぶことには時間、労力、お金がかかるので、それは自分の将来への投資といえます。
リスク管理
堅実でよく使われている技術、冒険的でハイリスクハイリターンな技術をバランスよく学ぶことで、どれかの分野の価値が下落したときの保険をかけることができます。また分散投資をして多角的に様々な技術を学ぶことで、変化の激しいコンピューティングの世界にもうまく適応して行けるようになるとのこと。例えば、新しい言語を学ぶことで問題に対する異なったアプローチを学ぶことができ、思考の幅が広がるかもしれません。
安く買い、高く売る
これもまた投資と同じで、今後伸びるであろう技術を探し出し、それが一般的になる前に学んでおく。あまりにも最先端を追い求めるのも個人的にはあまり向いていないのですが・・・こういった考えを持ち続けることは大切です。
自分の作品に誇りと責任を持つ
プログラマーは責任のがれを潔しとしません。自分のコードに誇りをもってサインします。
問題が発生した場合、解決するための責任が生じます。問題はもしかしたら、ベンダーやプログラミング言語仕様、管理体制、同僚にあるように思え、言い訳をしたくなるかもしれませが、まずはその前に、とり得るすべての解決策を提案し、誠実に対応し、再発防止策もまた提案します。直接自分のせいではない(例えばライブラリのバグ、ベンダーの対応)場合でも、事前にリスクを検討し代替策を準備できたでしょ？ と上司に言われてしまわないようによく計画を立てるべき。逆に、自分では責任を取れない範囲外のことについては責任を「負わない」ことも大切で、リスクが大きすぎる場合には声を上げるべきです。(うーん、なるほど)
同じことを繰り返さない
DRY原則 - Don't Repeat Yourself = 同じことを繰り返すな
「二重化の過ち」 セクションで語られてるかの有名なDRY原則。
時間というプレッシャーを感じながら仕事をしていると、つい既存機能をコピーして少し書き換える、なんて事を考えがちですが、何処かにバグが見つかった、機能が追加になったなどよくあるケースで何箇所も修正しなければならず、漏れなどミスにもつながってきます。他にも複数人で開発していて知らずに重複した機能を作ってしまったということもあります。自分自身注意すること + 調整者を立てて二重化が起こらないように監視してもらうという事も書かれています。
モジュール間の依存度や結合度を下げる
「直交性」を保つようにと表現されています。異なる機能がお互いの動作に複雑に依存している状態では、片方を修正した時に別のコンポーネントへの影響を常に気にしている必要があり、生産性低下やリスク増大と言った問題へつながります。「恥ずかしがり屋」なコードを書くことが大切で、不要な情報を公開せず、逆に他のモジュールの実装を当てにしないこと設計を心掛けましょう。これはUNIX哲学の「一つのことを、うまくやれ」にもつながるかもしれません。自己完結した、独立し単機能の目的によくあったコンポーネントを設計するようにします。
変更に柔軟な設計をする
「可逆性」で語られています。
開発現場では、仕様や要件は必ず変わる・最終決定など存在しないなんて事が現実だったりします。今まで上記で書いたことを貫き通す事ができれば、予想もしなかった大きな変更にも対応できるかもしれません。
プロトタイプの作り方
「曳光弾(えいこうだん)」と呼ばれている、暗闇を照らして開発の方向性や目標を明るく照らすプロトタイプを作成することについてです。正確には曳光弾とプロトタイピングは違い、以下の様に定義されています。
曳光弾
使い捨てではない。最小限度のものでも完全でシステムの最終形態の骨格の一部を構成するもの。つまり、そこで作成したコード(エラーチェック、ドキュメント含め)はすべて将来利用する前提でササっとつくれれば、早いうちにユーザーにアプリケーションの動きを見せてフィードバックを受けたり、骨格を開発者に提示して理解を共有したりできる。
プロトタイピング
使い捨て。システムの最終形態への理解を確認するためのもの。ここでは「モックアップ」「ハリボテ」という言葉が近いのでしょうか。安価に作れるため、実験的で過去に例がないケースやインターフェースの議論、リスク分析などに最適。
「曳光弾」というのは、必ずしも最終形態の目標を捉えていなくても(はずしていても)、軌道修正してゴールに近づく為のアプローチです。アジャイル開発や、CIともつながる部分かもしれません。
ひとつのエディタを熟知する
生産性を高めるためにも、手の延長であるエディタは熟知すべきです。職人たるもの道具にはこだわるべきです。良い道具なくして良い仕事はできません(というような事が書いてある)。逆に複数のエディタに手を出すと、それだけ学習コストがかかり熟達が難しくなるので注意です。特に最近のIDEは機能やキーマッピングも多彩なので、ツールの使い方に時間が取られてしまい、もどかしい事があります。なるべく早く自分にあったエディタを見つけて習熟していきたいものです。
契約を使った設計
ファンクションと、それを呼び出す側との間に契約を結ぶ、という考え方で、DbC(Design by Contract)と呼ばれています。呼び出し側で実行前の「事前条件」を確実に満たした場合のみ、ファンクションはそれを実行し、約束してあった「事後条件」の返却を保証する必要がある、と言うものです。こちらも参考になります。つまり、コードは契約したこと以上も以下も行わないことを保証する設計です。
コードがなぜ動いているのかをしっかり理解する
「偶発的なプログラミング」と呼ばれる、コードがなぜ動いているのかを理解しないまま実装し、またテストにおいても幾つかのケースをパスしたことで「問題なし」としてしまうことの危険性についてです。 根拠のない仮定でテストOKとしてしまうと思わぬ罠があるよ、と言うことです。それはただ単にそれまでのテストが「偶然」通っていただけだったということにだからです。テスト自体が「制限付きのテスト」だったり、境界値や呼び出し順、誤った文脈からの呼び出しなどの変化により、容易に動かなくなる可能性を持っています。自分の書いているコードがなぜそのような挙動をするのかを意識し続けましょう。
現実では、フレームワークやコンポーネントなどそもそも使う側は中身を意識しなくていいように設計されているものや、また学習するときに色々仮定して動作させて、など様々なケースがあるので、難しい部分もあるとは思いますが・・が、やはり常に実装を理解しようという気持ちを持つことは大事で有ることは間違いないと思います。
また、「慎重」にプログラミングする習慣の大切さが以下の様に書かれていました。
- 常に何をやっているのか意識する
- 明確にプランニングする
- 偶然や仮定に依存せず信頼できるものだけ前提とする。あるいは最悪のケースを仮定する。
- 仮定をドキュメント化し、仮定をテストする
- リファクタリングを怖れない
要求を掘り起こす
技術者としてプロジェクトの最終的な目標は要求通りのものを作るということではなく、ビジネス上の問題を解決するということです。その為、ヒアリングをします。ところが大抵の場合、依頼者の要求と言うのは様々な仮定、誤解や政策の奥底に埋められていて、その要求の本質的な部分をすぐに見つけることは困難です。 プロデューサーやデザイナー、営業の方々と、あとになって「え？ 前と言っていることが違うじゃん！」とか、「すまん、仕様変更になった」・・。まあ良くあることですが、そもそもどんな目的を達成したいのかを良く考え、要求とは別のビジネスポリシーをロジックから切り離して別設定ファイル化できているかなどは大切です。
さいごに
内容を個人的な理解に当てはめ、かつかなり要約していますのでズレている事もあるかもしれません。ただエンジニア業界での普遍的な事実でもあるので自戒も込めての読書感想文です。他にも様々な有要な情報が書かれているので、持ってて損のない本だと思っています。
「ロックンロールの精神でコードを作成して下さい」
一番響いた言葉(笑)
ロケンロー♪
