  |
はてなキーワード: UMLとは
資格取得向けではない
賛否両論もあると思うが、IT系現場で働いていたり交流すると話に上がる本がメイン
勉強ももちろんだが、現場の話題についていくという点において読んでおいて損はなさそう
| 書籍 | 主なテーマ | 現在の位置づけ |
| ------------------------ | -------------------- | -------------- |
| 人月の神話 | ブルックスの法則、概念的完全性、銀の弾丸 | ソフトウェア工学の最重要古典 |
| ピープルウエア | 生産性、組織、作業環境、チーム形成 | 開発組織論の古典 |
| 達人プログラマー | 技術者の姿勢、抽象化、自動化、変更容易性 | 現代でも読みやすい準古典 |
| Code Complete | コーディング、設計、レビュー、品質 | 実装技術の百科事典 |
| ソフトウェア作法 | UNIX的なプログラム設計と思考法 | プログラミング文化の古典 |
| プログラミング作法 | 命名、デバッグ、テスト、性能、移植性 | C中心だが原則は普遍的 |
| 珠玉のプログラミング | アルゴリズム的問題解決 | 計算量・問題分解の古典 |
| 計算機プログラムの構造と解釈 SICP | 抽象化、評価、言語処理系 | コンピュータ科学寄りの古典 |
| 書籍 | 内容 |
| ------------------------------------------------------- | ------------------- |
| リファクタリング 第2版 | 振る舞いを変えずに内部設計を改善する |
| レガシーコード改善ガイド | テストのない既存コードを安全に変更する |
| Clean Code | 命名、関数、クラス、可読性 |
| テスト駆動開発 | TDDの基本的な進め方 |
| Growing Object-Oriented Software, Guided by Tests | テストからオブジェクト設計を成長させる |
| Working Effectively with Unit Tests | 単体テストの設計とテスト容易性 |
| A Philosophy of Software Design | 複雑性を減らす設計 |
| The Programmer’s Brain | コードを読むときの認知負荷 |
| 書籍 | 位置づけ |
| --------------------------------- | ------------------ |
| オブジェクト指向における再利用のためのデザインパターン | GoFデザインパターンの原典 |
| Head Firstデザインパターン | パターンの入門書 |
| アジャイルソフトウェア開発の奥義 | SOLID、パターン、アジャイル設計 |
| エンタープライズアプリケーションアーキテクチャパターン | 業務アプリの設計パターン |
| 実践UML | オブジェクト指向分析・設計 |
| オブジェクトデザイン | 責務駆動設計 |
| 書籍 | 内容 |
| ------------------------------------------- | ------------------- |
| ソフトウェアアーキテクチャの基礎 | アーキテクチャ特性、スタイル、意思決定 |
| ソフトウェアアーキテクチャ・ハードパーツ | 分割、粒度、データ、トレードオフ |
| Clean Architecture | 依存関係、境界、ユースケース |
| エンタープライズアプリケーションアーキテクチャパターン | 業務システムの設計パターン |
| Domain-Driven Design | 複雑な業務領域のモデル化 |
| 実践ドメイン駆動設計 | DDDの実践的な適用 |
| Building Evolutionary Architectures | 変更可能なアーキテクチャ |
| Fundamentals of Software Architecture | 現代アーキテクチャの概論 |
唯一の正解ではない
「依存関係を内側に向ける」「業務ルールをフレームワークから分離する」という考え方を学ぶ本であり、すべてのアプリを同じ円形の構造にする本ではない
| 書籍 | 内容 |
| ------------------------------------------- | -------------------- |
| データ指向アプリケーションデザインDDIA | DB、分散処理、一貫性、レプリケーション |
| 分散システムタネンバウム | 分散システム全般の教科書 |
| Designing Distributed Systems | 分散システムの設計パターン |
| Release It! | 本番障害、安定性、回復性 |
| Site Reliability Engineering | SRE、SLI、SLO、運用 |
| Building Secure and Reliable Systems | セキュリティと信頼性 |
| Web Scalability for Startup Engineers | Webシステムのスケーリング |
| System Design Interview | システム設計の考え方を広く学ぶ |
| 書籍 | 内容 |
| -------------------------------- | ----------------- |
| マスタリングTCP/IP 入門編 | 日本で最も定番のTCP/IP入門書 |
| コンピュータネットワークタネンバウム | ネットワーク全般の教科書 |
| コンピュータネットワーキング トップダウンアプローチ | アプリケーション層から学ぶ |
| ネットワークはなぜつながるのか | ブラウザからサーバーまでの流れ |
| 書籍 | 内容 |
| ----------------------------------------- | ------------------- |
| 詳解TCP/IP | TCP/IPの古典 |
| TCP/IP Illustrated | パケットレベルの詳細 |
| High Performance Browser Networking | TCP、TLS、HTTP、ブラウザ通信 |
| パケットキャプチャの教科書 | Wiresharkなどを使った解析 |
| 書籍 | 内容 |
| -------------------------------- | ---------------- |
| Real World HTTP | HTTPの歴史と現代的機能 |
| Webを支える技術 | HTTP、URI、REST |
| HTTP: The Definitive Guide | HTTP/1.1時代の体系的解説 |
| Web API: The Good Parts | Web API設計 |
| 書籍 | 内容 |
| -------------------------------- | --------------- |
| オペレーティングシステム 3つの簡単なピースOSTEP | 仮想化、並行性、永続性 |
| Operating System Concepts恐竜本 | OSの標準的教科書 |
| 詳解UNIXプログラミング | UNIXシステムコール |
| Linuxプログラミングインタフェース | Linux APIの詳細 |
| Linuxのしくみ | Linux内部の入門 |
| ふつうのLinuxプログラミング | Linux上でのプログラム実行 |
| 30日でできる！OS自作入門 | OSの動作を作りながら学ぶ |
| コンピュータシステムの理論と実装Nand2Tetris | 論理回路からOSまで |
| 書籍 | 内容 |
| ------------------------------ | --------------- |
| データベースシステム | DB理論の教科書 |
| Database System Concepts | DBの標準的教科書 |
| SQLアンチパターン | よくあるDB・SQL設計の失敗 |
| 達人に学ぶDB設計 徹底指南書 | 論理設計、正規化、性能 |
| 達人に学ぶSQL徹底指南書 | SQLの考え方 |
| SQLパフォーマンス詳解 | インデックスと実行計画 |
| High Performance MySQL | MySQLの性能設計 |
| PostgreSQL徹底入門 | PostgreSQL固有機能 |
| 書籍 | 内容 |
| ------------------------------------------- | -------------- |
| 体系的に学ぶ 安全なWebアプリケーションの作り方徳丸本 | Webセキュリティの国内定番 |
| Web Application Security | Webアプリの脆弱性と防御 |
| The Web Application Hacker’s Handbook | Web攻撃手法の古典 |
| Security Engineering | セキュリティ工学全般 |
| 暗号技術入門 | 暗号、ハッシュ、署名、証明書 |
| マスタリングTCP/IP 情報セキュリティ編 | ネットワークセキュリティ |
| Threat Modeling | 脅威モデリング |
| Building Secure and Reliable Systems | セキュアで信頼できる運用 |
| 書籍 | 内容 |
| ------------------------------------ | -------------- |
| アルゴリズムイントロダクションCLRS | アルゴリズム分野の標準教科書 |
| アルゴリズムとデータ構造 | 大学教科書的な基礎 |
| 珠玉のプログラミング | 問題解決の古典 |
| プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 | 実装を伴う学習 |
| 問題解決力を鍛える！アルゴリズムとデータ構造 | 日本語での実践的入門 |
| The Algorithm Design Manual | 問題に適したアルゴリズム選択 |
| 書籍 | 内容 |
| --------------------------- | ------------- |
| テスト駆動開発 | TDDの原典 |
| ソフトウェアテスト技法ドリル | 同値分割、境界値など |
| はじめて学ぶソフトウェアのテスト技法 | テスト技法の定番 |
| 実践ソフトウェアエンジニアリング | 開発工程と品質全般 |
| Googleのソフトウェアエンジニアリング | 大規模開発、テスト、保守 |
| 単体テストの考え方／使い方 | 良い単体テストの設計 |
| xUnit Test Patterns | テストコードのパターン集 |
| Continuous Delivery | 自動テストからリリースまで |
| 書籍 | 内容 |
| ----------------------------------- | ------------------ |
| The DevOps ハンドブック | DevOpsの実践体系 |
| Accelerate | 開発組織とデリバリー性能の研究 |
| Continuous Delivery | 継続的デリバリーの原典的書籍 |
| Site Reliability Engineering | GoogleのSRE |
| The Site Reliability Workbook | SREの実践 |
| LeanとDevOpsの科学 | Accelerateの日本語版 |
| Infrastructure as Code | IaCの原則 |
| Kubernetes Patterns | Kubernetes上の設計パターン |
| Release It! | 本番耐性と障害対策 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
| Kubernetes完全ガイド | Kubernetesの体系的な理解 |
| Kubernetes Patterns | Kubernetesの設計パターン |
| 入門 Kubernetes | Kubernetesの概念 |
| Docker系の入門書 | コンテナの操作 |
| Infrastructure as Code | インフラのコード化 |
| Cloud Native Patterns | クラウドネイティブ設計 |
| クラウドデザインパターン | クラウド上の設計パターン |
AWS、Azure、Google Cloudについては、以下を優先する
| 書籍 | 内容 |
| ------------------------------------- | -------------- |
| 要求工学系の教科書 | 要求の抽出・分析・管理 |
| ソフトウェア要求 | 要求定義の体系 |
| ユーザーストーリーマッピング | ユーザー行動と開発計画 |
| ユースケース実践ガイド | ユースケース記述 |
| RDRA2.0ハンドブック | 要求とシステム構造の整理 |
| 実践ドメイン駆動設計 | 業務モデリング |
| Domain Modeling Made Functional | 型を使ったドメインモデリング |
| イベントストーミング | 業務知識の探索 |
| 書籍 | 内容 |
| ------------------------- | ------------ |
| 誰のためのデザイン？ | 人間中心設計の古典 |
| インタフェースデザインの心理学 | 認知心理とUI |
| ノンデザイナーズ・デザインブック | レイアウト・配色・文字 |
| Don’t Make Me Think | Webユーザビリティ |
| About Face | インタラクションデザイン |
| デザインシステムの育て方 | デザインシステム |
| Lean UX | 仮説検証型のUX開発 |
| 書籍 | 内容 |
| ---------------------------- | ----------------- |
コードが書けるじゃなくて、「誰でもアプリを、システムを作れる」というもう一つ上のレイヤー。
殆んどの人にとって「やりたいこと」は「コードを書くこと」ではない。
例えば、ファイル整理の自動化、コンテンツの一括取得、パラメータの最適化といった具体的な課題を解決することである。
プログラミングはそのための手段であり、目的ではない。これはAI以前から変わらない。プログラマ自身もまた、「面倒を減らすため」にコードを書いてきたのである。
ーーー
別の話
「Writeing」能力と「Reading」能力は 別であるということ。
文法上正しく書く というのと、 文法上正しく書かれたものを読む のとでは必要とする 能力レベルが異なる。
文章は読めるし単語は書けるけれど、文章が書けない。という人はそれなりに居る。
否。
何のために読むのか？
「意味」を理解する必要があるのであって表層であるコードを読める必要はない。
別にAI以前の時代でも既存アプリやコードの意味を解析する際に、機械語を逆アセンブラや逆コンパイラで読みやすい別の形に変えたり。
もっと言えばUMLやコールグラフと言った図という文字列以外の方法で理解してきたのだから。
例えば、例外をthrowする構文をしらなくてもいい、throwされた例外をcatchするための構文を知らなくてもいい。
読めないのに理解できるのか？
AIに説明させればいい。理解できるまで何度も、質問すればいい。図示してもらってもいいし、もっと基本的な条件分岐から教えてもらってもいい。
多くの人が機械語を読んでいるか？もっと言えば、プロセッサ内で期待通りパイプラインが組まれてるか？メモリは期待するタイミングでバス転送されているか？ペリフェラル制御は？
コンパイラも、チップも多いわけではないがそれでも毎年コンスタントにエラッタは出てる。
AI以前ですら最下位レイヤの表現を「読める」エンジニアはほとんどいない。
結局自分が「読める」レイヤで期待通りの動作するかテストすることでしか 検証できてないのだから。
机上での話なら、
「実際そのままでは動かない、AIエージェントで設計から実際に動くプログラムを作れる」
って話に
「いやUMLで動くなら」
って反論風に噛みついてきたのは何でなん？
UMLが動かす
でも
UMLで動かす
でも
UMLを動かす
でもどれでもいいぞ。さあやってみろ。
お前はまさかUMLで書いたからってコードじゃないから動かないとかマジで言ってるのか？
そもそもお前の言ってたのはUML「が」動くとかUML「を」動かせとかいう話だぞ
お前は「で」と「が」と「を」がおんなじか？
なんでもミソもクソもおんなじか？
お前はバカか？
なんかそういうツール使うってこと？
ノーコードとか超高速開発とか言ってプログラミング無しにソフト作るのを流行らせようとしてる勢力がいたのは知ってるけど、別に流行らなかったよね
いや君は日本語で異常系とかやってたから動かなかったんだろうけど
俺は普通にUMLで動くレベルなら普通に動くってかむしろUMLがちゃんとしてないから動かないんだけど
ロジックを君自身が分かってないのにAIで動かしてるってこと？
どういうソフトなの？俺が今やってるのとかはコンプライアンス絡みでロジックの厳密性が一番ヤバい部分なのでそこはAIにやらせられないが
