もしあなたがアムステルダムののんびりとした日曜日の午後に Amazon の CTO である Werner Vogels に偶然出会う幸運に恵まれたら、彼と同じように「ソフトウェア開発について、私たちはどのように考え方を変えるべきでしょうか？」と自問するかもしれません。
これに対して、ヴォーゲルス氏はこう答えた。「ソフトウェアは、それを書くのにかかる時間よりも何十年も長く運用される必要があるのです。」
これはソフトウェアがレガシーソフトウェアに分類されることを意味しますが、それは単に、数年後、あるいは数十年後も人々が使い続けたいと思えるようなソフトウェアを開発したということを示すに過ぎません。しかし、Vogels氏が開発者に目指すべきと示唆するような長期使用を実現するのは、必ずしも容易ではありません。
物事は退屈になりそうだ
データベースのようなエンタープライズテクノロジーを選ぶ際に、退屈なソリューションが良い理由については以前記事を書きました。企業にとって最優先事項は、事業の継続、アプリケーションの稼働継続などです。そのため、十分に理解された機能と障害モードを備えたソリューションを選択することが重要です。
参照: 開発者として成功するキャリアを築く方法 (無料 PDF) (TechRepublic)
しかし、「退屈」とアプリケーションには別の側面があり、それは特定のビジネス課題を解決するための最も基本的なアプローチを取ることを意味します。開発者のマヌエル・オデンダール氏が指摘するように、彼は「非常に単純な」コードで「非常に価値のある製品を一貫して生み出す」ことができ、「高度な数学」や奇抜なAIを使わずに済むのです。彼の秘訣は、「ビジネスが実際に処理するデータではなく、ビジネスに必要な情報を理解する」ために、「多くの質問をすること」です。
ビジネス ニーズを満たすためにアプリケーションが消費および配布する必要がある情報を正確に絞り込むための質問をすることで、アプリケーションをシンプルな状態に保つことができます。
「情報がA地点からB地点に到達するまでの経路がシンプルであればあるほど、システムはより良くなります。適切な質問をすることで、ソフトウェアは的を射た、真のビジネス課題を解決する力を発揮しています。」
これは非常に価値がありながら、しばしば見落とされがちな原則であり、ソフトウェアの長期的なサポートにとって鍵となります。AWSのエンジニアリングエグゼクティブであるマット・ウィルソン氏がヴォーゲルス氏に正しく指摘したように、「運用システムで実行されるソフトウェアは、記述が完了することはほとんどない」ため、この原則はさらに重要になります。
コードを可能な限り簡潔に保つことで、開発者は数か月後、数年後、あるいは数十年後に改良しやすくなります。ここでも、優れたドキュメントが重要になります。
記録しなければ、それは起こらなかったことになる
開発者アドボケートのメイソン・エッガー氏は、優れたドキュメント作成は、オデンダール氏が強調したのと同じ基本原則、つまりシンプルさを保つことから始まると強調しました（PyCon 2022でデイビッド・カッセル氏が指摘した通りです）。ドキュメント作成においてエッガー氏は、開発者はドキュメントが読者の達成に役立つ明確な目標を明示すべきだと指摘しました。読者を過剰な言葉で圧倒する必要はありません。開発者は何かを達成するためにドキュメントを作成しているのですから、その目標を達成するために必要な情報をすべて提供し、それ以上のことで開発者の時間を無駄にしてはいけません。
参照: 採用キット: Python 開発者 (TechRepublic Premium)
エッガー氏によると、開発者は説明よりもサンプルコードにすぐに飛びついてしまうことが多いため、実例を使うことを強く主張しました。また、エッガー氏は、読者が必要な情報を素早く見つけられるように、ドキュメントを簡単に検索できるようにする必要性も強調しました。専門用語や不必要に複雑な言葉を使わず、できるだけシンプルに書くことも重要です。目指すのは常に、シンプルさと簡潔さです。
コードサンプルと説明テキストでは、ドキュメントに誤ってエラーを残していないことを再確認することも重要です。
「文書がないよりも悪いのは、不正確な文書です」とエッガー氏は言います。「文書がないと、どこか別の場所で探すことになります。不正確な文書は時間の無駄です。」
これらの（そしてその他の）ドキュメント作成のヒントは、数日後、数週間後、あるいは数年後にサンプルコードに遭遇した人が、それをより容易に理解できるようにするのに役立ちます。その結果、より多くの人がそれを使用する可能性が高まります。したがって、ソフトウェア自体とそのドキュメントは、将来にわたって読みやすく、使いやすくするために、今日できる限り分かりやすくする必要があります。
開示: 私は MongoDB で働いていますが、ここで述べられている意見は私自身のものです。
