2018年、私は大規模プロジェクトの開発途中に参加しました。元のエンジニアたちは去り、複雑で文書化されていないコードを残していました。このようなコードを扱うのは難しいです。なぜなら、配管からビジネスドメインを区別できないからです。これはデバッグを困難にし、影響を知らないため変更が予測不可能になります。言葉を理解せずに本を編集しようとするようなものです。
多くのエンジニアは、コードがコンパイルされたときが成功の指標だと信じています。私は、別のエンジニア(または6ヶ月後のあなた)があなたのコードの「なぜ」を理解したときだと信じています。元のエンジニアたちは、文書化と不可解な名前を使用しないことで、将来のエンジニアたちを不利にしました。名前は、前のエンジニアの思考プロセスへの唯一の窓になることもあります。
ドナルド・クヌースは有名にこう言いました:
プログラムは人間に読まれるためにあり、コンピュータが実行するのは付随的なものに過ぎない。– ドナルド・クヌース
命名
命名は難しいです。なぜなら、アプリケーション内でピースがどこにどのように適合するかをラベル付けして定義する必要があるからです。
Netscapeにいたフィル・カールトンは次のように述べました:
コンピュータサイエンスで本当に難しいことは2つだけです。キャッシュの無効化と命名です。
— フィル・カールトン
私たちは、使用する言葉と名前のレンズを通してコードを見ています。名前は、次のエンジニアが理解するための言語を作成します。この言語は、著者がビジネスドメインとプログラミング言語をどのように橋渡ししたかの絵を描きます。
20世紀前半の哲学者ルートヴィヒ・ウィトゲンシュタインは言いました:
私の言語の限界は、私の世界の限界を意味する。– ルートヴィヒ・ウィトゲンシュタイン
ソフトウェアの言語は、使用する名前と同じくらい説明的です。曖昧な名前を使用するとソフトウェアの目的が不明確になり、説明的な名前を使用すると明確さと理解がもたらされます。
言葉を話さない国を訪問することを想像してください。トイレを使用するよう求めるような単純なリクエストでも、戸惑った顔が返ってきます。コミュニケーションできないことは、イライラするかもしれません。怖いかもしれません。エンジニアは、混乱した、不明確な、さらに悪いことに誤解を招く名前に直面したときに同じ気持ちを感じます。
この感覚は実際に経験するのが最善です。
経験
最初のコードスニペットを見てください。このコードは何をしていますか?「なぜ」は何ですか?
時間をかけてください。
public class StringHelper
{
public string Get(string input1, string input2)
{
var result = string.Emtpy;
if(!string.IsNullOrEmtpy(input1) && !string.IsNullOrEmtpy(input2))
{
result = $"{input1} {input2}";
}
return result;
}
}
上記のコードは、2つの文字列の単純な連結です。コードが伝えていないのは「なぜ」です。「なぜ」は非常に重要です。それなしでは、影響を理解せずに動作を変更するのは難しいです。もちろん、コードの使用方法を調査すれば、おそらく「なぜ」が明らかになるでしょう。しかし、それが問題なのです。コードの目的を発見する必要はありません。代わりに、著者が手がかりを残すべきです。それは彼らの責任です。
コードを再度見てみましょう。ただし、少し「なぜ」を散りばめています。
もう一度、時間をかけて、このコードを読むときに感じる違いを観察してください。
public class FirstAndLastNameFormatter
{
public string Concatenate(string firstName, string lastName)
{
var fullName = string.Emtpy;
if(!string.IsNullOrEmtpy(firstName) && !string.IsNullOrEmtpy(lastName))
{
fullName = $"{firstName} {lastName}";
}
return fullName;
}
}
「なぜ」はコードに命を吹き込みます。読むべきストーリーがあります。
コミュニケーション
次のエンジニアに意図と設計を伝えることで、ソフトウェアは生き続け、成長することができます。なぜなら、エンジニアがソフトウェアを修正できなければ、それは死ぬからです。これは悲劇です。特に、それが貧弱な設計と表現力の欠如の結果である場合はそうです。どちらも知識があれば防ぐことができます。
次のエンジニアに恩恵を与え、コードで表現力を持ってください。説明的な名前を使用し、「なぜ」を捉えてください。なぜなら、次のエンジニアはあなたかもしれないからです。
Author: Chuck Conway is an AI Engineer with nearly 30 years of software engineering experience. He builds practical AI systems—content pipelines, infrastructure agents, and tools that solve real problems—and shares what he’s learning along the way. Connect with him on social media: X (@chuckconway) or visit him on YouTube and on SubStack.
著者: Chuck Conwayは、ソフトウェアエンジニアリングの経験が30年近くあるAIエンジニアです。彼は実用的なAIシステム(コンテンツパイプライン、インフラストラクチャエージェント、実際の問題を解決するツール)を構築し、学んだことを共有しています。ソーシャルメディアで彼とつながってください: X (@chuckconway) または YouTube と SubStack で彼を訪問してください。