《構建之法》第一 二 十六章 閱讀感受

2022-08-21 05:21:15 字數 1461 閱讀 6895

第一章開篇作者用於引出的第乙個疑問,「關於二叉樹的遍歷演算法實現有什麼意義」, 第二個疑問「所有的演算法都已經被實現了,學習的資料結構和演算法有用嗎,如何區分好的程式設計師和不好的程式設計師」。

這兩個卻又恰好正是現在的我所面臨的問題。已經是大二下學期了,已經一頭扎在演算法與程式設計中一年多了。起初甚至一直到現在都是抱著一腔熱血地去研究演算法,去做競賽。並沒有很認真的考慮過這兩者能給我帶來什麼。而這個學期開始接觸軟體工程導論,系統分析與設計這些課程的時候,發現自己的專案能力確實有些不足,需要提高。而在自己真正著手去做專案的時候,又迷茫地發現自己不知道學的那些個演算法能做什麼。

在開篇看到了這兩個問題之後,很感興趣地再繼續往下閱讀,希望能從書上,不是說獲得答案,獲得一些新的看法建議或者是例項也是好的。而結果頗令我失望。

概論這一章確實讓我對軟體工程、電腦科學、工程的概念、軟體的特殊性有了更深刻的了解。但是我依舊沒有找到我目前所熱衷的演算法能給我自己帶來什麼。對於這種勾起胃口又不給飯吃的感覺,也是忍俊不禁。

所以有沒有什麼演算法對專案有這巨大提高的例項呢。

psp(personal software pro-cess)個人軟體開發流程。在其中最引起我興趣的是,效能分析部分。而這一部分確確實實對我第一章的困惑又做出了些許的解釋。

2.2效能分析工具中看到自己特別熟悉的複雜度分析,o(n^2)還是o(n*logn)。那麼從複雜度的角度考慮,我想了想我們目前實現的導航軟體,如果是用的dijkstra演算法的話,acm告訴我可以用堆進行優化(當然我不知道現在的導航軟體是怎麼實現的,只是在圖論最短路當中,可以提出我自己的想法)。如果是字串匹配的話,kmp比暴力更優,那麼這些優化確實落實的話對於資料處理確實有很大的提高。這也使我感覺到了自己所學是一種切實可用的感覺。-.-

在本章特別有意思的乙個點還在於軟體工程師和大學生在個人專案上的耗時對比。工程師在「需求分析」和「測試」這兩方面明顯要比大學生花更多的時間,而具體編碼上工程師所花時間更少。這也可以看出,我們需要鍛鍊的不只是**的實現能力,還需要我們對使用者需求、產品功能進行合理有效地分析與設計,在付諸行動取得成品後,還應該對於產品進行測試和完善。感覺這些和自己做競賽特別的像,先是對問題進行分析,設計自己的程式,用合理的演算法進行優化以降低低複雜度,最自己的程式輸入樣例進行除錯,測試臨界值以防溢位和bug。

這一章的內容讓我感覺既近又遠。近在於就在昨天還聽了學校乙個關於創新創業的講座,裡面有這樣的一句話:大學生創業是在人生整個創業過程中代價最小的。而大學生謀求創業的同時,是離不開創新的。

手機的發展和銥星計畫的手機,讓我認識到,軟體開發,軟體工程這樣的乙個專業和領域,他不是乙個飄在天上的科目。他不僅需要像數學物理這些理論學科一樣研究更新的東西,而且我們還需要從實際出發,從應用入手。此時在回頭看第一章所講到的,「軟體團隊要從需求分析開始,把合理需求梳理出來,進行軟體架構、實現、測試、發布」。感觸就比第一次讀到更深了。

寫完這篇之後再回頭來看,發現自己的思路並不是作為乙個軟體開發者的思路,還是以乙個做演算法的人的角度去處理的資訊,做出自己的思考。這可能與自己長期在做的事情有關吧。卻也不知道這樣的思維模式是好還是不好。

讀《構建之法》一 二 十六章隨筆a

第一章 概論 軟體團隊要從需求分析開始,把合適的需求梳理出來,然後逐步開展後續工作 p3 問題 好的使用者體驗要從軟體分析開始,那麼軟體分析僅僅是從使用者的需求出發嗎?我的看法 需求分析是軟體開發的基礎階段,乙個軟體有人買就得找到顧客,顧客有各種需求,有些靠譜有些不靠譜。軟體團隊要從需求分析開始,把...

對一 二 十六章提出的問題

第一章 問題一 第二章 問題一 書上告訴了我們怎樣才算乙個好的單元測試 應該準確 快速地保證程式基本模組的正確性 並告訴我們驗證單元測試好壞的一系列標準,其中提到了單元測試應該覆蓋所有 路徑。一些資料也說到,在做單元測試時,覆蓋率常常被拿來作為衡量測試好壞的指標。於是,我想知道 覆蓋率對於單元測試的...

讀一 二 十六章後的思考

第一章概論 第乙個問題 1.1軟體 程式 軟體工程中的第2個小例項 1.我成了一名職業程式設計師,但是我發現所有的演算法別人都已經實現了,我只要呼叫就可以。似乎我們公司的軟體與資料結構 演算法的關係都不大。那我當初辛辛苦苦學習的資料結構和演算法有用麼?如何區分乙個好的程式設計師和不好的程式設計師呢?...