ボーイスカウト・ルールを現実的に実現するためには?

2020/07/06 2020/07/06

プログラマが知るべき97のこと

こんにちは。のんです。

本日はプログラマが知るべき97のことを読んでいてこれ「いいな」と思った箇所について書いてみようと思います。

こちらの書籍はとても有名なので、既読の方もいらっしゃるかもしれません。
そういう方は復習というか、内容を思い出したり、私の意見と違うところや共感できるところを探していただければ幸いです。

ボーイスカウト・ルールってなに？

プログラマが知るべき97のことにはこう書いています。

ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。

最近、私の町ではボーイスカウトの姿を見なくなってしまいました。私が子供の頃は友達がボーイスカウトしていたこともあって結構身近な存在だったのですが、現在はどうなんでしょうか？

しかし、これまでの人生このような光景は見たことあるかもしれません。ボーイスカウトに限らず、小学校で美化活動として昼過ぎくらいに町内清掃している姿くらいは見かけているはずです。

「この考えをプログラミングにも取り入れようよ」という考えがボーイスカウト・ルールです。

結構簡単そうじゃない？いえいえ、かなり難しいはずです。

コードに散々しているゴミコードをただ修正変更するのは結構簡単と思えるかもしれませんが、私は難しいと感じます。その理由を１つずつ挙げると、

バグ修正は気軽にできない
すでに正常動作しているコードを修正することへの心理的ハードルが高い
納期に追われているなど、時間的余裕が無い
コミットをきれいに保ちたい。（ブランチ作成や切り替え作業が面倒くさい）

すぐに思いつくのは以上のような理由でしょうか？他にも色々あるかもしれませんが、多分共感していただけると思います。

バグ修正は気軽にできない

バグ修正は気軽にできません。影響範囲の調査や、バグを修正したことによるデグレーションを考慮しなければならなくて、とても工数がかかります。ゴミ拾いと同じ感覚で修正していたらいつの間にかscrap & buildしていたとかなりかねません。（時間的余裕と、影響範囲潰しができればとてもGJ👍ですが！！）

すでに動作しているコードを修正することへの心理的ハードルが高い

四則演算の効率化や簡単化など、ちょっとした処理の修正に対して変更を行うことを想定しましょう。すでに正常に動作しているコードを修正すると考えるだけで不安になります。心の中で、（うーん……次のマイナーバージョンでするか）みたいになるのは火を見るより明らかです。

納期に追われているなど、時間的余裕が無い。

これは簡単ですね。そもそもその程度の修正をする時間すら存在しない時です。

コミットをきれいに保ちたい

一般的にGitを用いて開発をする場合、ブランチは機能単位に切られ、マージできるレベルでコミットされるはずです。あるAという機能を作成しているときに、ボーイスカウト・ルールに則って修正を行うと、A機能のためのブランチにBの修正が混じることになります。これを嫌がる人や、是としないチームはたくさんあるはず（というか、そういうルールが推奨されているはず）です。

そういうルールがある中でボーイスカウト・ルールを適用しようと思うと、（Aという機能を作るという別の仕事をしているにも関わらず、）ブランチを新しく作成したり、マネージャーへ連絡したりしなければなりません。

それが面倒臭いという人は必ずいるはずです。（私もそうでした。）

こういった「課題をクリアする」というより、ボーイスカウト・ルールを適用しやすい環境を作る方がとても簡単です。上記の課題を例にボーイスカウト・ルールを適用しやすい環境を考えてみました。

ボーイスカウト・ルールのハードルを下げる

見かけたバグはすぐ直す。このルールをそう受け取る方もいるかも知れませんし、そう思っていない方も、義務感から修正への執念を持っているかもしれません。私の知り合いには、あまりにひどいコードに遭遇し、もはやこの考えが強迫観念となっている方がいました。

もっと気軽に考えましょう。以下のポイントを押さえ、継続すればうまくいくはずです。

変数名や関数名本当に軽微なポイントにのみ注目する
ノルマなどは当然設けない
修正というより整頓と考える（後述）
- 関連して、一気に修正 / 整頓しない

修正というより整頓と考える

例えば、引き継いだプロジェクトで下記のようなコードに出会ったとしましょう。自分はある程度経験を積んで、よくわからない処理を調査していました。数十分ほどかけて、そのロジックを解き明かしたとしましょう。

copied.<?php

class DustSample
{
    /**
     * @var string
     */
    private $dust;

    /**
     * @param string $dust
     */
    public function __construct(string $dust)
    {
        $this->dust = $dust;
    }

    public function unknown()
    {
        // 難解なコードで自分が頑張って読み解いた重要な処理
    }
}

この時、unknowメソッドをボーイスカウト・ルールに則り修正するのではなく、コメントを書くなどして、わかりやすくしたり、一部privateメソッドなどで切り分けられそうなものを切っておきましょう。だから修正より整頓と考えるわけです。

copied.<?php

class DustSample
{
    /**
     * @var string
     */
    private $dust;

    /**
     * @param string $dust
     */
    public function __construct(string $dust)
    {
        $this->dust = $dust;
    }

    /**
     * 〇〇を✕✕して△する処理
     */
    public function unknown()
    {
        // 難解なコードで自分が頑張って読み解いた重要な処理
    }

    /**
     * 〇〇を✕✕する処理
     */
    private function unknown_parts()
    {
        // 難解なコードの一部、でも、処理を切り分けることでどんな処理をするのかが少しわかりやすくなっている
    }
}

少しはハードルが下がるはずです。少なくともコメントの追加で動作が変わるというのは早々ないでしょう。

これまでの慣習をできるだけ無視し、オブジェクト単位で、特に依存を無くす実装にする

PHPだとよくあるのは、全部Controllerに書かれていて、しかもそれが他の処理に密結合を起こしている場合です。

そうなってくると、ボーイスカウト・ルールどころではありません。
ちょっとした改修タスクを作成し、その部分だけでもオブジェクト化しておきましょう。

クリーンアーキテクチャに基づいたDDDがオススメではありますが、そうでなくても、振る舞いを閉じ込めたEntityのみを採用するだけにとどめたり、ValueObjectだけでも採用したりすることで、ボーイスカウト・ルールをしやすいコードへと変身させるのです！

わかりやすい、あるいは依存していないコードに対してはとても修正をかけやすいです。心理的ハードルが下がるはずです。Interfaceで抽象クラスを作成したり、ControllerではなくActionでリクエストを捌いてみたり、とにかく小さく処理を作成するように心がけると、みんなは自然とゴミを拾ってくれます。

ここでも大事なのはストレスのかからないレベルで導入することです。隅っこの方のディレクトリにModels/Entityとディレクトリを切り、その中に必要な振る舞いと値を入れるだけとかでもいいです👍

テストコードを整備する

ここまでで気づいている方は多いでしょう。

テストコード、これがあればストレスとはおさらばですね👍

なんちゃってリファクタリングではなく、本格的なリファクタリングができるようになります。

https://www.amazon.co.jp/Java言語で学ぶリファクタリング入門-結城-浩/dp/4797337990

その時はこちらの書籍を読むといいかもしれません。

TDD(テスト駆動開発)と勘違いする方がいますがここでは関係ありません。

リファクタリングについては、また違う記事でしましょう。

やはり一番の処方箋は開発者の心理的ハードル下げることでしょうか。

修正してくれたことを褒めたり、感謝する文化を作ったり
その修正を勤務評価にフィードバックしたり

ポジティブな理由ですすめることができたら間違い探しをしているみたいに楽しいかもしれません

ボーイスカウト・ルールを適用するにあたっての注意点

一応デメリットとしてあげられるのは、計画的 / 継続的にやりましょうとういことです。

計画的に進めなければ、プロジェクトの方針と食い違う可能性が出てきます。継続的に進めなければ、中途半端になってしまいます。

見かけたら100%の修正をする必要はありませんが、その分続けなければならないことは感覚的にわかりますね。

最後に

ボーイスカウト・ルール。この考えとても好きです。年末に大掃除するとき、慌てない家庭はこのルールをキチンと守っているのでしょう。あるいは夏休み宿題で苦労することはないでしょう。

継続的インテグレーションが完全に普及した今、コードを作成したらそれで終わりという文化もなくなりました。　コードのメンテナンスをしっかりすることで、バグの早期発見や仕様の理解もできるでしょう。

私も完全に出来ているわけではないので、今後も頑張りたいです。

プログラマが知るべき97のことについての記事はまた書くかもしれません。

そのときはよしなに。