『プログラマが知るべき97のこと』の感想
2020/01/03
こんにちは！@kaori_choです！
「プログラマが知るべき97のこと」を読んでいる感想です。
3行まとめ
- 97のコラムなので、隙間時間に読める。仕事のモチベーションがちょっと上がる。
- 実はぐぐるとコラム全文読めます。
- 定期的に読み返して、自分にできていることを確認したり、これからの仕事の仕方のヒントをもらえる本。
おすすめな人
- 目の前の仕事のモチベーションが少し下がっちゃっている人
- 普段ゴリゴリ勉強進めているが、中長期で私何がしたいのかなあとふとした時に思う人
- プログラマが普段何を考えて仕事しているか知りたい人
プログラマの気質についても、色々な考え方がある。97人97様の答えが載っているので、黒い画面の前で何考えているんだろうプログラマっていう人たちは？と思っているプログラマでない人が読むにも意外とおすすめかなあ。
あとは私も駆け出しエンジニアの時にこれを読んで「一流ってすごいな！」とテンション上がったので、最近駆け出した人でまだ読んでない人にもおすすめしたい。全部コラムなので、気軽に読めるよ。
感想
似たような本で「情熱プログラマー」がありこっちのほうが新しいと思ってたけど、日本での初版はどちらも2010年だった。（むしろ情熱プログラマーのが出版はやかった）もう10年前なのびっくり。COBOLの話とかしていて少し古い部分も出てきていると思うが、流行りすたりのある技術面の話が本筋ではなく、プログラマとして働くのに必要な「心構え」的な部分が大きいので、いつ読んでも学びがある。
書くコラムに写真が乗っているのも良い。ただこれ今写真みて思ったけど、もっと女性プログラマもここういうところに載っていきたいね？今はまだ数がが少ないけど私も地道に生き残って進出していきたい。
紹介したの意外にも好きなコラムがたくさんあるので、読んだ人よかったら一緒に語らいましょう。
メモ
年始なので、年始っぽさのあるものをチョイスしてみた。
74 「イエス」から始める
p.149
要望が出されたコンテキストがわかれば、新しい可能性が広がることが多いのです。
開発者にとってばかばかしい要望に即座にNOというのは容易い。でも、まずは「OKわかった、それで、なんでそれが必要なんですか？」と会話することが大事だと常々思っている。「なぜ」を5回繰り返せとはよく聞くが、それよりさらにシンプルでわかりやすい行動指針が「イエスから始める」のコラムにこめられている。
問われた現時点でわからなくてもできそうになくても、「OKわかった、考えてみよう」と言うだけで、問題が解決に向かうということは、実はよくある。最終的に要望に答えないとしても、きちんと説明と会話をすれば、対立は生まれず、協力関係が生まれる、と本コラムにも書いてある。
つまり対話の中で真のissueを見極め、ありのままの課題を共有し、信頼関係を築くこと。これが大事と。（大きく解釈した。）昨日読んだリーンインにも繋がるな。
88 コードは生涯サポートするつもりで書く
p.177
コードを書くというのは、自分の知識や技術、取り組む姿勢、つまりプロ意識や責任感がどれほどのものか、それを他人がうかがい知るための手がかりを残すということです。コードをみれば、メソッドやクラス、モジュールの設計、コーディングを、担当した人がどのくらい楽しんでいたかもわかります。
前職で私は「この管理画面のソースコードはおばあちゃんちの匂いがする」とか「先輩の書いたコードはなんか見ると背筋が伸びる、冬の日の空気みたいに澄んでる」とかちょっとエンジニアなのにかなり感覚的なことを思ったりしていたのだけど、あながち間違いではない感覚だったなーと。性格でるよね、コードに。
本コラムでは自分の産んだものに責任を持て、のようなメッセージを含んでいて、これは子供を産んでからよりぐぐっと深く突き刺さるようになった。ソフトウェア開発社は自分の生み出したコードベースをmy babyとまさに我が子として扱うことがあるが（どっかの本に書いてあった、、）自分の子に対して、生涯サポートするつもりで向き合うのと、そうでないのとでは、やっぱり長期的な成果に差は出てくると思う。
私は生涯サポートするつもりでありつつも、究極は「子が自立すること」つまり私の手から離れることが最終ゴールだと考えている。なので「私しか仕組みがわからない難解で完璧に動くコード」よりも「私がいなくても誰かから必要な助けを得られるようなわかりやすいコード」を書いていきたいなあ。
名前重要
まつもとゆきひろさんのコラムなので、これはRuby知っている人ならもしかすると一度は目にしたことあるかな。実は本書のコラムはここで読めるので貼っておきます。私の感想はいいのでむしろこっち読んで欲しい。（よかったらアマゾンで買ってね）
p.221
ふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自信も十分理解できていないということなのではないでしょうか。
Rubyって名前が可愛いよね。名前だけで好印象もてるRubyが長く愛されているのは必然なんだろうな。と思えるコラム。
プログラミングにおける命名だけでなく、依頼者と「共通言語」を作るのって本当に大事。時にそれはプロジェクト名だったり、達成目標数値だったり、夜も眠れない問題そのものだったり。プロジェクトを進めていて「なんか話噛み合わないな」という時って共通言語ができていない時だなあと。
名前重要なのは賛成なのだが、これは良い名前の選定方法について語られたコラムではない。私は良い名前選定の方法が知りたいし共通言語を作りたい。今のところの私の解は、「理解に徹する、考えることをやめない、最後は勘」という感じである。全然プラクティスになっていなくて申し訳ない。あーでも「3つくらい案を出してチームに聞く」とかはやるかな。自分のイチオシを決めた上でね。
コツがあるとすれば、命名時に感じる腹落ちしないモヤモヤ感には正直でいる、かな。モヤモヤが残る時は大抵うまくいかない。重要なドメインのコアであれば、ハゲるほど考えるしかない。（あとはよく寝るくらい？。）ハゲなくてすむ方法があれば誰か教えて欲しい。
そんなことを考えながら、読みましたとさ。
@kaori_choでした！
よかったらいいね、フォローいただけると嬉しいです＾＾
Discussion