今天有乙個學弟很認真地跟我聊了一些關於軟體工程有關的話題，現在我把我們的聊天記錄貼上來，希望聽聽各位老師的意見。（為保護隱私，文中隱去了直接的學生和團隊的名字）
干神，我覺得軟體工程其實和軟體關係不大，目前為止我的感受是它應該叫做工程管理，軟體的部分反而顯得很小。
軟體的部分反而顯得很小是指什麼？工程管理是必要的，做管理是因為這是乙個團隊的專案，專案經理本身就需要做很多管理的工作。不知道你覺得**有疑問呢～
管理本身沒有錯，如果每個人都是全職的軟體工程師，時間充裕的確沒問題。但是現在問題是每人平均每天最多有2小時花在軟工這門課上，其中近1小時用於管理和匯報，但是我們仍要完成足夠影響力的軟體。
這兩者結合的結果是很難同時做到很好，所以我說這門課偏向於管理，因為過程中被檢查的總是部落格和會議記錄，這些屬於管理方面。最後也只是看乙個大概的結果和資料作為軟體方面的評分，至於**是否可維護拓展(與架構相關)，api文件是否清晰(與傳承相關)等軟體方面的內容反而沒有被太多關注。
你說的有些道理，但是我有幾個問題問一下
1.為什麼每天匯報工作需要1個小時。scrum meeting之所以站立，就是希望將會議的時間在15分鐘左右，讓進度匯報不佔那麼長時間。至於燃盡圖，寫部落格，更新進度這些由專案經理負責，或輪值負責，不會拖整體的時間吧。
2.過程中檢查的不止是會議記錄和部落格，我們會看你們簽入的**，也會看你們團隊的合作。
每個人匯報+分配任務，很容易到半小時，多則45分鐘
我上次參與過某支隊伍的scrum，他們的會就開得很長，因為會有一些無用資訊摻雜進來了。比如上次有乙個同學，他提到分詞器，然後把分詞器目前的現狀什麼的講了一下，但是這些對其他同學來說重要嗎？這些東西其實是不太重要的，本就不需要讓每個人都知道你做的模組的原理。不知道你們團隊裡是否有這樣的情況？
scrum meeting的進度匯報盡可能簡短有力，有一下子解決不了的問題私下單獨交流，減少開會成本。沒問題就安排下一步任務。你可以在今天scrum的時候把握一下時間，如果今天開完scrum以後還覺得scrum非要45分鐘才可以結束的話，那你再來找我，說一說你們scrum時主要內容是什麼。
我覺得軟工這個課最後可能形成的東西是，表面有完整的管理體系，但是軟體本身就像乙個大作業，而不是乙個專案，管理是成體系了，但是軟體還不是成體系的軟體。
比如舉個例子，干神你們的物理實驗**，七八個實驗的前端**全部寫在了乙個頁面裡面，2000多行擠在一起，後面的人怎麼維護更新…
還有物理指令碼完全個人化了，我看得懂，上帝看不懂，這也是所說的軟體不成體系。
前端**這個我沒注意過，這個可能是我們的工程師習慣不好。
但是這些本來就應該是在你們考慮的範圍，之前你們的專案經理說要接手我們專案的時候我就說過，這個東西不是想象的那麼簡單，接手乙個專案可能要比新建乙個專案更困難。
軟體成體系的問題，我在上軟工課之前也沒有受過系統的訓練，我相信我們組其他人也一樣。所以你們在預估接手專案的風險時，就應該考慮到：學長的專案究竟是個燙手山芋，還是乙個香餑餑？你們究竟有多少時間用於真正的開發？你們維護的代價會非常大嗎？
我作為專案經理，我們是乙個面向使用者的需要快速迭代做出來的產品。我不能要求後端的人寫多麼詳細的注釋和清晰無誤的api文件，前端的人一定要用工程足夠規範的方法，我只能說：規範和文件是伴隨著工程量或使用者的增加而慢慢進行的，包括模組化，包括單元測試這些。架構的設計也是一樣，難道我們**最開始就要設計成可以處理千萬級請求的架構嗎？這不現實。
另外，我不同意每人每天最多只有2個小時用來開發的說法，如果這門課是必修課，或者是很高的學分，大家是不是重視程度就更高一些了？每個人對每件事情都有優先順序排序，我能理解。每個人在軟體工程課程花費時間不一，收穫也都不同。
第一，15分鐘的會議，無法對各成員的工作有充分的理解，既然是只是想知道做了什麼，也什麼要特意開乙個會呢？顯然每個人私信一下即可完成。如果說有什麼問題再私聊，會議上不多做討論，那這私聊的時間算不算會議的延伸？
第二，如果說軟體工程就是偏管理不教架構設計不講軟體程式設計規範那我是接受的，但顯然這導致了軟體內在問題很多，這個並不是說這課不好，只是側重點不同，選課之前和之後會有一點願望的落差而已。但是既然不講怎麼寫**怎麼管理**，那最終對軟體的要求終究是有所降低，希望有足夠使用者量，能夠執行下去的願望都是不堪一擊的，那麼最終評分的原則必須對管理方面有所傾斜，不能說沒教的東西評分過重。
第三還是那個說法，我們不是全職，所以做法應該有一定的自由度，不能說全部按照全職的那一套來。比如現在我們上課受到老師的質疑——老師希望我們是按使用者視覺來看問題，增加使用者所希望的新進展，當然成熟的產品自然沒問題，但是考慮到維護性，考慮到非全職，我們在過程中重構了的部分應該也算入工作量裡面，甚至我們一半的工作量都在於重構，即便是我功能沒有一點增加，但是我重構了乙個很好維護的東西，比之前好，也應該是我們的成績，不能說因為沒有增加特別多的功能，看起來和之前沒有差別就不算我們的工作，另一方面也是因為這既然是偏管理，那在軟體方面就應該降低要求。
重構**我認為是可以的。我之前跟另外的幾組也說過，只要說清楚你的重構是有意義的就可以，我不反對重構。而且重構的工作當然要算在工作量裡。
你們可以從不同的角度來闡釋軟體工程這個詞的含義，不論是面向開發者的，還是面向使用者的。物件不同，工作重心不同。老師認為對的，未必一定是正確的，你們按照自己的理解來，只要你們有收穫，能說明你們的工作是有價值的，那我這邊對你們絕對是肯定的態度。
羅老師質疑你們其實是因為：學霸online的那個**，四年重構了四次。所以羅老師害怕你們會有這樣的趨勢，才會質疑你們，他怕你們佔著已有專案的優勢不做對使用者有價值的工作。你們要抗住老師的壓力，在心裡把目標明確就可以。
的確一百個人有一百種**，**文件不全，主管跳槽了後面整個公司都開發受阻也不是不可能。
恩，那你們就抓住我們專案存在的缺陷，把它們按你們的理解去彌補、修復，我覺得這也是乙個很好的工作啊。
這是實際問題，根本問題還是大管理套小專案，工程管理和**管理分的比較開，我認為羅老師希望學霸online通過每一屆接手最終越做越好在這種情況下是不現實的。
所以我的立足點還是在你們自身的收穫有多大，而不是專案本身有多厲害。
嗯行。
北航軟工教學 前七周個人排行榜
個人week1 個人專案 個人week2 個人week3 結對專案 個人附加 結對附加 總附加總分 對映分1122941 109.5897 512158.5 1001195 8.539 1012875 5156.5 1001197841 87.5806 511144.5 961113 7.539 9...
軟工 軟工文件總結
1 定義 軟工文件是與程式開發 維護和使用有關的 材料，記錄了軟體開發活動和階段性成果 理解軟體所必需的闡述性資料。2 目的與作用 1 目的是為了保證專案開發的成功，最經濟的花費這些投資，並且便於執行和維護，在開發的每乙個階段都需要編制文件。2 作用是 a 作為開發人員在一定階段內的工作成果和結束標...
北航軟院初試總結
距離2020考研已經過去兩個多月了，成績也在十天前出來了。分數不高 政治 60，英語 55，數學二 71，專業課 資料結構與c語言 125，總分311.按照去年北航的分數線285來看，應該算過線了。總結一下考研的經歷 1 數學，是關乎考研成敗的一科，北航的數學單科線2019年是60分，雖然不高，但是...