拙著「ちょうぜつソフトウェア設計入門」の発売から1年を記念した特別イラストです。毎年恒例だったなんとかパターンのシリーズは、ネタ切れでした。今年はこれ単品でご容赦を。 まえがき まずは、いまこそ明かせるちょうぜつソフトウェア設計入門(通称ちょうぜつ本)制作秘話、というほどではないですが、最初はこんな流れでした、というお話をしましょう。 GoFのデザインパターンを1人で書き切るアドベントカレンダーをQiitaでやると宣言し、最終回のバズりのおかげで個人総合1位の座に輝いたのは、2019年のことでした。そこから、技術評論社さんのSoftwareDesignにマンガで釣る入門者向けのシリーズを担当させていただき、その後単著の執筆を企画する機会をいただきました。 実は当初、このキャラクターで何か書く、とは決まっていたのですが「GoFパターンツアーとかでいいんじゃないですかね」ぐらいのゆるい感じでし

ちょうぜつ設計概要 ちょうぜつ設計とは、自分の手でプログラムを書かない人たちの思い込みに反して、一見不思議に見えるけれど、普通の現役エンジニアが当たり前に備えている、暗黙的なソフトウェア設計センスの常識のことである。クリーンアーキテクチャとアーキテクチャ実体のメタ関係と構造的に同じになる。 なぜ変更しやすく作るのか ちょうぜつ設計の目的は変更容易性である。変更が容易なソフトウェアでなければ、反復的な開発に耐えることはできない。 使い捨ての簡単なソフトウェアはウォーターフォールで作ることができる。ウォーターフォールに変更容易性を求めるのは、技術者の自己満足にしかならない。反復的な開発において、以前開発した箇所を調整する、あるいは、運用を続けているサービスを壊さずに機能拡張する、といった目的がなければ、変更容易性は不要である。現代のソフトウェアの主流は当然後者である。 変更容易性は、結果得られ

複雑なプログラムを書いてしまうのを避けるために、if 文の else を避ける制約を設けてプログラミングしてみましょう、というアプローチがあります。これはあくまで、ThoughtWorks アンソロジーに書かれていた、ある種のプログラミング思考のトレーニング方法のひとつにすぎないものです。 しかし、権威だからか、あるいは、あまりコードを書かない人がわかりやすいと感じるからか、プロダクションコードの規約に使おうとする誤った考えがあります。そんなことをすると、コード品質は下がります。 else 禁止制約というのは、「これまで if-else で記述していた多くのコードは、実は、生成するオブジェクトの多態性によって、分岐の前倒しが可能になるものだったのか」という認識を得られれば、すぐに忘れるべきルールです。 ある実在の OSS コードを例に説明します。 https://github.com/xr