10年後：完全に意見が変わったソフトウェアに関する考え

8,111 文字

ソフトウェア開発に関して、業界で10年働いて考えが変わったトピックについてお話しします。4年前に同じようなトピックについて投稿したことを、あるメールで思い出しました。考えが変わったことや、過去の自分なら議論したであろう現在の考えについて振り返ってみましょう。
シンプルさは当たり前ではありません。それには絶え間ない努力が必要です。正直なところ、このシンプルさと複雑さの議論をあまり理解できていません。リッチ・ヒッキーによるシンプルさと複雑さの定義を見る必要があるのかもしれませんが、LSDを使ってクロージャーを大量に作るなどしない限り、他の方法で解決できるとは思えないことが多いのです。必要以上に複雑さを増すことへの反論はわかりますが、そもそもどうやって複雑さを増やし始めるのかが気になります。
リッチ・ヒッキーはLSDを使っているようには見えませんね。これが私の問題の所在です。私のファンクショナルプログラミング好きに対する当初の印象は、みんなタイダイTシャツを着てLSDを使っているというものでした。リッチ・ヒッキーは確かに私の期待通りでした。
問題領域が複雑で、実装方法も狂気じみているコードに出会ったことはあります。シンプルさと複雑さの違いについて、私なりの定義をすれば、それは本質的に振る舞いの局所性の尺度です。小さなコードの断片を見て、構造を理解するために型定義をいくつか確認する程度で、10行程度のコードを見ればその中で何が起きているのかを理解できるべきです。これが私の考えるシンプルなコードです。
その10行が理解するのにとても難しい場合もあります。例えば、偶然Mulberry 32の実装に出くわした場合、その実装自体は理解できないかもしれません。それは構いません。少なくともその限られた空間で何が起きているのかはわかります。
Mulberry 32とは何かというと、JavaScriptのような言語で実装できる、シードを使用した擬似乱数生成器です。決定論的な振る舞いが必要な場合、Math.randomの代わりにMulberry randomを使用できます。
シンプルさと複雑さの違いは、シンプルな概念を過度に抽象化しようとすることです。しかし、私はこの定義でさえ完璧とは思えません。私のシステムの一部、Twitchの扱い方を抽象化したことがありますが、それは良い選択でした。余分な間接層を追加しましたが、多くのテストが可能になり、プロキシTwitchやサービス実行Twitchなども実装できるようになりました。実際、シンプルな問題をより複雑にする過度な抽象化によって、複雑な問題がシンプルになったと考えています。
シンプルさから複雑さへの境界線を越えたかどうかを判断するのは本当に難しく、振り返ってみて初めて過度に複雑化したことがわかることが多いです。最もシンプルな解決策だと思って実装したものが複雑な作業につながることもあれば、複雑な作業が結果的にシンプルな解決策をもたらすこともあります。どちらに傾倒すべきかを事前に知るのは難しいです。だからこそ私たちは反復を行うのです。
これらの主張について、私はいつも一面的に感じます。正直なところ、私が理解力不足なのかもしれませんが、シンプルさと複雑さについては後知恵でしか理解できません。予見的に理解できることは滅多にありません。
複雑さを管理したり理解することに誇りを持つべきではないという意見がありますが、この主張も理解できません。私にとってはシンプルすぎて意味がわからないのかもしれません。複雑さを管理し、可能な限り削減して、物事をより直接的で理解しやすくすることに誇りを持つのは当然だと思います。ただし、時にはリファクタリングによって他の人にとって理解が難しくなることもあります。
経験レベルが混在したチームでは型付き言語が不可欠です。LSPの登場以来、型付き言語への私の愛着は大きく成長しました。以前は「JavaScriptでもTypeScriptでも好きな方を使えばいい、私はJavaScriptの方が好きだ」と言っていました。それはLSPがまだ普及していない時期で、JavaScriptでは参照を追跡するのが難しく、ある程度の推論や型ヒントを得るにはJavaDocやJSDocを使う必要がありました。
Pythonはどうでしょうか？多くの企業でジュニアレベルからシニアレベルまでの開発者がPythonを使用して成功を収めています。だからこの議論にも完全な意味があるとは思えません。確かにPythonには型がありますが、それは型ヒントであって本当の型ではありません。必要に応じて型付けを追加できますが、それはある意味で...という感じです。
Javaは退屈だからこそ素晴らしいという意見があります。私のJavaに対する一般的な問題は、すべてのJavaプロジェクトがクリーンコードの要件を満たす必要があるという認識から、すべてを抽象化しすぎて追跡が困難になったプロジェクトをたくさん見てきたことです。これは単なる私の経験かもしれませんが、多くのJavaを書いてきた中で、実際にはそれほど悪い言語ではないと思います。Javaは受けている評価よりも良い言語だと思いますが、みなさんそう思いませんか？...いや、だめですか。私は人々を団結させようとしているのに、みなさんは完全に否定してしまいます。
REPLは有用な設計ツールではないという意見がありますが、探索も設計の一部ではないでしょうか？この主張自体が理解できません。プログラミングのほとんどは、単一の行を書く前に行われるべきだという意見には完全に反対です。これは恐らくクリーンコードスタイルの個人的な考えでしょう。UMLダイアグラムだけで何かを救うことはできないと思います。
むしろ、経験こそがコードを速く書くための最良の場所だと考えています。ただし、プログラミング初心者にとっては、構築前に何を作りたいかを考え、頭の中でイメージを作り、その筋肉を少し鍛え、予測を立てて実際に構築してみて、その結果が良いか悪いかを確認するという練習は有効かもしれません。私も長年そうしてきて、かなり上手くなったと感じています。しかし今では全くそうしなくなりました。これを普遍的な原則として受け入れることには賛成できません。
アルゴリズムを理解しようとする時はまだフローチャートを書いたりしますが、それくらいです。言語が強力であればあるほど、最初の行を書くのが速くなるという意見にも全く同意できません。私にとっては、ソフトウェアを構築した経験が多いほど、最初の行を書くのが速くなります。ソフトウェアの設計が下手だった過去には、構築方法について時間をかけて考えることが役立ちました。
フロントエンド開発は悪夢のような世界で、もう楽しめないという意見があります。フロントエンド開発は特定の設計哲学のために悪評を受けていると思います。フロントエンド開発を嫌いになって関わりたくないと思うようになった場合は、少しの間Webコンポーネントを試してみることをお勧めします。各部分をWebコンポーネントで構築し、少しバスを入れてみてください。少し扱いにくいソフトウェアかもしれませんが、バックエンドから生成する必要があり、単純なAjaxだけでは済ませたくない場合はHTMXを少し使ってみるのもいいでしょう。
これらを組み合わせて、少し古い方法で試してみると、フロントエンドを再び好きになるかもしれません。多くのフロントエンドアプリは実際に書くのが退屈ですが、本当に楽しいフロントエンドアプリもいくつかあります。
エレガンスは実際の指標ではありません。正直なところ、エレガンスが何を意味するのかさえわかりません。コードがエレガントだと言われても、それが何を意味するのかわかりません。
良い管理は非常に重要です。私のキャリアの大半は、それが上手く行われているのを見る前に過ぎました。私は良い上司に恵まれ、Netflixでの最後の上司は素晴らしかったです。
DynamoDBは良いデータベースだという意見については、最近なぜこんなに多くのデータベースがあるのかわかりません。私はSQLiteを使用しています。Postgresを使用したい理由はわかりますが、多くの人々はデータベースについて考えすぎて、何か奇妙なものを使用しています。Redisも、リモートでキャッシングを行うために必要な場合は良い選択肢になり得ます。
DynamoDBは驚くほど高速ですが、ここで少し物議を醸すかもしれない発言をします。ほとんどの人々は、データベースの速度が人生に全く影響を与えない世界に住むべきです。SQLiteやPostgresを使用している場合、同時に3人、5人、10人のユーザーがいるため、マイクロ秒を数えているようなものです。もしかしたら1秒間に20から30の同時リクエストがある狂気の場所にいるかもしれませんが、ほとんどの場合はそうではありません。
30から50の同時ユーザーがいる場合、1日に1000万人のユーザーがいることになります。それは多くのリクエストです。人々は50の同時リクエストがどれだけ多くの人々を意味するのかを忘れています。または、フロントエンドが完全に狂っているのかもしれません。ページに着地すると9000の小さなリクエストを行うようなウェブサイトを見たことがありますか？それは設計の問題であり、本当のデータベースの問題ではありません。
RESTとキャッシングなど、そうする理由は理解できます。私も良いキャッシングのチームにいます。しかし、それは少し狂っています。そのようなウェブサイトを見たことがありますし、そのようなウェブサイトを書いたこともあります。
一般的なアプリケーション開発では、ほとんど抽象化は存在しません。必要なコードを書くだけでよいというのは非常に良いアドバイスです。これは私が毎日立ち返らなければならないアドバイスで、人生で最も自分に言い聞かせる必要があったことかもしれません。
ソフトスキルの向上に積極的に投資する必要があります。パブリックスピーキングのコースに参加することをお勧めします。私はパブリックスピーキングが得意ではありません。本当に上手くなるには常に実践するか、多くの練習が必要だからです。しかし、上手くなる方法を見つけ出し、練習することはできます。とても楽しく、素晴らしいスキルです。
対照的に、ライブラリ開発は抽象化に関するものです。代数を探す時間を費やし、OMM（オブジェクト-リレーショナルマッピング）はすべての言語と実装において悪魔のようなものです。問題領域によると思います。SQLを自分で書くべきという意見には一般的に同意しますが、Laravelはかなり良いものを持っています。
しかし、最終的には実装を自分で書く必要が出てきます。OMMへの過度の依存が主に悪いのは、ほとんどの興味深い問題が1対1のマッピングではないからです。単一のものを取得して単一のものを見るだけということは滅多にありません。そのような場合にはOMMが完璧に適合します。結合などを始めると、その良し悪しをコントロールする余地はほとんどありません。
十分な時間が経過すると、サーバーレス関数の上に構築したことを深く後悔するでしょう。これは興味深い意見です。サーバーレス関数で解決できる問題のセットはあると思います。内部的には、サーバーレスで実行できる簡単なことがたくさんあります。しかし、多くの人々がこれで失敗していることも知っています。私はまだサーバーレスについて判断を保留しています。明らかに長期的なサーバー、つまり自分でサーバーを実行する効率性の違いは桁違いです。
キューベースのトリガーには素晴らしいですね。内部処理のように、一瞬だけ必要なものやバッチ処理のように現れては消えるものには、クールな使い方がたくさんあります。特にSQSやSNSのようなCFAのバージョンを使用している場合、これらの2つは非常に相性が良いと思います。素晴らしいアイデアに感じますが、デバッグなどは本当に最悪だと確信しています。
型は世界に対する主張ではありません。これは偽の型の世界です。本当の型はメモリレイアウトに関するものですが、現在はボックス値を使用しているため変化しています。JavaScriptの世界では、オブジェクトは実際にはオブジェクトではありません。foo: 5、bar: 6のような場合、実際にはそのように動作していません。代わりに、JSValueやそれに類するものがあり、それはJSオブジェクトで、プロパティと値の両方に専用のバイト数のメモリストレージを持ち、値はポインタまたはSMIである可能性があります。
分散ロックは何らかの理由でまだ難しいようです。恐ろしそうですね。形式的なモデリングと分析は必須のスキルセットだそうです。UMLのことを話しているのでしょうか？シーケンス図については、多くの人が良いものだと同意できると思います。
分離は良い統合スイートの最も重要な特性です。結合について話していると思いますが、同意します。DynamoDBは一般的なアプリケーション開発には最悪の選択肢だそうです。私はDBの戦争には参加しません。Vimについて話してくれれば、Vimの戦争について話しましょう。
クラフトについて気にする人は少ないでしょう。気にする人を大切にし、他の人々は彼らがいる場所で出会いましょう。私にとってはちょっと悲しい感じがします。クラフトについて気にするべきだと思います。
漸進的な依存型付き言語が未来だという意見がありますが、この主張は間違っていると思います。これはミームだと思いますが、間違っていますか？
テストコードにコメントを多く追加しすぎることはありえないという意見には完全に反対です。一般的に、コメントはコードにとって悪い選択肢だと思います。例外的な場合もありますが、テストコードに限らず、どんなコードでもコメントは悪いと考えています。
自分のコードで表現できない開発者に、読みやすいコメントを書くよう求めるのはやめましょう。コメントが適切な場合もあります。ライブラリとそのAPI定義です。機能の内容を読めるようにしたいと思います。実際、関数の定義が全くないようなケースにしばしば遭遇します。インポートしてLSPで使用できるライブラリを書いたのに、そのドキュメントが全くないのは非常に困りますね。IDEで何をすべきかを読めるようにしたいです。
ドキュメントはコメントと同じではないことは知っています。しかし、まだ言いたいのは、もし書かないなら...ドキュメントはコメントのスーパークラスのようなものかもしれません。「これに触るな、後悔することになる」というコメントは、私も実際に評価します。「この奇妙なスワップを行うのは、送信先のサーバーが3週目の木曜日にクラッシュするからだ」というような文脈を提供するコメントは良いと思います。しかし、これは稀なケースです。3週目の木曜日にクラッシュする行を削除するようなコードを、どれだけ書くでしょうか？絶対にゼロですね。
たまにはそういうこともありますが、それを毎行やっているなら、あなたは宇宙で最悪の場所で働いているということです。「これはハッシュの衝突がないことを前提としている」というコメントは書く必要はありません。SHA-512や256を使用している場合、一般的に衝突はないと仮定します。理論的には衝突の可能性はありますが、実際には衝突はないと想定しています。
意見が変わっていないこと：コードスタイル、リンティングルール、その他の細かいことにストレスを感じる人々は、いまだに奇妙な人々です。私にとって重要なことに集中します。時には同意し、時には同意しません。コードのスタイルについてはどうでもいいです。自分のやり方が好きです。人々を自分のスタイルに従わせようとするのは奇妙なことだと思います。
個人的には「一貫性を保つべき」という意見にも同意しません。コードの一部が少し異なるスタイルだからといって理解できないということは、ほとんどありません。異なるコードベースではそれぞれ異なるスタイルがありますよね。どんなスタイルでも読めるようになるべきです。
gofmtが最高だという意見がありますが、私はそれが最悪だと思い、使用を拒否します。馬鹿げていると思います。
モノリスは依然として良いものです。同意します。コードカバレッジはコード品質とは全く関係ないという意見については、明らかに強く反対します。逆比例の関係があるとは思いません。0%から100%までのカバレッジカーブで考えると、カバレッジがないコードベースと何らかのカバレッジがあるコードベースには、確実に違いがあります。
ガウス分布的なカバレッジを想定すると、ほとんどのコードベースはそのような形になると思います。いくつかのテストは良いことです。テストがないコードベースについても、テストが多すぎるコードベースについても、何か言えることがあります。
数十年にわたるRDBMSの研究と改善について。これはJavaでデータベースを扱う方法のことですか？RDBMSが何なのかも知りません。これはとてもJavaっぽく感じます。JavaScriptやJavaでリモートシステムを扱う方法のことでしょうか？完全に間違っていますか？これは単にSQLのことですか？JDBCと混同していましたか？申し訳ありません、私の間違いです。頭の中でJDBCが混ざっていました。
RDBMSさん、申し訳ありません。60年代から使用されていますよね。SQLは良いものだと思います。時々、ファイルにJavaScriptを書き始め、複数のスレッドでJavaScriptを書き始めて、SQLiteを再発明していることに気付くことがあります。
マイクロサービスには正当化が必要です。それは次第に当たり前のことになっています。その通りです。AWS内部のプロジェクトでさえ、そのようなスケールを必要とせず、それを装うことで損害を受けています。同意します。
プロジェクトマネージャーの93%から95.2%は、明日消えても影響がないか、むしろ効率が上がるでしょう。正直に言って、それは理解できます。少し高めかもしれませんが、良いプロジェクトマネージャーも確かにいます。この意見には完全に共感できます。
10年以上の現場経験で、良いプロジェクトマネージャーに2人しか出会っていないという意見もあります。確かに存在します。良いプロジェクトマネージャーとは何でしょうか？大きなプロジェクトに参加したことはありますか？Netflixで最後に携わったプロジェクトはライブゲーミングでした。同時に多くの異なることが動いていた様子は想像できると思います。そこでは実際にプロジェクトマネージャーが非常に有用でした。
これは実際にかなり良い記事でした。人間によって作られ、GPTではありません。素晴らしい仕事です。全般的に、これは長年Javaに携わってきた人の視点だと感じます。Javaを多く使用していると、ソフトウェアの作り方について特定の見方を持つようになり、それは良いことだと思います。
Javaのプロジェクトの多くはクリーンアーキテクチャ、クリーンコーディングに重点を置いているので、おそらくこれらは本当に素晴らしい意見でしょう。パターンを書き出してUMLで表現すれば、それで上手くいくのでしょう。個人的にはそのような環境では死んでしまいそうですが、それが一部の人々の生き方だということは理解できます。
ソフトウェアは多くの方法で成功裏に書くことができます。Excelでジェットコースターを書くことだってできるのです。