達人プログラマー第2版を読んで伝えたい事が多すぎる問題（第一章）
はじめに
達人プログラマー第2版は新人のプログラマがこれから悩んでしまう場面に対して、助けてくれる本だと私は信じています。
初めて本書を読み始めた時はプログラマになる前でした。
高卒レベルのコードですら書くこともわからない当時ですら読んだ衝撃は忘れていません。
そして今、プログラマとなり改めて読んだ発見や共感を書きたいと思い執筆しました。
私が理解できた内容をまとめ、同じ境遇や悩みを抱えるプログラマーが本書を見るきっかけや見るときの手助けになってくれることを期待しています。
そして最初はすべてまとめたうえで投稿する予定でしたが思った以上に伝えたい事が多すぎたので章ごとにとりまとめお伝えしたいと思います。
執筆時点で行っている業務内容
参考に私の業務内容を記載します。
- プログラマ（エンジニア）歴：7ヵ月
- 取扱い言語：Java、JavaScript
- 業務内容：プロダクトコードのデバッグ、バグ修正（初程度～中程度）、UIUX改善
まえがき
達人プログラマーの「達人」とはギリシャ語の「行うに適していること」であり本書は「行う」にフォーカスされている。
「行う」とは、顧客の要望から 翻訳/設計/実装/提供 のすべてでありプログラムに限って言えば、すべてが0と1で表現されるプログラムの世界とすべてがあいまいさで表現されている現実世界をつなぐ役割であると言えます。
達人プログラマーに必要な素養
- アーリーアドプター（先駆者）
- 研究好き
- 批判的
- 現実的
- 何でも屋
正直これを見たとき達人になれやしないと思いましたが事実はそんなことはない。
素養は身に着ければいいだけだと私は思っています。
継続は力なり
「継続は力なり」、よく言う（そしてよく聞く）言葉ですが本書でも取り上げられています。日々自分自身を改善することが達人プログラマーの大切な一歩です。
第一章 達人の哲学
この章はプログラマとして生きていく中で考えるべき、そして行動すべき事柄が書かれています。それはプログラマに限らず必要な生き方があり、まだ業務にアサインされていない方がいても、この第一章だけは目を通してほしいです。
第一章の構成は以下です。
- あなたの人生
- 猫がソースコードを食べちゃった
- ソフトウェアのエントロピー
- 石のスープとゆでガエル
- 十分によいソフトウェア
- あなたの知識ポートフォリオ
- 伝達しよう
あなたの人生
人は誰しも不満を抱えています。「在宅勤務をしたい」、「チームの雰囲気が悪い」、「評価が低い」そんな不満を抱えながら今を生きています。そして明日も同じように不満を抱えながら業務をするでしょう。
「変化に向けて足を踏み出せないのはなぜでしょうか」
「あなたは組織を変えることができる、組織を変わることもできる」
驚くほど簡単な答えですが、深く刺さるものでした。もう一度考えてみましょう、不満を解消するだけの機会は選択肢はすぐ手の届く範囲にあります。
猫がソースコードを食べちゃった
プログラムの世界では無知がエラーやトラブルを引き起こすことは大いにあります。ですが自身が無知であることを恐れてはいけません。いつだって完璧なソフトウェア（そして人）は存在しないのです。
「じゃあどうしたらいいの？」
常に最善を尽くしてください。努力を続けてください。それでもできないときは素直に「できない」と言いましょう。わからないことは「わからない」と言ってやりましょう。
そうすることが自身の行動に「責任を持つこと」になります。
ソフトウェアのエントロピー
本書でのエントロピーは「無秩序が無限大に増大してしまう」という意味合いで使われています。
ほとんど秩序で満たされていたコードは、修正に修正が足されていく中で無秩序が増えていきます。無秩序は無秩序を生み、いつのまにか無秩序で満たされたコードに生まれ変わっています。
要件が追加・変更されることもあるため、修正されないコードは存在せず、いつかはなんらかの形で変更されるのです。それでも無秩序を容認することはできません。
私たちができることは「出来る限り綺麗に保つこと」です。質の悪いコードや陳腐化したコードは徹底的に排除しましょう。目に入った無秩序はできるかぎり正しましょう。
石のスープとゆでガエル
今回の執筆では割愛します。（もしかしたら書く時が来るかもしれません。）
所感としてマネジメントの考え方が強く、現時点の経験では役立ったことがありませんでした。
十分によいソフトウェア
今回の執筆では割愛します。（もしかしたら書く時が来るかもしれません。）
所感として上流工程（要求設計や設計時の品質要求）の話であり、現時点の経験で強く意識できるものはありませんでした。
あなたの知識ポートフォリオ
今あなたの頭の中をポートフォリオ化できるでしょうか。（ちなみに私は自信がありません。）
知識ポートフォリオのためにできることがあります。（本書では業務ではなく普遍的な知識を取り扱っています。）
それは定期的な投資を続けることです。
定期的な投資とはなんでしょうか。少し具体的な例を考えてみましょう。
- 新しい言語を学ぶ
- 読書をする（月1冊は読むペースで）
- ソフトスキルを身に着ける
- 講習を受講する
- コミュニティに参加する
- 異なった技術を使ってみる
- 最新の情報を身に着ける
今度は身に着けた知識を分析してみましょう。
- 「５つのなぜ」を問う
- 誰にメリットがあるのか
- コンテキストは何か
- それはいつ有効になるのか
- なぜこれが問題なのか
どれも簡単に答えが分かるものではありませんがそれでもやってみましょう。
一人では難しければ誰か仲間を集めてみるのも良いかもしれません。
伝達しよう!
プログラマにコミュニケーション能力は必要でしょうか。
答えは必要です。実際には1行のコードを書くよりも多くの時間をドキュメントの作成やミーティングに費やします。そして時にはコンサルや営業といった別の業務をしている人とコミュニケーションをとることも珍しくはありません。
あなたは誰かと話すとき「単に語っているだけ」になっていませんか？
（私は多々あります）
そうならないため少しだけ考えてみましょう。
聞き手の事を知る
聞き手が知りたい情報とはなんでしょうか？
言いたいことを知る
私が伝えたいことはなんでしょうか？
タイミングを選ぶ
相手が聞き入れてくれる状況でしょうか？
スタイルを選ぶ
相手に伝わる言葉を選んでいるでしょうか？（時には絵も描いてみましょう）
見栄えをよくする
見せるドキュメントは整理されているでしょうか？
聞き手を巻き込む
できるなら草稿段階から聞き手に見てもらいましょう！
聞き手になりましょう
時にはこちらから聞いてみましょう
相手の立場になる
慌ただしい毎日の中で放置している通知はありませんか？
今すぐ返してあげましょう！
ドキュメントとコードをまとめる
プログラマはコードを書いて、動くものを作ってしまったら満足してしまいます。レビューのためにまとめた資料もリリースされてしまえば頭から消えてしまいます。しかし、先述のとおりコードは「変更されるもの」なのです。そのたびにドキュメントを探して、背景や漏れを見つけなければいけません。
ではどうするのでしょうか。答えは簡単です。
コードとドキュメントをまとめてあげることです。幸いなことにコードにはコメント機能があります。Javaではクラスやメソッド事にドキュメントを作ることもできます。
あなたのドキュメントの努力を、コードに乗せて伝えてあげましょう。
第一章のさいごに
伝えたいことが多くてかなりの分量になってしまいました。
第一章で取り上げられたことはプログラマに限らず活かせることだと思っています。もし気になった方がいる場合は是非「達人プログラマー第2版」を手に取ってみて頂くことをおすすめします。
Discussion