網頁

2013年11月15日 星期五

【文章】十則來自 Google、Pinterest 工程師的金玉良言

【來源:Inside】

1、慎重選擇第 1 門語言

程式語言各有不同,不過區別不大。但用語言的人區別就大了。選擇了一門語言你就選擇了一個族群。
– Sam Kaufman,自由職業者,iOS 開發者,10x management
如果你想快速建立原型(尤其對於希望對產品進行 iterate 升級的創辦人來說),那就用 Ruby 或者 Javascript。
– Erin Parker,Spitfire Athlete 創辦人兼首席開發者

2、你不是隻「程式猿」(code monkey)!

偉大的開發者能夠建構並開發應用程式。驚豔的開發者能夠在關注業務的同時做這件事。業務端的人大都不懂程式,但是肯定能夠理解特定功能背後的動機。
別人說什麼開發者就做什麼,沒有去理解為什麼要這麼做,導致雙方均錯失了機會,這樣的事情太常見了。
– John Coggeshall,自由職業者,web 開發者,10x Management,PHP 核心貢獻者
精通程式是一個崇高的職業目標。一旦實現了這個目標,別忘了考慮一下你自己。不要成為任何公司的奴隸或者在毫無價值的東西上浪費你的時間。
— Greg Sadetsky, Python 及Javascript 專家,10x Managemen;協同辦公空間Abri.co 創辦人
要想按期完成,得在開始技術工作之前事先進行專案溝通(哪怕這並非先決條件),因為其他人的響應速度千變萬化。
– Andrew Wilcox ,web 應用開發者,Meteor 核心貢獻者,10x Management

3、保持敏捷,不斷交付

早發表,不斷發表,以唱 rap 的節奏發表。
– Max Nanis ,自由職業者,web 開發者,生物訊息學專家,10x Management
不斷測試。好的測試包如保單和煤礦裡的金絲雀之結合。它能幫助你在生產週期中更早地找出錯誤,而錯誤越早發現越容易解決。
– Jeremy Green,自由職業者,web 開發者,專長Ruby on Rails,10x Management
快速失敗。寫程式(及生活)時我希望儘早知道什麼地方不能工作,而不是放任不管讓它增殖擴散。全面放開,快速失敗,修補缺陷,不斷繼續。
– Stephanie Volftsun,Kno​​tch 聯合創辦人兼CTO
為所有程式編寫自動測試!盡可能踐行測試驅動的開發。
– Zoran Kacic-Alesic,Industrial Light & Magic 研發主管

4、保持對測試流程的控制

許多專案深受多測試週期之苦。這會拖累專案,導致組織整體出現高層次的問題。
工程師應該專注於對自己的程式進行單元測試及半回歸測試。他們比其他任何人更了解程式庫,也知道自己會影響到哪些變更。有時此類變更會由於 QA 測試範圍有限而缺失,因此導致生產環節出現重大問題。
– Sanjib Sahoo,tradeMONSTER CTO
要想在力所能及的情況下盡快開發出無缺陷程式,永遠永遠也不要把寫測試放到後面。我們更清楚這一點。要檢查一下測試的覆蓋率,確保100% 無死角。
– Seth Purcell,Signpost 工程副總裁

5、如果你是自由職業者,要學會說不,哪怕面對的是金錢

要對時間和成本有一個合理的評估,然後把它加倍。如果有人說「這應該很簡單」,那,快逃吧。
– Ryan Waggoner ,自由職業者,web 及行動 app 開發者,10x Management

6、榮譽屬於過去—理論是一回事,但實踐更重要

改進軟體開發品質的最佳方式就是去開發軟體。許多雄心勃勃的剛入門的工程師花了很多的業務時間去讀書,關於最新工具的、關於開放流程的,諸如此類的東西。
很多人都是這麼消磨自己的閒暇時間的,但這樣很容易就把你給耽擱了。別這樣,通過盡可能用腦來強化大腦負責開發軟體的那部分。
–James Cropcho,General Assembly 的 Ruby on Rails 專家及講師
不斷探索。我見過的許多工程師手上都有幾個在進行的業務專案。做業務專案迫使你要探索新技術然後學習創建 app 的各方面。你可能需要做前端的 HTML/CSS,後端的 API 集成,數據庫優化,做行動 app,還得設置自己的伺服器。
– Andrew Waage,Retention Science CTO 及聯合創辦人

7、互相切磋是你的秘密武器

兩人一組寫程式非常必要。兩個工程師共同開發同一個模組可以相互檢查對方的程式。開發團隊每周也要召開程式審查會議,讓每一個開發者給其他人的程式提供回饋或意見,解釋如何改進程式。這能夠形成一種協作文化。把開發者的自負拋開!
– Sanjib Sahoo

8、像躲瘟疫一樣避免過早優化

只有在問題和解決方案都出現在你面前時才進行重構(refactor)—過早重構是時間上的巨大浪費。不要投入半年後可能被扔掉的任何東西的完善上。過早優化是罪惡之源。
–Seth Purcell
不要過早優化!我不斷看到工程師在使用者還沒有到1000 的時候一再對擴充到100 萬的使用者規模擔心。
– Mariya Yao,Xanadu Mobile 創辦人兼創意總監,移動開發者及設計師

9、你的程式只寫一次,可別人會讀它千萬遍

你寫的程式機器會解析執行,可其他人卻需要讀你的程式,理解它、擺弄它。你必須明白,你的程式會有未來的觀眾。程式也是一種書寫形式的溝通。
– Tracy Chou,Pinterest 軟體工程師
聽起來很奇怪,但是你永遠都得替自己的未來著想。問問自己:如果你有健忘症的話,你還能不能理解自己寫過的程式?
– Wai Ching Jessica Lam,Sugarbox 共同創辦人兼 CTO
通讀你的文件。設計改變很多,有時候程式更新的時候註釋不一定會跟進。保持檔案的更新,未來的人(包括你自己)理解起來就更容易。我說不清有多少次我看回自己程式時總在想:「我到底在幹什麼?」只要我寫出了好的註釋,未來頭疼的狀況就少很多。
– Kitt Vanderwater,Google 軟體工程師

10、這是一個崇高的職業。把你的技能用到好的地方。

幫助他人是深層次的人類需求。想辦法用你的工作來改善人類,你就會有成功的把握。
– Greg Sadetsky

As always , if you have any question , feel free to contact me.
有任何問題,請聯絡我

歡迎轉載,請註明出處,感謝。

沒有留言:

張貼留言