今天在公司裡面，聽到很多的吐槽，最近以前的團隊有很多開發工程師離職，結合自己在公司多年的工作經驗，也發現這個問題越來越嚴重，這裡也吐槽一下。
在一般傳統的小的it公司，準確說的是小的技術團隊，由於涉及到的業務比較少，人員相對也比較小，一半小於10個人，一般情況下，這種10個人的團隊裡面一般會有乙個技術方面的team leader，大多數情況下，這個leader一般也就是技術開發的高手，應該算是小團隊技術最好的，會從事一線的編碼工作，這樣的leader和其他成員相比，級別會高一些，一半情況下，團隊的所有技術決策，都由他來決定，基礎框架也或者核心部分編碼都會由他來負責，所以相對來說，是比較合理的，因為他技術好，開發能力強。這裡面一般就兩個層級。由於團隊小，技術leader對下面技術人員的基本上都會有了解，而且基本上考核的維度都比較簡單如編碼能力，編碼質量等等。而且這個時候業務和系統架構都不是非常複雜，對業務架構和技術架構的要求都不會非常高。
可以看出，架構師是幹活的和忽悠的標準（這裡的忽悠沒有貶義，只是說架構師的工作主要是做業務規劃和技術規劃，這一塊的推廣需要好的表達能力）。
當乙個開發人員從底層開發做起，然後做乙個系統的負責人，到乙個業務域的負責人，到平台的負責人，就是不短晉公升的結果。當業務域的負責人的時候，主要的工作職責就是做規劃，因為他已經對系統的業務非常了解，知道業務的發展。慢慢他已經不在寫**，大多數的工作基本上都是評估風險，review**，規劃系統的技術架構或者業務架構，而具體實現則由開發工程師來進行負責。
我們主要來看看在這種情況下，底層工程師的狀態。
首先工程師是真正的coder，他會把上一級別已經規劃好的東東做乙個真正的實現。他沒有決策權。他只能在上級工程師設計好的框架去實現功能，基本上沒有自主權。工程師想用新的技術（就是超出目前基礎框架的技術，比如指令碼語言等等），這個必須由上一級進行審核或者批准，不能私自使用。如果自己的專案的工程結構不符合標準的結構，也是不可以的，必須按照標準的來。甚至使用了第三方jar包都需要進行評估。
工程師是業務的實現具體的實現者，很了解業務的細節。但是在業務規劃上基本上是沒有發言權的，因為你的級別不夠，架構層面的級別會議你是根本參加不了的，更別說去規劃自己所在的業務。有時候架構反而不如開發對業務了解，但是有一些流程上對業務的改動必須由架構來評估，可惜有時候架構並不了解細節，根本評估不了風險點，導致架構有問開發，相當於開發在評估，由架構出具報告。
在對外推動和配合上，雖然底層開發有時候有一些觀點比較正確，畢竟在一線開發，對於系統和業務上了解還是比較深入的。但是你的級別比較低，你說話沒有分量，涉及到跨團隊配合的時候，對與錯已經不重要，重要的是誰的級別高，誰說話有分量，有分量就夠了，至於對於錯，執行之後在看看結果。
在工作環境上，底層開發感覺是最惡劣的，有無數流程在卡開發，比如**規範報告，review報告，**質量報告，缺陷分析報告，sql規範報告，發布計畫（乙個發布計畫裡面將近有100想 check list）等等，上面列舉的還只是一小部分。很多開發，做事情都必須求著配合方幹事，比如求dba，求sa，求架構，求asa，求pd 等。而且一旦除了線上故障，開發首先需要背責任，由於老闆也會有等級觀念，級別低的我可以說說，級別高的，我不能說，所以往往底層開發又是最受氣的乙個群體，架構們弄錯了，最後估計不了了之，畢竟可以說這個本來就是探索性的，但是開發產生bug了，就是實實在在的問題，能導致線上實際的影響，自然要被說。
在團隊文化上，由於開發的前途由一些已經不再編碼的人來決定，那麼這個是很難做到公正客觀的。你的編碼能力強，**寫的好對於上級來說，他根本都不知道。所以導致一種表現文化。簡單的說，就是做表面功夫以取得上級的認可，而不是切實提高自己的技術能力。很多人開口閉口談架構，談設計，而這些人的**質量可能非常差，編碼能力非常差，因為架構和設計是不需要編碼的，而這些就是上級做的工作，這樣上級就認為你非常牛逼，導致整個團隊整體編碼質量下降。我一同事就是這樣，嘴皮子功夫相當那個厲害，可惜給乙個專案讓他做，就是做不好，而另外乙個同事技術能力不錯，是乙個做實事的人，給他做的專案比較放心，但結果前乙個人能晉公升。
最近看了 左耳朵耗子 寫的工程師文化，很有感觸，可惜公司的業務不一樣，導致開發模式不一樣。比較羨慕啊。抄送一張送給那些底層的碼農和編碼愛好者們。
觀念的改變
在沒有從事這行的時候，完全為了興趣而去寫程式，也不知道為什麼它這樣吸引著我。在自學的那個時候，真是能敲敲 都覺得心裡爽，雖然那個時候什麼有實際作用的東西也沒有做出來過。現在時不時要做些東西了，並不是自發的要做，剛開始這樣的時候不管接到什麼我都會從頭做起。慢慢的時間長了我發現 明明是千篇一慮的功能，我...
我的技術學習觀念
我一直認為基礎知識最重要,無論是對國家,還是對個人的後期發展,都是最重要的.有些人自以為是,以為會玩玩struts,hibernate之類的工具,就覺得自己不得了,其實,那算什麼,乙個用高階工具的使用者而已,如果中國全是這樣的高階使用者,中國軟體永遠不會有出頭之日,永遠只能用別人做好的工具 非常遺憾...
阻礙改善設計的常見觀念
既然軟體設計如此重要，那麼忽視它就是一種戰略短視行為。軟體工程師最重要的工作內容理應是進行真正的 創造性的軟體設計，而不是只忙於簡單地修補漏洞。漏洞是得補，但得補得有藝術 有深度，而不是頭痛冶頭 腳痛冶腳地補。那種沒有深度的修補方式注定是在為將來埋下更大的定時炸彈，也可以預見未來的軟體維護工作將愈加...