提問

寫了再改Code-and-Fix模式真的很差嗎?

在這篇部落格中,提到了使用寫了再改模式缺點很多.但是在現實中寫程式碼往往遇到設計很難想到的問題,比如oo課程中的表示式求導,很難說一次就想到一個很好的程式碼實現架構.而且即使是在企業中某個專案也沒辦法做到一次設計就能成功吧.下文提到的瀑布模型的修改不也是寫了再改模式嗎?

寫了再改對於寫作業來說應該是足夠的。在實際企業開發中，我覺得其實很多也是這樣做的。除非是極其有經驗的程式設計師才能在一開始的時候看到整個專案的全貌，提前考慮到效能問題，所以對於絕大多數人來說都是暴力解決所有問題。直到出現效能問題才去解決問題。這樣做在效率上有一定保證，但是從長遠來看，該模式有一定的壞處，可能專案未來需要大規模重構。

部落格中提到的眾多軟體開發團隊形式有本質區別嗎?

在這篇部落格中,提到了一窩蜂模式,主治醫師模式,明星模式 ,社群模式 ,業餘劇團模式,祕密團隊,特工團隊,交響樂團模式....感覺這些模式都是為了應對不同的團隊成員的個性以及專案的難度來做的一個調整,沒有本質性的區別.而在現實中團隊是一定要按某個模式來開發嗎?或者說大多數的團隊其實是根本不需要模式這個概念的,只要處理好一些溝通上的問題就行?

本質上都是開發團隊組織開發的方式。不同點在於不一樣的人，不一樣的專案導致了不同的方式。在團隊作業中，也能看到不一樣的組採用不同的組織方式，但是從結果來看，不同的組織方式帶來的效率也是不一樣的。

開發團隊中需不需要"影評家"?

在這篇部落格中,提到了一個影評家這樣的角色,那麼在開發團隊內部需不需要一個一行程式碼都不敲的影評家?雖然他有一定的提供需求的作用,但是很招人煩.

不需要，在團隊作業中也聽說了一些故事，所以還是不需要吧。

開源專案的商業價值如何體現?

在這篇部落格中讀了以下內容

斯坦：那開源/共享軟體是怎麼一回事，如果開源了，商業價值如何體現？
阿超：這個問題問得好，我估計如果開放討論，以咱們的風格，三天三夜也講不完。
 

對這個問題還是蠻好奇的,以及為什麼很多人要去追求創造開源社群?

開源專案做大的商業價值就是使用者不需要花錢，能夠獲得很大的流量，帶來變現，同時能夠搞得競品流量下降。如果能輔以各種手段留住使用者，那效益會更高。

像Vue個人技術型的盈利應該完全靠贊助，官網流量應該是挺大的。

像uniapp企業級開源專案做了很多的相關生態，外掛市場，後臺管理，雲打包等等。

像鴻蒙作業系統開源，希望更多的開發者能夠使用，從中獲利也是遲早的事。

現在軟體工程理論在現實應用中具有多少操作性?

隨著技術的進步,越來越多的開源工具出現,很多大型專案其實已經有很好的輔助工具幫助進行專案的管理,包括測試,程式碼分格的要求,文件的撰寫等等.包括軟體工業化,出現大量的模板程式或者是ui元件.使得很多專案不需要軟體工程方法就能實現很好的管理.同時現在寫程式碼的人越來越多,你想到的需求很可能已經有人實現了,而那些沒有想到的需求可能也不需要很多行程式碼就能完成.那麼其中的理論在現在能用到的有多少?雖然看到老師的部落格羅列很多,但都感覺只是現象或者是經驗,而不是一個系統的理論.

把理論應用到實踐難度是非常大的，特別是像軟體工程管理這樣的管理學科。我在團隊作業過程中雖然沒有刻意去留意用了哪些東西，但是或多或少用到了軟體工程的知識。需求分析，設計，管理，測試等。雖然現在有了很多用於管理，開發的工具和元件，但是人類的需求是無限的，這些東西不能滿足所有人的需求，因此還是需要一些理論作為支撐。

知識點

需求

• NABCD
• 需求一方面要開發者去思考，同時也要深入瞭解使用者的理念。
  • 在需求分析階段我們自己根據自身經驗設計了很多刷題app相關功能，如：做題模式、題目推薦、快速做題、搜尋、題目收藏、錯題整理、題目筆記、題目評論等，同時發放了問卷調查，根據使用者反饋刪掉了排行榜，線上pk功能。因為我們認為我們主要爭對考期的同學實現他們的需求，pk和排行榜對於只有考期使用的使用者來說應該是不會用到的。

設計

• UI設計對後期的指導和功能完善意義極大
  • 在團隊作業中我主要負責前端開發，在UI設計時使用了以前從未用過的原型設計工具。UI設計是將需求與功能結合，把最終產品呈現出來的過程。在產品做出來之前，想好產品是什麼樣子，能夠幫助我們思考哪些需求還不夠完善。以及不得不思考是UI滿足需求還是需求滿足UI，可以說這是一個雙向過程。特別是首頁的UI設計，不斷地思考完善才能夠做出更好的產品。
  • 以及在開發工程中，有些頁面不知如何下手時，也可以參考前期的UI設計，能夠提供靈感。

實現

• 實現階段一定要保持溝通，否則會有跟不上進度的情況。
  • 在實現階段起初我只顧完成自己的部分，與團隊的工作有些偏離，導致後來有些耽誤團隊工作。

測試

• 測試能夠保證系統的安全性和穩健性。
• 做不到完備的測試那就準備好及時修鍋。
  • 在前端開發的過程中，以為自己已經儘可能地考慮了文字溢位導致ui混亂的情況，但是在評論中還是出現了文字過長沒有換行地情況。這一方面在後期開發中也是下了很大的注意力，但是依然不敢保證沒有問題。

釋出

• 釋出階段一定要關注同類產品的宣發，提前搶佔資源。
  • 在beta版本釋出的時候，突然殺出一個IOS競品，這是萬萬沒想到的。ios版本的產品搶先一步在學校的表白牆，朋友圈等地方釋出，使得我們再去會有一些誤解，使得我們的產品釋出會受到一些影響。

維護

• 要積極的收集使用者反饋，滿足使用者的需求。

感想

個人專案

閱讀作業上回顧了與計算機結緣，在計算機學習，未來的打算。在這裡讀書是挺幸福的事，要考研了，可能以後沒書讀了，嗚嗚嗚。

閱讀作業2閱讀過一些部落格以後，讀過感覺和沒讀一樣，之前課程如資料庫也都講過這些東西了，沒什麼收穫，然後提了一些莫名奇妙的問題。

案例分析作業 掌握了一些軟體測試的方法,學會了對一個軟體客觀的進行評測.

不是很擅長寫東西，所以個人作業完成的不是很好，不論是排版還是內容都需要很大的改善。

結對專案

結對專案我有幸於一位大佬結緣，在實現過程中，深刻體會到了結對程式設計的效率之高，兩人溝通之下使得敲程式碼也不再那麼無趣，在不知不覺中便完成了專案。從大佬身上也學到了一些優秀品質，大佬對程式碼風格的要求很嚴格，用java實現事件回撥和事件回滾機制，使得設計更加合理。同時我們也使用了CICD進行單元測試部署，幫助我們保證專案的正確性。

團隊專案

團隊專案有幸結識了一群願意做出優秀產品的隊友，大家的目的就是把他當作一款產品去做。在需求分析階段我們連續熬了好幾天，拍視訊，寫文件。起初本來定的專案是做一款與考研相關的app，本來我們將使用者鎖定到學校內的考研同學，將學校也縮小到985，211，從而達到縮小需求的目的，我覺得這個專案是十分可做的，但是被課程組給否掉了。

後來比較幸運，我們能夠選到航概這個最簡單的課程組提供的專案去做。但是簡單的專案做出花來並不容易，我們需要考慮如何創造出新的東西。起初設計的功能包括：四種刷題模式的支援，錯題和收藏的支援，題庫資料的支援，這些功能並沒有辦法填滿首頁的六個格子，且都是已有題庫小程式實現的功能。我們想到了用日曆來管理考期的時間、用知識卡片來幫助大家複習非選擇題、用資源社群幫助大家分享資源、在結對專案中，我對gitlab的issue使用有了一個比較深刻的體驗(不斷地向課程組的問檔提問)，我發現這是一種很好的提問解答模式，於是決定在我們的小程式中實現一個類似的功能，幫助大家解決某一門課程的問題。這些都是我們的創新點所在。而課程組在需求分析階段不考慮這些東西，在第二次設計階段才考慮，可以看到需求分析所做的那場彙報是一個很空泛的東西，沒有設計，沒有實物，只有空談出來的需求，課程組只根據這個，進行專案的否定和通過我覺得是有大問題的。我主要負責前端，之前也有寫過前端，但是技術都不夠成熟，也沒有做出來一個自己引以為傲的專案。所以我選這門課的目的就是完成一款比較優質的應用程式，如果不是一件有趣的事可能真的很難堅持下去。

除產品設計以外，開發時隊友也是比較給力，我們採用兩天一次線下集中開發，每次開發都花費六到八個小時，這樣的開發時間確實能夠很合理的平衡上課和軟工課程的時間分配。除此以外，PM的宣發令人十分舒適，他的爆肝帶動我們爆肝。自己的分可以揚了，隊友的分不能揚。