| 這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/zjlg/rjjc20 |
|---|---|
| 這個作業的目標 | <通過閱讀《構建之法》這本書學會獨立思考問題> |
| 姓名-學號 | <朱宇柔-2019339930003> |
問題一：
-
如何避免“分析麻痹”？
分析麻痹：一種極端情況是想弄清楚所有細節、所有依賴關系以后再動手，心理上過於悲觀，不想修復問題，出了問題都賴在相關問題上。分析太多，腳都麻了，沒法起步前進，故得名“分析麻痹”（Analysis Paralysis）。
大牛問，果凍，你怎么還沒去打水？
木桶有一個洞，咋辦啊，大牛？
修哇，果凍！
用啥來修啊，大牛？
用粗麻神把它堵上，果凍！
麻繩太長，咋辦啊，大牛？
用刀砍短啊，果凍！
刀太鈍，咋辦啊，大牛？
......
-- 引用自《構建之法》P48
思考：這種“分析麻痹”對於軟件工程師來說確實是一種糟糕的思維，不僅僅是軟件工程師這個職業，對於任何一個從事技術性職業人員來說，“分析麻痹”無疑是他發展道路上的一個障礙。然而，在這本書中沒有說明如何去避免“分析麻痹”這種現象，或者對於已經有“分析麻痹”習慣的人如何才能漸漸改掉“分析麻痹”這種思維慣性。由於本人對“分析麻痹”有着深刻的體會，因此，我認為，“分析麻痹”竟然是一種很正常的現象，經常存在這樣的現象，當發現自己需要填補一個問題時會出現一系列的連鎖問題，最終可能迷失其中，發現自己還是太菜了，要把這些坑都填上了再來補那個大坑，這樣導致的結果就是事情總是不拿按照預想的時間安排展開。總的來說，“分析麻痹”確實是一個很不好的習慣，那么如何才能避免“分析麻痹”呢？
問題二：
-
什么是一個優秀的軟件開發團隊？
什么是好的軟件？一些同學認為，所謂好軟件，就是軟件沒有缺陷（Bug），所謂軟件工程，就是把軟件中的Bug都消滅掉的過程。這的確是抓住了軟件工程的一個重要因素。和軟件打交道的專業人士都知道軟件有“Bug”，軟件團隊的很多人都整體和Bug打交道，Bug的多少可以直接衡量一個軟件的開發效率、用戶滿意度、可靠性和可維護性。
-- 引用自《構建之法》P15
思考：看到這個地方，我不禁在腦海中想到我們現在使用的大多數軟件，如微信、騰訊視頻等，都在很正常的運行，是不是這些軟件自從開發運營以來就再沒有出現過Bug，可以說是完美的軟件，那么是不是一個軟件團隊只有做到開發出十全十美的軟件才能夠證實一個團隊的能力呢？后來，我又在網上查到，2019年1月20日，黑灰產團伙通過一個拼多多過期的優惠券漏洞盜取數千萬元平台優惠券，進行不正當牟利，針對此行為，平台在第一時間修復漏洞。我這才認識到，一個優秀的軟件開發團隊並不是會設計出一款十全十美的軟件，因為世界上90%的軟件工程師都會發現他們是在如復一日的修復Bug中度過的，一個優秀的軟件開發團隊是擁有能夠迅速修復Bug的能力的，軟件中的Bug也許會隱藏很久或者軟件也會遭到不良人士的入侵，但是如果軟件開發團隊能夠在第一時間修復Bug，那么這樣的團隊才算是優秀的。
問題三：
-
到底要不要一個代碼復審者的存在？
問：這么說如果開發者做到完美,復審者的時間和精力就是一種浪費了？
答：不對,即使是完美，代碼復審也還有“教育”和“傳播知識”的作用。更重要要的是不管多么厲害的開發者都會或多或少地犯一些錯誤，有欠考慮的地方，如果有問題的代碼已嵌入到產品代碼中，要把所有的問題找出來就更困難了。大家學習軟件工程都知道，越是項目后期發現的問題，修復的代價越大。代碼復審正是要在早期發現並修復這些問題。
另外，在代碼復審中的提問與回應能幫助團隊成員互相了解，就像練武之人互相觀摩點評一樣。團隊中有新成員加入時,代碼復審能非常有效地幫助新成員了解團隊的開發策略、編程風格及工作流程。
-- 引用自《構建之法》P74
團隊復審是指對於兩人的團隊就某一程序實體進行的復審，團隊復審的缺點在於：
1）什么時候開會做復審？不可能一個團隊天天開會。要找到以誒給所有人都能出席的時間，並不容易；
2）牽涉的人員眾多，理解程度不一，復審的速度和效果不能得到有效的平衡————太快則有人不懂，太慢則浪費許多人的時間；
3）正是由於成本問題，無法對所有的設計和代碼進行深入的復審；
4）由於人員眾多，有面子的問題。
-- 引用自《構建之法》P80
思考：在書中的P74頁寫到復審的必要性時，對作者的觀點我是沒有意見的，但是當一個主程序員寫完自己的代碼時，自己對整個程序的思路時清晰的，一個對此套程序思路毫無了解的人來復審程序時，會不會增加程序出錯的可能性？或者由於對思路不理解，則需要主程序員對其進行說明，在者上面消耗的交流成本和時間成本未免頁太大了些。在書中的額P80頁又寫到團隊復審的弊端，確實是如此，復審的人有時候也會因為面子問題即使看不懂也假裝看懂了的樣子，復審者若不是程序員本身基本不會對主程序有很深入的人士和理解，與其做這樣的復審還不如讓主程序員自己來再一次審查。我認為作者在書中的這兩處是表達了不一樣的觀點的，那么，在實際的軟件開發團隊中，是否存在一個代碼復審者呢？他又是如何高效工作並找出程序漏洞的呢？