今日隨筆-構建之法讀書筆記

新晋软工小白發表於2024-06-09

透過一週時間對這本書的快速閱讀,我對軟體工程這個專業有了一種更深刻的認識.軟體工程,顧名思義,就是把系統的、有序的、可量化的方法應用到軟體的開發、運營和維護上的過程。

  一個人的成功不是天生的,而是慢慢積累的。當然,一個優秀的程式設計師也是慢慢學成的;正所謂:千里之行始於足下,我們必須從最基礎的開始,不僅要學會寫程式碼,更要學會看程式碼,看別人的程式碼,發表自己的意見;並且還要學會將程式碼規範化,程式碼看了要簡潔明瞭,讓別人看了就很舒服;當程式碼完成後,我們在為團隊成員複查的同時,要注意觀察程式碼編寫者所遇到的問題或bug,提出自己的意見。軟體的開發,需要一個團隊合作,而每個團隊有不同的合作模式。主治醫生模式,一個人負責主要設計,其他人為他負責支援;明星模式,主治醫生模式的加強版;社群模式,大家共同負責,完成自己擅長的部分等等。但每個團隊最後都會演變成為功能團隊,具有不同能力的人平等合作,共同完成。

  軟體開發,第一步要做的,便是需求分析,我們要知道做的是什麼,有什麼要求,不然當我們投資了許多人力、物力,到最後做出來後卻沒人要,白白浪費時間。所以我們事先向使用者瞭解需求,透過焦點小組、深入面談、卡片分類等方法調查,對功能進行定位。然後透過初始階段瞭解軟體系統的大概構成,系統的風險有哪些;細化階段分析問題領域,建立健全的體系結構基礎;細化階段,團隊要開發出所有的功能集,並將其變成測試驗證過的產品;交付階段,團隊要確保交付的產品符合使用者的實際需求。這樣,才能算是完成一個合格的產品。

此書讓我認識到以下幾點:

一個軟體的開發需要一個團隊不懈的努力;團隊成員首先要有一個共同目標,相互分工,共同完成,隨後團隊成員完成程式碼後,經過測試員後期不斷的測試,完善程式碼;最後經過效能分析,改進,再分析,逐漸提高產品的效能。這樣才會產生出一個符合顧客要求的合格產品。

程式設計軟體能力不是與生俱來的,是每個軟體開發師經過不斷學習,慢慢學成的;每個程式設計師剛開始都是一個小菜鳥,都是自己積累軟體開發知識,學會將程式碼規範化,瞭解軟體開發過程所遇到過的問題,並在發現問題的過程中解決它,慢慢學習,慢慢的提升自己的職業技能,成為一個程式大佬。

理論與實踐相結合。這本書介紹了軟體工程的一些概念:單元測試、軟體開發流程、敏捷開發、軟體需求、使用者體驗、軟體測試、質量保障等。作者在介紹了這些概念的同時,也詳細說明了程式設計師在開發軟體過程中與其的聯絡。軟體工程中軟體的開發包含:需求分析、設計、編碼、測試和維護等方面;只有每個方面做好了,才可能做出一個好的系統。並且,作者最後還提到了IT行業非常重要的創新,時代在進步,所以創新對於我們程式設計師來說也很重要,我們不能墨守成規,必須勇於創新,才能不被時代淘汰。

在讀完構建之法這本書後,對軟體開發的整個流程有了一定的認識。在典型的軟體開發流程中,從一個專案的立項到最後專案的釋出,其經過了多個步驟,以此來確保專案的順利進行。在典型開發流程瀑布模型中,為了獲取軟體需求,需要用常用的獲取需求的方法和步驟來。而對於競爭性需求,我們需要NABCD框架來分析和獲取,即需求、做法、好處、競爭和推廣。對於軟體功能的定位和優先順序,即殺手功能、外圍功能、必要需求和輔助需求,通常採用四象限方法。為了更加深入的理解使用者需求,通常需要採用典型使用者和場景的方法。在軟體開發過程中存在兩種型別的說明書:軟體功能說明書和軟體技術說明書,其中軟體功能說明書主要用來說明軟體的外部功能和使用者互動情況,而軟體技術說明書則用來說明軟體內部的設計規範。而為了將使用者的需求變成可以直接進行的開發工作並源源不斷地實現這些需求,需要功能驅動的設計。軟體開發的生命週期中,在不同階段需要使用不同的測試方法,比如在遠景和計劃階段進行測試計劃和測試設計說明書,同時收集使用者對非功能測試的需求,在開發階段需要單元測試,功能和場景測試,建立迴歸測試基準,探索式測試,整合測試,同時開展非功能性的測試,在穩定階段需要進行驗收測試。為了讓整個軟體開發的工作更加高效,需要設定PM職位,以此來協調軟體開發工作中除了開發和測試之前的一切事情。而在軟體穩定和釋出階段,可以使用軟體按時釋出的招數:DCR與ZBB,針對出現的不同問題,可以有不同的解決方案,以便於軟體的正常釋出,RTW最終釋出版本。而為了保證軟體的質量,需要達到一定的CMMI等級。在閱讀過程中,出現了一些困惑,具體如下:

1.對於軟體中相互獨立的幾個層次,進行單元測試時層次之間有無測試順序的問題。

2. 在實際工作中結對程式設計能否實現?如何分配結對程式設計兩個人的工作量?公司如何衡量結對程式設計兩個人的工作量。

3. 根據瀑布模型進行開發過程的後期中,如果相鄰兩步之間進行回溯時,之前的步驟是否需要做出改變?

4. 最終設計文件出現在程式設計、編碼和測試階段?

5. 在敏捷開發任務認領的階段,如果一個任務比較困難,沒有團隊認領,該如何解決?

6. 軟體版本的釋出和後續bug的修復之間應該如何取捨?

7. 在競爭性需求分析中,如果我方的輔助性優勢明顯弱於競爭產品,那麼為了持平這方面的弱勢,是參照競爭產品還是?如果參照競爭產品,會不會涉嫌抄襲?

8. PM在與開發團隊交流溝通時,需要具備什麼樣的技能?

9. 各種測試方法。單元測試過程中如何保證所測試模組的正確性,怎麼提高單元測試的正確率?單元測試用例什麼數目最優?在單元測試是否需要考慮極端情況?

相關文章