時間があれば良いコードは書けるのか?

よく話題になる話だけど...


seaさん「もっと時間さえあれば良いコード書けるのになー」


landさん「良いコードを書ける人は時間がなくても良いコード書く」

     (書けない人は時間があっても良いコードは書けない)



jfluteの考えとしては...
「だいたい両方正しい」という感じでしょうか(^^。

矛盾してるって思われますでしょうか?

良いコードにも程度がある

コードを0点から100点と評価するとしましょう。

時間がないとき:
良いコードを書ける人: 70点のコード
良いコードを書けない人: 40点のコード

もっと時間があれば:
良いコードを書ける人: 70点 → 99点 (+29点)
良いコードを書けない人: 40点 → 45点 (+5点)


※数字は感覚値なので、70が80でも40が30でもよいです。

※書ける人と書けない人と単純化して二分していますが、実際はグラデーションがあるし、もっと多様です。


良いコードを書ける人は:
o 時間なくても、まあまあ良いコード書ける
o 時間あったら、さらなる良いコード書ける

良いコードを書けない人は:
o 時間かけても、たいして良いコードにならない

ってところですね。なので、さっきの話は「だいたい両方正しい」と。


良いコードを書ける人は、コードに対する期待値 (セオリー) を知ってるので、早い時間で70,80点くらいまで到達するでしょう。さらに高レベルな期待値も知ってるので、時間があればそこからブラッシュアップもできるでしょう。
(というか時間がないから業務都合に合わせて70,80点にコントロールしてると言えるかも)

良いコードを書けない人は、そもそも期待値を知らないので、時間を掛けても効果が薄いわけです。もしくは、業務的に非現実的な何倍もの時間を掛けてやっと70点レベルに到達するとか。

腹いせの格言にならないように

seaさん「もっと時間さえあれば良いコード書けるのになー」

seaさんが良いコードを書ける人であれば、たぶんlandさんも反論しないと思います。

でも、seaさんが良いコードを書けない人であれば、たぶんlandさんは「時間のせいにするな」と言いたい気持ちが生まれるのではないでしょうか?

なので、シンプルな格言的な言葉で伝えようということですね。

landさん「良いコードを書ける人は時間がなくても良いコード書く」
 ↓
(そもそも良いコードを書くスキルを事前に身につけておこうよ!)

ということを。


ただ、すごく気持ちはわかる一方で、シンプル過ぎると腹いせ感のある言葉にも捉えられてしまいがちで、一番伝えたい当事者にあんまり伝わらないかも知れないっという懸念もあります。

seaさん「landさんって怖い人なんだ」

って感じで。

なので、もう少し噛み砕いた論理にした方が良いのではないかと思ってブログを書いてみました。


具体的な施策は?

さて、時間かけてもダメってことは、現実的にどうしたら良いでしょうか?

そんな話も少ししておきましょう。


列挙するのは、どちらかというとチームとして良いコードを書けない人をいかに書けるようにするか?という施策の話ではありますが、良いコードを書けるようになりたいと思っている人は、「なるほど、ここが学びどころなんだ」と思って意識してもらえたら嬉しいですね。

そこで得た学びが、自力で良いコードを追求するきっかけやパワーになると思いますので。

施策1: どうせならレビューに時間をかけよう

ということで現場で実施されているのがレビューですね。良いコードを書ける人がアドバイスをして、できるだけ良いコードに仕上がるように。

結果だけではなく、良いコードを書ける人から良いコードを書けない人にスキルが伝承されて、徐々に書ける人になっていくために。自力40点が自力45点に、半年後は自力55点に、時間があれば70点まで到達できるようになるかも知れません。


ただ、これは良いコードを書ける人の時間を使ってると言えます。

時間を掛けて効果を得るためには、どうしても良いコードを書ける人が必要なんですね。

特に80点から99点の高レベルなブラッシュアップだと、チームに期待値を知る人がいない可能性も高いので、他のチームの人や技術顧問の方に一時的に得意な人にレビューワーとして入ってもらってチームで継承するというのも良いでしょう。

施策2: 研修の時点で良いコードを追求しよう

新卒研修にせよ、中途研修にせよ、単にプログラミング言語の文法やフレームワークの使い方を覚えるのではなく、良いコードを書くスキルが鍛えられるカリキュラムがあると良いかなって思います。

研修内で全部を習得はできないどころか一部だけにはなるでしょうが...

良いコードに仕上げる意識させ芽生えれば、その後の経験でちょっとずつ積み重なってくるでしょう。

逆に言うと、意識がない状態だと、経験を積んでも「ふーん」って感じでスルーしてしまうんですよね。レビューを経験しても「言われたから直した」になってしまって、あんまり積み上がらない可能性もあるのです。


初心者は、良いコードの何が嬉しいのか?もわからない状態だったりしますから。意識がある/ないは大きな分かれ道だと思っています。

jfluteは、どの現場での研修でも最初から意識付けを心がけています。意識が付くだけでどんどん変わっていくのを実感しているからです。

施策3: 最低限の体裁とかは自動化/手順化

スーパー月並みなんですけど、結局できてない現場が多いので。

フォーマッター、警告の仕組み、チェックスタイル、いくらでも支援ツールがあります。

これらのツールを使っても自動化されるのはせいぜい40点50点レベルの部分ではありますが、時間がいくらあっても足りない良いコードを書けない人にとっては、自動的に40点50点が取れるのであれば、その分の時間を+5点に使えるわけです。

また、レビューのときに、低レベルな指摘で高レベルな指摘の時間がなくなってしまう問題や、低レベルな不備がノイズになって高レベルな不備を見逃してしまう問題も防ぎやすくなります。(あとレビューワーのコードを読む気力にも影響しますので。最低限の体裁が整ってないとコード読むストレスになるもので)

この辺の難しいのは、設定が人によってバラバラだと機能しなくなるので、ちゃんと最初に設計が必要になりますし、強制させる共有の仕組みが必要になります。その辺を司る設定ファイルが gitignore になってて、人によってバラバラだったり、全く有効になってなかったりとか、そういう現場たくさんありました(苦笑)。


また、「自動化できないけどわりと定型的なポリシー」をちゃんとドキュメント化しておくというのも大切だなと最近実感しています。

チームが安定しているうちは良いですが、5年6年と月日が経ってだいぶメンバーが入れ替わったりしたときに、「このプロジェクトでは、ここはこうする」っていうのが引き継がれてなかったりするのですね。

新しいメンバーもドキュメントに書かれてるポリシーには従うけど、書かれてないことは知らないからやらないですよね。


時にもう必要のないポリシーもあったりするので一概に良い/悪いも言えないですが、続けていた方が良いポリシーが途絶えているケースも良く見かけます。もしくは、新しいメンバーの導入オリエンテーションをしっかり実施するというのも一つの策でしょう。

とある現場では、jfluteが新人だろうがベテランだろうが導入オリエンテーションを必ず実施して、コーディングに関する現場の方向性とかを伝えるなどしています。

施策4: コードリーディング会を開こう

(追記: 2022/07/12)

読む人の気持ちを知ることが良いコードの第一歩、他人のコードを読むと発見がたくさんあります。

一人で読み続ける力も必要ですが、最初は効率悪いので読める人と一緒に読んでいく機会があると良いかなと思っています。

みんなで楽しみながらソースコードリーディング会!


直接業務と関係の無いコードであっても、良いコードを書くための糧になりますよ。

そもそも良いコードとは?

良いコード良いコードって言ってますが、良いコードはけっこー人によってブレます。コードデザインの方向性や多少の好み、プロジェクト都合や業務要件の特性などによって、良いコードは一致することはあまりないでしょう。

特に90点から99点の間はブレやすいので、そこに関しては議論する人も学ぶ人も注意しながら追求した方が良いでしょう。

良いコードを書ける人って単純化していますが、みんな今でも「どうすれば良いコードになるのか?」を試行錯誤しています。一生探し続けることでしょう。


また、70点を80点にする労力と90点を99点にする労力は同じにはならないものです。

最後の詰め、90を99にするってのは得てして大変な作業だったりします。費用対効果もレベル帯によって変わるものなので、低レベル帯と高レベル帯では判断基準を同じ議論では語れないことも多いでしょう。


でもって、なんで100点が出てこないの?ってところですが、先の通り最後はバランス次第でコードが変わるということで、複雑であればあるほど100点のコードって存在しないって思うので、あえて99点という表現を使ってます(^^。


まあ、このブログの論点にはあまり影響しない話ですが、「良いコード」という概念を単純に捉えてしまうとまた迷子になるかもしれないので、但し書きのようなものとして。

レビューしやすいコードへ

実はjfluteは、普段あまり「良いコード」という表現は使いません(^^。

抽象的な話をするときに便宜上使うことはあるでしょうが、伝えるときには曖昧すぎてあまり適してない気もして。


ぼくはまず「レビューしやすいコードを意識してみよう」とよく現場では言っています。

レビューしやすいコード (Reviewable Code) | jfluteの日記