2019/11/06 このエントリーをはてなブックマークに追加 はてなブックマーク - 質でもスピードでもなく、安全を求めるプログラミングがある

質でもスピードでもなく、安全を求めるプログラミングがある

カテゴリ: ,


ただのスライドを読んでの感想文です。
大仰なタイトルを思いついてしまってごめんなさい。



質とスピード / Quality and Speed - https://speakerdeck.com/twada/quality-and-speed

質とスピードのスライド、素晴らしいと思ったのだが、
その2軸だけでもないなと思ったり。

それがなんなのか。自分の頭の中で考えてみると、
身の安全を守るプログラミングかなと思う。
保険というか保守的というか保身というか。
麻雀でいうところの安牌を切るタイミングっていうんでしょうか。
スピードや質よりも保守的アプローチをプログラマーが選ぶタイミングはあるように思う。


ちょっと発表スライドの趣旨からは横道に反れる主張な気もするけど書いてみます。

  • バグ
  • 外部のお客さん、エンドユーザー
  • 上司
  • チームメンバー

など。


本番稼働していて慎重な変更を入れたい。
あるいは、自分の裁量がどこまであるか分からない(=裁量が無いと思っている)場合。
コード変更に対して合意形成するのが非常に高コストである場合。

不協和を避けるために、プログラマーは保守的行動をとりがちな気がしている。
なんというか、硬直したプロジェクトはどうしてもそうなりやすい。


プログラマーが

  • とにかく目立つ大きな変更をしない
  • 変更箇所を最小限に抑える
  • 最小部分をテストする
  • リファクタリングをしない(もしくはそういう選択肢がない)

など。


こうなると、質とかスピードとかいう話ではない。
定速・定品質って感じがする。

ただ、これを良しとする文化、チーム、プロダクトもあるといえばあるだろうと思う。
特にリリース後の保守・運用を含むフェーズになると特に。


常に保守的にプログラミングをするとは限らない。

時には、リファクタリング提案したり、改善系のコミットしたりもあるかもしれない。

ただ、安全な選択肢をとることは誰でもあることだと思う。
したがって保守的アプローチが悪いとも僕は思わない。
過剰な保身でコードが捻れることは避けたいけど。


一定速度/一定品質を続け過ぎてしまうと、
質もスピードも上がらなそうではある。

むしろ、安全択を取り続けることは、
いわゆる品質を犠牲にした実装ほどではないけど
スピードは緩やかに落ちていきそうにも思う。


あのスライドで言えば、今ここに書いている保守的アプローチは
スピードを優先して品質を下げた軽度の事例なのかもしれない。

でも、そのあたりやっぱ難しい。どうしようもないタイミングがある気がしている。

意図的に品質を下げて(悪くして)リリースを急いだものは、
明らかに良くないのだけど

保守的アプローチというのはそこまで悪いものではない、というか仕方ない時ないかなぁ？と思っている。

という意味で、結構パワーのあるスライドなので
それに反したら悪、それ以外は正義みたいなものと捉えると危ないなぁとかも思う(ただ良い資料とも思う。。)。

もちろん、スライドで善悪をつける趣旨は無いように見えますし、
横道に反れすぎ感は否めません。

songmuさんがツイートしていたところあたりに僕個人の気持ちは近そうかも


過渡期のシステムをどう取り扱うかというと
保守的アプローチと、質の向上アプローチを織り交ぜてスピードアップまでこぎつければ望ましいだろうなぁ。


人月の神話だったと思うけど、システムは作り始めた一番最初が美しいみたいな話がある。
理想を言えば、作った瞬間から質の高いものを積み重ねていくのが良いのは明らかですが。
それが出来るプログラマーが優秀だと思うし、
自分もそう在りたいというかそうでなければみたいなところもある。
それが質とスピードのスライドの本筋だと思っている(のでこの文章は野暮ではある)。



質は上げていかないといけないとして、
何がフィットするかも考えないとなぁとも思ったりした。


  • スピード云々の前に、既存のものの品質がより良くなるのは良いこと
  • 結果としてスピードが上がれば良いよね

って前提で

  • 質とは一体何か、定量的か、それはチーム内で合意が取れるか
  • 合意を取らないでも自明な部分の向上か
  • スピードを上げるためにどう質を上げるか
  • チームメンバーがそれによってスピードは本当に上がるか(or 上がる可能性がある変更か)

とか色々。


ryushiさんのツイートも興味深かった。

質とスピードの2軸だけではないコミットもたくさんあるよなぁというボンヤリした感想でした。
質という指標もスピードという指標もないタイミングがある。かなぁと。
質を高めるためのコミットがしやすいコードベース、CI/CD環境、チーム、製品、お客さんになっていればスピードを増すことが出来るかな。

そういう環境を作るためには
有効なテストを増やしていけばリファクタリングとかで質に転じることもあるかなぁとか思ったり
(いたずらにテストを増やすこともあまり好きではないけど。感覚としては、これ→ テストを書きたくない話 / I don't want to write tests)。
またはボーイスカウトルールとかですかね。
要はバランスおじさんぽい文章になっており辛い。


t_wadaさんのスライドは原則の話をしていて、僕は詳細の話をほじくっている感じもしてなんだか微妙な気もしてきた。
というのを、プログラマーテストの原則 by Kent Beckを読んで思ったりした。
https://medium.com/waicrew/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%8E%9F%E5%89%87-by-kent-beck-eac2d10c8f97



Posted by at
このエントリーをはてなブックマークに追加
カテゴリ: ,

0 件のコメント:

コメントを投稿

GA