## 需求確認 > * 凡產品那邊給過來的需求文檔、高真等不全，研發負責人認為有不合理的，可直接拒絕開發，如果產品有什么異議，拉上我一起解決； > * 如果研發負責人認為可接受的情況下，同項目的開發工程師有什么問題，直接向研發負責人或我反饋； > * 沒有經過上述兩步，出現任何的抱怨、不滿，請自己反省。超過三次，要考慮自己是不是不適合這個環境。 > * 對于產品提出的需求，你認為不合理的，要有合理的理由和建議方案，否則請按需求去開發。 ## 開發原則 ### 提交（簽入）代碼需要填寫備注說明 > 團隊開發中必定會使用一些類似 svn 的代碼管理工具，在提交代碼時填寫備注，這個好處是不言而喻的。它可以幫你記錄這次修改完成了哪些功能、修復了哪些 bug，包括的團隊的其他成員，也可以看到你這次提交代碼所做的貢獻。 ### 每天匯報自己的工作情況 > 我們可以每天早上把今天的工作做個簡單的計劃，然后在下班前把今天的工作內容做一下小的總結，并抄送給領導，很多時候因為不知道要寫啥，或者可能一句話就能說清楚，我們就不愿意去做這個簡要的匯報，有的公司會要求大家每周做匯報，但自己還是覺得每天有個開始和總結，不僅能夠讓自己對任務更加清晰，同時也可以加強自己和領導間的溝通，何樂而不為呢？ ### 對一些公共庫的修改一定要謹慎，并且測試再測試 > 有時候我們并沒有修改自己寫的代碼塊，但發現一段時間后，自己的代碼編譯不了了，于是你很驚訝的發現，代碼中調用的公共庫接口被修改了。這樣的問題相信大家經常遇到，所以當你需要修改公共類庫時，一定要非常謹慎，最好在修改完后進行全面的單元測試，或者通知你團隊中的每一個成員。 ### 需求要確認，切勿盲目編碼 > 很多的問題其實改起來并不麻煩，但是如果要是因為理解的不一致造成的改來改去，這個是最折磨人的，所以，必須雙方都完全確認后，再動手！切忌不要擅作主張。 ### 經常主動地去和別人進行 Code Review > 有很多我們固有的不良編碼習慣，或者一些我們不熟悉的內容，這些都是我們很難觀察到，但我們的同伴可能一眼就能看到的地方，有交互才會有學習，多去理解和學習同伴的好的編碼習慣和思考方式，對我們來說這是最容易的一個途徑。 ### 要相信自己的工作在團隊中是舉足輕重的 > 有了這樣的信念，你就會對你的任務更加重視，更全力地去完成它，而不會像其他人一樣老是項目延時，這對你在項目中建立信心至關重要。 ### 不要盲目拷貝代碼 > 這一點我想很少有程序員能夠做到，無論是從網上的搜索結果還是團隊中其他成員編寫的代碼，即便它們能完成你想要的功能，也不要直接全部復制過來。因為這不僅讓你失去了思考問題的能力，而且也有可能引入一些不必要的問題。雖然重復造輪子的做法不可取，但是在你拷貝代碼的時候是否也需要思考一下代碼的實現思路，這對你的提高非常有用。 ### 及時記錄工作日志 > 這點也很少會有程序員能夠做到，“一個沒有博客的程序員不是好程序員！”，用博客記錄自己開發過程中的經驗教訓，時間久了，這也是一筆巨大的財富。另外，你分享的這些經驗教訓，也許還可以幫到別的開發者，或者你團隊中的小伙伴。 ### 控制情緒，遇到問題提出來 > 職能之間應該是平等、和諧的關系。誰也不是大爺，誰也不是孫子。大家都應該有一個共同的目標——把事情做成做好。