工程師想必對於 DRY, KISS(Keep It Simple, Stupid), YAGNI(You Ain’t Gonna Need It) 這些廣為流傳的開發原則並不陌生，這些原則都是過去許許多多優秀工程師透過自己的經驗而濃縮的開發準則。

但是作者觀察到有滿多工程師對於這些開發原則/命名標準/最佳實驗經驗等採取一個不信任態度，甚至覺得導入這些東西都是浪費時間。
因此本文章是作者探討什麼樣的工程師可能會不太願意去學習與導入這些廣為流傳的開發原則與經驗

Small projects and experience

作者開宗明義地說，小專案的成功經驗基本上是沒有辦法導入到大專案的開發的，小專案的特型譬如 1) 合作人員很少 2)專案時間少
這類型的特性只得技術債或是欠缺設計的程式架構不太會影響整個專案，畢竟專案太小，時間太短，後續的人不一定有機會真的觀察到這些潛在的問題。

而小專案還有一個很大的特性就是後續維護的人很有可能跟當初的開發者不同，所以對於開發者來說非常難去感受後續維護的痛苦與需求。

上述特性有可能會使得開發者覺得自己的開發經驗非常足夠且堪用，因此就會基於這樣的經驗來抵抗其他更多被推廣且推崇的開發原則與最佳實戰經驗。

因此對於一些只開發過小專案且沒有後續維護的工程師來說，其有可能就不會想要學習這些原則與經驗，畢竟自己的工作流程根本沒有機會感受到好處。

Reward and incentive

簡單來說就是「劣幣逐良幣」的概念，從工程師開發的角度來看，寫一個「可能比較好維護，未來比較不會有問題，高品質的程式碼」如果實務上不會帶來任何好處，甚至可能「績效表現比較不好」的情況下，那為什麼工程師要努力寫出高品質的程式碼？

軟體團隊除了開發者之外，還會有相關的專案管理人員，產品管理人員以及最終使用者。
對於非技術人員來說，其在意的點更有可能專注於「程式開發速度，產品上線速度」，至於專案的後續維護性，開發靈活性等長時間才會看到的問題都不是他們所在意的點。

這種情況下，如何評價一個工程師的能力很有可能就變成「能夠多快的滿足專案需求，而不是寫出的程式碼品質」，所以對於工程師來說，快速寫出功能不考慮後續其他維護等長期問題反而更可能受到團隊重視，因為「功能出的快」。

所以如果團隊沒有辦法好好的去重視「高品質程式碼等考慮長期問題的開發原則」就有可能會導致工程師不會想要好好的去撰寫好的程式碼，長期下來這些工程師就可能會開始拒絕學習各種開發原則與最佳實踐的經驗，畢竟導入這些東西沒有任何實質上的幫助，反而初期可能會降低功能的上線速度。

「知彼知己，百戰百勝」，沒有花時間去學習這些開發原則的前後脈絡與適用情景就沒有辦法很順利的導入到開發專案中，所以實際上這些導入都要工程師花時間去學習與理解，然後嘗試導入與使用。

然而並不是每個工程師都願意花時間去學習，畢竟平常工作就是寫寫程式碼，寫寫文件，結果來說能動就好。花這些時間去學習這些東西

作者認為很多工程師「其實都不知道自己不知道什麼」，這導致他們很難去學習新技術與新概念，畢竟未知領域帶來的好處與優勢不是他們工作經驗中有機會去體驗到的，就如同前面所述，對一個擅長開發短期專案就拋棄給別人維護的人來說，其很難體會到各種長期維護與技術債的問題。
practices.

另外一個非常常見的問題就是「導入開發原則與好的開發經驗」與否對於初期開發來說很有可能沒有很任何明顯的差異。
從短期目標來看，兩者開發角度產生的結果不會差異太大，但是對於只有幾個月的小專案來說，後者甚至能夠更快的完成需求然後拍拍屁股結束閃人。

架構複雜性，技術債以及其他的爛程式碼可能產生的後續問題都需要時間發酵，所以團隊事主如果沒有辦法以長期觀念來看到程式開發的話，上述的問題就沒有辦法被重視，就如同前面所述，開發者就會「速度為主，品質為輔」的概念來開發，至於後續維護痛苦與否就是後續接手人的事情。

剩下其他論點就可以到原文去觀賞

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

</div