変わった考え
- シンプルさは自然に与えられるものではなく、継続的な努力が必要な要素である
- 複雑性を管理したり理解したりすることに誇りを持つ理由はないと気づいた
- さまざまな経験レベルが混在するチームでは、型付き言語が必須である
- Javaは面白くないからこそ、むしろ優れた言語である
- REPLは設計ツールとしては有用ではないが、探索的な用途には有用である
- 実際のプログラミングは、コードを書く前の段階でほとんど完了しているべきである
- Frontend開発はKafkaesqueな悪夢のような領域になってしまい、もはや楽しくない
- 優雅さという概念は実際の測定指標にはなりえない
- まともなマネジメントは非常に貴重な存在である（長いキャリアの中で、まともなマネジメントをほとんど見たことがない）
- DynamoDBは、特定のワークロードに正確に合致するなら良いデータベースである
- オブジェクト指向は、うまく適合する領域では卓越した手法である。Functionalだけを盲信する態度は愚かである
新たに得た意見
- エンジニアリングの核心はコミュニケーションである
- JavaでMonadの概念を過度に適用してはならない
- Query Plannerは過酷な存在である
- 何かが「簡単だ」と感じる瞬間は、実はきちんと理解していないというサインである
- 新人開発者には探求し、失敗できる余裕を与えるべきである
- Soft skillは積極的に伸ばすべきである。投資効果がすぐに表れる
- 一般的なアプリケーション開発では、「本当に汎用的な抽象化」というものはほとんどない。必要なコードだけを書くほうがよい
- 一方で、ライブラリ開発は抽象を設計する仕事である。正しい構造（代数的な形）を見つけるために時間をかけるべきである
- ORMはあらゆる言語、あらゆる実装で問題が多い。素直にSQLを直接書くほうがよい
- Functionalプログラミングの問題は、しばしばその信奉者たちにある
- 十分に長い時間が経てば、Serverless Functionsの上にシステムを積み上げたことを大いに後悔するようになる
- Typeは、私たちが世界をどう見て断言するかを表すものである
- 分散ロックはいまだに非常に難しい問題である
- 形式的モデリングと分析能力は、必ず備えておくべき力量である
- 統合テストスイートで最も重要な特性は隔離性である
- DynamoDBは一般的なアプリケーション開発にとって最悪の選択になりうる
- ほとんどの人はコードの「職人技」にそれほど関心がない。関心を持つ人は大切にしつつ、そうでない人たちとは彼らのいる場所で協働すべきである
- Gradualでdependently typedな言語が未来だと思う
- テストコードには、どれだけコメントを書いても多すぎることはないと確信している
変わらない意見
- コードスタイルやリンティング規則など、些細な問題に執着する人たちは相変わらず変わった類いだと思う。もっと重要なことに集中すべきである
- コードカバレッジはコード品質と無関係だという立場を維持している（多くの場合、むしろ反比例する傾向すらある）
- Monolithは今でも十分に良い選択肢だと考えている
- 数十年にわたって蓄積されてきたRDBMSの研究と改善に勝つのは難しいと認める
- Micro-serviceを適用するには正当な理由が必須である（最近はますます当然視される傾向があって残念である）
- ほとんどのプロジェクト（AWS内部のプロジェクトでさえ同様）は、実際には「スケーリング」を必要としておらず、むしろスケーリングを前提に設計すると害になることが多い
- プロジェクトマネージャーの93%、もしかすると95.2%ほどは消えてもほとんど影響がないか、むしろ効率が上がるだろうと思う（4年前より割合が上がった）
- 15年目にはまたどう変わるのか見ていくつもりである
20件のコメント
業界で10年過ごした後、ソフトウェア開発に関する考えが変わった話題
ほとんどが共感できる話です
スケーリングが必要になる瞬間は、ほとんどのプロジェクトでは永遠に訪れないか、必要になる前に消えてしまうものです...
Gradual, dependently typed languages って何でしょうか..?
ポッドキャストで小耳に挟んだ話では、値が型に影響するような型システムらしいです。この記事の著者が関数型言語に触れているのを見ると、その話で合っているのでしょう。関数型言語の分野で研究・開発されているものですし……
たとえば、
List型が……値がすべてソート済みならSortedListになる……といった具合です。こういう性質があれば、コンパイル時の型検査でもっと多くのことを証明できるのでしょう。
ある関数が
SortedListを受け取ってSortedListを返す関数だとして……もしコードにバグがあってソート状態を壊してしまったら、コンパイル時に型エラーになるわけです。もちろん……型検査のコストはかなり高そうですが……
実用性がどこまで来ているのかは、正直まったく見当がつきません。
ああ、ありがとうございます。不思議な感じがしますね…
静的型付けと動的型付けの間を柔軟に行き来しながら適用できる言語を意味するそうです。
Javaはつまらないからこそ、むしろ優れた言語である
どういう意味ですか？
誰が書いてもだいたい似たようなものになるので、保守しやすい、という意味ではないでしょうか。
特別に気を配るべき点や開発者を驚かせるような部分がなく、そのこと自体に安定感がある、という意味で言ったのではないかと思います。
コードスタイルやlintに関することは、かなりの部分をツールで解決できるので、逆にそこを気にしない人に会うと、一緒に働きたくないと思ってしまいます。
同意します。私はCIにスタイルチェックを追加して、スタイルに準拠していなければマージできないようにしています。
> コードスタイルやリンティング規則のような些細な問題に執着する人たちは、今でも変わった部類だと思う。もっと重要なことに集中すべきだ。
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
ただし、そのまま見過ごしてはいけないという意見もあります。人間である以上、集中しにくくする要素なので、解決してから進めるほうがよいという話です。
> ほとんどの人はコードの「職人気質」にあまり関心がない。関心を持つ人は大切にしつつ、それ以外の人たちとは彼らがいる場所で協力していくべき
共感…
サーバーレスの上にシステムを積んで後悔している一人。
コールドスタートはいまだに遅く、
ある瞬間にトラフィックが急増して、オンデマンドと大差なくなり、
あらゆる手段を尽くしてもデプロイがあまりにも遅い。
コードカバレッジがコード品質と無関係だとすれば、
この2つではないかと思います。
テストコードは、高いカバレッジと、エラーを引き起こす多様なシナリオによって、同じ部分を異なる入力で何度もテストしてこそ、初めて意味を持つのだと思います.
後者の意味として解釈するほうがしっくりきますね。コードカバレッジという数値が高いことがコード品質に直結するわけではなく、意味のあるテストケースで埋めていくことが重要ですから。
> Javaはつまらないからこそ、むしろ優れた言語なんだ
なんだか面白いですね（笑）
共感します
> 一般的なアプリケーション開発では、『本当の意味での汎用的な抽象化』というものはほとんどありません。必要なコードだけを書くほうがよいです
業界で6年過ごした後、考えが変わったソフトウェア開発のトピック
Hacker Newsの意見