架構設計:“專案需求重於個人簡歷”
阿新 • • 發佈:2019-01-06
“專案需求重於個人簡歷”
摘自書,也有我的示例。
作為工程師,我們常常要向客戶/老闆推薦技術,手段,甚至方法論來解決問題。但
有時我們心裡不是想尋求解決問題的最佳方案,而是希望藉此豐富自己的簡歷。
這樣做很可能得不償失。
信譽遠勝過時髦的程式設計技巧和流行的正規化。掌握最新的技術趨勢,與時俱進固然重要,但不能讓客戶為此買單。作為架構師,職業操守絕不能忘。公司託付重任給你,是期望你盡職恪守,不受利益誘惑。如果你覺得專案不夠尖端,挑戰性不足,無法滿足職業發展的需要,大可另棲高枝,另謀高就。
選擇正確的解決方案可以降低專案的壓力,團隊工作起來更開心,客戶也更滿意。你會有更
充裕的時間,既可以鑽研現有技術,也可以利用空閒時間學習新知識,甚至重拾嚮往已久的
業餘愛好。家人察覺你的變化後,也會感到欣慰。
把客戶的長遠需求擺在自己的短期利益之上,才能立於不敗之地。
示例:
我遇到的一件事,分析類的任務程式碼是選擇 Scala 還是 Java?
我推薦選擇 java 而有同事推薦選擇 Scala
我的理由有三:
1,Java 團隊中會的成員比較多。
2,是個更成熟,資料更多的程式語言。
3,編輯風格文件總結更全面,瞭解的成員更多。
同事推薦的 Scala 理由:
1,新的函式語言。
2,與 Spark 配合使用更好。
最後領導選擇了 Scala , 且沒有聽我的建議使用 Scala 的風格規範應用於團隊。
這件事沒有對錯,只有時間能證明那個是更好的選擇。
因為選擇的不同,是要後面的故事來證實那個成本更高,開發更有效率的。