一、提問回顧
提問博客點這裏
關於第一章中的“軟件的非連續性”
經過這一學期的實踐，我對軟件的非連續性有了比較具體的認識。
在我們的項目中，後端涉及比較複雜的狀態機，而可能一些小的輸入變化就會觸髮狀態機的改變，進而影響系統的運行狀態。測試後端狀態機是整個項目最困難、最複雜的地方，在這部分，軟件的非連續性就體現得淋漓盡致。
而應對這種困難的方式也有很多，一方面，可以做充分的測試，盡量覆蓋狀態機的每一條狀態轉移路徑，另一方面，在設計時也要做好充分的考慮，盡量讓系統的狀態數較少，轉移數較少，從而使得系統的穩定性提高，易於維護和管理。
關於第二章中提到的“單元測試”
在學期初提出的問題是
是否有必要追求100%覆蓋率的單元測試
經過這一個學期的實踐，我覺得我找到了答案，測試是必需的，但100%覆蓋率的單元測試既不必要，不也現實。
在這個學期的項目中，我們的產品從前端到後端涉及到了瀏覽器、服務器、Docker、文件服務器、磁盤文件系統。其中，很多功能都是需要多個組件協同完成的，而單獨處於一個組件內部的單元測試常常無法兼顧整體，例如，在服務器系統內就很難監控到Docker的運行狀態，相應的單元測試也就很難開展。因為不存在一個組件可以訪問和控制到整個系統的每個組件，如果真的存在這樣的組件的話，那說明系統的設計也是不好的，沒有很好地實現系統層次之間的隔離，整個軟件的耦合度比較高。
但是，這是不是意味着我們可以放棄對單元測試的要求而為偷懶找借口了呢？不是的。
首先，單元測試依然起着十分重要的作用，拿建築樓房為例子，單元測試的作用就是保證每個磚塊、每根鋼筋的質量，雖然它很難保證整個樓房的藍圖設計是正確無誤的，但是作為第一層保障，它可以有效地保證我們的最低層組件工作正常。
以我們的項目為例，在後端服務器實現中，會用到很多的工具類，這些類之間的耦合度很低，各自完成相關的一系列功能，為上層提供服務。單元測試在這裏就可以發揮很大的作用，對每個工具類的每個方法進行全面的測試，可以為將來進一步的開發排除很多潛在的隱患。
而除此之外，我還認識到了測試不僅僅是單元測試這麼簡單，測試是一門學問，相應的也有諸多經典的測試方法，例如，在我們的項目開發後期，常常採用錄製腳本的方式進行測試，通過瀏覽器錄製一系列操作形成腳本，這個腳本可以重放，從而在軟件開發過程中可以隨時回歸測試，保證之前腳本中包含的功能運行正常。
所以，總結來說，測試十分重要，但100%的單元測試往往不切實際，但在單元測試無法覆蓋的地方，必須要有其他的測試手段進行彌補，要保證軟件的每個環節都有相應的測試作為保障，才能在接下來的開發中保持軟件的高質量。
關於第四章中提到的“結對編程”
在學期初提出的問題是
結對編程的開發方式開起來很美好，但是在實際團隊開發中真的有廣泛使用嗎
經過本學期的結對編程實踐，我依然對當初提出的問題持保留意見，也尚不能完全認同結對編程中的所有優點。
在書籍中介紹到結對編程有如下幾個優點
- 可以起到教學作用，技術高的程序員可以幫助技術較弱的程序員進步
- 可以提高代碼質量，因為代碼的每個部分的質量都取決於一對程序員中在該方面技術較高的一個
- 可以提高團隊凝聚力，促進團隊交流，利於團隊管理
- 可以有效應對團隊人員變動
針對這幾點，我也想談談我在實踐過接對編程后的理解和困惑。
- 可以起到教學作用，技術高的程序員可以幫助技術較弱的程序員進步
關於這個優點我完全認同，在接對編程實踐中，我從搭檔身上學到了不少東西，不論是編程技巧還是設計藝術，同時，我有時也能夠為他提供一些幫助和想法，應該是完全起到了相互促進的作用。
但是，在這個優點背後有一個問題值得思考，也是我所困惑的。這樣的時間成本是否較高，一方學到東西的代價是另一方需要停下開發的腳步，而且，並非每個人都有成為老師的潛質，有的人技術高超但是表達能力不強，讓他們教授別人技術或許不如讓他人查閱相關資料來的效率高。同時，編程和思維都是有節奏和狀態的，打斷編程者的連續輸出其實對於編程人員來說是一件效率很低的事情，這樣看來，這個教學作用的成本是否較高。
- 可以提高代碼質量，因為代碼的每個部分的質量都取決於一對程序員中在該方面技術較高的一個
這個優點我也完全認同，但是，在我實踐過程中的體會就是，達到這個最優往往會經歷一番周轉。
當雙方在某個設計點上意見不一致時，需要停下進行分析，這本身沒有問題，尤其是在雙方技術水平相差較大時，一方會主導話題，從而使得問題的討論和解決較快。而當雙方技術水平相當時，問題就可能出現，可能雙方各有不錯的設計，但這兩個設計相去甚遠，說服任意一方接受理解另一方的設計都是比較困難的事情。其本質就是默契問題，是否雙方有很高的默契度，編程和設計習慣上風格一致，這些都影響着結對編程的效果和實際性。倘若雙方無法保持高度默契，那麼有時時間就會被浪費在類似上面提到的場景上。
- 可以提高團隊凝聚力，促進團隊交流，利於團隊管理
這一點我完全認同，也認為十分實際，當下，很多公司也有技術茶話會這樣的活動，目的也是為了可以一邊交流技術、提高團隊水平，一邊也可以提高團隊的凝聚力、促進團隊交流。
- 可以有效應對團隊人員變動
確實有這方面的意義，但是我個人感覺這依然沒有解決本質問題，這樣的解決辦法下，風險依然是在人員本身上，只不過將一個人變成了兩個人而已。
而我認為更好的解決辦法可以是完善相關的內部文檔，每個人負責各自工作範圍內的技術文檔維護，這樣可以有效地規避掉人員變動的風險。
這一點在這學期的強制轉會中深有體會，據我了解，有的團隊就將項目開荒初期的學習和技術文檔維護了下來，從而使得轉會新來的成員可以快速上手項目，團隊的開發進度不會受到很大的影響。
關於第十六章中提到的“要成為領域的專家，才能創新”
在書中，作者的觀點是這樣的
這個想法看起來沒什麼錯，我們不就是為了成為某個領域的專家，才來上學，拿學位，希望拿到學位之後成為專家，然後再開始這個領域的創新？但是統計數據表明，70%的創新者說，他們最成功的創新，是在他們的拿手領域之外發現的。
之後作者舉出了HTTP的誕生、阿里巴巴的誕生等例子，佐證上面的觀點。
經過這學期的實踐，我對這個觀點有了一定的理解，也有了一些自己的看法。
在這學期，我們是自選項目，也算是做了一些創新性的設計實現，但是這背後是經過了一定的調研和學習才得來的。雖然不能說經過調研我們就成為了領域的專家，但是至少對領域有了一定的了解和認知，知道哪些是實現了的，哪些是空白的，哪些東西因為沒人想到所以沒人做，哪些東西因為難度太大所以沒人做。
當然，作者的意思不是說對某個領域聞所未聞就企圖在其中有所創新，而是說創新的領域不一定是自己最拿手的領域。這一點，經過這學期的實踐，我有了全新的理解。
創新和實現不同，創新更關注的是要站在一個應用者和設計者的角度去思考，而不是實現者或者架構師的角度，它更多關注的是需要什麼而不是如何實現。當然，這兩者都十分重要，單純有想法但無法實現也無濟於事。但是，這背後正是作者想要表達的意思，不一定每個人都有實現某個東西的能力，但是每個人一定都有想到、想出某個東西的能力。
那我們的項目為例，我們發現在初學編程時，環境的配置很麻煩，IDE的安裝很麻煩，所以我們想解決這個問題，於是我們提出了自己的WEB版IDE，對這方面的需求提供了一定的支持。這個創意源自於我們的真實需求，同樣，那些偉大的創意，也往往來自於真實的需求。這正是作者想要表達和闡述的。
關於第十七章中提到的“磨合階段”
經過這學期的實踐，我發現沒有磨合階段的團隊和無法磨合的團隊都很少，以我們的團隊為例，大家在最開始雖然意見不統一，但是經過一段不長的時間的調整和交流，很快大家在認識上就可以達成一致。
我認為，除了一些極端人員難以融入團隊，可能會成為團隊的害群之馬以外，大部分時候，團隊都是可以磨合和愉快合作的。
而在學期開始時，我提出了如下問題
如何判斷一個團隊是處於“磨合階段”還是說這個團隊的人員配置本身真的存在問題呢
針對這一點，結合我的實踐體會，我認為，如果一個團隊能夠明確地完成分工，並且每個人都能夠清楚自己的職責和任務，那麼這個團隊就可以繼續合作下去。即使最開始存在團隊成員的進度不能很好地達標的情況，但也依然可以認為團隊的人員構成本身沒有問題，是可以合作的。
因為如果每個成員都清楚自己的任務和職責，那麼這至少說明了大家在工作和認識上達成了一致，在這個一致達成的基礎上開展後續的合作都是有可能的。而倘若成員之間連分工和職責分配都無法明確，則要麼是團隊管理出了問題，PM沒有很好地協調成員，要麼就是團隊成員無法達成一致，整個團隊內對任務和目標沒有一個清晰的認識和把握。
所以，我的理解是，團隊成員之間能否對團隊任務和目標有一個統一的認識和把握是可以作為評判團隊人員配置是否合理的一個重要標準。
二、新的問題
實踐出真知，經過一個學期的實踐后，再回顧最初提出的問題，確實顯得有些稚嫩和缺乏實踐了。
不過在實踐過程中，我也產生了一些新的問題，下面提出來和大家共同探討。
如何對抗歷史代碼遺忘問題
這個項目總共歷時2個月，從最初的搭建，到後來項目功能越來越多，魯棒性越來越強，這其中都是需要進行代碼的修改和添加的。
然而，在項目後期常常會出現一個情況，就是幾周前的代碼在幾周后再次閱讀時不能很快地回憶出其中的實現細節。
這裏並不是想表達代碼的可讀性較差，即使是在充分利用面向對象編程和函數式編程的優勢的情況下，回顧以往的代碼依然要耗費一定的時間去閱讀。
特別是在系統的狀態較多較複雜的情況下，這種問題尤為明顯，需要花費比較多的時間理清楚系統的狀態遷移。
我認為，完備的設計文檔和代碼註釋會有幫助，同時，設計多個小型專用系統來替代單一的多功能大型系統也會有所幫助。
但是我並無法滿足於上述兩種可能的解決方案，同時，因為問題暴露較晚，所以我也沒有機會去實踐檢驗上述辦法是否真的有效。
所以在這裏提出這個問題，希望能夠得到幫助。
軟件功能和軟件安全性的矛盾
網絡安全是一個很大的領域，而WEB應用依賴於網絡，自然WEB安全也是一個很大的話題。
在項目初期，我們花費了不少時間在安全機制的設計上，甚至對於安全機制的考量一度影響到了我們正常功能與核心功能的開發進度。
我們每個人都承認，在軟件領域，軟件的安全性無論對於用戶還是開發者都是十分重要的，它關乎雙方的利益。但是，在能力有限，或是缺乏相應的專業技術人員的情況下，過多的安全設計考慮常常會影響到功能的開發。
所以，我很困惑應該將安全機制設計放在軟件開發的哪個階段。
倘若在最初軟件設計時就將大部分安全機制考慮到並設計在最初架構中，那這樣肯定會影響到軟件的開發進度，特別是在缺乏專業技術人員的情況下。
而若不在最初設計時將安全機制考慮在內，而寄希望於在後期逐漸添加安全機制，那麼很可能出現一種情況，就是為了添加安全機制，軟件架構需要一些變動，這有時甚至會破壞單元測試的可用性，因為更高的安全性背後往往是更低的便利性，可能會有一些原本可以正常工作的單元測試不能在新的安全機制下運行，這就又給回歸測試帶來的困難，進而迫使軟件開發進入了一種比較危險的狀態。
所以，我很想知道，在有限的條件下，應該如何平衡安全機制設計和功能開發。
三、實踐知識點回顧
需求階段
在需求階段，我學到的知識點是
需求調研不僅要保證提出的需求是真需求，同時也要保證我們的產品有優於同類產品的地方
我們的項目是WEB版的IDE，其實，這個領域的同類產品還是有不少的，但是我們在需求調研時提出了我們獨特的地方，即面向新手。
我們提出的需求是，許多新手初學編程時會被諸如環境配置、IDE配置等一系列配置工作阻礙，而我們的目標就是為他們消除阻礙，能夠提供一個開箱即用的編程環境。
那麼，我們提出的需求是真需求嗎？是的。
據調查，很多大一新生在編程學習的前半個學期都會對開發環境有着或多或少的困惑和不解。然而理解這背後的一系列內容又本身超出了他們現有的能力範圍，那麼，我們產品的使用人群和使用場景也就應運而生了。
而我們的產品是否有優於同類產品的地方呢？是的。
根據調研，市面上大多數的WEB版IDE的功能都十分強大，基本涵蓋了非WEB版IDE的絕大部分功能。但同非WEB版的IDE類似，這些WEB版的IDE依然使用難度較高，需要一定的經驗，也需要一定的配置，並不能做的開箱即用，而這就是我們產品的優勢。
設計階段
在設計階段，我學到的知識點是
有效地分隔任務為若干個子任務會有利於設計的進展
在我們項目最初的設計階段，我們就將項目進行了分隔，粗略分為了前端、編輯器、後端這三個部分，而這三個部分又各自被分隔為若干個更小的部分，然後針對每個部分的功能需求去單獨設計。這樣，一方面有利於強化對於項目的整體把握，另一方面也有利於控制軟件的複雜度，可以使得每個小部分都得到較優的設計和實現。
實現階段
在實現階段，我學到的知識點是
團隊開發中的每日例會十分重要，有利於每個成員把握整體的開發進度
在alpha和beta階段都有14天的scrum階段，其中每天都要舉行例會，在實現階段的每日例會是十分重要的。
一方面，通過每日例會，每個成員都可以比較清晰地把握團隊整體的開發進展，進而便於規劃自己未來幾天的任務。
另一方面，也可以起到監督和督促的作用，在每日例會上，大家都會彙報自己的工作進展，這在無形中就起到了督促作用。
此外，每日例會也能夠起到活躍團隊氣氛、促進團隊團結的效果，每日例會不僅是彙報工作的地方，也是團隊成員交流的機會。
測試
在測試階段，我學到的知識點是
要常常回歸測試，不要等到最後統一測試，那樣往往費力不討好
在alpha階段，我們的測試基本上是在發布前統一進行的，在開發過程中的測試較少，所以最後發布前的測試工作十分緊張。
統一測試的壞處在於，一方面，統一測試的工作量很大，面對一個初有體積的項目，要進行覆蓋度較高的測試是十分耗時耗力的工作。另一方面，在最後統一測試的修復成本較高，在軟件開發階段發現並修正錯誤往往是比較容易的，但是當軟件完成了整合，再進行測試並修正錯誤，那樣的修復成本往往較高，因為在軟件整合完成之後發現的BUG有可能是整合導致的，也有可能是某個組件自身帶來的，這樣不僅問題定位困難，而且修復時常常會涉及到多個組件，牽一發而動全身。
發布
在發布階段，我學到的知識點是
推廣十分重要，優秀的推廣能夠助力讓產品最終擁有大量的用戶
在alpha階段的發布環節，我們團隊並沒有十分重視產品的推廣，因而導致在alpha階段最終用戶數量不多，相應的，收到的用戶反饋也就較少，為beta階段的展開帶來了一定的困難。
而在beta階段，我們及早進行了發布和推廣，有力地吸引了一批有效用戶，他們為我們的項目提出了寶貴的意見和建議，從長遠來看，這將十分有助於我們產品的進一步發展和更新。
維護
在維護階段，我學到的知識點是
要做好系統數據收集工作，在維護階段要密切關注系統數據記錄，及時發現系統可能存在的問題
在alpha階段，我們的後端系統並沒有設計太多的日誌系統，用戶的操作基本都沒有被有效記錄下來，導致維護時出現了問題很難定位。
在beta階段，我們針對後端系統的設計強化了系統日誌方面的實現，記錄了所有數據庫查詢操作、API訪問操作等諸如此類操作的記錄，便於在維護時定位錯誤和排查隱患。
四、理解與心得
無論是個人項目、結對項目還是團隊項目，都需要有一個思路清晰的領導者（管理者）來把握整體的前進方向。
在個人項目中，自己是那個管理者，在結對項目中，兩人都是管理者，而在團隊項目中，PM是主導的管理者，每個人也都參与其中。
為什麼說這個管理者十分重要，因為在多人完成一項任務時，思路統一是很重要的一件事情。每個人都有自己的主意，那樣是無法擰成一股繩來合作的，需要有人來管理和協調，讓大家的想法達成一致，才能使得團隊高效地合作。
同時，管理團隊和管理軟件開發周期也是一門學問。
管理團隊涉及到協調大家不同的意見，盡量不偏不坦，保證每個人的個性的同時又要保證團隊的統一。要能夠充分發揮每個人的特點，盡量滿足每個人的愛好和想法，這本身就是一項十分有挑戰的事情。
而管理軟件開發周期更甚，軟件開發涉及到多個環節，每個環節都有每個環節的任務和特點，在每個階段都指定明確的目標對於按期完成軟件開發而言有十分重要的意義。
同時，軟件開發不僅是技術的挑戰，也是設計的挑戰。
高超的技術可以幫助程序員實現功能，但是並不能幫助程序員設計出優秀的產品。軟件開發往往細節之處見真功夫，這種功夫不一定是實現難度有多高，往往是設計思想上的巧妙。優秀的設計可以讓產品更加易用，更加具有粘性，讓用戶更加依賴於產品。
這一點我在我們的項目中深有體會。我們的IDE主打易用，所以在很多地方的設計上都是精雕細琢，如功能的布局、UI的設計、項目的入口等等，都力求讓用戶能夠快速上手，長期使用。
此外，我也有一些想進行反思的地方。
首先是和大家的交流方式上，我覺得我一直存在一定的問題，同時，這也是團隊合作中十分重要的地方。團隊合作，大家不僅僅只是簡單的在一起做個東西，人際層面的往來對團隊的建設也十分重要，良好的交流方式有利於提高團隊的凝聚力，營造良好的團隊氛圍。在這一點上，我覺得我做的還不夠，有時會將個人情緒遷怒到他人，也是感謝大家對我的包容吧，能夠讓團隊的合作一直很愉快。
還有就是缺乏思考，尤其是設計上的思考。好的軟件開發人員會設計優秀的接口和服務，讓使用者一看就能覺出這是大家之作，方便易用的同時功能全面。這一點上我覺得我做的還不夠，很多時候都是功能有了就可以了，而不再進一步考慮如何優化接口，優化API設計，讓調用者更加方便地使用接口與服務，這一點在未來的軟件開發設計上也是需要提高的。
總結起來說，這一學期的軟工實踐體驗是很充實的。從單人項目到結對項目再到最終的團隊項目，實踐了不同模式下的開發過程，也最終取得了一個小有規模的產品，無論是過程還是結果都值得欣慰。同時，通過一系列的實踐，我也深刻體會到了團隊大型軟件開發的難度和痛點，也為將來的進一步學習和發展奠定了基礎、明確了方向，從這些角度上講，都是十分有益的。希望這個學期的實踐可以成為未來軟件開發生涯的一個好的開端。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※南投搬家公司費用需注意的眉眉角角，別等搬了再說!
※教你寫出一流的銷售文案?