【做業】軟件工程課程總結博客

原博客地址

【軟工做業&思考】關於軟工的一些概念性理解暨第一次閱讀做業

關於之前的一些疑惑

其實呢，之前自己我這塊不存在特別多的直接疑惑，畢竟之前本人有過至關的項目實踐經驗，對有些事情仍是相對了解的。

既然如此，那在這裏筆者就簡單說下以前的問題在本學期中所面臨的一些真實情況。

PM作開發和測試以外的全部事情

這塊的話，咱們團隊總體作的還算能夠。分工相對明確，你們都有必定的熱情和積極性。並無出現寡頭壟斷的狀況，因此天然也不存在後續的崩盤之類的。

豬、雞和鸚鵡的故事

這部分的話，咱們團隊內各自對這個項目，以及這個項目中本身的得與失，還算是基本拎得清的。總而言之總體上合做愉快。

新的問題

如何與技術段位差距較大的人相處或達成一致

筆者以前的話，其實在多個技術團隊作過事情，基本上沒啥問題。

可是，以前的團隊無論怎麼說，協做者都是有着至關完善的工做經驗的。而在軟工課程中所面對的這個團隊確實一羣完徹底全的學生。因而在不少地方就存在了思想上的衝突：

• 我：
  • 這個項目應該如何計劃才能作的更大，效益更好？
  • 這個地方代碼應該如何維護才能將來更方便？
  • 這個地方需求如何設計才更有效益？才能用最小代價換取最大收益？才能在市場上佔據必定的主動權？才能在和學校有關部門交涉的時候有足夠的籌碼？
  • 學期結束後，咱們應該如何把這個項目進行安置，才能讓其真正的穩定而不至於人去樓空人周茶涼？
• 學生：
  • 這個項目如何才能拿到更高的分數？
  • 這個地方應該怎麼寫才能更快地寫出能跑的程序？
  • 這個地方需求如何設計聽起來才最讓老師信服以便給個高分？（沒錯，劃重點：聽起來）
  • 學期結束後，咱們的項目應該如何處理才能讓我多拿幾分？

這樣的矛盾其實很顯然，雖然我某種意義上大概能理解爲啥不少人會有這樣的學生思惟（實際上很早之前的我也差很少，只不過經歷的比較早而已），可是不少時候爲了更長遠的利益，卻又不能妥協。然而講道理卻又不是何時都能行得通的，畢竟視野深度和廣度存在明顯的代差。

因而在這樣的狀況下，如何和具備代差的人相處並作好事，就是一個亟待思考的問題了。

管理層如何讓下屬，甚至是高階下屬，在利益上達成共同體，是否有什麼通常性的思路

正如筆者在前面的博客中所寫：

世上只有利益上相互依存的關係，纔多是穩定的關係。

同時，基於上面一點的論述，不難發現技術段位差距較大的人，已經容易存在眼界和視角上的代差。那麼在現實的組織架構中，一個高層管理所能看到和察覺到的問題，可就和下層的人相比起來差異大了去了。

因此，在這樣情報嚴重不對等，甚至不少時候連深層的信賴關係都難以達成的狀況下，能依賴的惟一紐帶就是共同的利益關係。或者也能夠說，正是由於不少的下層人員與上層所共同考慮的問題也基本只有利益（996事件中，大部分基層程序猿的發聲，基本邏輯都是如此），因此利益也是最靠得住的一種紐帶。

那麼問題來了，在這樣嚴重不對等且沒有信賴關係的狀況下，利益共同體該如何達成？是否有一些通常性的思路。

先說說我的目前的一些粗淺認識，思路有兩種：

• 充分換位思考，瞭解對方利益訴求
  • 這是最開門見山的一種思路，也是解決問題最直接的一種手段
  • 可是這樣的方法存在一些操做性上的問題
    • 「子非魚安知魚之樂」，你再怎麼去試圖理解他們，但你畢竟不是他們。
    • 因此，實際上很容易發生即使換位思考，依然不得要領的狀況。意識是客觀存在的主觀映像，所謂換位思考思考出來的，與其說是對方，倒不如說是對方+本身。
    • 並且事實證實，在這樣的狀況下，被換位思考的那一方還基本上不會買帳。就比如，人家要一個蘋果你給人家拉來一車梨。
    • 最典型的一個反面教材——世界上有一種冷，叫作你媽以爲你冷；世界上有一種食慾，叫作你媽喊你回家吃飯
• 既然沒有信賴關係，那就創建信賴關係
  • 這個辦法須要多一步，可是實際上若是能實現的話效果會很好
  • 實際上，不少成功的領導者，甚至政治家，所作到的事情也正是與本身目的路上核心位置的人員全都創建了信賴關係，並以此爲突破口，再以利益關係做爲穩定因素，增強安全性（典型例子：劉備、司馬懿、希特勒等）
  • 可是這件事依然存在一些難點：
    • 對於全部的人，若是都要創建起信任關係的話，那實際上成本實在過高了（尤爲對於高層領導，對下層全部的人都直接聯絡感情？聽起來不太現實）
    • 並且實際上，不少人也並不在乎這層信賴關係。最典型的就是如今常說的「社畜」，他們就是賺錢，工做時間之外的任何事別來煩我。畫大餅？那是啥？大家作領導的不是最喜歡騙咱們麼？責任？那是啥？有錢重要麼？信賴？那是啥？本大爺不對大家這羣黑心壞領導宣戰都是給大家臉了，還信賴，要咱們同流合污？腦回路很清奇對吧？可是他們還真就是這麼認爲的，這種心態極其廣泛。
    • 固然，能趕上好溝通善解人意的人，固然是極好的。可是很顯然，如今的社稷國情下，不能把這類偶發事件當作所有，更不可能只靠這個過日子。

綜上，實際上在上下級這一層的關係維繫上，是存在這樣一個很尷尬的僵局的。因此，這塊應該仍是須要一系列更成熟的思路和解決方案。還望不吝賜教。

如何和通常性的其餘人或者團體達成利益共同體，是否有什麼通常性的思路

一樣的，實際上在合做方之間，也會存在這樣的一層問題。

簡單來講，人家也有人家的利益。人家不可能由於你胡吹出來的那點所謂的「情懷」、「信仰」，就來和你談合做，由於人家也是人，也得吃飯，也和你同樣沒有太多的時間作無心義的事。

和上面一條基本相似，此處再也不作詳細描述。

作中學總結

需求

首先，需求層面，須要從兩個角度來分析：

• 甲方。在不少的狀況下，需求方只能說出大概的需求（好比，我想作一個場館數據系統，我想作一個用來刷航概的app），更細的，即使問他們，他們也不知道。可是對於甲方而言，若是你把一個產品擺在他的面前，問他合適不合適，對不對，這樣的問題他們是能給出明確答案的。
• 乙方。對於程序猿而言，不少時候只有知道明確的需求才能進行工做。然而如上文所言，甲方是不可能作到直接給出這樣的明確需求的。因而這個時候，PM的一個重要職責就是在甲方和程序猿之間創建一個橋樑，將甲方需求轉化爲開發需求。同時也須要在和甲方溝通的時候，對程序猿們有充分的瞭解（好比大體瞭解哪些東西可作，哪些東西好作，哪些東西不可作）。

設計

在需求層面基本明確的狀況下，那麼設計也就該提上日程了。

設計也分爲幾個層面：

• 產品設計。產品設計主要是將需求進行一個整合，和上問的需求分析轉化基本相似。
• 架構設計。架構設計則是在已知的詳細需求下，思考如何構建一整套的代碼，以及軟硬件資源配置。同時，須要從架構層面來考慮後續的可維護性。

實現

實現這塊，則須要在總體架構設計相對明確的狀況下進行。

此外，在實現的過程當中，最好伴隨着主幹功能的實現，一併將單元測試也進行實現。

除此以外，還須要在開發實現的過程當中，注意後續的可維護性（實際上我的感受開發與維護這塊自己就是一體的）。

課程心得

本學期對我而言，實際上只至關於把之前作過得事情再次弄了一遍。惟一一點比較重要的差別，在於此次的團隊配置和之前大不同（前文有說到）。因此能總結的內容其實頗有限。

不過實際上，筆者也在思考這個課程的一些得與失。同時，筆者也在這個學期當OO的助教，對有些問題也算是有那麼一些略微的認識，在這個部分我就着重說下這方面的問題吧。

思考與建議

課程週期短，相關內容體現不足

首先，這個課程是一個只有一學期的課程。並且一學期時間，涵蓋了三個階段，包含了那麼多個環節。

老實說，以我以前作創業項目的實際體驗來看，除特殊狀況外，通常不會有周期如此之短的事情。

並且這樣的短週期還會帶來另外一個問題，那就是不少要素的重要性的體驗嚴重不足。例如：

• 維護先後期的重要性。如此短的一個項目，即使一路無腦硬衝，也基本上不會出啥問題。並且實際上在一學期內，根本也不太會遇到真正的大範圍業務需求變動這樣傷筋動骨的操做（正常的PM應該都會去極力避免）。因此實際上這一塊與現實存在必定程度的脫節
• 與用戶的深刻互動。一樣，這個課程項目，做爲一個「課程」項目，在不少組的眼裏，還完徹底全是個搖分樹而已。即使要求了用戶指標，他們所作的事情也大都不過只是全部人朋友圈轉一轉，各個大羣發一發而已。而用戶用來到底真實感覺是怎樣的？沒有有問題？嚴重問題仍是隻是體驗問題？問題出在哪裏？怕是不少組根本就沒有作過詳細的調研。對於繼承項目，尤爲有這樣的問題。筆者所在的組還好，最起碼很明確用戶羣體，也有過與相關組織進行直接溝通。可是其餘一些組，可就難說了，據我所知，拿來代碼 --> 編寫代碼 --> 羣裏轉轉 --> 截個圖 --> 交做業這樣流程的怕是不在少數。而這麼一個循環弄下來，他們真的能有多瞭解用戶呢？知己知彼百戰不殆，大環境都摸不清楚的團隊，除了能在學校賺點分以外，出了學校是作不成什麼事情的。

實際上，在OO課程哪邊，也同樣存在相似的問題。OO和軟工的一個共同特色，那就是有些內容是很概念化抽象化的，與其說是技術技能倒不如說更像是概念機能。在短週期內想作到這件事，並不容易，甚至必定程度上，軟工比OO面臨的形勢只會更加嚴峻。

在這樣的環境下，如何把握好整個週期，如何把有些該體現的內容充分體現出來，讓學生在學習過程當中把這些內容落到實處而不是流於形式，則是須要課程組好好考慮的問題。

相關指導偏向於抽象

如題，不少的指導仍是偏向了理論，和實際操做的結合有必定的錯位。這就致使一些組或者我的，到了必定階段會開始陷入很大的迷茫，並且尚未辦法經過理論課的講解來進行補足。

其實，這件事說來並不能全怪這門課程。學生在學習這門課程以前，實際上一些前置知識仍是比較匱乏的。好比一些考慮問題的基本方式，以及一些架構佈置方面的基本功（這塊2016級及以上會表現的比較明顯，由於OO這塊的總體學習質量不夠好；相比之下2017級，也就是明年開始，由於今年OO大規模課改，同窗們的這塊能力會有明顯的好轉）。因而實際上，咱們的指導須要分爲幾個階段：

• 起步階段
  • from personal development to team-working
  • from programming to coding, and then to developing and producting
  • from doing homework to exploring and creating
• 步入正軌
  • 引導學生們真正開始思考有些問題，並且必定須要他們去進行實打實的操做，而不是博客寫幾個字重複幾句套話就了事。

其實OO也有相似的一些過程：

• 起步階段
  • 教會你們Java基本語法
  • 教會你們多線程基本知識
  • 教會你們基本的調試與測試技能
• 步入正軌
  • 面向對象
  • 設計模式應用
  • 契約式設計，Java modeling language
  • 深層次設計工具，UML繪圖

今年所採用的模式，是兩部分交織着進行。在第二單元多線程結束後基本完成起步階段的教學，可是正軌部分實際上第一單元就開始了。保證學生作到不至於養分不良，也不至於養分過剩，飯一口一口吃，事情一點一點作。到了起步階段徹底結束的時候，一多半的同窗已經具有了完整的架構思惟，剩下的就是不斷優化追求卓越了。

因此建議課程組也在這個問題上多下一些功夫，要切實瞭解起來學生的真實狀況。

助教與學生之間直接互動偏少

如題，實際上助教在同窗這邊的存在感實在是很低（相比於機組和OO課程而言），一整個學期除了通知消息以外基本見不到助教出沒，甚至通知消息也都是高階助教一我的在不斷的通知。

助教，實際上是個很微妙的職業。說微妙，其實緣由以下：

• 老師，瞭解整個學科，可是不容易瞭解學生的一線情況（不要說老師沒去了解，以前OO也發過調查問卷，結果是什麼樣的大家內心都清楚，能夠上知乎看看；就算不說這個，可是全部學生內心都有一條不成文的規矩——不在有老師的羣裏說真心話，這個應該助教們內心也都清楚的）
• 學生，最瞭解一線情況，可是大部分的學生，對整個學科是沒有特別完整的認知的。（因而，就會總有一部分一瓶子不滿半瓶子咣噹的學生，基於一線情況和本身那點正確率感人的揣測，鬥天鬥地鬥空氣，鬥來鬥去卻毫無結果。雷打的震天響卻死活見不到一滴雨，除了自嗨任何事都沒見被解決。秀才造反三年不成，說的就是這類人）
• 而助教，做爲過來人，具有必定的學科思惟，同時也有不少的機會了解第一線的學生狀況。

助教的這一特色其實很微妙，老師、學生，都總體上缺少某一方的資源，而助教卻徹底有這種可能打破資源時空分佈不均的困局（甚至部分比較厲害的助教本身一我的就能完整的掌握兩頭的情報）。

因而，我的認爲，助教的一個職責就是——充當起師生情報傳遞的橋樑。

若是追求更深層次的話，那就是——基於雙邊的情報，優化雙邊資源配置，一達到一個全局更優的解。

因此，其實建議助教們看到這句話也能好好思考一下。我相信助教們也都應該是有志於改進整個課程的人，那就好好思考思考我說的這些，想一想看本身到底該作點什麼，而不是隻是一味充當苦力，或者乾脆只是一個傳話筒子（並且搞很差仍是單向的）。