《程式設計師修煉之道 從小工到專家》閱讀筆記03

2022-06-20 09:00:14 字數 1436 閱讀 8870

靠巧合程式設計應該避免靠巧合程式設計,避免依靠運氣和偶然的成功。而要深思熟慮的程式設計。

怎樣深思熟慮的程式設計:1)總是意識到你在做什麼2)不要盲目的程式設計3)按照計畫行事4)依靠可靠的事物5)為你的假定建立文件6)不要只是測試你的**,還要測試你的假定7)為你的工作劃分優先順序。把時間花在重要的方面。

重構:周遭所見,皆是變異與衰敗。**需要演化:他不是靜態的事物!不要對改動猶豫不決

**若具有如下特徵,則應該考慮重構:1)重複2)非正交的設計3)過時的知識4)效能

就其核心而言,重構就是重新設計:怎樣進行利大於弊的重構:1)不要試圖在重構的同時增加功能2)在開始重構之前,確保你擁有良好的測試。 (盡可能經常執行這些測試,如果你的改動破壞了任何東西,你很快可以知道)

易於測試的**:單元測試< 測試你的軟體,否則你的使用者就得測試 >

需求只坑完美,不是在沒有什麼需要增加,而是在沒有什麼需要去掉時達到的。不要蒐集需求而要挖掘他們!與使用者一同工作,以像使用者一樣思考!

解開不可能解開的謎題

解開謎題的關鍵:確定加給你各種約束,並確定你確實擁有自由度

< 不要在盒子外思考,要找到盒子 >

我們可以先確定最為嚴格的約束,然後再在其中考慮其餘約束很多時候,對需求的重新詮釋能讓整個問題全部消失 ------ 就像戈爾迪斯結

等你準備好:有時猶豫的人會得以保全

< 傾聽反覆出現的疑慮,等你準備好再開始 >

規範陷阱:編寫程式規範就是吧需求規約到程式設計師能夠接管的程度的過程

結構化程式設計 ------ 擁有長久的生命

注重實效的團隊:有了注重實效的開發者,讓他們工作在能夠發揮自身能力的環境中,他們很快就會發展並提煉他們自己的、有效的團隊動力機制

無處不在的自動化:軟體開發人員常常會使用最糟糕的工具來完成工作

無情的測試:

< 早測試,常測試,自動測試 >

< 要到通過全部測試,編碼才算完成 >

< 通過」蓄意破壞「測試你的測試》

< 測試狀態覆蓋,而不是**覆蓋 >

< 乙個 bug只抓一次 >

全部都是寫好記性不如爛筆頭:把英語當做又一種程式語言

靠巧合程式設計應該避免靠巧合程式設計,避免依靠運氣和偶然的成功。而要深思熟慮的程式設計。

看到這裡,我不禁想問,套用模板的程式設計算是巧合程式設計嗎?答案是肯定的,因為沒有經過你自己的深思熟慮的程式設計都是巧合程式設計。就像老師說的那樣,總有一天你接到乙個專案,你找不到對應的模板時,你該怎麼辦?

**的重構:不要對改動猶豫不決,我自己本身就有這樣的問題,廢了九牛二虎之力碼出來乙個程式,老師卻提出了新的要求,這時候我就開始猶豫了,怎麼改動呢?從**開始改呢?

**若具有如下特徵,則應該考慮重構:1)重複2)非正交的設計3)過時的知識4)效能

就其核心而言,重構就是重新設計:怎樣進行利大於弊的重構:1)不要試圖在重構的同時增加功能2)在開始重構之前,確保你擁有良好的測試。 (盡可能經常執行這些測試,如果你的改動破壞了任何東西,你很快可以知道)

程式設計師修煉之道 從小工到專家

在專案開始之前 需求需要挖掘,而不僅僅是收集。找出使用者為何要做特定事情的原因,而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯,以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係,而是雙向關係。它們是 交付...

程式設計師修煉之道 從小工到專家

基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設,要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...

程式設計師修煉之道 從小工到專家

這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理,作為一本偏向理論與思想的書,書中不可避免有些假大空的地方,再加上作者寫完本書的時間還在1999年,書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處,作者曾在本書完成十年後說過,如果這本書是放在現在編寫,1999年的那...