自分の知見をどうやれば伝えられるか？に悩んでいる話

最近、Zenn が素晴らしいので、技術系の記事を Zenn で書くようにしています。

erukiti

で、さっきリファクタリングについての記事を公開したところです

リファクタリング

この記事を書いた理由は、

この記事はプログラミングの世界をほんの少しよくするための記事です。

リファクタリングという単語を聞いたときに、「いっぱい時間をとってやる作業」「気合いを入れてやる改善作業」「大変なもの」「やりたいんだけど、上司が許してくれない」というイメージを持っている人が多いかもしれません。そのとき想像しているものは決してリファクタリングではありません。

リファクタリングとは「外から見た振る舞い（GUIなら画面、関数なら入出力、副作用）を変更せずに、コードをほんの少し改善する行為」のことです。

ほとんどの人が想像するものは「リデザイン」とか「リアーキテクティング」と呼ぶべきもの、つまり「再設計」になっています。

この記事を読んで、覚えておいてほしいことは「リファクタリングは、安全に少しずつ書き換える」ための技術なので、「いっぱい時間をとってやる作業」ではありませんし、「気合いを入れてやる改善作業」でも「大変なもの」でもありませんし、「やりたいんだけど、上司が許してくれない」ものでもありません（本来のリファクタリングすら上司の許可がないとできないかもしれませんが、その場合はもはや組織論なので、この記事の範疇ではありません）。

というものでした。

つまり、記事を書いたモチベーションは「みんなリファクタリングを大げさに考えすぎでは？」「小さく改善しようよ」というものです。

僕の悩み

じつはこの記事はもともと、ブラッシュアップしてから Zenn に投稿する事を前提に書いた社内記事です。ただそれを読んで、リファクタリングのやり方そのものが分からないという話が出てきました。

実際のところ、僕としてはその社内記事で「小さく繰り返すんやで」という考えや、ちょっとしたサンプルを示してから、あとは Martin Fowler のリファクタリング本を読んで練習してくれと言いたいところなのですが、どうもそれだけだと道筋としては足りないという話になりました。

まぁ、社内記事の方ではプロダクションコードで実際にどうやればいいのか、実例を示すのが一番だ！という話に落ち着いたんですが、知見を伝えるとき、そういったやり方しかないのかなーというのが、悩んでいることです。

それとは別件でパフォーマンスチューニングをしました。より正確に言うと、利用している npm パッケージがアップデートしたときに CSS の特性が変わった事で、急激に処理が重くなって、しかも、特定のケースでしか症状がでないものだったため発覚が遅れて「何が原因か分からん」という状況で、その原因を特定して、hotfix を出すというものでした。

これも、僕が実際にやったことは、基本に忠実にやっただけです。

ところが、この知見を横展開したいねと CTO と相談していて、結論として「経験値だよなぁ」という身も蓋も希望もないものになってしまって、いやなんかあるだろ！このままだと教育の敗北だろ！という話になったんですが、イマイチいい方法がその会話では見つからず。

経験がモノを言うは、事実としてあるんだろうけど、どうしたものかなーと悩んでいます。リファクタリングも全く同じで「嗅覚を鍛えるしかない」という結論になってしまうのです。

この記事も、本当のところ、この4冊をみんな読んでくれたのか、読んで実践して読んでを繰り返して、血肉にしてくれたのか？という疑問が残っています。

何かいい方法をご存じのかた、教えていただけるととても助かります。

ちなみにもう一つ悩んでるんですが、Note を全部 Zenn で書いてもいいのでは……というものです……。Zenn とても書きやすいんです。あと、最近の Note の信頼性の低下や、運営の不誠実さが気になっています。