在第一章 緒論的第7頁 我看到了這樣的一段文字：
如果一架民用飛機上有需求，使用者使用它的概率是萬分之一，你還要做這個功能嗎？我的疑問是：每乙個細微的需求都需要得到滿足嗎？這裡像是玩了乙個文字遊戲，因為只提到了需求使用的概率是百萬分之一，但是並沒有做其他的任何條件約束。我按照我最真實的想法，選擇了直接忽略掉這個需求，但之後才知道這個百萬分之一是飛機的安全方面的訴求，那麼它的確是有必要去做的。也許是寫在緒論這裡為了言簡意賅，所以說的比較不嚴謹，我認為大多數使用概率極低的功能都是可以砍掉的，因為面面俱到是一種臃腫的實現方式，我們應該為使用者提供簡明方便的使用方法。比如我們常用的office辦公軟體，也許它也可以包含許多百萬分之一概率使用到的功能，那麼它的介面和下拉列表對於使用者來說還是友好的嗎？所以我認為商業化的軟體反而要敢於刪減自己的功能，從而提供良好的使用者體驗。
其實本書在後面的章節對於類似的問題也給出了很好的解決方案。在書中的第8章 需求分析中已經有提到，對於需求要考慮他們的優先順序，要著重實現那些殺手功能，並且參照在166頁提到的功能的象限劃分，對於乙個軟體的不同功能，我們可以採用維持、抵消、優化、差異化和不做五種不同的方式來應對。對於那些基本用不到的功能並且不是必要需求的殺手功能，我還是秉承自己的觀點，大可不做。
在第三章 軟體工程師的成長 的 3.2思維誤區 49頁 我看到了這樣的一段文字：
過早優化是一切罪惡的根源。我的疑問是：是否可以在寫軟體的某個模組的時候進行適度的優化呢？其實在之前的程式編寫時也遇到過類似的問題，比如乙個類中定義了很多的屬性和方法，並且這些屬性和方法在其他的地方也得到了呼叫，但是如果在整體寫完後想要對這個類內部的一些方法進行優化，有時候會增補或者刪掉一些屬性，或者可能改變某些方法呼叫的引數、返回值或者是它的功能，那麼在其他呼叫的地方就要進行相應的修改，這樣可能會造成很大的工程量並且容易引發新的bug。如果我本身的軟體工程水平不高，沒有在寫程式前高屋建瓴的想好所有的布局，那麼在優化的時候遇到這樣的問題就很麻煩，所以我之前會寫完乙個模組後嘗試進行一些優化，並且感覺效果也不錯。所以我覺得這句話說的太絕對了，應該是對於某些極致優化的過分執著才是一切罪惡的根源。
在讀完第六章 敏捷流程 和 第九章 專案經理 之後我有這樣乙個疑問：
既然敏捷已經成為了一種風潮，並且在敏捷的體系中大家集思廣益，不需要pm來制定什麼計畫，那麼pm這個職位還有存在的必要嗎？pm會最終被淘汰掉嗎？但我又始終覺得乙個敏捷的團隊也可以擁有乙個pm來起到燈塔作用，傳統的體系與敏捷的體系能結合嗎？
在第十一章 軟體的設計與實現 中提到了構建這個概念，並且在235頁有這樣的一段話：
在我們的全球調查中，我們發現成功的公司中有94%每天或者至少每週完成構建，而不成功的公司絕大多數每月甚至更少的去做構建``````我的疑問是：構建具體指的是什麼？是說每日對於要做的軟體的乙個功能的規劃嗎？因為這本書的名字就是《構建之法》，我理解的構建就是文章對於軟體的結構以及團隊組成、合作等一整套的方法。但這些都是巨集觀上的，那麼每日要做的構建究竟是幹什麼，怎麼幹。後文雖然有乙個對話形式的解讀，但是還沒有弄清楚。
在第十六章 it行業的創新 中，有這樣一段話：
創新的人士的關鍵特點不是喜歡冒險，也不是躲避風險，而是從錯誤中回覆並繼續努力，就像文言文說的「屢敗屢戰」。我的疑問是：風險究竟要不要躲避？因為很多的創新對於個人或者團隊而言都是極大的風險，比如資金、時間、或者其他機遇。如何評估自己所謂的「創新」是真正的創新，而不是徒勞無功的嘗試呢？
-何時：2023年
-何地：美國
-何人：margaret hamilton
「軟體工程」一詞是margaret hamilton在阿波羅計畫期間發明創造出來的
在2023年夏季奧林匹克運動會開幕典禮上，伯納斯-李獲得了「全球資訊網發明者」的美譽。他本人也參與了開幕典禮，在一台 next 計算機前工作。他在 twitter 上發表訊息說：「這是給所有人的」，體育館內的 lcd 光管隨即顯示出文本來。-優點：是乙個工作流協作的引擎，它允許乙個團隊使用他們自定義的流程，並使用在專案歷史中實時收集起來的乙個集中的資料倉儲。整合性。版本控制系統和工作項儲存器在註冊時整合在一起。當註冊時，可以將其與乙個或多個工作項關聯。並且任務版上能將需求、專案進度一覽無餘，對小團體適用。
-缺點：tfs通過複雜的看似功能強大配置管理，將聯機看做是整個專案週期的常態，這在實際使用中造成極大的不便。能應用起來的團隊、公司的數量極少，多數真正用起來，也就是源**管理這部分，這也僅僅是佔tfs極小部分功能。
-優點：基於web，允許你使用git的源**管理功能，並且上面有大量的開源程式。
-缺點：訪問速度緩慢，對於企業而言使用起來成本較高。
-優點：svn允許乙個檔案有任意都的可命名屬性，功能十分完備，並且svn會關心所有的檔案型別，不需要你來手工操作。
-缺點：要將許可權控制檔案儲存為svn支援的utf-8格式，乙個庫可以有多個工作目錄但乙個工作目錄只能對應乙個庫雖然可以更改庫位置但是要求很嚴格，庫中檔案存放方式，看不到檔案真正的內容。而且svn速度超慢。提交、更新、瀏覽歷史的速度都很慢。
-優點：力求不影響現有團隊的開發過程，良好的擴充性，以里程碑的方式進行專案管理。並且是乙個為軟體開發專案需要而整合了wiki和問題跟蹤管理系統的應用平台，是乙個開源軟體應用。
-缺點：功能不是很強大，使用有很大的侷限性。
-優點：支援設定保護分支，被保護的分支只有指定的一些成員才可以寫（更新），其他成員只有讀的許可權。這在開發中可以避免一些重要的分支被成員隨便修改。而在預設情況下，專案內的所有成員都有對專案的所有分支的全部許可權，包括讀、寫、刪除等等。
-缺點：產品的改進也非常少，基本已經落後。
-優點：是乙個開源的缺陷跟蹤系統，它可以管理軟體開發中缺陷的提交，修復，關閉等整個生命週期。並且具有強大的檢索功能， 使用者可配置的通過email公布bug變更。
-缺點：是專門為unix定製開發的，不是所有的作業系統都可以使用。
-優點：mercurial 是一種輕量級分布式版本控制系統，採用 python 語言實現，易於學習和使用，擴充套件性強。並且它管理起來很輕鬆。
-缺點：不是很靈活。
-1. github：約31,000,000使用者量
-2. sourceforge：約3,700,000使用者量
-3. bitbucket：約5,000,000使用者量
軟體工程 個人閱讀作業2
標籤 軟體工程 1，在第四章 兩人合作 中，p92頁提到兩人合作的不同階段和技巧，文章著重強調如何使一方去影響另一方，如 如何影響對方 p94 如何正確地給予反饋 p95 作者只看到一方而忽略了雙方。如果被動方自己本身並不願意接受，那麼主動方所做的一切就顯得有些蒼白無力。如何正確看待別人對我們的意見...
軟體工程 個人閱讀作業2
標籤 軟體工程 1，在第四章 兩人合作 中，p92頁提到兩人合作的不同階段和技巧，文章著重強調如何使一方去影響另一方，如 如何影響對方 p94 如何正確地給予反饋 p95 作者只看到一方而忽略了雙方。如果被動方自己本身並不願意接受，那麼主動方所做的一切就顯得有些蒼白無力。如何正確看待別人對我們的意見...
軟體工程第1次作業
在閱讀此書的時候，我盡量和自己的實際經歷結合起來思考，的確產生了一些想法。年輕學生都志向遠大，上了一些課，就很想解決高層次的問題，一些學生非常想做高層次的 科研 覺得 工程 是基礎，沒意思。而且他們認為 我已經知道怎麼做了 我應該是書上例子的反面，最開始就是打算解決中低等層次的問題。在學習理論知識的...