***部分

我是一名剛入職半個月的新員工，新員工入職***步肯定是先學習、了解工作相關的內容，盡可能快的上手。就談一下前期熟悉公司項目的經驗和感想吧。

作為新入職的一名程序員呢，我們需要學習公司的文檔管理規則，項目流程管理和產品技術路線等，當然最重要，也是工作量***的部分就是“讀代碼”。

我談“讀代碼”並不是因為他的“重要”或是“難”，而是他的稀缺性。因為我平時經常在網上瀏覽各種技術類的文章，有編程語言的“優劣”討論（其實編程語言隻是一種工具，並無優劣之分，隻有適不適合。這是網上很多人的觀點，我也讚成這種觀點），有具體的某種技術實現方法或思路，甚至還有程序員***的歸宿等。

但仔細回顧一下好像沒看到過“讀代碼”的相關文章，所以我就來分享一下我的“讀代碼”的方法和思路（我們從事的是嵌入式開發，單個項目一般不會很龐大，基本上一個人就能完成），各位讀者如果有不同的方法或思路歡迎討論。

新員工入職一般不會直接上手新的項目，而是先維護公司現有的項目。在了解這個項目的技術框架和實現原理外（這部分主要是看文檔），接下來就是需要鑽到代碼裏去了。我看代碼是先粗略的看一遍，主要是看用到了什麼技術，第二步就是開始鑽到各個模塊裏去研究具體的技術細節和實現原理。如果項目的整體框架設計合理，那麼各個模塊間相對獨立，耦合的部分較少，看起來不會太費力。但是如果代碼風格不好，寫的很隨意那看起來就會很痛苦了。

先說說我在***家公司上手的經曆，我入職的時候我前面的程序員已經離職了，所以我就隻能自己看他留下來的代碼（隻有一個軟件開發人員），那時候沒什麼經驗而且他留下來的代碼風格確實不怎麼樣，所以很難上手，剛好那段時間有一個項目需要做些修改，可我完全不知道怎麼下手，然後我就和老板攤牌說這個項目太龐大了（其實項目並不大，甚至可以說是一個小項目），我改了這裏那裏就不行了，不知道怎麼弄。老板就讓人聯系了我前面的工程師讓他來幫忙。在一個周末，他來了後我們就一起調試，他三下五除二就找到了問題。原來是有些硬件上的線路接反了，淚崩...... 那天他告訴了我一些調試的方法，最最重要的是他教了我一個在後面的工作中經常使用的算法，線性回歸（y=ax+b），就是把傳感器中測量的模擬量線性值轉換成實際使用的長度單位。經過這一次的溝通我一下子“開竅”了很多。在之後的一個更大的項目中把一些遺留的問題和客戶提出的要求都順利的解決了。

第二部分

能修改接手的項目隻是勝任工作的***步，第二步就需要開始研究項目裏各個模塊的細節。那時候工作時間經常要協助其他部門的同事處理一些技術相關的事情，留給自己的時間並不多，我隻能利用碎片時間去研究代碼，也經常會在晚上下班後一個人呆在公司加班。

我的策略就是一個模塊一個模塊的研究、測試。從最基本的 I/O 輸入和輸出開始，桌子上就放著控製板，根據原來已有的程序自己一行一行的過一遍，理解每一條語句的用意和功能，發現有待優化的部分自己試著優化。在不懂的地方，不理解為什麼要這麼做的地方，查看文檔找出他的硬件特性。

花了兩三個月的時間把所有的模塊全部弄通，弄懂。在這個過程中也學到了不少東西。比如說關於串口的一個存儲隊列，裏面有一個軟件模塊專門負責把從串口接收到的數據存儲到一個緩存中，防止一下子接收的數據太多，導緻數據溢出。應用層在讀的時候按照先入先出的規則讀取串口的數據，有了這個軟件，讀寫串口的數據效率提高很多。

之後我再對公司的項目就輕車熟路了，不管是維護舊的項目，還是開發新的項目都能做到胸有成竹，不會再像剛開的時候那樣總是心裏沒底，怕自己搞不定。後來我還根據自己的一些經驗和見解優化了一部分項目裏的代碼。

***總結一下我的讀代碼策略，就是先根據文檔和代碼對項目的整體框架有個理解，如果前期馬上就需要上手維護項目，就再把相關的項目的細節了琢磨透，先讓自己做到能維護項目。第二步就是一個長期性的讓自己慢慢的熟悉其中的細節和實現原理。因為隻有做到這兩步才能有那種“兵來將擋，水來土掩”的自信和從容。當然我的這些經驗隻適合較小的項目，就是一個人負責一個項目的那種情況，如果是大型項目，一個小組或很多人一起合作完成的項目就不適用了。