SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。 でもテーマが定まってない感がすごい。

『ベタープログラマ』を読んだので、ランダムに質問に答える(読後所感)

『ベタープログラマ』、読みました。

honto.jp

Twitterで、時々タイムラインに流れてくるので、気になって購入しました。

ざっくり紹介

自分なりの感想となります。

『達人プログラマー』という本があります。
その本を現代的な視点で書いたもの、と思うとよいです。
特に、コードに対する言及は、同意できるものや、耳が痛くなるような指摘等あるので、何かしら得るものはあると思います。
特にテストに関しては、何度も大事だと言われます。*1

特に、第三部「個人的なこと」は、とても熱い内容でした。
ここだけで熱弁したいぐらいです。
学びを愛して生きるという表題*2がとても良いし、内容も最高です。

…本題からずれそうです。

この記事で何を書くのか

本書には、38の章があり、それぞれ章末に質問があります。
それに答えていきます。

とはいえ、全部で183問*3あり、全部はしんどいので、ランダムに5問選びます。

ちゃちゃっとプログラムを書いて、質問選択!

f:id:hiroronn:20180213074957p:plain

選ばれた質問に、自分なりの回答を考えます。

16章 単純に保つ

質問

4.コードの単純さを維持したままコードを最適化することは可能でしょうか。

ここでいう最適化とは、

アルゴリズムを壊して、特定の条件下の限られたコンピュータ上で速く実行させること

を指します。

回答

個人的には、可能ではあると思っています。
今、目の前に見えている単純さは崩壊させるかもしれませんが、別の視点で単純化してしまうと良い気がします。

最適化のために壊すアルゴリズムを抽出して、そこを抽象化。その後最適化、という手順で行えば、単純さは保たれます。
DBアクセスであれば、直接エンティティにアクセスするのを止めて、リポジトリパターンをうまく適用する等です。

機械学習みたいに、データを切り捨てたり、計算を変えたり、という場合は、単純さの維持は難しいかもしれません。*4

19章 コードを再利用するケース

質問

4.ウェブからのコードを追加するときは、その実装元を示すコメントを書くべきですか。その理由は何ですか。

回答

レビューアーとしての視点で言います。付けてほしいです。

本書でも、『達人プログラマー』でも出てきますが、初学者は、状況に応じて適切な行動ができない、と言われます。
ウェブにあるコードをそのまま使うのは、理解していないから行う行為だと、推測されます。

なので、そのソースを引用した理由を、レビュー時に聞くのが正しいと思われます。
引用元を見ながら、そのコピー行為が正しいのか、内容を理解しているのか、という部分を実装者とレビューアーが一緒に考えることで、

  • 初学者の勉強になる
  • レビューにより不可解なソースの混入を避けられる

という、二つの効果が得られるものと思います。

よって、実装元は付けてもらったほうが良いです。
ただし、全てのプログラマーにルールを強制するのは止めたほうが賢明です。*5

24章 学びを愛して生きる

まさか、この章が選ばれるとは…嬉しい限りです。

質問

5.学んでから仕事をしましたか。それとも、仕事をしながら学びましたか。どちらが効果的だと思いますか。

回答

実体験を言うと、私は学んでから仕事をしました。
研修でC#を学び、そのままC#を使う部署に配属されたので、学んだ後に仕事をしたことになります。

しかし、実際には学んだ内容では全く足りず、追加でアプリ作ったり*6、新たに学習したり、という状態でした。

C#PythonSQLに関しては、一通り学んでから仕事をやっており、それ以外はいきなり仕事から入っているので、両方体験したことになります。

さて、どちらが効果的だと思いますかということですが…
私は「学んでから仕事をする」が良いと思います。

仕事という場だったら、新たなスキルを要求されるのは会社都合ですので、そもそも会社がその技能を学ばせるべきだと思います。
仕事から学べることは多いですが、やはり基礎があったうえで学ぶものです。
その基礎ぐらいは学んでから、仕事に入ったほうが、学びも大きくなると、私は考えています。

最も避けるべきは、仕事に最適化された知識を持つことだと思います。
他の仕事に入ったら使えない技能を積むのは、開発者にとって不幸です。

21章 ゴールポストを抜ける

ここでいうゴールポストとは、QA部門のテストのことです。これを抜けるとリリースだ!という意味合いのようです。

質問

4.ソフトウェアの「品質」に責任を持っている人は誰ですか。うまく行かなかったときに「非難」されるのは誰ですか。それは健全ですか。

回答

今の会社では、ちょっと答えづらいので、前の会社の内容です。

  • ソフトウェアの「品質」に責任を持っている人
    プロジェクトリーダー、設計リーダーもしくは上司(部門長)

  • うまく行かなかったときに「非難」されるのは誰
    全員

はい。さて、健全でしょうか?
すみません、健全かどうかは分かりません。

個人的な願望を言うなら、逆がいいです。
品質は関係者全員で担保するものであり、うまくいかなかった時には上司がかぶってほしいです。
というか、品質を大事にする方針を立て、チームを回すのはリーダーの責任だし、全員で品質を高めよう!とするのも、リーダーがやったほうが良いです。

リーダーの責任が重いですね、はい。

32章 完了したときが完了

質問

4.現在の開発プロセスは、作業を分解して見積もる方法をどのように決めていますか。その方法は十分ですか。

回答

です。残念ながら。

そもそも、作業分解が各開発者に任せられている状態で、力量の差がはっきりと出ています。
私は「タスク分解が上手」と言われますが、タスク時間や頭の切り替え頻度等を考慮して決めているので、一概にこう、とも言えません。

開発プロセスとしてみたら、不十分です。

タスク時間管理のツールは、チーム全体で入れており、それは日々の進捗を記載します。
それとは別に、私はカンバンツール*7を自分で使っていて、そこにはどんなに長くても3時間程度で終わる粒度にするように、タスク分解しています。

まずは一人アジャイル。『カイゼン・ジャーニー』に書いてあることを、少しずつ実践しているような状態です。

おわりに

なんか、所感としてどうなんだ、という気持ちはありますが。
『ベタープログラマ』、個人的にはぜひ読んでほしい一冊です。

学ぶことがあるならよし、学ぶことが無く、こんなの当たり前と思うなら、それもよし。

章ごとに勉強会を開く用途にも使えるように思います。

学ぶことがすごく多い、とまでは言えませんでしたが、特に第三部、ここは最高に良いです。
普段から勉強している人にとっては、大変勇気づけられる部分です。

ぜひ、手に取ってみてください。


*1:大変、耳が痛いです

*2:第24章

*3:自分で数えた結果

*4:しかし、現在機械学習で使えるライブラリ等は、驚くほど単純に使える。相当努力されたのだろう、と思ったりする

*5:無用なルールの押し付けは、生産性の低下につながる

*6:仕事の便利ツール程度のもの

*7:KanbanFlowというツール。いずれブログに書きたい