近一個月來,努力撰寫排水溝分析程式,突然感到最花時間的地方,其實不是在寫程式碼,而是反覆地在改資料結構和演算法。臺灣人最會自作聰明之處,就是在看完別人的資料結構和演算法後,緊接著說:「這個我也會,我花XX天的時間就可以寫出來了。」不要用我的資料結構和演算法,尤其是不能使用我的演算法,重頭開始寫到跟我一樣的進度,請你仔細評估一下究竟需要花多少時間呢?
傳統的程式設計問題1 + 2 + 3 + … + N = ?,而且考慮N為任意正整數和大數運算原則,緩慢的計算方法是連續加總得結果,快速的計算方法是梯形公式直接求解,此處的連續加總和梯形公式都是演算法。若是演算法不佳,資訊同行會說爛方法兼沒技術,不想被人這麼品頭論足,就得花點時間想演算法。以上,都是屬於可以直接求解的問題,而歸類為不能直接求解的問題,程式設計師常會問起業主:「你的計算流程大概怎樣?…」有些工程設計根本沒有流程,僅僅是反覆地在試誤取得差不多的解。雖然,已經儘量不咬文嚼字,但是仍想更白話的說:「重點是你打算怎麼解?」
程式設計真正困難之處在於演算法,要是耍白目想讓業主確實了解其困難性,就是按照他的意思將程式碼寫出來,然後讓他知道他的想法不可行。業主頭一次遭到挫折,想必應該還是自信滿滿,再照一次他的意思寫給他看,然後再讓他知道第二次想法仍然不可行。想當然耳,事不過三就已經可以體會到演算法有多困難,尤其是必須在有限時間內解出問題,常常會遭遇困難於計算之處。演算法往往和資料結構互相牽連,所以兩者相互間會改來改去,因而得反覆如此直到近乎完善為止。
傳統的程式設計問題1 + 2 + 3 + … + N = ?,而且考慮N為任意正整數和大數運算原則,緩慢的計算方法是連續加總得結果,快速的計算方法是梯形公式直接求解,此處的連續加總和梯形公式都是演算法。若是演算法不佳,資訊同行會說爛方法兼沒技術,不想被人這麼品頭論足,就得花點時間想演算法。以上,都是屬於可以直接求解的問題,而歸類為不能直接求解的問題,程式設計師常會問起業主:「你的計算流程大概怎樣?…」有些工程設計根本沒有流程,僅僅是反覆地在試誤取得差不多的解。雖然,已經儘量不咬文嚼字,但是仍想更白話的說:「重點是你打算怎麼解?」
程式設計真正困難之處在於演算法,要是耍白目想讓業主確實了解其困難性,就是按照他的意思將程式碼寫出來,然後讓他知道他的想法不可行。業主頭一次遭到挫折,想必應該還是自信滿滿,再照一次他的意思寫給他看,然後再讓他知道第二次想法仍然不可行。想當然耳,事不過三就已經可以體會到演算法有多困難,尤其是必須在有限時間內解出問題,常常會遭遇困難於計算之處。演算法往往和資料結構互相牽連,所以兩者相互間會改來改去,因而得反覆如此直到近乎完善為止。