『ベタープログラマ』、読みました。
Twitterで、時々タイムラインに流れてくるので、気になって購入しました。
ざっくり紹介
自分なりの感想となります。
『達人プログラマー』という本があります。
その本を現代的な視点で書いたもの、と思うとよいです。
特に、コードに対する言及は、同意できるものや、耳が痛くなるような指摘等あるので、何かしら得るものはあると思います。
特にテストに関しては、何度も大事だと言われます。*1
特に、第三部「個人的なこと」は、とても熱い内容でした。
ここだけで熱弁したいぐらいです。
学びを愛して生きるという表題*2がとても良いし、内容も最高です。
…本題からずれそうです。
この記事で何を書くのか
本書には、38の章があり、それぞれ章末に質問があります。
それに答えていきます。
とはいえ、全部で183問*3あり、全部はしんどいので、ランダムに5問選びます。
ちゃちゃっとプログラムを書いて、質問選択！
選ばれた質問に、自分なりの回答を考えます。
16章 単純に保つ
質問
4.コードの単純さを維持したままコードを最適化することは可能でしょうか。
ここでいう最適化とは、
アルゴリズムを壊して、特定の条件下の限られたコンピュータ上で速く実行させること
を指します。
回答
個人的には、可能ではあると思っています。
今、目の前に見えている単純さは崩壊させるかもしれませんが、別の視点で単純化してしまうと良い気がします。
最適化のために壊すアルゴリズムを抽出して、そこを抽象化。その後最適化、という手順で行えば、単純さは保たれます。
DBアクセスであれば、直接エンティティにアクセスするのを止めて、リポジトリパターンをうまく適用する等です。
機械学習みたいに、データを切り捨てたり、計算を変えたり、という場合は、単純さの維持は難しいかもしれません。*4
19章 コードを再利用するケース
質問
4.ウェブからのコードを追加するときは、その実装元を示すコメントを書くべきですか。その理由は何ですか。
回答
レビューアーとしての視点で言います。付けてほしいです。
本書でも、『達人プログラマー』でも出てきますが、初学者は、状況に応じて適切な行動ができない、と言われます。
ウェブにあるコードをそのまま使うのは、理解していないから行う行為だと、推測されます。
なので、そのソースを引用した理由を、レビュー時に聞くのが正しいと思われます。
引用元を見ながら、そのコピー行為が正しいのか、内容を理解しているのか、という部分を実装者とレビューアーが一緒に考えることで、
- 初学者の勉強になる
- レビューにより不可解なソースの混入を避けられる
という、二つの効果が得られるものと思います。
よって、実装元は付けてもらったほうが良いです。
ただし、全てのプログラマーにルールを強制するのは止めたほうが賢明です。*5
24章 学びを愛して生きる
まさか、この章が選ばれるとは…嬉しい限りです。
質問
5.学んでから仕事をしましたか。それとも、仕事をしながら学びましたか。どちらが効果的だと思いますか。
回答
実体験を言うと、私は学んでから仕事をしました。
研修でC#を学び、そのままC#を使う部署に配属されたので、学んだ後に仕事をしたことになります。
しかし、実際には学んだ内容では全く足りず、追加でアプリ作ったり*6、新たに学習したり、という状態でした。
C#、Python、SQLに関しては、一通り学んでから仕事をやっており、それ以外はいきなり仕事から入っているので、両方体験したことになります。
さて、どちらが効果的だと思いますかということですが…
私は「学んでから仕事をする」が良いと思います。
仕事という場だったら、新たなスキルを要求されるのは会社都合ですので、そもそも会社がその技能を学ばせるべきだと思います。
仕事から学べることは多いですが、やはり基礎があったうえで学ぶものです。
その基礎ぐらいは学んでから、仕事に入ったほうが、学びも大きくなると、私は考えています。
最も避けるべきは、仕事に最適化された知識を持つことだと思います。
他の仕事に入ったら使えない技能を積むのは、開発者にとって不幸です。
21章 ゴールポストを抜ける
ここでいうゴールポストとは、QA部門のテストのことです。これを抜けるとリリースだ！という意味合いのようです。
質問
4.ソフトウェアの「品質」に責任を持っている人は誰ですか。うまく行かなかったときに「非難」されるのは誰ですか。それは健全ですか。
回答
今の会社では、ちょっと答えづらいので、前の会社の内容です。
ソフトウェアの「品質」に責任を持っている人
プロジェクトリーダー、設計リーダーもしくは上司（部門長）うまく行かなかったときに「非難」されるのは誰
全員
はい。さて、健全でしょうか？
すみません、健全かどうかは分かりません。
個人的な願望を言うなら、逆がいいです。
品質は関係者全員で担保するものであり、うまくいかなかった時には上司がかぶってほしいです。
というか、品質を大事にする方針を立て、チームを回すのはリーダーの責任だし、全員で品質を高めよう！とするのも、リーダーがやったほうが良いです。
リーダーの責任が重いですね、はい。
32章 完了したときが完了
質問
4.現在の開発プロセスは、作業を分解して見積もる方法をどのように決めていますか。その方法は十分ですか。
回答
勘です。残念ながら。
そもそも、作業分解が各開発者に任せられている状態で、力量の差がはっきりと出ています。
私は「タスク分解が上手」と言われますが、タスク時間や頭の切り替え頻度等を考慮して決めているので、一概にこう、とも言えません。
開発プロセスとしてみたら、不十分です。
タスク時間管理のツールは、チーム全体で入れており、それは日々の進捗を記載します。
それとは別に、私はカンバンツール*7を自分で使っていて、そこにはどんなに長くても３時間程度で終わる粒度にするように、タスク分解しています。
まずは一人アジャイル。『カイゼン・ジャーニー』に書いてあることを、少しずつ実践しているような状態です。
おわりに
なんか、所感としてどうなんだ、という気持ちはありますが。
『ベタープログラマ』、個人的にはぜひ読んでほしい一冊です。
学ぶことがあるならよし、学ぶことが無く、こんなの当たり前と思うなら、それもよし。
章ごとに勉強会を開く用途にも使えるように思います。
学ぶことがすごく多い、とまでは言えませんでしたが、特に第三部、ここは最高に良いです。
普段から勉強している人にとっては、大変勇気づけられる部分です。
ぜひ、手に取ってみてください。
