這半年的一些事情

進了公司半年，老大離職後，我被指定接手開發團隊，壓力有點大。剛開始這個項目算是失敗了，客戶都不是很滿意。我總結了一下問題，雜七雜八的，總結起來就是

 

• 因爲軟件須要根據不一樣的客戶來進行擴展子功能，沒有設計好框架致使擴展性不夠。

 

以前的開發團隊是直接把全部的功能都塞進了一個軟件裏面。給不一樣的客戶的軟件只是把客戶端上的界面也隱藏掉(經過宏定義或者配置文件)。

這個也不是隻有在這個公司才碰見，在上家公司就有了。我感受這個應該是大部分企業的通病， 軟件的核心功能是針對於該行業的全部用戶的，可是卻須要針對不一樣的用戶進行定製開發修改

 

 

• 開發人員水平不夠。各類傳參使用值傳遞，強轉都是亂強轉，崩潰都不知道崩潰在哪裏。數組各類越界，指針各類野指針，在遍歷list的時候，各類這種 std::list<int> copyed_list = src_list 這一種代碼，qt的水平也是半桶水。一份代碼寫個四遍也很正常

 

 

我瀏覽了一下代碼，軟件是有進行簡單的分層和功能抽象的，後面愈來愈失控，有幾點緣由

• 開發人員的流動和功能的迭代，產品沒有規劃好
• 趕時間和進度
• 開發人員的隨意，畢竟項目作了兩年多也沒成果，不少人已經不耐煩了，離職的離職，怠工的怠工，還有人都是在作本身的事情
• 開發人員的水平所限，這個是中小公司的問題，畢竟預算就那些，也沒什麼名氣，能招到人就不錯了。

 

到我接手軟件組的時候，整個系統基本上沒有什麼框架可言了，團隊也已經比較散了。因此在開發的時候，不能僅僅從技術上考慮，還須要考慮到開發人員的心理情況以及開發水平。

 

開始的時候老闆跟我說即便把整個軟件推翻重寫也沒問題，該把人換掉就換掉。我想了下，仍是想在原有的軟件上開發下去。當時考慮的主要仍是公司預算的問題。

• 在我接手前，項目已經作了四年多了，換了好幾任的技術主管，基礎已經都有了
• 已經錯失了最佳的發展時機了，市場已經愈來愈小了。不能再慢了
• 小公司，沒有那麼多預算，從成立軟件部開始一直在虧錢，我仍是挺但願部門能在我手上開始給公司盈利的。這個是很重要的一個緣由
• 我對本身比較有信心,由於這些問題我在第一家公司都有遇到過，都在着手想解決方案，想要試一下是否可行

 

軟件開發方面:

• 創建編程規範，好比將全部的強轉改爲dynamic_cast,將void* 改爲variant，保證類型安全。數組改爲vector等等，具體在另一篇文章裏面

• 整理通用代碼，優化工程結構
• 着手設計插件框架
• 自動化檢查代碼
• 查找全部崩潰的問題。這一點真的很吐血，C++崩潰真的很難找，用了不少工具以及修改了不少代碼來查找，犧牲了好幾個假期來弄這些
• 捨棄界面的細節，優先保證穩定和功能。這點爭議很大，爲此跟產品鬧了幾回矛盾。考慮到開發人員的心理，畢竟CPP程序員很不喜歡對這界面調一個像素兩個像素，不少界面細節調整我都拒絕了
• 開始獨立部分服務，好比圖像處理服務，視頻處理服務，後期往微服務方面調整。獨立的原則主要有兩個
• 是否吃性能
• 服務的功能是否能夠作成通用，單獨成一個產品，後期是否須要添加太多的功能
• 強制編寫註釋以及簡單的文檔
• 使用持續集成以及自動發佈
• 代碼審覈以及自動化測試(後面放棄掉了)

 

人員管理方面:

• 清退了作私活的人
• 一些老員工很難處理，畢竟呆了三四年，我來了半年的人也很差管，有時候我說他們，他們都不理我。可是事情仍是作的，因此這些人基本就是我下發任務後就無論了。有問題來問我，沒問題我偶爾催催進度，也算是得過且過了。總算沒拖後腿
• 支持個人員工，就比較好辦了，該怎麼作就怎麼作了，核心的功能也會給他們作

 

其餘方面:

• 關於進度，剛開始壓力真的很大，產品每天催進度，我本身又不喜歡加班，後來仍是在沒有強制施行全員996的狀況下完成了任務，仍是挺開心的。固然這點跟上面那些支持個人員工關係很大，他們作不完要嘛本身加班，要嘛遠程解決
• 人員流失。有一個員工離職跟我講我不重視和信任她。緣由是我從不分配給她重要的事情，只是讓她改BUG。我想一想也對，由於她常常抱怨太麻煩，太累，因此我也不想把重要的事情給她，更多的是分配給比較積極的人。想一想本身，有時候雖然會抱怨累，可是解決了仍是頗有成就感
• 跟產品的衝突，有時候確實不理解產品的想法，很容易陷入細節裏面，致使一直改來改去，後來不少東西都被我拒絕掉了，研發團隊仍是不能當作產品的下屬，而是要有本身的意見，不然很容易讓研發團隊離心，畢竟如今研發仍是比較好找工做的

 

 

經歷過半年總算把公司產品弄上了正軌，感受仍是挺開心的

不過這半年真的發生了不少事情，會發現一個產品真的不止是技術問題，還有銷售問題，還有產品問題，還有管理問題，之前想問題太單純了。

 

 

人員方面，公司不是什麼大公司，也並無那麼多預算，不可能什麼事情都招水平高的人。我剛來的時候大部分人連引用都用很差。加上IT行業目前屬於人員缺乏的狀態，不少人只是混混日子攢攢經驗而後跳槽，所謂的招優秀的人在咱們公司基本不可能，最終變成了招踏實肯幹的人，水平卻是其次了

 

產品奉行簡單粗暴，而不是精益求精。不止產品，包括代碼。這個也是我後面放棄代碼審覈的緣由，加入代碼審覈後，以目前團隊的水平，一個問題來來回回可能要好幾周才能解決，加上會把你們搞得很煩，畢竟目前士氣低落，須要有業務和產品來提高目前的團隊士氣。最終代碼審覈只是寫了一個簡單的靜態語法檢查腳原本檢查

 

還有不少想吐槽的，可是想一想畢竟這個是目前符合咱們公司情況的，不少東西只能捨棄掉，大概相似於分佈式裏面的CAP理論吧。聽了太多網上大神的思想，本來也想創建一個能力高強，默契的團隊，有自動化測試，代碼審覈,

完整的文檔,引入wiki，markdown，git等新技術，可是最終只能選擇目前這種狀況，才能保證團隊活下去，也是一種妥協吧