2025年02月05日 06時00分メモ

ソフトウェア開発者が考える「開発者の哲学」とは？

SF作家でソフトウェア開発者のqntm氏が、自らの開発者としての哲学を大きく7点にまとめてブログで公開しています。

Developer philosophy @ Things Of Interest
https://qntm.org/devphilo

qntm氏によると、職場で駆け出しの開発者を対象としてソフトウェア開発哲学を語る機会があり、その内容をもう少し詳しくして記録しておくことには価値があると考えて記事をまとめたとのことです。qntm氏が哲学として挙げたのは以下の7点です。

1：「一から書き換え」が魅力的に見えるような状況になることは絶対に避ける
「土台からやり直した方がいいのではないか」という状況がまずいというのは、一般的にも理解されていることです。このためqntm氏は一歩引いて、「やり直しが魅力的に思えるなら、すでに回避不能なミスが発生している」と指摘しています。

注意すべき危険な兆候としてqntm氏は「技術的負債の増加」「単純に見えるコード変更が難しくなること」「コードのドキュメント化・コメント化が難しくなること」「新たな開発者の受け入れが難しくなること」「コードベースの特定領域が実際どのように機能するか知っている人の減少」「誰にも理解されないバグの出現」を挙げ、一から書き換えを行うリスクは回避可能だと述べました。

2：使える時間の50％で作業の90％を終わらせるようにする
qntm氏はソフトウェア開発界隈でささやかれる「仕事の最初の90％に時間の90％が費やされる。最後の残り10％に残り時間の90％が費やされる」という格言について、「ちょっと面白いし、絶対に事実に基づいたものです」と述べています。

一度コードを書いて動作させるのはある程度の時間がかかるもので、実行するところまでいったら「仕事は半分終わった」といえます。一方で、コードの洗練や保守、ドキュメント作成などの仕事が残っていて、もし飛ばしてしまうと機能が粗悪で不完全なものになってしまいます。また、コードの記述自体が予測しない障害を引き起こすこともあり得ます。

qntm氏は、もし余らせていた時間が必要ないとわかった場合は、プロセス改善の実装に取り組んだり、技術的負債の返済に充てましょうと述べました。

3：よい習慣を自動化する
「新しいベストプラクティスがある」「一貫して使う必要のある新しいツールが出てきた」のようにプロジェクトに参加する開発者全員が始めるべきこと、あるいは「メソッドやAPIを使わないことになった」のように開発者全員がやめるべきことが発生したとき、開発者ベースで全体の動きを変えるには2つの方法があります。

1つは、1人ずつ声をかけるか、あるいはチームミーティングのような形で全員に直接伝えたり、メールを送ったり、新しいガイドラインをWikiに記載したり、リポジトリのREADMEに追加したりする方法。

もう1つは自動化する方法です。

ただし、qntm氏は、自動化は完璧な解決策でも、普遍的な解決策でもなく、自動化できないソフトや抽象的な技術的要件はたくさんあり、あまりにも多くの恣意的なルールを作ってしまって運用が難しくなる可能性があると指摘。その上で「『○○するのを忘れているので、常に○○するようにしてください』と何度も言っていることに気付いたら、○○を自動化するときかもしれません」とまとめました。

4：極端なデータを考慮する
コードはあらゆる可能性を処理する必要があります。たとえば、要求が失敗した場合や永遠に停止してしまった場合はどうなるのか。1時間にわたって秒間1バイトだけ返してきたとき、表示しているテーブルに100万行あるときはどうなのか。10億行ならどうなのか。名前にスラッシュが含まれていたり、末尾に空白が含まれていたり、長さが1MBあったりしたらどうなるのか。qntm氏は、「もし文字列が空ではないことを証明できると言われても、私はあなたを信じない」と述べています。

5：普通はもっと簡単な書き方がある
qntm氏は、古いチェスの格言の「いい手を見たら、もっといい手を探せ」や、出典不明の言葉「こんな長い手紙を書いて申し訳ないが、短い手紙を書く時間がなかった」という言葉を引用。「使える時間の50％で作業の90％を終わらせる」ようにすれば、時間を適切に確保することができれば、もっとうまくやる方法があるかどうかを確認する時間が取れると述べています。

6：テスト可能なコードを書く
これは「明確に定義されたインターフェイスと、最小限の副作用」を意味するとのことで、テストが困難なコードはおそらく適切にカプセル化されていないとqntm氏は述べました。

7：コードが「明白に正しい」では不十分、「明らかに」「目に見えて」「些細なところまで」正しくなければならない
コードによっては偶然に正しく動作することもあります。しかし、それは「悪い入力によって失敗するような状況」が、周辺の他のコードの構造によって除外されているためであり、「私はこのことが嫌いだ」とqntm氏は述べ、技術的にはバグがなくても他のコードを再構築するのは困難で危険だと説明しています。