こんにちは。いっとくです！
皆さんには見ただけで心がもやっとするものってありますか？
僕はあります。たくさんあります。態度には出しませんがたくさんあります。
例えば次の電車を待てば良いのに駆け込み乗車しようとして扉に挟まるノンモラリストとか、飲食店で店員さんに横柄な態度を取るノンモラリストとか、Twitterで知らない人に平気で暴言をぶつけるノンモラリストとか、
あとはソースコード上にある名前だけじゃ中身の予想がつかない謎の変数とか。
モラルの欠如に関しては、もはやその人自体の問題なので放置するしかないわけですが、一番最後の意味不明なコードに関しては僕でも改善の余地があります。
そう、リファクタリングをすれば良いのです！！
プログラムの振る舞いを変えずにコードの中身を書き換えるという、プログラミングを知らないマネージャがトップだったら「うん、でも問題なく動いてるんでしょ？時間がもったいないからそれは今度にしてくれ」と言われ、延びに延びて一生その日が来ないんじゃないかと思うような作業です。
しかしリファクタリングでソースコードのメンテナンスが向上すると、バグの発生を減らしたりパフォーマンスチューニングが行いやすくなるため、後になって知らず知らずのうちにメリットを享受することができるようになります。
すばらしい。やりたい。こういう細かい作業を僕はやりたい！
でも一つ問題があります。
僕みたいなプログラミングの道に入って間もない初心者にとって、リファクタリングとは簡単なものではないのです。
特に構造を丸ごと変えるようなリファクタリングは、どの方法がもっとも最適か判断するのも難しいし、実行にも時間がかかります。
ましてや、冗長化しているコードにデザインパターンを使ってスッキリさせるなんてことになったら、、、
僕の場合、まずデザインパターンについて勉強するところからごにょごにょ…みたいな感じで、超大変です。
いつかできるようにならねばとは思うけど、、、、ね？
時としてリファクタリングは外科手術と例えられることがあり、重症化していればしているほど、ソースコードの変更には痛みを伴います。
しかし、でも行動しない限りは絶対に悪化していくだけなので、何かしないといけない。
ということで小さなリファクタリングから始めよう！
そこで役に立つ考え方が今回紹介する「ボーイスカウト・ルール」！
先日読んだこちらの本の一説でとても感銘を受けたので紹介したいと思います。
学びになることもあれば、今の僕にはちんぷんかんぷんなこともたくさん載っている本でしたが、ロバート・C・マーティンさんのボーイスカウト・ルールは自分がチームビルディングをする立場になった時には是非とも実践していきたい内容でした。
というか、別にメンバーの立場でも実践すると良いことがある思う！
ボーイスカウト・ルールとは
ボーイスカウトというのは、複数人数でのキャンプやハイキングを通じて青少年の人格やリーダーシップなどなどの能力を開発することを目的とした活動のことですが、このボーイスカウトには鉄の掟が存在します。
それが、
「来た時よりも美しく」
というもの。
とんでもなく素晴らしい考えだよね。
自分らが出したゴミを持ち帰るのは当たり前ですが、逆に元からあったゴミまで持ち帰るというのは、人間としてかなり精神的にエネルギーを消耗する行為だと思うんですよ。
それを若い頃に実践するわけですから、人格者が誕生するよなぁというね。
そしてこのボーイスカウト・ルールですが、ソースコード上でも実践できちゃうんじゃないの？？
自分が修正や機能追加を行う際に、少しでも読みやすいコードに変えていけるんじゃないの？
というのが、僕が感銘を受けたボーイスカウト・ルールの概要です。
これ、めっちゃ良い考えだと思うんですよね。
もちろん無秩序にやると大変なことになりそうなニオイがプンプンするのですが、気をつけるべきことさえ気をつけたらすごく良いことが起きまくると思う。
この「プログラマが知るべき97のこと」では、97つ（日本版は107つ）ものプログラマの考えが紹介されていることもあって、一つ一つはだいたい２ページにギュッとまとめられているため、深いところまでは触れられていません。
そこで、自分なりにボーイスカウト・ルールでどんな部分を改善していけば良いのかとか、実践するに当たって気をつけたほうが良いんじゃないかと思う点について深掘りしていこうと思います。
ボーイスカウト・ルールでやるべき作業
まずはやるべき作業についてですが、本格的なリファクタリングを始めてしまうと、自分がやっている本来の案件の納期とかを圧迫することになると思うので、ご利用は計画的にというのが大前提です。
そこまで大規模なリファクタリングであれば、もはやリファクタリング自体を案件にしてしまうほうが色々と良さそうですしね。
なので、このボーイスカウト・ルールで行う作業というのはもっと小さなリファクタリングをやっていくべきでしょう。
パッと思いつくものだと、
- 変数やメソッド名を適切なものに変える
- 条件分岐やループ処理のネストを浅くする
- 使わなくなっているのに消されていない処理をなくす（コメントアウトも）
- インデントを整える
- 長いメソッドを細かい機能に分割する
- メソッドを適切な場所に引っ越す
などなどその辺でしょうか。
僕のプログラミングレベルが高ければ、もっとできることも増えるでしょうけど、デザインパターンを使って書き換えたりとか全くわかりません！！
でも、確実にわかるのは今いじっているコードに混沌が訪れる気配があるのに見て見ぬ振りをしていると、どんどん重症化したコードになっていくということ！
重症化が進むと、普段の業務やリファクタが超大変になります。
普段から無駄を削いで、わかりやすいコードに変更していかないと、いざ本格的なリファクタリングをするって時に可読性が低すぎてにっちもさっちもいかなくなりそうですね。
ボーイスカウト・ルールを導入するメリット
僕はこの本を読んでから、ボーイスカウト・ルールを意識して仕事をするようにしています。
やってみてから初めて見えてきたメリットとかもあるので、よかった部分を紹介したいと思います。
もちろんソースコードがよくなる
当たり前なのですが、ソースコードが少しずつですが綺麗になります。
僕が現在携わっているプロジェクトは割とソースコードがカオス化していて、何を表しているかよくわからない変数、死ぬほど長いメソッド、受け取った値によって全然振る舞いが異なるように条件分岐が走るメソッド、人によって異なる空白の開け方、、、などなどあげればキリがありません。
空白とかインデントの開け方くらいはエディタの機能を使えば自動でやってくれるので、徹底してその機能に依存しちゃえば良いのに…
こうなってしまった原因はそのルーツと歴史にあります。
実はこのプロジェクト、ソースコードを一から作ったわけではなく社内の別サービスのコードを元に作ったうえに、今までいろんな人が携わってきたという歴史があるんですね。
そのため、いろんな人のこだわりがファイルごとに垣間みえてきます。笑
ボーイスカウト・ルールを取り柄れた作業というのは、そんな歴史を少しずつ塗り替えていく作業です。もはや歴史との戦い。
最初のうちは、全然効果を実感しないのですが、何ヶ月か続けているうちにふと開いたコードが読みやくなっているのを実感します。
ソースが読みやすくなると普段の機能追加やバグ改修の作業スピードも上がるので、生産性も上がっていきます。
これはやる前から想像のつくメリットですね。
作業に主体性が生まれる
こちらのメリットは実際にやってみるまで気がつかなかったのですが、普段の業務に主体性が生まれるので、作業者のモチベーションがすごく上がります。
僕の現在の仕事内容をもう少し具体的に話すと、求人サイトの運営をしています。
基本的な業務内容は機能追加とバグ改修の2点。
案件が発生すると、プロジェクトのリーダーがメンバーに案件として割り振って、各々その作業を進めていくという形の業務スタイルです。
初めのうちはソースコードにも作業環境にも慣れていないのでそこそこ刺激的なのですが、慣れてくると見たことあるソースコードを直すだけのつまらない作業になり、めちゃくちゃ眠くなってくるんですよ！
あまりにも眠すぎるので、考え事をしているふりをしながら、脳の機能を止めることもあります。
しかしこのボーイスカウト・ルールを使って、今いじっているクラスやメソッドの中に「何か改善できる点はないかな！？」という意識で作業に取り組むようにすると、やらされていた作業が自分でやる作業に変わるのでめちゃくちゃ集中力が増して、眠気が吹き飛びます。
そんなわけで、僕はこのボーイスカウト・ルールはやる気に溢れたチームを作るための習慣としても結構良いんじゃないかなと感じ始めているわけです。
気をつけないといけない点
何かと良さげなボーイススカウト・ルールですが、気をつけないといけない点もあります。
それは、「何が正しいかをチームで共有する」ということです。
プログラミングってかなり創造的な仕事だと思うんですよ。
実装するべき機能は決まっているのに、そこにたどり着くまでの方法は数え切れないくらいのパターンがあります。むしろほぼ無限。
そのため、メンバー全員がボーイスカウト・ルールを発動させて小さなリファクタリングを行う時、それぞれの理想の形に大きな差があるとうまく回りません。
別の人が直したコードを、後日別の人がまた直してみたいなループを繰り返すことにもなりかねません。
なので、まず諸々のコーディング規約と理想とするソースコードのイメージをチーム内で共有する必要があると思うんです。
そうすることによって、ソースコードはよりスピーディに改善されていくのではないでしょうか！？
ただ、必然的に変更する範囲が広くなってしまうので、gitでマージする際にコンフリクトが起きやすくなるかもしれません。
そこらへんはチーム内でうまいこと変更範囲を決めるとか工夫をこらすとより良いかもしれませんね。
スキルの低い人のボーイスカウトは迷惑？
プログラミングに関わらず、どんな仕事でもそうだと思うのですが、スキルが低い人の生産物というのは熟練者のものよりも品質が低いものになる傾向があります。
それが原因で仕事がうまくいかなくなることもあり、アメリカのIT系の企業で人手不足の状態からスキルの低いエンジニアをリストラすることによって、結果的に人で不足を解消したという事例もあるくらいです。
この例における人手不足の原因は熟練プログラマが、尻拭いに大きなリソースを割いていたためです。
ということはスキルが低い人が自発的にリファクタリングをしても、熟練プログラマの尻拭い作業を増やすだけなので、言われたことだけをやる方がいいのでは…？
答えは現場によっても異なると思いますが、僕はやるべきだと思います。
ソースコード上にウンコのような記述を見かけて「誰だこんなコードを書いたやつは！」と思い、プンスカしながらgitの履歴を見たら自分だったなんてことはエンジニアあるあるですよね。
なので、スキルがない状態でリファクタリングをしても、逆にコードが汚くなって迷惑をかけてしまうというのは間違いではないかもしれません。
というか僕はボーイスカウト・ルールを実践している今、まさしくこう思っています。笑
でもそこで挑戦をやめてしまったら、成長するのが遅くなってしまうと思うんです。
例えばボーイスカウト・ルール通りに改善をしてみたとしましょう。
もしそれが良いコードであれば何も言われないだろうし、悪いコードであれば突き返されると思います。
つまり、自分でリファクタリングをしたことの良し悪しが直接的にしろ間接的にしろ何かしらのフィードバックがあるため、自分の成長の糧にすることができるわけですよ。
しかも自分から主体的にやることなので、自分ごとで捉えることができ、受動的にやる作業と比べてもすごく学びが多いと感じます。
自分にスキルがないことを自覚していれば、どうすれば綺麗なコードがかけるようになるかという部分のアンテナも高くなります。
スキルの低いエンジニアを足切りするんじゃなくて、こうやって自発的に動いてもらい、適切なフィードバックを与える事で成長してもらい、現場のレベルを底上げする方が長期的に見たら生産的なのではないでしょうか！？
なので、もし僕がプロダクトマネージャーだったら、とにかくこのボーイスカウト・ルールを恐れずにやってほしいと言って実践したい。
まぁ下っ端なのでしばらくは関係ないんですけどねー！！
ということでボーイスカウト・ルールかなりおすすめですよってお話でした。
ぜひチームビルディングを考える際の一つの参考にしていただければ幸いです。
チームのレベル感によってはよりカオスの世界に突入する危険性もありますが、そうならないよう工夫して解決いくこともまた一つの成長なんだと思います。
もし、個人的にボーイスカウト・ルールを取り入れてみたいけど勝手にやるのはちょっと…という方は、チームのリーダーに「こういう考え方があるのですが、取り入れてみて良いですか？でもスキルがまだないので、あまりよくないことをしていたらフィードバックをいただければと思います」というような相談を事前に投げておくと、心置きなく実践することができそうですね。
世の中根回しが大事ってことです。
勝手に色々変更して上司にブチ切れられたら、上司にとっても自分にとってもストレスにしかなりませんから。
今回はボーイスカウト・ルールだけ取り上げましたが、本書には色々な考え方が掲載されています。
ぶっちゃけ今の僕のスキルだと理解できない内容とかもゴッソリあったので、定期的に読み返してく価値がありそうな感じでした。
それでは、今回はこの辺で！さいなら！
コメント