悪いコードを書くと生産性が 2 倍になりましたが、それには落とし穴がありました

これまでにどれだけのサイドプロジェクトを成功させたか数え切れません。日の目を見なかった人もいます。その他は初期段階で放棄されました。理由はたくさんありましたが、共通する理由の 1 つは、プロのソフトウェア エンジニアが従うルールを破るのではないかという恐怖でした。

初日からすべてを完璧にしようとすると、オーバーヘッドが増えて燃え尽き症候群を引き起こすだけでした。そこで私は、多くのプログラマーが恥ずべきことだと考えるようなことをやろうと決めました。意図的に悪いコードを書き始めました。悪いコードとは、急いでいたり、乱雑であったり、場合によっては間違っていたりするコードを意味します。

コードがどのように見えるかを気にするのをやめ、コードをクリーンアップするのをやめたところ、コードの作成を完了するのにかかる時間が大幅に短縮されました。有意義な結果に到達するまでに以前は 1 か月かかったプロジェクトが、今では 2 週間以下で完了します。ただし、これは両刃の剣であり、私はそれを苦労して学びました。

意図的にコードを壊すと、何を書いてはいけないのかがわかる

今日の間違ったコードにより、明日のデバッグ時間を節約できます

クレジット: Coralnes / Shutterstock

これは、プログラミングに関連する何かを学ぼうと決めたときは常に私が身に付けている習慣です。おそらく皆さんの中にもそうしている人がいるでしょう。新しいプログラミング言語、フレームワーク、さらには新しい概念を学ぶとき、私は何が起こるかを確認するために、意図的に間違った壊れたコードを書きます。

コンセプトをしっかりと定着させるためにこれを行います。これは、ツールがどのように機能し、動作するかを試すのに最適な方法です。そうすることで、将来直面する可能性のある一般的な罠について学び、回避することができます。

これは研究によっても裏付けられています。 2022年の研究では、意図的に間違った定義を書いて修正した学習者は、単に正しい定義をコピーした学習者よりも、後のテストで良い成績を収めました。公平を期すために言うと、2024 年の複製の試みでは同じ効果は見つかりませんでした。また、この研究はいずれもコードに関するものではありませんでした。それでも、それは私の経験と一致します。

中級の JavaScript の概念を学習していたとき、時々気まずくなることがあるため、これをよく行いました。たとえば、次のような構造化の例は次のとおりです。

const このテーマについてさらに詳しく知りたい方は以下をご覧ください = null;
// TypeError: Cannot destructure property 'name' of 'null' as it is null.

JavaScript はすぐに停止します。エラー メッセージには、何が問題だったかも示されています。正直なところ、これらは友好的なバグです。見逃すことはできません。しかし、多くの初心者が驚くことは次のとおりです。

(10, 1, 2, 25).sort();
// ( 1, 10, 2, 25 )

エラーや警告はありません。デフォルトでは、 sort() は値をテキストとして比較するため、「10」は「2」より前に表示されます。これを見てからは、次のような比較関数を渡すことを忘れなくなりました。 (a, b) => a - b。私がフォローしていたチュートリアルではこれらをパスしていましたが、何が起こるかを確認するためにパスせずに実験してみました。

お気づきかもしれませんが。サイレントエラーは対処が面倒です。したがって、これらの罠を学ぶことで、本格的なコードを作成するときに直面する可能性のある突然の驚きに備えることができます。

他の人があなたのコードに依存している場合、ルールが最も重要になります

練習や個人的なプロジェクトの場合は、それらを中断する自由があります

初心者のプログラマーがオンラインでソフトウェア エンジニアの話を聞くと、SOLID 原則やファクトリー メソッドなど、多くの派手な言葉を学びます。もちろん、これは本物のアドバイスです。重要なのは、そのアドバイスが誰のためのものかを理解する必要があるということです。これらは、運用コードを作成し、大規模なコードベースでチームで作業する人を対象としています。

ほとんどの新人プログラマーは、To-Do アプリや電卓を使って仕事を始めます。 100 行のコードにこれらのルールを適用する必要はありません。実際、コードを厳密に守りすぎると、きれいなコードでも足かせになることがあります。他の誰もあなたのコードを読んで作業しない場合、それらのルールの多くは突然重要でなくなります。

たとえば、プロトタイプを考えてみましょう。 『The Pragmatic Programmer』の中で著者は、プロトタイピングによって使い捨てのコードが生成されると述べています。ただし、最終プロジェクトに残る「トレーサーコード」についても言及されています。したがって、本当のコツは、自分がどれを書いているかを知ることです。実際のシステムに組み込まれる場合は、十分な注意が必要です。

私の場合、週末に奇妙なプロジェクトに取り組んでいるときは、エンジニアリングの考え方を完全にオフにして、夢中になります。もしそのコードを見たら、おそらくどのソフトウェアチームからも追い出されるでしょう。

良くも悪くも

AI と LLM がコーディング タスクで上達し始めたとき、私もバイブ コーディングと AI 支援開発に引き込まれました。このとき、私の悪いコードを書く習慣がピークに達しました。

一方で、私は AI を使用して大量のコードを生成しましたが、それをクリーンアップすることさえ気にしませんでした。プロンプトを与えるとき、私はプロンプトを最小限に抑え、ルールや原則に従うように要求しませんでした。したがって、当然のことながら、これらの AI ツールが作成したコードは「機能」しましたが、品質は低かったのです。

一方で、自分で悪いコードを書いた場合は、常にクリーンアップを AI ツールに任せていました。彼らが私をサポートしてくれることを知っていたので、私はこの機能の最初のバージョンを書くときに厳格なルールに従うことを気にしませんでした。ただし、ご想像のとおり、これは決して確実な計画ではありませんでした。

より多くのコードを書くことが必ずしも生産性を意味するわけではない

自分が書いた悪いコードはまだ読まなければなりません

さて、私が苦労して学んだ部分についてです。 AI 支援プロジェクトの多くでは、数千行のファイルが複数できるまで、やみくもにコードを生成し続けました。現在は機能を 1 つずつ開発し、それぞれをテストしながら進めています。しかし、バグに遭遇したときに現実が起こりました。

私が最初にしたことは、他のバイブコーダーが行うのと同じように、AI ツールにバグを説明し、修正するよう依頼することでした。それは惨めに失敗した。初めて、自分でファイルを開いてコードを読む必要がありました。いや、私は驚きました。

私にはプログラミングの知識があったので、コードの断片は理解できました。しかし、データの流れ全体、すべてがどのように組み合わされているのか、各コンポーネントがどのような役割を果たしているのか、まったく分かりませんでした。

つまり、最終的には、悪いコードを書くことで時間を節約することはできましたが、後でそのコードを読む必要がある場合には、最初から適切にコードを書いた方が良いと考えています。

まずは仕上げて、残ったものだけを磨く

「機能するなら触らないでください」は、プログラミング コミュニティではよく知られたミームです。それだけでも嬉しいです。ミーム。悪いコードが私をより悪い開発者にしたわけではありません。いつ使用すべきかを学んだので、速くなりました。また、エリート プログラマーが組織化されたコードを書くのが習慣である理由もわかりました。