1，和需求的溝通，
第一點：
千萬千萬不要隨便聽需求的隨意加需求，加需求是乙個嚴肅的事情！！！！！！，太可怕了，一改全改，一動全動，後面控制不了了，！！！！！！
最後加班加點苦了開發測試，天天加班，還不出活，這太可怕了，不要以為乙個小小的功能，
第二點：
需求出來了之後，一定要盡快的分解需求，梳理需求，看有沒有很難實現的，在時間內完成不了的，有設計和原功能邏輯矛盾的，！！！
還有就是遺漏的，需求不清的！！！！這都要及時提出來，否則你都開發了很多了，然後才發現不行，需求再改，那就返工，時間不是一點半點了！！！！
2，和測試的溝通，
3，和其他後端開發的溝通，
比如對接介面
4，和前端的溝通，
關於溝通成本的問題
昨天有同事在討論 了乙個指令碼異常，我一看便知道和我協作的另外一同事的函式寫少了乙個引數，可能我花幾秒鐘就可以幫忙改完提交了，但為了尊重 ta 的工作，便在討論群上回覆怎樣修改。但久久不見同事在群裡回覆，便主動走過去告訴 ta ta 聽了連忙翻群裡的聊天記錄，說沒留意到，於是告訴 ta 怎麼一回事。...
軟體開發中的老問題 溝通
軟體開發中的老問題 溝通 在軟體開發中有這樣的乙個法則 brook 法則 向進度落後的專案中增加人手，只會使進度更加落後。我們經常可以聽到 1 1 2 的說法，但從這個法則中可以知道，在軟體開發中 加 1是小於 的，甚至是小於 1的，這是為什麼呢？其中主要的原因就是溝通，專案開發人員之間的相互溝通產...
關於開發中的命名問題
1.包的命名 一般包全部採用小寫字母，包的名字一般為公司網域名稱的倒置，比如com.dqpi.util 2.類的命名 1 首先要使用駝峰標識，當乙個類的名字由多個單詞組成時，每個單詞的首字母都需要大寫，其餘的字母小寫，這個就是駝峰標識 2 最好要做到見明知義，當別人看到你的類的名字的時候，他就知道這...