Posts Tagged ‘programming’

在 appWorks 有一些問題我們常常討論，例如：用什麼工具、做什麼產品、該怎麼行銷、該跟誰合作、怎麼合作、什麼時候增資、該拿多少錢… 等等，這些問題往往沒有一定的答案，也必須要視情況而定。但越是沒有標準答案的，我認為越是應該多討論，這樣才能幫助創業者們根據自己的情況，定義出最適合自己的處理方式。

而關於 coding，「要不要寫 test」就是其中有一個這樣的問題。我個人的意見是當你要做一個非常簡單、用完即丟的 MVP，那不必寫 test。如果邏輯比較複雜、日後有維護的必要或是有和人家協同工作，那你一定要逼迫自己寫 test。

這絕對不只是完整性、邏輯性或是身為一個工程師的職責問題，而是你如果不寫 test，就是跟自己過不去 — 跟好的 comment/documentation 一樣，不做的話，日後要維護時，你將會花更多時間在弄懂自己當初寫的 code，當別人要用你的東西，你也必須花更多時間跟他解釋，這不就是跟自己過不去嗎？

我得承認關於更深入的判斷什麼時候要寫 test、該怎麼寫，我不是專家。但是今天讀到一篇文章寫得很好，在這裡跟大家分享。

1. Test 讓你用程式功力去挑戰你的程式功力 — 身為工程師，大家最討厭的就是不斷的手動測試了，那何不把這些寫成程式？況且最好的進步方法就是以己之矛，攻己之盾，這樣不斷的循環下去，你的程式功力一定突飛猛進。
2. Test 讓你跟你寫的程式還有你自己對話 — 當你若干時間之後回來看自己寫的 test，你將會重新檢視自己當初的邏輯 — 這樣複雜的錯誤處理真的有必要嗎？這個物件夠獨立嗎… 等等，並且想清楚你寫的程式跟整個系統的架構是否吻合。
3. Test 提醒你程式是用「用了」多少行衡量，而不是「寫了」多少行 — 記住，最棒的程式碼，不是程式碼！
4. 好的 Test 設計還包含好的 Test 註解 — 如果你寫好的測試，別人更容易了解你的程式，和如何跟你介接。
5. Test 讓你可以看穿別人寫的 code — 同樣的道理，如果大家都寫好的測試，那你可以更容易了解別人寫的 code，大家都會進步的更快。

以上，就是一些關於寫 test 這件事情的觀念，希望能夠讓你更認同 test code 的價值。或許你有更有趣的經驗？歡迎留言跟大家分享。

想要在臥虎藏龍的 appWorks 跟高手們一起創業？第四屆 appWorks 育成計畫歡迎你的加入。

(image via richardmoross, cc license)

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

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

這些工程師往往可以輕鬆的通過面試，但當他們真正開始工作，卻讓人大失所望。我讀了很多關於這個問題的研究，但當我越看它，就越發現這些「殘障工程師」，就好像我的英語學生一樣。他們有 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)

聊完了軟體工程估算時間的問題，工程師薪水的問題，今天來和大家分享兩個很不錯的程式設計「做」與「不做」列表。首先，是 Andres Taylor (安綴斯‧泰勒) 寫的「Top 10 Things Ten Years of Professional Software Development Has Taught Me」，翻成中文就是「十年的程式設計經驗教我的十件事情」。

原文不長，裡面有很多不錯的觀念，我鼓勵你們去讀讀。以下是中文版：

1. 物件導向比你想像中的還難，很多
2. 程式設計師最重要的技能：溝通
3. 你必須要學會說「不」
4. 如果所有的事項都一樣重要，那意思是它們都不重要 — 無論如何必須把先後順序排出來
5. 千萬別把事情複雜化
6. 深入問題的核心，但是不要被困住了
7. 非常清楚的了解其他人在做的事情，無論是行銷、設計、客服
8. 你的同事就是你最好的老師  (你該試試 Pair Programming)
9. 無論如何最後的產品必須是好用的
10. 這世界上總會有一些混蛋

而至於什麼事情應該要避免，大家可以參考 Dare Obasanjo (戴爾‧歐巴桑侯) 寫的「Top 10 Signs Your Software Project is Doomed」，翻成中文就是「十個軟體專案注定失敗的跡象」。

1. 第一個版本就想做太多功能
2. 採用太新的技術平台
3. 「複雜的問題，需要複雜的解法…」
4. 團隊人手不足
5. 成員開始隱藏進度落後的事實和原因 (Schedule Chicken)
6. 不斷更改、增加的需求 (Scope Creep)
7. 不知道客戶在哪裡
8. 2.0 症候群 — 後繼版本非要更大、更強、更美 (Second System Syndrome)
9. 與公司裡面另一個很有份量的產品競爭 (這在創業團隊應該不可能發生)
10. 根本從一開始就選了一個你無法解決的大問題

以上，跟大家分享，希望能夠幫助你們在做的產品更順利、更成功，加油！

(via Coding Horror, photo via stianeikeland CC license)