Re: [轉錄] 新創網站這樣開發才夠快

看板Soft_Job (軟體人)作者TonyQ (自立而後立人。)時間14年前 (2012/04/07 17:10)推噓2(2推 0噓 15→)

留言17則, 7人參與討論串2/6 (看更多)

http://www.kuobrothers.com/article-124.htm 這篇講的每一點，因為我三年多前在 startup 待過，感覺是有一點知道他想表達什麼，也是有一點心有戚戚焉。但我認為這給 startup 的 PM （通常也就是創辦人）參考的，不是給程式設計師參考的。就我經驗所知， startup 的特性就是 1.團隊成員少可能只有5-6 個甚至更少，所以溝通/管理上的成本是相對低的 2.火力是有限的因為人少，所以能作得事情也少，需要專注的集中方向釋放火力。只要一個失焦，很有可能一兩個人月就浪費了。 3.績效導向流量、使用者數等，是拿來跟金主或廣告商談的籌碼，所以他們會重視這些 KPI 遠勝於其他所有事情。如果能保證拿到 user 的心，即使把網站功能架構修改的破破爛爛也沒有問題。 4.人員流動大你今天的計畫今天的火力明天可能隨著人員的離職就大幅被銳減，其中因為人少，人員離職的影響也更大。 ----------------------------------- 回到原文，從原文提到的幾點寫我對這些事情的一些相關看法：（有任何意見/見解歡迎不吝分享/討論/筆戰。XD） ----------------------------------- ＠01.讓全團隊都用你(創辦人)的開發語言和環境: 這一點是溝通成本，降低溝通成本很重要，因為不同語言不同思維的確是會有出入，但是也不能完全就這麼說要跟著 PM 或者主持人的語言走，因為重要的是誰去跟程式設計師溝通跟他能不能好好溝通。這只是因為 startup 說穿了就是校長兼撞鐘，要高度 monitor 才會變得這麼極端。＠02.只設計給當下使用，不考慮未來任何擴充性: 這個我其實是贊同的，除非可知極短距離內（一個禮拜內?）那些事情就會發生，不然考慮太多擴充性實在是找自己麻煩。但是，也並不是說因為這樣，就該把程式碼充滿著 duplicated code 或 dead code，兩者是有差的。程式碼的品質即使不考慮未來需求，還是有其要求。什麼東西是歸類在程式碼品質，什麼東西是歸類在擴充性，那一把尺我想並不好說明，是屬於經驗的部份。＠03.不寫任何comment(程式的註解): 我想應該說「不要所有東西都想寫註解」或是「只寫重要的註解」。以 Java 而言，除非你在作 framework ，不然每個 method 都寫 javadoc 是不是真的有必要我想我持否定態度。而真正困難不寫註解就會看不懂的東西，寫個註解是省時間不是花時間。那就該做 (ex. regex ) ＠04.不寫任何documentation: 文件是給人看的。如果今天參加政府 xxx 計畫，他們需要專案文件之類的，就不是他說要不要寫的問題。我覺得跑專案也是一樣，是因為有人看所以要寫。如果專案沒人需要看文件或者是 PM 不需要倚賴文件就能掌握現況，那當然就不需要有文件。一般而言 Issue tracker 之類的系統，應該都能取代大多專案管理文件的需求。＠05.不要把可以用文字表示的東西變成圖檔: 這我是完全同意。作這種事情真的是找自己麻煩。＠06.不要有一大堆測試環境和policy: 我覺得這要看「做什麼」。你總不能連開發者本機的 local development 都沒有吧，打錯字直接爛 production ? 這個部份應該是有點誇張。如果你開發一個網站有十台測試機器是有點蠢啦，但至少提供開發者跟測試者有一個本地能測試的環境是重要的。不管是集中一台 server 還是要他們也 setup IDE / server。我覺得第六點該強調的，是不需作完全部 test environment 跟 test 流程，才上 production 。（前提是如果你心臟夠大顆功能嚴重性也還ok的狀況下）至於「做什麼」，舉個例子就好，如果今天是搞金流系統的，跟我說 production 等於 test enviornemt，我大概會翻臉。XD 測試環境是很倚賴測試需求的東西。＠07.PM的話聽聽當參考就好: 我同意，PM的話就跟任何網路上的文章跟建議一樣聽聽當參考就好，可以知道、可以想一想，但是要有挑戰精神跟質疑精神。因為他們的經驗並不是你的經驗。（當然，前提是你不會跟PM 打架或者 PM 不會一個不爽就不幹之類的。）＠08.不一定要寫很好的程式: 我覺得這是對的。重要的是先解決問題，手段之後還可以視需要再回來作精緻化，而且大多數的東西其實沒有精緻化的必要。但你可以不寫好的程式，但你至少需要知道你在寫的是不好的程式，也就是你要有程式碼的「品味」。＠09.不要追求網頁效能: 我覺得這不是有沒有流量的問題，是使用者感受上能不能接受的問題，一般而言我們在作 performance tunning 是 as best as possible ，但是使用者的感受並不是這樣，使用者感受在效能上會有邊際效應。去微調那些只有專精此道的工程師才感覺的到的幾十微秒是沒有意義的。不過網頁五秒如果是 dom ready 五秒，是真的有點太久了。我個人認為使用者能忍受時間是兩秒。（內容 loading 可以久，但出現畫面不行）＠10. 少用Fancy的東西: 第十點，應該說不要一開始就強調精緻化，而是以功能該有的都有為主，精緻化是上線之後再持續地作的東西。 ----------------------------------- 整體來說這篇文章我覺得他的理念其實是對的，只是有些結論有點麻煩，我總覺得如果有工程師奉行之也是很困擾的事情... 這應該是 PM 要去設定工作項目或團隊規範時該參考的，而不是工程師該採用這種方式做事。有人感覺的到這兩者的差異嗎 XD 以工程師的角度而言，他們仍應該追求更高品質的程式碼、更好的文件註解撰寫方式，那些事情是有價值的，而不是不去做。但是 startup 產業的特性就是他們沒有時間讓工程師學習、練習，所以只好採取這種斷尾的方式加速。（不作就不會花時間，也不用煩惱）長期而言，工程師容易失去成就感跟認同感。這也是 startup 的 developer 跳來跳去的理由之一... 回過頭來說工程師，如果是我所見過的專家，他們可以在有速度的狀況下，又兼顧一定的程式碼品質、只寫必要性的註解，只是那種人通常也不是 startup 環境能負擔得起的。所以說穿了，就是產業生態的演化。:) -- Life's a struggle but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.25.49.122 ※ 編輯: TonyQ 來自: 114.25.49.122 (04/07 17:11) ※ 編輯: TonyQ 來自: 114.25.49.122 (04/07 17:13) ※ 編輯: TonyQ 來自: 114.25.49.122 (04/07 17:14)

推

genius945

04/07 17:29, , 1^F

04/07 17:29, 1^F

→

TonyQ

04/07 17:37, , 2^F

04/07 17:37, 2^F

→

alongalone

04/07 17:43, , 3^F

04/07 17:43, 3^F