軟體的開發本身就是個 「犯錯的過程」;不論你精通多少的軟體工程、技術,都沒辦法去改變這一軟體開發的本質⋯
 
在軟體開發的這一行,精通軟體工程;有能力設計好的軟體架構,有能力寫好的代碼;的人,不計其數。
但,走向超過預算、延遲交付、甚至是以失敗告終的項目,也是不計其數。
 
為何 ?!
 
是軟體工程的方法有問題 ?! 還是軟體開發真的是存在著 「人定也無法勝天」 的一面; 只是我們 「不知道」 罷了 ?!
 
我們一直的都 「認為」 我們已經 「知道」 了軟體開發的方方面面,然而,事實上,我們只是 「不知道」 我們 「不知道」 什麼罷了 ?!
 
我們永遠都不可能知道:
@ 產品中的 5% 的業務邏輯是會如何的變化的 ?
我們永遠都只是在用 「昨天」 對業務邏輯上的理解,去隔離、去設計 「今天」 我們所面對的業務邏輯。
這樣子的作法是我們能做的,也是唯一能做的方式;因為,我們 「大腦的結構」 就是讓我們只能這樣子的去做。
這樣子的作法對於產品中的 95% 的業務邏輯是沒有問題的;然而,對於那剩下的 5%;我們永遠都不可能知道會如何變化的 5%;這樣子的做法,卻是很有可能的會產生讓項目失敗的 「技術債務」 ?!
 
@ 我們寫代碼的習慣
當我們是在 「學習」 著寫代碼的時候,我們是可以 「有意識」 的到什麼是好代碼?什麼是爛代碼的?
但當我們是進入到 「產品開發」 的模式的時候,我們就是在用 「個人寫代碼的習慣」 在驅動著代碼的產出;我們就只能意識到我們 「個人寫代碼的習慣」,而沒辦法意識到所謂的好代碼 ? 爛代碼 ?
 
也就是說,我們永遠都不可能知道,我們由 「個人寫代碼的習慣」 所產生的技術債務,是否會讓項目走向失敗的墳場 ?!
 
@@@ 我們對於我們永遠都不可能知道的那一面所產生的 「技術債務」,我們已無法再藉由軟體工程來幫我們解決;軟體工程只能幫我們解決我們 「知道」 的那一面。
 
@@@ 我們對於我們永遠都不可能知道的那一面所產生的 「技術債務」,我們只能藉由 「數學」 來幫我們解決;數學幫我們找出我們在軟體開發中所犯的錯誤; 所產生的技術債務;而且是最值得花人力、花時間去償還的技術債務。
 
@@@ 當我們用軟體工程、敏捷開發、IT 技術都沒辦法解決我們所面臨的軟體開發的問題的時候,我們就應該要來到 「數學」 的世界;因為,我們要的答案就在那裡⋯

發表評論

您的電子郵箱地址不會被公開。 必填項已用*標註

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據