很難描述公司裡的幾個研發帶頭人，因為有些人可以擔任研發帶頭人的位置，這並不一定意味著他們的程式設計和研發指揮能力還可以有一天，我們的老闆受不了了，有時候乙個簡單的專案，原則上可能只需要一兩天就能完成。 但是，由於我們專案的邏輯是不可重用的，因此本可以在一兩天內完成的專案往往需要一周以上或更長時間。
老闆告訴我們，“從今天開始，所有專案都應該封裝通用邏輯，以便下次可以重用相同的邏輯！”
但是我們公司的幾位研發負責人似乎不聽！
我們公司之前接手過乙個工廠電腦的專案，這個工廠有很多車間，軟體介面邏輯有一些差異，但也有共性。 例如，主介面的操作邏輯、與資料匯流排通訊的邏輯、與硬體通訊的邏輯等。
但是當我設計介面時，我與當時負責該項目的研發負責人產生了分歧
我覺得每個車間的軟體介面除了影象顯示部分不同，其他地方的邏輯都是一樣的，我覺得軟體介面應該這樣設計：
設計乙個主程式，然後以外掛程式的形式動態載入顯示影象部分的邏輯，這樣主介面的邏輯就可以復用了！因為我們需要區分每個車間需要用到哪些外掛程式，所以我們可以把外掛程式放在乙個外掛程式資料夾裡，根據需要放上對應的外掛程式。
然而，這個設計思路被我們公司的一位研發領導拒絕了，他覺得做動態載入太複雜了，認為最好把所有的介面都寫在乙個專案中，然後在專案中直接寫if-else，通過判斷車間型別來決定要顯示哪些介面，而且工坊型別是配置和通讀配置檔案的，甚至沒有動態載入的方式，他認為邏輯是通用的，不需要花太多精力去重寫每個工坊的介面，複製貼上！
聽到他這樣設計程式，我一時說不出話來。 然而，他的話終於讓我知道了誰是讓老闆頭疼的罪魁禍首！
來到現在的公司後，我發現我們公司的很多專案都是通過if-else來判斷和展示的，而所謂的復用，更誇張的就是把之前寫好的專案整體複製，然後在原來的基礎上進行新增或修改。
這種奇怪的復用方式，導致很多**在很多專案中都是一樣的，但是其他一些專案的介面在新專案中沒有被刪除，因為害怕刪除問題。
因此，每個專案都有很多冗餘，其中會有很多浪費。 主要問題是，如果這些專案中的某些“重用”邏輯有問題，那麼所有專案都必須更改！
回想起維護舊專案的所有不適，我覺得研發領導的建議不好，並說了一堆不建議這樣使用的理由，比如冗餘太多，維護不方便等等。
看到我這麼說，這位研發負責人還想利用自己的職權向我施壓：“我覺得沒關係，你去做就行！”
於是，我對他說：“我不敢說我的想法是最好的，但可重用性還是很不錯的，如果你非要讓我跟著你的想法走，對不起，我受不了這種寫法！”
最後，我們倆不愉快地分道揚鑣，但好在咱們公司的專案經理在演講中更受重視，權衡了一下，我決定用我的想法，但我還是得罪了這位研發負責人。
最後，在公司裡，我有一種“難以溝通”的印象，有意無意地向別人表達了這個“問題”，這讓我很無奈！
因為我們公司的研發領導都是C++程式設計師，而我是C程式設計師，所以有時候需要C++來做演算法，需要C來呼叫。
在我來公司之前，以前的做法是用C++單獨編寫乙個程式來做演算法，因為如果C++單獨寫乙個程式來做演算法，就需要整合乙個通訊模組來C++和C進行通訊。
儘管如此，即使是通訊方式也非常混亂，有的使用 socket 通訊，有的使用 websocket 通訊，有的使用 redis 進行資料快取，以至於無法直接通訊。
我看到每個專案的溝通方式都不同，所以我問一位研發負責人，“你能C++把演算法部分封裝成乙個動態鏈結庫嗎？我們可以直接呼叫庫來執行演算法！畢竟，溝通是有時間損失的！”
研發領導聽了，可是研究了很久，卻發現自己編譯不出動態鏈結庫，或者編譯成功後，呼叫C語言，最後他不耐煩了，說最好用通訊方式！
然後我驚呆了！
有一天，我忍不住了，於是我問了公司裡的一位老專案經理，如何成為這個級別的研發帶頭人
最後，專案經理苦笑著說：“這都是公司剛成立時老闆跟著的，最初的研發沒了，只剩下他們，誰不需要呢？”
粗略地說，雖然他們可能技術不精通，但對公司的業務非常熟悉，並沒有那麼難以忍受。
最後，我只能無奈地笑了笑，這更像很多公司的情況。
專案經理還說了一句完全逗我開心的話，他說：“公司之前也招過一些大牛，但是看了公司以前的專案後，我搖了搖頭就走了！”
最後，我認為，既然這些人懂業務，那就讓他們管理業務，他們也可以管理專案開發，但不要自己參與研發，更不要自己寫**！
基本上，任何乙個有幾年工作經驗，作風好的程式設計師，在閱讀我們公司之前的所有專案時，都會感到頭疼。
我不否認公司一些老員工對公司的貢獻，但可能正是這些人會成為，這些人會被打敗！