我的閱讀做業

軟件工程最後一次做業

總結

對軟件工程的學習作一個總結。

這個學期有兩個老師開了軟件工程課。
我問了一下學長的建議，兩個學長都說：必定要選羅傑的。
我以爲可能學長們的重點仍是這兩點，提升真實能力與充實簡歷這一塊。
而另外一個老師開的軟工，主要是寫文檔，而且「開發」了一個虛擬的程序。

一開始羅傑老師的課有60人選，第一次做業事後就只剩下20人。

我問了其餘退選的同窗，廣泛都說：

由於這個學期還有一樣重要的兩門課——數據庫和編譯，事情不少並且從學分的角度來講不值得。
以上是題外話 。

提及本身的軟件工程的學習：

前幾回做業感受都還行，從團隊項目alpha版本開始，就開始深陷本身編碼能力的不足帶來的問題了。

每一個學期都深陷這樣的問題：
無論是計組仍是OO仍是軟工仍是編譯
因爲咱們的編碼能力，好吧，準確地說是因爲個人編碼能力不足，致使我認爲我並無學習到這門課程最核心的一些理念，好比此次的博客做業我就完成得比較吃力，反卻是過了一年再回首纔有了一些相對深入一些的感覺。
最明顯的仍是OO課，老師在上課時也表示，由於大家編碼能力不足，因此跟大家細講概念也沒有意義。雖然我OO做業都完成了，完成狀況較好，可是我仍是對OO不能說出個因此然，因此打算進一步自學。
至於軟工。在老師佈置第一個閱讀做業的以後，在我讀構建之法的時候。我有個想法：我之後必定要把這本書好好地看一遍，把每一個參考文獻都看一遍，把擴展閱讀都看一遍。
我這個想法可能不切實際。

有些書上前人總結的一些精煉的話，在第一遍閱讀的時候因爲經驗不足不能得出什麼深入的理解。而軟工恰恰又是一門作種學的課程，沒有作的經歷天然也得不出深入的理解，最終仍是須要有開發的經驗纔會有更深入的體會。
因此我仍是要把這些文獻再仔細閱讀一遍的。

關於能力的提高。

編碼能力提高了，瞭解了軟件開發的過程與難點，愈來愈有了這樣的體會：我能用代碼來完成一件事

其餘體會

個人體會是，一個好的PM無論這個PM是 programming 仍是 product 仍是 project / managing 對於團隊來講都是很重要的。

同時因爲這個學期的一些問題，軟件工程的一些流程仍是沒有體驗，好比維護的環節。與獲取用戶反饋的環節。從頭至尾需求比較穩定，因此沒有體驗過被用戶追着趕需求的推背感，整體上說沒有體驗過跟用戶交互的環節。

結合閱讀材料談談本身的理解或心得

NO SILVER BULLET

首先是《no silver bullet》一文，做者觀點很明確當前軟件開發的過程當中面臨着complexity(複雜性)、comformity(軟件整合)、changeability(易變性)、invisibility(不可見性)四個問題，緊接着文章介紹了過去解決軟件開發解決事故性困難的方法：高級語言：使得開發者不用在乎底層實現，更好地以更接近人類思惟的方式設計軟件；分時：只要分時的頻率足夠大，就能取到很好的效果；統一的編程環境：這個很少說，統一的格式會帶來交流的便利，同時代碼也無需修改就能在不一樣的開發者的電腦上運行。

至於可否找到解決軟件生產率的銀彈，做者就以下問題進行了討論：

• ada和其餘高級程序設計語言的發展
  -- 實際上，這只是一個新的高級語言，它只能帶來新的設計程序的方法
• 面向對象編程的方法
  -- 這隻能下降定義接口的複雜度，而軟件開發須要的複雜度並無被解決
• 人工智能和專家系統
• 自動編程
• 圖形編程
  -- 因爲軟件開發具備不可見性，因此這一條路也顯然不能走
• 程序驗證
  -- 驗證程序也是程序。
• 環境和工具
  -- 工欲善其事，必先利其器，可是環境和工具只是針對了軟件開發中的其餘矛盾，不能實際減少開發的複雜度。

• 工做站

  最後做者論述了尋找銀彈的一些前景：

  Buy versus Build

  Requirements refinement and rapid prototyping

  Great designers

  就咱們此次開發來講：

  great designer大大提升了軟件開發的效率

  同時，關於第二點，個人思路更偏向快速成型，而其餘組員更偏向要求完善，在這一點上，若是咱們能在這兩個方向上達成共識，找到折衷點，這對咱們的開發應該能帶來更大好處。

BIG BALL OF MUD

大泥球指指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆代碼。

而泥球的產生其實是由於

對需求和設計的理解不透徹，對軟件業務流程不熟悉，缺乏開發經驗，另外，就像滾雪球同樣壞的代碼會不斷累計成更壞的代碼，除非咱們着手完善它。

實際上咱們的代碼裏確定存在泥球，但不是大泥球，所以受這個的影響較小。

CatB

關於這一點，咱們的初衷是想作成一個大教堂，實際上咱們也使用了不少開源庫，也就是實用了集市裏的東西，咱們也不排斥集市這一方法。但前提是咱們的項目要可以吸引人們來使用。

一個開放式的項目，若是加以良好的管理和運做，能取得比同等的封閉式項目大得多的成功。

引用阮一峯老師的博客來講：

開放式的文化會最終勝利，這或許不是由於"開放"在道德上正確，或者"封閉"在道德上錯誤，而只是由於開放式合做能夠在一個問題上投入多幾個數量級的技術工時，封閉的世界沒法贏得這樣的競爭。

之前的博客

連接

0.軟件具備易變性，咱們如何在最初的開發中設計好程序的結構使其易於擴展呢？或者說，咱們如何能在最初的開發中就預見到將來不斷改變的需求呢。尤爲是當咱們連一點用戶反饋的時候都沒有的時候。

這須要產品經理對市場敏銳的嗅覺來奠基基礎。

1.官僚模式下，程序員應當如何正當提出領導者的錯誤同時不被領導反感並使其虛心遵從技術人員的建議？

這個問題更傾向於人際交往而不是軟件工程的範疇。

2.在結對開發的磨合環節中，若是此時面臨嚴峻的任務要求，如何加快磨合進度，仍是說，此時嚴峻的任務要求，就足夠加快結對的磨合了？

這個問題同上。

3.在團隊開發中，我的貢獻量究竟如何衡量？根據代碼量？跟據修復的bug量？因爲團隊中個體處於不一樣位置，個體的具體任務也不同，這樣如何公平，或者說有一個讓團隊信服的我的貢獻衡量策略？

關於我的貢獻衡量策略，衡量策略必定程度上能提升共事者的積極度，可是從咱們這學期的開發經從來說，一開始（在開發初始）就制定好這種衡量策略並無起到預期的做用。多是由於咱們組特別和諧。。。連架都沒有吵過，並且對於貢獻度你們都有一竿很公平的秤。另外還有多是咱們模擬的不夠完全。同時個人觀點是對於咱們這種首次開發的團隊，與其一開始就制定好貢獻衡量策略，不如等一個階段的編碼結束後，看看你們都幹了些什麼事，經過成果來衡量貢獻，更有效一些。這時你們都積累了必定的工做量，同時經歷了磨合，培養了一些默契，對相互的工做都有了解。這樣能更高效地衡量貢獻。

4.關於軟件工程師的職業道德這個問題，關於阿里月餅案件，阿里開除涉事程序員這一舉措，是否合理？是否太重了，此次事件對涉事程序員的職業生涯有多大的影響？

​關於這一點：好的員工要知道什麼事情是本身能作的，什麼事是不能作的，最基礎的一點是，在作事以前問問老闆的意見。