【軟工作業&思考】關於軟工的一些概念性理解暨第一次閱讀作業
其實呢，以前本身我這塊不存在特別多的直接疑惑，畢竟以前本人有過相當的專案實踐經驗，對有些事情還是相對了解的。
既然如此，那在這裡筆者就簡單說下之前的問題在本學期中所面臨的一些真實狀況。
這塊的話，我們團隊整體做的還算可以。分工相對明確，大家都有一定的熱情和積極性。並沒有出現寡頭壟斷的情況，所以自然也不存在後續的崩盤之類的。
這部分的話，我們團隊內各自對這個專案，以及這個專案中自己的得與失，還算是基本拎得清的。總而言之整體上合作愉快。
筆者之前的話，其實在多個技術團隊做過事情，基本上沒啥問題。
但是，之前的團隊不管怎麼說，協作者都是有著相當完善的工作經驗的。而在軟工課程中所面對的這個團隊確實一群完完全全的學生。於是在很多地方就存在了思想上的衝突：
學生：這樣的矛盾其實很顯然，雖然我某種意義上大概能理解為啥很多人會有這樣的學生思維（實際上很早以前的我也差不多，只不過經歷的比較早而已），但是很多時候為了更長遠的利益，卻又不能妥協。然而講道理卻又不是什麼時候都能行得通的，畢竟視野深度和廣度存在明顯的代差。
於是在這樣的情況下，如何和具有代差的人相處並做好事，就是乙個亟待思考的問題了。
正如筆者在前面的部落格中所寫：
世上只有利益上相互依存的關係，才可能是穩定的關係。同時，基於上面一點的論述，不難發現技術段位差距較大的人，已經容易存在眼界和視角上的代差。那麼在現實的組織架構中，乙個高層管理所能看到和察覺到的問題，可就和下層的人相比起來差別大了去了。
所以，在這樣情報嚴重不對等，甚至很多時候連深層的信賴關係都難以達成的情況下，能依賴的唯一紐帶就是共同的利益關係。或者也可以說，正是因為很多的下層人員與上層所共同考慮的問題也基本只有利益（996事件中，大部分基層程式猿的發聲，基本邏輯都是如此），所以利益也是最靠得住的一種紐帶。
那麼問題來了，在這樣嚴重不對等且沒有信賴關係的情況下，利益共同體該如何達成？是否有一些一般性的思路。
先說說個人目前的一些粗淺認識，思路有兩種：
既然沒有信賴關係，那就建立信賴關係
綜上，實際上在上下級這一層的關係維繫上，是存在這樣乙個很尷尬的僵局的。所以，這塊應該還是需要一系列更成熟的思路和解決方案。還望不吝賜教。
同樣的，實際上在合作方之間，也會存在這樣的一層問題。
簡單來說，人家也有人家的利益。人家不可能因為你胡吹出來的那點所謂的「情懷」、「信仰」，就來和你談合作，因為人家也是人，也得吃飯，也和你一樣沒有太多的時間做無意義的事。
和上面一條基本類似，此處不再做詳細描述。
首先，需求層面，需要從兩個角度來分析：
乙方。對於程式猿而言，很多時候只有知道明確的需求才能進行工作。然而如上文所言，甲方是不可能做到直接給出這樣的明確需求的。於是這個時候，pm的乙個重要職責就是在甲方和程式猿之間建立乙個橋梁，將甲方需求轉化為開發需求。同時也需要在和甲方溝通的時候，對程式猿們有充分的了解（比如大致了解哪些東西可做，哪些東西好做，哪些東西不可做）。
在需求層面基本明確的情況下，那麼設計也就該提上日程了。
設計也分為幾個層面：
實現這塊，則需要在整體架構設計相對明確的情況下進行。
此外，在實現的過程中，最好伴隨著主幹功能的實現，一併將單元測試也進行實現。
除此之外，還需要在開發實現的過程中，注意後續的可維護性（實際上個人感覺開發與維護這塊本身就是一體的）。
本學期對我而言，實際上只相當於把以前做過得事情再次弄了一遍。唯一一點比較重要的差異，在於這次的團隊配置和以前大不一樣（前文有說到）。所以能總結的內容其實很有限。
不過實際上，筆者也在思考這個課程的一些得與失。同時，筆者也在這個學期當oo的助教，對有些問題也算是有那麼一些略微的認識，在這個部分我就著重說下這方面的問題吧。
首先，這個課程是乙個只有一學期的課程。而且一學期時間，涵蓋了三個階段，包含了那麼多個環節。
老實說，以我之前做創業專案的實際體驗來看，除特殊情況外，一般不會有週期如此之短的事情。
而且這樣的短週期還會帶來另乙個問題，那就是很多要素的重要性的體驗嚴重不足。例如：
實際上，在oo課程哪邊，也一樣存在類似的問題。oo和軟工的乙個共同特點，那就是有些內容是很概念化抽象化的，與其說是技術技能倒不如說更像是概念機能。在短週期內想做到這件事，並不容易，甚至一定程度上，軟工比oo面臨的形勢只會更加嚴峻。
在這樣的環境下，如何把握好整個週期，如何把有些該體現的內容充分體現出來，讓學生在學習過程中把這些內容落到實處而不是流於形式，則是需要課程組好好考慮的問題。
如題，很多的指導還是偏向了理論，和實際操作的結合有一定的錯位。這就導致一些組或者個人，到了一定階段會開始陷入很大的迷茫，而且還沒有辦法通過理論課的講解來進行補足。
其實，這件事說來並不能全怪這門課程。學生在學習這門課程之前，實際上一些前置知識還是比較匱乏的。比如一些考慮問題的基本方式，以及一些架構布置方面的基本功（這塊2016級及以上會表現的比較明顯，因為oo這塊的整體學習質量不夠好；相比之下2017級，也就是明年開始，因為今年oo大規模課改，同學們的這塊能力會有明顯的好轉）。於是實際上，我們的指導需要分為幾個階段：
步入正軌
其實oo也有類似的一些過程：
步入正軌
今年所採用的模式，是兩部分交織著進行。在第二單元多執行緒結束後基本完成起步階段的教學，但是正軌部分實際上第一單元就開始了。保證學生做到不至於營養不良，也不至於營養過剩，飯一口一口吃，事情一點一點做。到了起步階段完全結束的時候，一多半的同學已經具備了完整的架構思維，剩下的就是不斷優化追求卓越了。
所以建議課程組也在這個問題上多下一些功夫，要切實了解起來學生的真實情況。
如題，實際上助教在同學這邊的存在感實在是很低（相比於機組和oo課程而言），一整個學期除了通知訊息之外基本見不到助教出沒，甚至通知訊息也都是高階助教乙個人在不斷的通知。
助教，其實是個很微妙的職業。說微妙，其實原因如下：
助教的這一特點其實很微妙，老師、學生，都整體上缺乏某一方的資源，而助教卻完全有這種可能打破資源時空分布不均的困局（甚至部分比較厲害的助教自己乙個人就能完整的掌握兩頭的情報）。
於是，個人認為，助教的乙個職責就是——充當起師生情報傳遞的橋梁。
如果追求更深層次的話，那就是——基於雙邊的情報，優化雙邊資源配置，一達到乙個全域性更優的解。
所以，其實建議助教們看到這句話也能好好思考一下。我相信助教們也都應該是有志於改進整個課程的人，那就好好思考思考我說的這些，想想看自己到底該做點什麼，而不是只是一味充當苦力，或者乾脆只是乙個傳話筒子（而且搞不好還是單向的）。
軟體工程課程總結
出於課程作業的要求，以及個人有一些想要說明的感想，所以發布這篇部落格。有所冒犯和不適當的言論，敬請體諒。由於這一點的特性，課程中介紹需求獲取 介紹使用者故事 用例建模等知識的時候，我並沒有太過關注，因為這些方 和與程式設計不直接相關的知識並不能讓我感到對作業有多少的增益。雖然我也很理解，關於這些知識...
《軟體工程》課程總結
經過這次軟體工程實踐後，感覺對軟體工程這門學科有了深一層的認識。軟體工程是一門重視實際操作的科學。對於軟體產品，無非是產品定義 設計 除錯維護幾個步驟，看似簡單，可是實際操作卻複雜困難，它不比其它行業產品可預見可觸及，所以學好軟體工程能為以後從事軟體開發行業打好基礎。在軟體實踐這門課中，講到了有效利...
軟體工程課程總結
這學期的軟體工程的這門課，經過老師由淺入深的引導和講解，我從各個方面了解到了關於軟體開發的知識，對自己未來的工作與事業有了乙個新的認知，明白了如何去分析和處理問題的過程，應該說其範疇已經遠遠不止侷限於該門課程，成為了乙個綜合的乙個能夠解決問題的思想集合。在這學期的課程中,加深了對軟體工程的理解,軟體...