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

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

我談“讀代碼”並不是因為他的“重要”或是“難”，而是他的稀缺性。因為我平時經常在網上瀏覽各種技術類的文章，有編程語言的“優劣”討論（其實編程語言隻是一種工具，並無優劣之分，隻有適不適合。這是網上很多人的觀點，我也讚成這種觀點），有具體的某種技術實現方法或思路，甚至還有程序員***的歸宿等。但仔細回顧一下好像沒看到過“讀代碼”的相關文章，所以我就來分享一下我的“讀代碼”的方法和思路（我們從事的是嵌入式開發，單個項目一般不會很龐大，基本上一個人就能完成），各位讀者如果有不同的方法或思路歡迎討論。

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

先說說我在***家公司上手的經曆，我入職的時候我前面的程序員已經離職了，所以我就隻能自己看他留下來的代碼（隻有一個軟件開發人員），那時候沒什麼經驗而且他留下來的代碼風格確實不怎麼樣，所以很難上手，剛好那段時間有一個項目需要做些修改，可我完全不知道怎麼下手，然後我就和老板攤牌說這個項目太龐大了（其實項目並不大，甚至可以說是一個小項目），我改了這裏那裏就不行了，不知道怎麼弄。

老板就讓人聯系了我前面的工程師讓他來幫忙。在一個周末，他來了後我們就一起調試，他三下五除二就找到了問題。原來是有些硬件上的線路接反了，淚崩...... 那天他告訴了我一些調試的方法，最最重要的是他教了我一個在後面的工作中經常使用的算法，線性回歸（y=ax+b），就是把傳感器中測量的模擬量線性值轉換成實際使用的長度單位。經過這一次的溝通我一下子“開竅”了很多。在之後的一個更大的項目中把一些遺留的問題和客戶提出的要求都順利的解決了。