Posts Tagged ‘Software Engineering’

Warning: Use of undefined constant archives - assumed 'archives' (this will throw an Error in a future version of PHP) in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: Use of undefined constant page - assumed 'page' (this will throw an Error in a future version of PHP) in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: A non-numeric value encountered in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: A non-numeric value encountered in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26
class="post-2732 post type-post status-publish format-standard hentry category-startup101 category-management tag-code tag-documentation tag-engineer tag-productivity tag-programming tag-software-engineering">

最棒的程式碼,不是程式碼

June 9th, 2011

上次聊過工程師的生產力不應該用程式碼來衡量,因為他們的極致生產力,是在少寫幾行程式,而不是在多寫幾行程式。今天剛好又看到兩篇文章,可以用不同的面向延伸、解釋這件事情。

首先,是一位跑去日本教英文老師的前任軟體工程師,發現了寫程式和學語言間的共通性,他說:

這些工程師往往可以輕鬆的通過面試,但當他們真正開始工作,卻讓人大失所望。我讀了很多關於這個問題的研究,但當我越看它,就越發現這些「殘障工程師」,就好像我的英語學生一樣。他們有 5,000 字的詞彙,書裡面的每一個文法都背得滾瓜爛熟,但是就是說不出一句話。

我的理論是,程式其實就跟寫作沒什麼兩樣。多數的程式概念上一點都不難 (跟你想的不一樣),我們搞不好的原因往往只是寫作能力太差。大部分的工程師根本就不是「流暢」的語言使用者,也沒有努力想要讓自己變得流暢。他們不去多讀讀他人的程式,看不懂也不會使用「成語」,更不會「用程式語言來思考」。這些人寫出來的程式很糟,因為他們根本就是電腦語言的三歲小孩,卻試著要寫一本小說。

所以如果你是工程師,多讀讀別人的程式碼,是很重要的,就跟學習寫作一樣。

相反的,如果你的程式想要讓人家讀懂,那 documentation 是非常重要的。GitHub 工程師 Zach Holman 發表了一篇非常棒的文章,詳細解釋了為什麼你要寫文件,怎麼寫。

  1. Documentation 是個人的 — 相信我,你以後一定會回來改這些程式,如果要讓未來的自己更快進入狀況,把事情搞定,今天請你務必把東西寫清楚。
  2. Documentation 是清楚的 — 如果你不把你推出去的程式碼講清楚,那根本是在幫自己找麻煩,以後一定會出現一堆 bugs、困惑的同事,最後搞得自己更累而已。
  3. Documentation 是可以測試的 — 因為你必須要把程式的邏輯解釋清楚,這讓你重新思考自己的寫出來的東西是不是符合原始精神,有沒有更好的方式。為了不在寫文件時陷入無法解釋的難關,這也迫使你簡化每一個功能,把一個複雜的東西切成好幾個功能。
  4. Documentation 是可以比較版本的 — 好的文件可以讓版本間的比較更容易,也讓團隊合作更有效率。
  5. Documentation 是行銷 — 透過好的文件,可以讓下載你軟體的人更容易開始使用,這也大大提升了轉換率。
  6. Documentation 讓你在床上表現更棒 — 這點 Zach 還在驗證,不過他認為建立好的文件讓你很酷,這應該對自信會有幫助。

以上,希望這些觀念可以幫助你們更了解工程師、效率和生產力之間的關係,加油!

(Image via zooboing, CC license)

Warning: Use of undefined constant archives - assumed 'archives' (this will throw an Error in a future version of PHP) in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: Use of undefined constant page - assumed 'page' (this will throw an Error in a future version of PHP) in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: A non-numeric value encountered in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26

Warning: A non-numeric value encountered in /nfs/c03/h01/mnt/52275/domains/mrjamie.cc/html/wp-content/themes/minimalism/archive.php on line 26
class="post-2390 post type-post status-publish format-standard hentry category-startup101 category-management tag-development tag-pair-programming tag-project-management tag-software-engineering">

為什麼軟體工程無法估算時間?

April 11th, 2011

我們都有這樣的經驗:要開發一個東西,請工程師估算時間,大概要五天。結果過了一個禮拜,東西還沒出來。一問之下,碰到了原先完全沒有預期的情況,否則就是某個套件原來不能這樣用,必須要換一個,否則就是一個莫明的錯誤,找了一個下午還是不知道為什麼。久而久之,工程師開始習慣在回報的時間裡面灌水,預留空間給這些「未知數」,而我們也常常把他們給的時間乘以二,來得到最壞情況的數字。問題是這樣的方法之下,最後整個組織開始習慣用最龜的速度前進,因為估算精準、動作快,在這中間一點好處也沒有。更壞的情況,是叫九個女人去生一個小孩,那才是災難的開始。

為什麼軟體工程無法估算時間?

要了解這件事情發生的原因,你必須要先知道為什麼軟體工程是無法估算時間的。我以前常常喜歡用「常態分布」來解釋軟體工程時間的花費 — 上述的情況,讓大家慢慢從 Average 變成 (Average + 3 STD) 估算,最後平均浪費了 3 STD 的時間 — 不過這只是統計學上的解釋,並不是真正的「原因」。直到我前幾天看到這篇文章:「Why Can’t Developers Estimate Time?」,才給了我超大的一個領悟。(文章有點難,不過英文不錯的人,我鼓勵你們去讀讀。)

作者 Ashley Moran (愛許麗‧莫倫) 說:

我們無法預測軟體開發中每一個項目的時間,是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」,一但目標達到,自動化後的流程就可以重複的被執行,在可預測的時間裡面。所以一個軟體就像是「食譜」一樣,而電腦就是「廚師」,輸入的資料是「食材」,而輸出的資料是「晚餐」。

因此,我們在做的事情是讓未來從不可預測,變得可預測,讓大哥小弟、老爸老媽、只要想煮飯的,人人都可以當食神,給他三十分鐘,都可以弄出一鍋超級無敵海景佛跳牆。所以,「開發食譜」這件事情的本身,是一個創造新知識的過程,時間上當然很難預測。

如何管理

因此,軟體工程用硬體工程的模型去管理,從出發點就是錯誤。一個建築案是先有了「藍圖」,才去估算每個細項需要的時間。當我們在做的是藍圖本身,怎麼能夠沿用他們的模型?如果是這樣,一個創業團隊該如何「管理」開發的時間?

我的答案是你沒辦法 — 你怎麼能夠控制臭蟲什麼時候要出現?但是你可以管理「生產力」,也就是確認團隊總是在高效率的情況下工作,那最後你會得到的是 Average 的工作時間,比起前述 Average + 3STD 快上了 3 STD,這前後有可能就快了 2-3 倍。

而要管理「生產力」,一個現代化的軟體開發團隊,我認為有以下的幾個好工具可以用:

  • Pair Programming (兩人小組) — 一個人寫程式常常會有盲點,兩個人一起則可以看到對方遺漏的地方。更重要的是兩個人都會從對方身上學到很多知識和技巧,彼此都會成長。而當兩個人都了解一組程式碼,日後的維護也有了兩個選擇,不會因為一個人請假、離職,這些 code 就變成孤兒。記得給他們兩個鍵盤,實務上這會比鍵盤移來移去有效率。
  • Daily Stand-Up Meeting (每日早會) — 每天早上固定開一個快速早會,全部人都站著,每個人依序報告昨天的進度,碰到的問題,和溝通彼此程式間該如何傳遞資料。這讓團隊明確的知道彼此的進度,也省去很多溝通不良的麻煩。
  • 高效率的工作環境 — 開放、明亮、舒適的工作環境,或許讓大家換上拖鞋,確認團隊成員們可以取得他們需要的飲料、食物,但是不會吃得過飽、或是喝下過多的咖啡因。當其中一個成員困惑時,確認有人可以幫助他。
  • 隨時找得到使用者 — 代表「使用者」的那個人 (通常是 PM),最好是使用者本身,必須要隨時在現場,幫團隊解釋開發上細節不明確的地方。
  • 設定上線時間 — 雖然你沒辦法知道每一個子項目會花的時間,但是你可以設定一個上線的時間,然後所有的人通力合作在那個時間之前,盡可能做出一個可以推出的版本。當然,如果第一個版本推出時你不會覺得丟臉,那就是花了太多的時間

以上,希望可以幫助你們重新思考軟體開發該如何做,也希望對你們正在做的網站、行動應用有幫助。(當然這不是完整的列表,歡迎大家提出你們喜歡用的工具。)

___

除了網誌,我每天都會在 Facebook 分享許多創業者應該關注的資訊,歡迎追蹤

(Image via purecaffeine@flickr under CC license)

©2020 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成