想象我正在往乙個已有的**庫中新增新的功能。假如我一次只新增乙個小修改，這個小修改是如此簡單以至於它只有兩種狀態——寫完**之後只要看一看，我要麼是改對了要麼是改錯了；如果改錯了，我就用另一種方式來修改，後者一定是正確的。
如果我一次不是新增乙個小修改，而是新增兩個，然後把兩個修改放在一起來驗證。這時可能的狀態就有四種：一種正確的，以及三種不同的出錯方式。
如果我再貪心一點（或者是因為某些客觀條件的約束），一次新增三個小修改然後再驗證。這時可能的狀態就成了八種：一種正確的，以及七種不同的出錯方式。
所以這就是複雜度和變數個數之間的關係：c=(v的n次方)，其中c為「複雜度」，v為「單個變數可能的取值個數」，n為「變數個數」。所以複雜 度隨變數個數的增加而指數上公升。所以幾個簡單的問題可以分別解決、而合併成乙個複雜的大問題就根本無法解決，因為整個問題的複雜度不是做加法而是做乘方。
所以聰明的程式設計師知道要小步快跑。所以一次只做一件事、做好提交等build通過了再開始下一件。所以要頻繁地跟其他人的修改整合。所以不要同時 開多個story卡來做。所以不要講什麼「反正這些都是我的工作怎麼做都是一樣的」。所以不要講什麼「小心翼翼地重構太麻煩了不如一步就改過去多省事」。 因為軟體開發的工作量不是要敲多少次鍵盤，而是要處理多少複雜度。把漸進式的修改變成大步伐的修改，會增加工作量，而不是取巧。
所以越是痛苦的事越要頻繁做直到它不再痛苦。所以要讓反饋週期縮短再縮短。不光是為了練習和得到資訊，更是為了降低需要處理的問題的複雜度，使普通人也可以處理——從這個意義上來說，再次向所有不採用敏捷方法的程式設計師致敬，為他們所能處理的超大複雜度。
演算法的複雜度 時間複雜度與空間複雜度
通常，對於乙個給定的演算法，我們要做 兩項分析。第一是從數學上證明演算法的正確性，這一步主要用到形式化證明的方法及相關推理模式，如迴圈不變式 數學歸納法等。而在證明演算法是正確的基礎上，第二步就是分析演算法的時間複雜度。演算法的時間複雜度反映了程式執行時間隨輸入規模增長而增長的量級，在很大程度上能很...
演算法的複雜度 演算法的時間複雜度和空間複雜度
在一次筆試題目中，發現了自己對於演算法的時間複雜度問題上並沒有完全清晰這個概念和計算方法，故上網尋找到比較好的詳細介紹來學習。演算法的時間複雜度和空間複雜度合稱為演算法的複雜度。1.時間複雜度 1 時間頻度 乙個演算法執行所耗費的時間，從理論上是不能算出來的，必須上機執行測試才能知道。但我們不可能也...
演算法的時間複雜度 空間複雜度
時間複雜度和空間複雜度是度量演算法效率的常用指標 事後統計，不常用 事前統計影響因素 演算法策略 問題規模 程式語言 質量 機器執行指令的速度 撇開軟硬體的影響，演算法執行工作量的大小只依賴於問題的規模 通常用整數n表示 乙個演算法是由控制結構 順序，分支，迴圈三種 和原操作 指固有資料型別的操作 ...