本來是想把這些話寫郵件給公司的老總、技術總監的，但是現在看來，似乎已經沒有了必要，因為他們認為這個不重要！而且總是說，現在先把項目搞好，這些以后再說，你怎么總是花時間搞這個？我看你項目已經延期很多了！做事要分清輕重緩急、先后順序！你不要總是說，你先完成了再說。你可以給xx提建議啊。。
我也不知道說什么好了，或許我現在所在的公司根本就不是技術型公司。只是我認為，因為現在的管理方式、項目代碼的架構，經常出現的各種問題，無窮無盡的奇妙的bug，各級人員之間的沖突，各種的壓力，已經讓開發人員任務很重了， 需要減負，更沒有精力研究新東西， 不能一出錯就怪罪開發。。我和他們意見很大分歧，我認為所謂磨刀不誤砍柴工，先進的工具、技術可以大幅提高工作效率，難道不是嗎。需要吐槽的太多太多了，提出這些建議也是想公司變得更好，我也想自己一個人完成改造，奈何沒有人支持我，領導也不重視，所以就不管了。不過竟然已經寫好了， 我就還是發表出來吧！寫得有些亂，很多很多的細節，囿於時間限制，自己水平也十分有限，不能說得太細，不能進行細致的分析。下面是我的建議：
項目管理：
構建：使用mvn 構建吧，至少要搞個ant吧。現在所有工作全手工進行，這樣真的好嗎？ 我們現在發布新的版本，麻煩又容易出錯，而且很慢。發布個補丁，就更加效率低了！現在我將公司的主項目的龐大的 pom已經配置好，mave私服我已經搭建好了，就等切換了。
升級：升級jdk吧，現在都jdk8了，公司卻一直使用1.6，各個jar也是非常老的版本了。。這樣很多的先進的功能是都無法使用的。。
版本管理：
使用git 做分支管理吧！ 現在公司的產品分支多，而svn真的效率低，因為他只有一個遠程的版本中心，每次操作都要拷貝來拷貝去（這個大家都知道）。而git的分支管理也比svn強大太多了！ —— 用過用GIT+TortoiseGIT都會發現SVN太低效了 。。。 聽說svn也提供了 補丁功能，但經過研究，其使用也不是很方便。內部git 服務器我已經搭建好了， 只等大家一切來使用了！
缺陷管理：
使用bugfree/mantis進行 bug管理吧， 而不是TD，——TD都十幾年前的古老的產品了， 界面又丑又不好用， 而且功能非常有限。
軟件測試：
使用junit 單元測試-- lr壓力測試吧！而不是還是原始社會一樣使用手動的點擊進行測試。做測試經理的也要專業點吧，而且一定要測試好， 不要等問題到了實施客戶階段才去解決—— 這樣成本很高，很麻煩。。
推行自動化測試腳本， 自動化部署， 自動化構建吧， 不然真的人手不夠，就算再招很多人都還是會很累的！制定好的測試方案，不能每次開發做了些許小小的改動， 你就又全部重新測試，——這樣確實會很累而且抵消。
做測試的，絕不是說任何人都可以完成的點點鼠標就可以了的，也要會寫代碼，需要懂一些專業知識，需要提高測試覆蓋率。。
提bug的—— 不能亂寫一通， 必須的東西要說清楚吧必須的步驟，必須的截圖，日志，而且盡量的縮小范圍。 減少與開發的溝通成本。。另一方面，開發修改完一個bug，提交了重要的更新，應該通知所有相關人，適當討論，是否應該， 否則引起各種bug。
溝通准則：
電話溝通：與客戶溝通的時候，應該說， 您好， 我是xx公司的xx項目經理/負責人，（上次我們在xx見過面的），想和你討論下xx問題，請您協助下，可以嗎？ 而不是說： 我的xx公司的，我是xxx，—— 自我介紹的時候，最后面是一個“的” ， 讓人覺得不專業！就說，我是xx公司的xx(職位/負責人)，這樣別人聽着舒服些。
內部人員溝通：
qq討論組的建立准則 ： 對於像我們現在終於的項目型公司(一個產品，N個項目)，應該每個項目建立一個qq討論組，但是又不能太多，一旦建立好之后，不能隨意的改動，並且要維持固定的結構。
私下交流與群組交流： 個人認為應該少私下交流，應該全部在討論組里面討論，否則容易出現各種小團體，小黨小派。—— 私下交流和群組交流的效果是不同的， 同一個公司，就那么大的地方，才150-200平米的辦公室，總是通過qq來討論，真的好嗎？
交流方式有很多種： qq、一對一座位交流、遠距離喊話、會議室怎么進行問題討論和分析。 但是每次溝通都應該選擇適當的方式。
開發規范：
制定開發/編碼規范吧！javadoc ， 設計文檔， 需求文檔， 開發文檔。。。 都要必須出來！ 不然，這代碼還怎么開發下去啊！現在的很多東西混亂，只能靠看代碼， 而代碼少注釋，深度耦合，低內聚，各種代碼泥潭， 各種陷阱，各種坑爹，
項目更新：
制定代碼更新， 補丁准則吧。不然，這代碼還怎么更新，打個補丁就3、4小時了， 這工作還怎么進行下去。。。 。特別是多人開發，並行開發的時候。
公司氛圍：
搞好公司內部氣氛- 技術氛圍吧，技術群是用來討論技術的，而不是死群。每來一個新人，至少有對新人的歡迎吧，老員工帶頭吧，所謂的資深高級員工都到了哪里去了呢？怎么都不吭聲呢？每次有人在公司總群里發起了話題，應該有人接上才對啊！怎么能沒有吹水呢？ 老總說話都沒有拍馬屁，這真的好嗎？死氣沉沉的公司氛圍真的好嗎？難道每個員工都在想着走嗎？為什么這樣呢？
招攬人才：
招攬更多高級人才吧 .. 否則，現有人才是很難推動公司發展的，特別是技術部，不能一遇到比較難的問題就回避，選擇其他相當簡單的卻不是最好最合理的解決方案。所謂Engineer重點在於其engineering的能力。高科技公司不重視人才不就是尋死嗎？
開發/二次開發/實施准則：
沒有規范，沒有規矩，沒有有效的文檔，溝通始終是一個高成本的事情。常常看到的是，新人舊人的溝通非常麻煩而且低效，達不到預期效果。而且離職員工的交接也會變得沒有意義。
測試機器的分配：
應該是易找而且已經部署好。應該是每個人一個或兩個虛擬機吧，而且應該按照順序來，而不是胡亂分配，自己的使用自己的虛擬機， 而不能動其他人的，測試機器的分配應該也要有個章法吧！ 能把所有的機器的分配情況列表出來，並標示其功能，安裝情況嗎？ —— 這樣別人就不用每次找個機器問來問去了！ 而且下次又忘記！
加班管理：
每周1/3/5作為加班的時間，而不是每天下午6點就喊，有沒有要加班的？！這個太落后了。。
獎罰管理：
技術人員引入了一門新技術，大的改進，革新，顛覆，應該給予相應的獎勵，否則，應該指責。。
引入前端工程師：
。。前端是我的弱項，但是目前的前端也是混亂，樣式調整全靠一個美工/UI來完成，而他竟然不懂js 代碼。。。 於是搞后端的同時也要搞前端，同時還有搞數據庫。相互之間沒有交流，不能共同學習進步，每個人都要求是全棧工程師，真是苦不堪言。什么都搞的結果是什么都不精。
座位、電腦配置：
座位不要隔開太多了吧！應該一個項目相關人等圍成一圈做，不要有隔板。每個人的電腦不要太低了吧，至少要8g內存， cpu i5以上， 雙顯示器。
技術氛圍：
多多交流經驗技術吧， 不然老員工開發的代碼，只有老員工懂了， 新員工來了也沒有一個很好的，系統的，專業的培訓，你讓新員工如何快速融入公司，如何進行開發？老員工之前的工作沒完全做好，接着又調去開發新功能，然后留下一堆沒有優化的各種缺陷的代碼給新來的人做維護， 這樣真的好嗎？
寫代碼寫得多/快，功能點多，不是你厲害， 而是可拓展性，良好結構， 容易讀懂才重要， —— 若是靠復制黏貼，危害十足， 往往是造成痛苦的根源。
公司組織架構：
分工要明確，責任要明確，任務也要明確。界限要盡量清晰。所謂項目經理，一定是做項目經理的工作，而不是什么事情都來插一腳。但是他又什么都做不到最好，做簡單的事情花很長時間，反復各種bug，然后還說這個是開發的責任。。。
代碼缺陷檢查：
測試是對開發完后的代碼的檢測，但是，還有一個必須的步驟是，對剛剛開發完進行缺陷檢查， 比如代碼的格式檢查，警告的排查—— 我在華為也學習到一些基礎，java代碼中，有些警告是可以忽略的比如泛型，但是最好，還是認真的處理下每個警告的比較好。代碼規范的重要性： 我想查詢 aa = xx,但是有人的寫法是aa=xx, 於是就查詢不出來了。。
人員管理：
良好管理應該是 良好規則的制定/實施/推行， 最佳實踐的試用和實踐， 而不是以威視逼人。。
對於員工，應該對於每個人都給其指定一套升職路線，給予升級空間。而不是對下級員工不聞不問，明細的區別對待—— 開個周例會，分了好幾批。。。
采用最先進的管理技術，開發技術， 比如極限編程、結對編程、敏捷開發。。。
關於管理，有太多的東西可以討論， 個人本身也不太懂，不多深入探討了