昨日、私の友人の子供がソフトウェアエンジニアリングの専攻を申請し、ソフトウェアエンジニアリングでは何を勉強すればよいのかと尋ねました。それで私は彼に本のリストを作りました。
現在、大学は数多くの有名な専攻を開設しています。
一部のテクノロジー カテゴリ: クラウド コンピューティング、ビッグ データ、人工知能、モノのインターネット
一部のアプリケーション: 電子商取引、情報管理
しかし、個人的には、プログラミング言語を知っていて、オープンソースフレームワークを使用している人がたくさんいると感じていますが、中国にはシステム分析、システム設計、システムアーキテクチャの人材が不足しており、これらのコースは必要があると個人的に考えていますソフトウェアエンジニアリングのコアコースですが、我が国の単科大学のソフトウェアエンジニアリング専攻では、これらのことは教えていないようです。
（1）
ソフトウェアエンジニアリングもエンジニアリングです。
エンジニアリングについて考えるとき、私たちは次のことを思い浮かべます。
企画、調査、設計、テスト検証、レビュー
標準仕様・登録・認証
建築・プレハブ・大型建設工具
品質監督 品質保証、生産安全監督
プロジェクトのスケジュール管理/コスト管理/変更管理、技術文書管理
(2) システム分析
私は要件分析やシステム分析に関する良い本を勉強したことがなく、大学時代にシステムアナリスト試験に合格しませんでした。
要件分析に関して私が読んだ唯一の本は、「User Stories」です。
システム分析に関して私が読んだ本では、「分析パターン: 再利用可能なオブジェクト モデル」をお勧めします。実際、この本は副題を付けずに「Analytic Patterns」という名前の方が適切かもしれません。
分析の方法論というと、『ピラミッド・プリンシプル』という本がおすすめだと思います。
(3) システム設計
システム設計では、レイヤーとブロックの関係に特に注意を払います。この関係を切り離したり関連付けたりするにはスキルが必要です。そこで私は、『ドメイン駆動設計: ソフトウェアコアの複雑さに対処する方法』と『デザインパターン』の 2 冊の本をお勧めします。
デザイン標準シンボル：「UML Essence」。中国人が書いた『Elephant: Thinking in UML』という本もあり、これもとても良いです。
(4) アーキテクチャ設計
アーキテクチャに関しては、「Enterprise Application Architecture Patterns」と「The Way of Clean Architecture」という 2 冊の本が非常に優れています。
近年のソフトウェア アーキテクチャ スタイルは、コンポーネントから SOA サービス、マイクロサービスに至るため、次のことをお勧めします。
オブジェクト指向の時代：良い本を見たことがありません。さらに、Booch 先生の『オブジェクト指向分析と設計』は、建築設計にオブジェクト指向手法を使用することについての良い本ではないと個人的に感じています。
コンポーネント時代: 「COM エッセンス」、「EJB を使用しない J2EE 開発」
SOA時代: 「SOAコアテクノロジーとアプリケーション」
マイクロサービスの時代: 「サービス アーキテクチャの設計パターン」
(5) ソフトウェア開発
プログラミング言語やプログラミングフレームワークについての本はたくさんありますが、ソフトウェア工学の観点からソフトウェアの開発や実装について書いた本は非常に少ないです。
いくつかの本をお勧めします。
「テスト駆動開発」
「リファクタリング」
「コードをきれいにする方法」
「エクストリームプログラミング」
(6) 品質保証
本来、ソフトウェアのテストと品質保証はソフトウェア エンジニアリングの非常に重要な部分です。残念ながら、私は良い本を見たことがありません。ソフトウェアの品質という事実に誰もが注意を払っていないことがわかります。
(7) ツール
ソフトウェア開発用のさまざまなツールと言えば、IDE、フレームワーク、フロントエンド UI コンポーネント、実行ミドルウェア、データベースの開発に誰もが精通しています。ソフトウェア エンジニアリングの観点から見ると、誰もがさまざまな CI 継続的インテグレーション、CD 継続的リリース、DevOps ツールに精通しています。
おそらく私が無知なのかもしれませんが、このテーマに関して私が個人的に読んだ唯一の良書は、「継続的デリバリー: 信頼性の高いソフトウェアを公開するための体系的なアプローチ」です。
(8) 工程管理
ソフトウェアエンジニアリングマネジメントについて、全体のフレームワークの概要から学びたい場合は、まず「TOGAF標準マニュアル」をおすすめします。理由はわかりませんが、多くの人が TOGAF をソフトウェア アーキテクチャ手法とみなしていますが、私自身はそれが間違っていると感じています。ソフトウェア アーキテクチャを本当にやりたい場合は、上記のシステム アーキテクチャ設計のセクションで推奨した本を読むことをお勧めします。これらの知識だけで、ソフトウェアを真のアーキテクチャにできます。TOGAF を読んだ後は、ソフトウェアをアーキテクチャー化することはできません。多くの企業の IT 意思決定者は特に TOGAF の導入を好み、TOGAF を学習して使用した後はソフトウェアを構造化できると考えています。
総合部門なら「コード百科事典」、実践部門なら「Microsoft's Secret」がおすすめです。
プロジェクトマネジメントの本では『PMBOKガイド』がオススメです。私はソフトウェア開発プロセスに専任のプロジェクトマネージャーを導入することを強く推奨しますが、プロダクトマネージャーや開発部門長、開発リーダーにプロジェクト管理の責任を負わせないでください。これは大きな誤解です。
「The Mythical Man-Month」はソフトウェア エンジニアリングでは非常に有名な本ですが、読むことはお勧めしません。
ソフトウェア エンジニアリングについて考えるとき、非常に長いプロジェクト サイクル、多数の参加者、そして非常に重いプロジェクト プロセスを思い浮かべます。私自身、長年ソフトウェアの研究開発の分野に携わってきましたが、各専門部門の目標に一貫性がなく、情報共有や情報伝達の効率が遅い/情報が歪曲・歪曲されていると感じています。 。そのため、私は常に小規模チーム、無駄のない小規模チーム、フル装備のチーム、外科医スタイルのチームを提唱してきました。「SCRUM アジャイル ソフトウェア開発」という本を皆さんにお勧めします。
また、個人的にはアジャイルという表現があまり好きではなく、誤解を招いているような気がするので、今よく言われている市場と製品のマッチング、需要と実現のマッチングであるリーンという言葉を使いたいと思っています。ここ数年、ファーウェイのローカライゼーションの台頭により、誰もがファーウェイから学ぼうと急いでいたため、IPD の非常に古い語彙と手法が中国の IT 業界で普及しました。IPD が IBM から提供されたものであると考えると、誰もがこの方法は面倒だと思います。ただし、私は「IPD Huawei's R&D Way」と「IPD Refactoring Product R&D」の 2 冊の本をお勧めします。この2冊は元ファーウェイ関係者が書いたものですが、実際にはIPD、ましてやIBMのIPDが書いたものではなく、IPDと呼ばれていますが、内容はかなり新鮮で、市場と製品のマッチング、需要と実現のマッチング、市場-需要-製品-実現、各部門とポジションをどのように結び付けるか。
