http://www.kuobrothers.com/article-124.htm
http://www.kuobrothers.com/article-124.htm 一些看法：
1.讓全團隊都用你(創辦人)的開發語言和環境:
第一點是溝通成本 這個很重要 因為不同語言不同思維 的確是會有出入，但是也不能完全就這麼說，因為重要的是誰去跟程式設計師溝通跟他能不能好好溝通。 這只是因為他是startup 說穿了舊是校長兼撞鐘 要高度 monitor 才會變得這麼極端
2.只設計給當下使用，不考慮未來任何擴充性:
第二點，這個我其實是贊同的，除非可知極短距離內（一個禮拜內?）那些事情就會發生，不然考慮太多擴充性實在是找自己麻煩。但是，也並不是說因為這樣就該把程式碼充滿著 duplicated code 或 dead code，兩者是有差的。程式碼的品質即使不考慮未來需求，還是有其要求。
3.不寫任何comment(程式的註解):
第三點，我想問題是「不要所有東西都想寫註解」。以 Java 而言，除非你在作 framework ，不然每個 method 都寫 javadoc 是不是真的有必要我想就是見仁見智，而真正困難不寫註解就會看不懂的東西，寫個註解是省時間不是花時間。那就該做 (ex. regex )
4.不寫任何documentation:
第四點，文件是給人看的。如果他今天參加政府 xxx 計畫，他們需要專案文件之類的，就不是他說要不要寫的問題。我覺得跑專案也是一樣，是因為有人看所以要寫。如果專案沒人需要看文件或者是 PM 不需要倚賴文件就能掌握現況，那當然就不需要有文件。
5.不要把可以用文字表示的東西變成圖檔:
第五點，這我是完全同意。作這種事情真的是找自己麻煩。
6.不要有一大堆測試環境和policy:
第六點，我覺得這要看「做什麼」。你總不能連 開發者本機的 local development 都沒有吧，打錯字直接爛 production ? 這個部份應該是有點誇張。 我覺得第六點他想要強調的反而是不需要作完全部 test 才上 production 。（如果你心臟夠大顆 功能也還ok的狀況下）
7.PM的話聽聽當參考就好:
第七點，我同意，PM的話就跟這篇文章一樣聽聽當參考就好。（當然，前提是你不會跟PM 打架或者 PM 不會一個不爽就不幹之類的。）
8.不一定要寫很好的程式:
第八點，我覺得那是對的。重要的是先解決問題，手段之後還可以視需要再回來作精緻化，而且大多數的東西其實沒有精緻化的必要。
9.不要追求網頁效能:
第九點，我覺得這不是有沒有流量的問題，是使用者感受上只要是還能接受的程度，去微調那些只有專精此道的工程師才感覺的到的幾十微秒是沒有意義的。 不過網頁五秒如果是 dom ready 五秒，是真的有點太久了。我個人認為使用者能忍受時間是兩秒。（內容loading 可以久，但畫面不行）
- 少用Fancy的東西: -- 第十點，應該說不要一開始就強調精緻化，而是以功能該有的都有為主，精緻化是上線之後再持續地作的東西。
整體來說這篇文章我覺得他的理念其實是對的，只是有些結論有點麻煩， 我總覺得如果有工程師奉行之也是很困擾的事情... 這應該是 PM 要去設定工作項目或團隊規範時該參考的，而不是工程師該採用這種方式做事。 有人感覺的到這兩者的差異嗎 XD 以工程師的角度而言，他們仍應該追求更高品質的程式碼跟更好的文件註解撰寫方式，那些事情是有價值的，而不是不去做。 但是 startup 產業的特性就是他們沒有時間讓工程師學習、練習，所以只好採取這種斷尾的方式加速。長期而言，工程師容易失去成就感跟認同感。 這也是 startup 的 developer 跳來跳去的理由之一... 回過頭來說工程師，如果是我所見過的專家，他們可以在有速度的狀況下，又兼顧一定的程式碼品質、只寫必要性的註解，只是那種人也不是 startup 環境能負擔得起的。 很多時候雖然 startup 核心成員能力很強，但是因為他們也因為強會多去派在 PM 的角色，會不自覺的被環境開了限幅器，這種事情很常發生也是很可惜的。
Comments
No approved comments yet.