關於軟體研發的一些體會總結

       都說碼農是個苦逼的群體，果真如此？的確，程式設計師在我的印象中沒有多少人能夠是正常下班的，大多是需要加班加點的，有些行業的程式設計師高峰期需要通宵達旦來保障產品的上線，不少程式設計師在休息日還需要過來加班工作，不得已把家庭丟下奮戰在程式碼的戰壕裡，真的我們需要理解支援程式設計師，程式設計師家屬通常需要做出很多犧牲，特別是照顧小孩、老人、整個家庭。但是，這樣的路要一直下去嗎？程式設計師可不可以稍微輕鬆一點呢？方法總是有的，無非是提高效率，提高研發質量了，公司的研發任務是不會少的，產品要求也不會低的。為了公司的持久發展，程式設計師的使命也是要做出能讓公司盈利的產品，否則就是從一個戰壕挪到另外一個戰壕，迴圈而已。那怎麼做呢？現在市面上出現了非常多的軟體開發敏捷開發的書籍，筆者也看過幾本，結合筆者十餘年的一線碼農工作經驗，憑著腦子裡的印象我們來一起梳理一下我們研發路上的成功經驗以及失敗的經驗。

/*****************************************************************************************************/
宣告：本博內容均由http://blog.csdn.net/edsam49原創，轉載請註明出處，謝謝！/*****************************************************************************************************/

       研發過程中，作為程式設計師首先我們是一個個體，一個能完成一定開發任務的工兵；其次我們是團隊中的一員，是為了完成團隊目標的有機組成部分；再則我們是公司的一員，為達成公司發展願景而努力奮鬥的一顆螺絲釘；說得更大一點，我們是社會中的一員，為了實現個人價值，為了實現社會價值，做一個有益於社會的人，我們程式設計師也是有理想有目標的人。那我們來從這四個方面來逐步展開一些探討。

作為個體，我們需要擁有一定的知識積累，在開發過程中，我們難免遇到自己的知識不夠用的情況，那怎麼辦？還得靠我們自己啊！快速學習，快速形成能力並解決問題。對於一般的程式設計師來說，團隊下方的工作任務是比較具體的，相對會比較專注。有經驗的程式設計師都知道，其實對於寫程式碼來說這個時候相對還是更幸福一點的，一些專案上的雜事、一些協調的事、公司各部門的鬧心事一般還不需要去處理。安排的任務，首先我們需要充分去理解這個任務，然後再分解任務。理解這個任務，是需要了解這個任務的目的、它的設計初衷是什麼、為什麼要這樣設計，我們發現很多時候程式設計師已經變成了執行的機器。老闆怎麼要求的、產品經理怎麼要求的，一概接受，從不思考是否合理，而這樣做我們往往不會把事情做錯，但是很難把事情做好。沒有錯，是因為我們完成了別人的目標，做好是達成了這個事情更合理的做法，是充分表達了自己思考的方法在團隊中達成的共識，這樣才能做好。在我觀念中，對於這個任務，你是第一個實踐者，要有自己的感覺，要有自己的見地，有疑問需要及時的提出。比如一些應用開發的任務，只是為了按目標完成它，往往還好。完成後，返不返工呢？返工的教訓應該是很多的，限於原定設計者的認識水平以及同行的做法、或者一些方面的欠缺，如果我們程式設計師在做的時候能夠提出一些自己的看法，也許我們返工的機率會大大降低。因為返工，多數情況下累的是程式設計師啊！因此為了自己少累一點，我們要多主動多反饋多溝通。另外，我們在工作中可以慢慢積累一些功能的模板開發，比如JNI怎麼寫、service怎麼寫、廣播怎麼接收，形成模板後，自己又很熟悉，會提高我們的開發效率。

       我們作為團隊中的一員，肯定是為了完成團隊的總目標的。那怎麼順利的完整這個目標呢？我們肯定需要藉助一些管理工具，關於使用什麼工具、怎麼個流程，需要大家一起討論來決定。比如我們開發專案中用的android平臺，我們首選的版本管理工具當然是git，有些人又會說用SVN用習慣了，git不會用。那麼這時候團隊管理者就需要站在現實跟發展的角度來召集討論並決策，android平臺程式碼量特別大，單個git那樣的小工程，程式碼隨便都是幾百M的，如果用SVN來管理，檢視一次改動的程式碼svn就要執行很久，哪有git diff來得快。我們需要的朝正確的方向並持續的努力。如果程式碼量比較小的，團隊也可以採用svn這種輕量級的版本控制工具，根據專案需要來。其次，我們在設計方案選定的時候，需要充分討論，團隊成員一起來商量、分析、探討，然後在內部達成共識。在方案選定的情況下，在編碼實踐時，也可以根據一些變化來做修正，在專案管理的會議上提出，然後大家通過後再實施，不要私下貿然修改。關於敏捷開發中提到的立會，也就是每天早上站著開一下會，這個有好處，但是每天都開也太頻繁，很多工程師也煩。藉助於內部通訊工具，比如QQ，騰訊通之類的工具在專案組的群裡每天及時的溝通一下其實也挺好的。有些一個小團隊在一個辦公室，稍微喊一嗓子就達成目標了，專案會議也是需要定期召開一下。我們提交的程式碼要完整，不要造成伺服器上的程式碼編譯不過這種問題，這會影響整個團隊的開發。總之，保持頻繁的溝通反饋這個原則就好。再則在測試階段，測試的bug在大公司有很多用收費的高檔OA管理系統，在一般的公司裡還是可以借鑑一下開源的mantis，也挺好用的。有個管理工具，大家跟蹤起bug來就有章法得多。

       在整個公司中，也許你參與的專案只是公司的一個小專案小嚐試，只要是公司決定去做的專案一般都是通過了討論，在多個部門都會參與的情況下進行的。比如涉及硬體的裝置程式開發，首先就需要硬體板，測試需要測試部，當然還有ID設計的結構設計，以及一些品質控制、生產控制。有時候程式設計師做的一個功能，是完成了功能，但是可能在生產階段不方便不好用而要返工的，這個時候就需要我們在前期設計的時候能夠傾聽一下我們潛在使用者的意見跟建議，這一點很有必要。不然到了生產線得到不好的反饋，我們程式設計師又需要通宵加班解決問題了，這又是對我們自己受傷啊。保持各個環節的溝通，讓事情變得簡單一些。

       作為社會的一員，我們只是分工不一樣，選擇了程式設計師也許當初是因為他好找工作、待遇高、出入高檔寫字樓等等原因。本人當時也是因為這些原因走上這條路的，那時候哪知道將來乾點啥，一個是接觸的東西少、見識也少。慢慢地幹上了這個工作，後面筆者又進入了車載電子行業的開發，逐漸的我覺得自己的責任越來越大了，主要是覺得自己的智慧體現在產品上，流通在社會上幫助了我們很多的客戶。比如做的行車記錄儀的功能，解決了大量的碰瓷，為客戶的權益提供了有力的保障。慢慢的又開始做了ADAS，高階駕駛輔助系統。這個東西對駕駛員來說價值更大，真的可以避免很多事故的發生，比如你一走神一下車開偏離車道，ADAS直接來給你一個語音提醒，你可能來得及調整回來。那麼要做好這些功能是很不簡單的，首先需要好的演算法，好的攝像頭，需要我們認真負責的配合，另外我們軟硬體需要保障系統的穩定。從這個事情上我越來越覺得從心底有一種社會責任感似的，我們不僅僅是為了生活為了工作，我們是為了造福這個社會，為這個社會貢獻一點自己的力量。只有心裡有這個意思，我們的主觀能動性才能更好的發揮，否則被動的加班效率也高不了，成績也上不去。總的來說就是我們在思想上要提高認識，認識到我們從事的工作的社會意義，從主觀意識上鞭策我們向前進，這樣我們編寫出來的程式碼的質量應該是會越來越高的!