エンジニアが知っておくべき「ソフトウェア品質」の正体とは？（2022年版）

この記事では、ソフトウェア開発における「品質」という概念をどう定義し、日々の開発に落とし込んでいくべきかを深く掘り下げています。単にバグがないことだけが品質ではありません。保守性、テスト容易性、そしてプロダクトの持続可能性を考慮した設計思想について、当時の視点から考察した名記事です。

もしソフトウェアの品質を真剣に考えている会社があるなら、給料が7割減でもいいからそこで働きたい。

（2022年）

それはいいんだけど、どうやってバイクを直せばいい？

ジーン・キムは『DevOps ハンドブック』を書いた人だし、関連するDORAや『ザ・フェニックス・プロジェクト』、『ユニコーン・プロジェクト』といった小説形式の書籍にも関わっていたはず。それらとGoogleの『SREサイトリライアビリティエンジニアリング』を読めば、AIエージェントや新人の開発者たちが押し寄せてくるSDLCパイプラインの中でも、自分の価値を保ちながら彼らを導いていけると思う。システム設計の論理的な見直しにはXuの『System Design Interview』の1と2、企業のプログラム全般には『データ指向アプリケーションデザイン』、そしてクラスやモジュール単位からシステム全体に至るまで、SOLID原則やGoFデザインパターンを曖昧に適用したり、12ファクターアプリのデザイン原則を盲目的に当てはめたりすることなく、明確なモジュールの境界を定義するならCockburnの『Hexagonal Architecture Explained』がおすすめ。昔は単純作業が多すぎて品質は二の次だったけど、AIのおかげで優れたものを作るコストが下がったんだから、環境が許す限り最高を目指そうぜ。

この記事は話が脱線気味だし、ソフトウェアの品質が低下する一番の要因である「要件変更」について触れるのを忘れてるな。

どんなに素晴らしい抽象化を駆使した完璧な設計でも、一度の要件変更で台無しになることなんてザラにあるんだから。

このトピックについては過去に多くの議論が蓄積されているSWEBOKから学ぶのも一つの手かもね。

「テスト」は「品質保証（QA）」じゃない。これだけでも記事を読んだ甲斐があったよ、本当にそう叫びたい気分だ。

前回の議論...

ソフトウェア品質をどう考えるか (2022) - https://news.ycombinator.com/item?id=39490543 - 2024年2月 (コメント66件)