理想化編程

    關於理想化編程，三年前已經寫過一篇《關於理想化編程》的文章，具體當時關注的是接口性能，安全，Json字符串等，但是沒有那麼的「感同身受」，當時以爲只要是本身關注本身寫好的代碼就ok，本身當時也是踩着坑走過來的，因此整理了一下當中的某一些原則；若是本身是TL，時間緊任務重的時候，咱們該怎麼辦？CodeReview？先能用，再好用？效率和質量不能同時保證,只有成本足夠高的時候，那咱們該怎麼辦？能怎麼辦？

    最近跟MT的一個小夥伴溝通了一下全鏈路壓測的問題，固然我也看了一些資料，一個測試可以關注開發中常見的安全問題，性能問題及一些開發常犯的錯誤，這個測試必定會是一個合格的測試。只有這樣才能讓某些開發口服心服，直接指出你是由於什麼緣由出的問題，這樣才能「硬」起來。必定不能是簡單的業務測試，安全測試和性能測試歸入測試的考覈。

    先不說測試了，說說開發應該注意的，我以爲從開發的角度來講，最重要的是意識，固然老鳥能把本身的一些套路分享給新人是最好的，有了意識一切都有了，就像你今天要去見你心儀的女神，平時很糙的你會不會精心造做一番？讓你們意識到，代碼規範，線程安全，權限控制，冪等控制，事務處理等都是很重要的東西，固然也要意識到什麼狀況下會出現這些狀況才能更好的控制這些狀況，沒時間集體Code Review，做TL即便再忙也要增量看團隊成員的代碼，這一點最近作的不是很好，之後要增強。

    最近我對象也常常給我抱怨加班，是由於一件事情反覆的作，老闆說什麼領導就讓改，咱們不該該專業的事交給專業的人幹嘛？這樣效率才能更高嗎？好比最近加班太多了？那咱們問一下本身，本身的效率如何，整個Team的效率如何？所謂的工程師文化不就是：自由，效率，創造嗎？可是自由不是沒有約束，自由是自我驅動，自我精進。若是作的都很好，都沒問題，那咱們就正點上班，正點下班。最近看了一些文章說什麼互聯網寒冬，寒冬來了咱們不該該更加去修煉本身，去抵抗寒冬。   

    理想化編程應該是追求極致，不斷重構；不該該是得過且過，想固然。你應該去敬畏每一行代碼和每個方法。