算法，包含的問題很多。解決一個算法的過程，是一個工程的過程。不僅需要從數學角度，獲得抽象，獲得問題可解性，以及復雜度的相關估計，還需要用語言，庫，系統調用將其實現，這就需要一些積累的經驗。兩者共同決定著一個算法問題的解決是否有效，是否優雅，是否可維護，是否易擴展。下面就從兩個方面說說算法問題的解決。也為自己整理一下思路。
第0是仔細看題，常常幾個字的差別，題目的意思是完全不一樣的，要知道，NP問題其實和多項式問題，就差了幾個字哦。這點我深有體會，經常看了結題報告才發現原來題目沒有想象中的那么難。囧。審題可以從以下幾個方面入手：1 數據范圍 2 給的case 手動理解答案
第一是數學角度。數學抽象是所有問題的第一步，從一個實際的模型，獲得一個解的模型，其實屬于數學建模的范疇。好在一般算法題都是從抽象問題轉化而來，給出的條件常常很特殊，相信有一定做題量以后就能很快的進行建模。建模，首先必須有個初步的模型，才能在腦海中建立起適合問題的模型。這就需要算法經驗。在這方面，將基礎題一種一種過一遍是很好的方法。這使得你的腦海中起碼知道一些基本的模型。舉例來說，求最優解問題時候，就會自覺的想到最優解的幾種模型，是貪心的，還是動態規劃的，或是NP難的，在看到配對，關系的問題時，想到是否可以用有向圖，無向圖，樹形圖來表示關系，然后用并查集，最短路，最大流等經典算法。當求問題可能解時，是否用回溯模型，或者用遞歸。抽象是開始一個問題時，是我最頭疼的一步，因為本身沒有定法。我做題往往將問題抽象不夠，最后得到的算法又臭又長。這也是我喜歡模擬題的原因，單從建模方面，很簡單，只要足夠細心，一定能得到結果。 判斷一個抽象優劣的標準就是問題能否變得簡單。這里的簡單分為兩個方面：能并入現有問題的，能將問題簡單化的。第一點，算法常常是某個或某幾個問題的特例，套用前人的算法，證明都省了，而后者就需要自己分析問題了。這和解一道數學題的過程是一樣的，從已知推到未知，從復雜化簡。思路當然有幾個方面，常用的有：1 改變條件：去掉限制條件，或者加上特例條件，這樣常常可以獲得解的直觀印象， 也可以區分一些貪心和dp問題。2 分治 這是通用的思路，一個問題可以分為幾個子問題，子問題是否也是主問題的一種，子問題的最優解是否是主問題最優解。 完成以后，就可以開始考慮復雜度了。通常是先給出一種可解方案，再改進復雜度。
第二就是工程問題了。這直接決定你的代碼是否清晰，可讀，易懂。現在算法往往采用全局變量的聲明方法避免過多的參數傳遞，變量也簡短概括，頗有數學表達式的氣勢。況且有程序設計實踐中提到的，在局部作用域名字應該簡短的條款，那就大膽的采用最簡單的變量吧。工程中最重要的其實是數據結構。開始做bfs經常用到隊列，而數據結構中的隊列實現不然用鏈表，不然就搞的復雜無比，這導致了很多需要用隊列的題目我拿到以后很是害怕。最后，發現在算法中，基本沒人用new delete這樣的操作符，取而代之的是超大數組來實現鏈表。大家的理念是，用完就用下一個。這確實讓很多問題簡單化了。但是，隨著問題越來越復雜，需要的數據結構往往也隨著復雜了。看看算法導論里面那幾章，從二叉索引樹，到紅黑樹，到B樹，二項堆，斐波那契堆，這幾章到現在我還沒理解。這些數據結構都優化了數據操作，但是實現復雜，這時候就需要庫出現了。algorithm頭文件的出現，讓coder少寫了不少經典算法，stl也將數據結構的春風吹到了算法圈。而boost庫，則是在實用工程中可以看做stl一樣重要的庫。有了庫的幫助，就算你不怎么會數據結構，也能寫出很高效的程序來。
不管怎么說，實踐還是需要實踐。最簡單的方法，就是你的紙和筆。沒有IDE智能提醒，你能寫出多離譜的程序來。一個好的程序員，必須聰明，寫高效，整齊的代碼。這幾個字，需要你用時間去磨練。
Good Luck!