2015年10月25日 星期日

Code wins arguments - 工人智慧 程式演化

"Mark Zuckerberg’s Letter to Investors: ‘The Hacker Way’Code wins arguments."

工作時,我們常常會花時間在討論、或是說辯論、亦或是只為堅持己見而吵架討論。
從以前到現在,我一直都很重視自己所做的東西。越是在乎越容易陷入迷思,越是迷思更討論不清楚。不了解,是許多失敗會議的主因。

"Code wins arguments" 讓我反思。花這麼多的時間虛擬的討論,只要花一點時間,攤開程式碼來順過流程,問題便迎刃而解。能與人"溝通"與"講清楚"的能力,此能力並非普遍與生俱來的,是練習就能學會。在軟體設計裡面,不斷的加強溝通一環我認為非常重要。

下圖是最近滿流行的,在達成同樣功能下,不同的類的程式設計師寫法。在裡頭,我看到在程式內的溝通,是一個軟體未來能高速成長的關鍵因素。

常常看到軟體工程師不夠。明年要開 1000個職缺,大聲疾呼必須要重視資訊人才數目的培養。現在人才真的不夠多,政府請注意等等。

主要的因素在於容易修改、可擴充的程式碼過少,工程師重寫相同功能的次數過多導致。我認為這不是工程師的問題。而是組織內,有沒有把"程式"本身當成資產。

在寫每段程式時,一定有不可分割的部分(Lagacy)、可模組化的部分(Modulized)、可提供外部資料(Application Interface)。說穿了,就是用 Framework的概念,設計軟體。

在追求個人的程式精簡之美的反義就是只有自己看得懂。開發團隊舊人會離開、新人會加入。我認為從最底層的程式起,做架構管理是有其必要的。開發團隊建議迭代(iteration)的制訂團隊內,開發程式的共識、設計方法、注解、Commit log等,這些規定形成一個開發系統不斷成長。強調只做出功能的公司,稱不上軟體公司,只能是 Hackerathon罷了。

軟體開發跟硬體時代最大的不同,就在於此"軟體資產"是可以累計的。一次次的開發,多花一點時間,保存或進步自己的程式,才能築起通往成功之路。

編按:透過文章,把自己的想法整理、讓別人看得懂。果然是需要練習的。


















沒有留言:

張貼留言