頑張らない開発と自己コードレビュー
こんにちは、加藤です。コードを書くときは水を飲みます。コーヒーやお茶を飲むとトイレが近くなって、中断するたびに効率が落ちるのでよくありません。
貸し本棚を開発するときに最初に決めた「１時間ルール」というものがあります。壁にぶつかって１時間悩み続けて光明が見えなかったら放棄するという規定です。
あのときもっと頑張れば良かった……
こと開発に関して、このような後悔を抱いたことはありません。むしろ逆に「なんであんなに頑張っちゃったんだよ」という反省の方が頻繁です。
開発で頑張り始めるときは、多くの場合間違った道を選んでしまっています。登山道でないところを歩けば滑落します。これはむしろ落ちたほうがよくて、道なき道を歩めば、道なき頂上に到達し、下山できなくなります。
かつてWebsocketが出たての頃、取り扱うライブラリもサーバも無くて「自分で書くか」という軽い気持ちでpopenし、pack関数使ってゴリゴリ（サーバを）書き上げたことがありますが、後年それをリプレースしづらくなって保守に無駄なコストを割いたことがあります。
頑張らないを頑張る
努力が必要になった時点で、自分が誤った道を選択していないかについて疑い始めると同時に、もしかすると整理整頓できていない可能性についても考えるように努めています。
技術的な知識への学習意欲や探究心は誰しもあると思いますが、案外「自分が作っているものに対する学び」が足りていないと整理整頓されず散らかったまま設計され、散らかったままコーディングがスタートしていることがあります。いま自分がなにをどのように作ろうとしているのか、ノートに書き出して考えると、大抵粗が見つかります。作っている最中のシーケンスを詳しく書くと、ものすごく無駄な回り道を発見することがあります。
構築の実作業に着手できないのでフラストレーションがたまりますが、最初に構築物を最小単位まで分解して、整理整頓してから再開した方が、そのまま頑張り続けるより早く終わるし、品質も担保されると考えます。
構築の３倍
昔からデバッグは構築の３倍労力がかかると言われています。構築作業にマックパワー使い切るとデバッグでアンコントロールに陥りストールします。
構築時点では、あまり集中力を使わず余裕を持って完成させられるレベルの平易な設計になるように努めます。
なにかおかしいコード
個人開発では自分のコードを他人にレビューしてもらえません。自分で自分のコードをレビューしたところで、違和感に気づくことは稀だと思います。そこで「眼鏡を外す」という新しいレビュースタイルのご提案です。
御覧ください、よく見えないコードはまるで赤の他人が書いたもののようです。そしてそこに現れる悪意のあるネスト地獄、awaitの群れ、作文のように長大なプロパティ、異様に小さなメソッド群が見えてきたでしょうか。インデントのズレなど万死に値します。
再度眼鏡をかけたとき、意味不明だった形状の種明かしによって、自分自身の妥協と杜撰が明るみになります。showModal系のメソッドの間にscrollメソッドが混じっていても、見えているときは「動いてるから順番とかどうでもいいじゃん」と思っていましたが、もう許せません。粛清の時間です。
自分のコードがちょっとよく見えないだけで、瞬く間に他人のコードに早変わりします。そしてこのようなレビューによって、苦しみと無駄な努力の痕跡を早期に発見できるチャンスが増えます。
貸し本棚の抱える頑張った系問題
貸し本棚はあまり頑張らずに平易な機能を平易に実装しているので、ガワも中身もかなりシンプルです。ただ、その中で唯一の例外と言えるのが、外部投稿サイト連携機能です。これは貸し本棚に登録している作品を外部の投稿サイトに同期する機能です。
これは眼鏡を外さなくてもぱっと見でヤバいです。
完全なDDDじゃないのでクラスがあちこちに分散してます。なろうとカクヨムで中途半端に共有しているDIのクラスがあったり、ValueObject化されていない値のやりとりが混入しています。
一応動作していることと、同期先に変更があったときに修正は入れやすくしてあるので、現状リファクタリングは行っていません。もう少し使用頻度があれば改修しましたが、労力かかった割に使われていない機能になっています。これ以上頑張ってもリターンが見込めないので、とりあえずそのままにしています。
今回はあまり貸し本棚開発に関係ない話題でしたが、個人開発ではパワーのかけどころを誤ると、積み上がった巨大な頑張りの山から瓦解が始まります。ヤバそうな機能はマイクロサービス化して後ろに投げておくのが安全ですね。
この記事が気に入ったらサポートをしてみませんか？