想要成為軟體開發中的王者,需要明白的 21 條準則

csdn發表於2017-08-17

  本文筆者收集了 21 條有關軟體開發的準則和技巧:這些觀點可能互相矛盾,但仔細品味也會發現其不同點,可以對軟體開發者有一定的啟發。記住,它們並不是真理,只是觀點而已。

 

  01、軟體開發者的工作不是“寫程式碼”,而是解決業務問題,“採用的新框架”常常不能解決業務問題。

  02、我們與人一起工作,只是有時候寫程式碼而已,所以人際關係是這份工作的重要組成部分。

  03、軟體開發人員也是人,他們和所有人一樣都會受到認知偏差的影響。可以讀讀關於認知偏差、FAE(fundamental attribution error,基本歸因錯誤)、特別是Kahneman 的書。

  04、每一個新框架的出現,是因為前端開發者面臨的問題我們沒有理想的解決方案。每一個成功的新框架都有其創新之處,所以得想想“這個框架/庫如何改變我的工作”這個問題。

  05、軟體開發者不“只是寫程式碼”,而是參與開發過程。所以如果公司在使用敏捷(Agile),你必須對其認真對待,最起碼也要對其保有尊重。

  06、程式碼評審(Code review)是軟體開發過程的重要組成部分。對程式碼評審有所疏忽就不能成為優秀的軟體開發人員。

  07、作為軟體開發者,我們對自己部署的程式碼要負責。我們也負有道德上的責任,不要做不道德的事。

  08、使用者也是人。我們的產品和我們的失敗都可能直接影響他們的生活,對你行為的後果要三思。

  09、人與人並不相同,人們的思維方式也不同:有時候我們認為困難的東西從商業人士角度看來可能很容易。這是我們必須解決而不是逃避的矛盾。

  10、對截止時間(deadline)負責。如果在截止時間前完成不了,你必須重新溝通新的截止時間。

  11、任務有兩種複雜性:內部和外部複雜性。內部複雜性不可避免,因為這是任務本身;外部複雜性來自重新架構系統過程中異常決定的後果。要格外注意外部複雜性超過內部複雜性的情況。

  12、如果開發者在寫程式碼或架構系統時選擇容易而不是好的解決辦法,他欠下的技術債遲早有一天是要還的。

  13、“別人”寫的程式碼幾乎總是無法理解或著寫得很差,但並不總是因為程式碼真的寫得不好。有時候這些“別人”就是過去的我們。

  14、有時候在不改變程式碼的情況下也能解決問題。

  15、勇於改變需要改變的,接受那些無法改變的,用智慧來分辨其中差異。

  16、有時候對開發人員來說不重要的事情卻有極高的商業價值。商業是一個好的角度,不要逃避它。

  17、很少有公司關心你的個人成長。如果公司對你目前的水平不滿意,他們一開始就不會聘用你。

  18、會議或者聚會的價值在於在場的人,其次是交談內容。

  19、面試都是雙向的,不僅是公司在考察你,也是你考察公司。

  20、我們選擇這份職業是因為我們對其很感興趣,但付我們薪水是因為我們創造了價值。瞭解一下公司的成本和利潤,看看自己屬於哪一個。

  21、作為自由職業者,花錢請你是因為客戶不具備這些技能:客戶不會告訴你你程式碼哪裡不好、也不會指出其中錯誤,客戶用自己的方式提出這些意見。 

  原文:21 ideas for Software Developer 作者:Tim Marinin

  翻譯:牟雲飛

相關文章