新手程式設計師應該學會這3個原則
一、背景
和一些新同事相處一段時間後，發現他們經常犯一些低階的錯誤。
今天，我將工作五年總結出來的一些原則分享給你們，這篇文章先說最容易理解的三點。
通過遵循這些原則，你們可以做事效率更高，犯錯的概率也更低。
二、資訊敲錯了
在幫忙新人處理線上問題的時候，經常發生最終是配置檔案的資訊填錯了，或者程式裡的字串敲錯了等等。
後來進行問題覆盤的時候，發現很大比例都是因為對應的資訊是自己手敲的，結果敲錯了。
對於這個問題，我早在八年前在大學首次參加ACM比賽的時候，就學會解決方法。
參加過ACM比賽的朋友應該都遇到過，對於一些題，會要求按照指定格式輸出一些字串。
新手經常發生這樣的事情：你明明演算法都正確，但是最終就是過不了，一直WA。
最後找大牛來看，發現輸出的字串不符合要求。
比如有次，題目要求輸出字串main
,很多人敲為mian
。
這裡給你們的第一個原則就是：不要手敲，請複製一切資訊。 這些低階錯誤，通過這個簡單的原則就可以避免。
三、不是一個東西
這兩週，周圍的一個新人連續犯了兩個錯誤。
第一個是測試環境程式不符合預期。
比較MD5時，發現編譯機程式的MD5和測試機一樣，但是看日誌時，發現程式碼和測試機的日誌對不上。
後來發現這個程式有兩份程式碼，一份程式碼已經編譯出了程式（和測試機一樣，MD5在這份看的），另一份程式碼一直在修改開發（程式碼和日誌在這裡看）。
PS：MD5是根據檔案內容計算出的一串值，衝突的概率很小，所以一般MD5一樣就認為檔案一樣。
第二個是線上的程式出現了問題，測試環境原先也有這個問題，但是程式重新編譯後就不能重現了。
這個怎麼看程式碼都找不到問題，只好先發布恢復線上問題。
後來同事無意間發現發不錯程式碼了，複製的其中一份程式碼開發了一半，被髮布到線上去了。
我問為什麼會發生這樣的問題時，得知他的程式碼複製了三四份（震驚）。
再細問他經歷了什麼事情？
原來這個專案有多個獨立的功能，在一個目錄下。
開發每個功能時，都單獨複製一份程式碼。
在開發的過程中，他自己也經歷過很多次開發了一半，發現開發錯位置了，然後把開發的那些程式碼複製到其他位置。如果還錯了，就再複製，直到正確為止。
面對這種做事方法，我是不能接受的（這麼容易犯錯為啥還用這個方法？）。
這裡給你們的第二個原則是：一個專案的程式碼只有一份，可以避免很多開發機與測試機對不上的問題。
PS1：這裡的只有一份不是說備份問題，大家應該使用版本控制系統去備份管理程式碼。
對於處於開發的程式碼，我會使用同步工具從開發機實時同步到編譯機。如果開發機掛了編譯機還有一份實時備份。
PS2：當然，現在已經9102年了，我們卻還在收到管理這些系統。自從去年沒有夢想火爆後，聽說今天已經要引進CICD
了。
通過CICD
也可以避免這兩個例子裡的問題。
但是保持一份這個原則確實通用的。
比如程式碼裡的函式實現保持一份、公共庫保持一份等等，不然都會遇到類似的問題。
四、正確的反饋問題
我負責的是一個通用的資料服務，用於接入各種型別的業務資料。
業務資料出問題的時候，使用方首先找的就是我。
但是大多數人問問題的方法都有問題。
面對資料性系統，發現資料不對時，大多數人一直在說你的系統有問題哇，但是遲遲不說具體是什麼問題。
此時正確的姿勢應該提供具體資料的請求引數，以及預期和現在是什麼。
面對儲存也一樣，比如redis異常問題，應該提供具體的redis路由發現的資訊，以及具體問題（延時變高還是資料不一致）。
提供路由發現資訊，對應的負責人才能去看具體是哪個業務以及具體哪個redis例項有問題。
之所以需要這樣做，是因為很多人不會換位思考，或者自己想當然的認為對方知道一切。
比如你反饋資料系統的圖片不對了，你要說具體是哪個圖片，具體到對應的名字。畢竟後面有幾十個規格的圖片，只有你知道你用的是哪個圖片。
比如你反饋redis有問題，以直播為例，在你看來你只用了一個redis，但是對redis的負責人來說，你們直播業務接入了幾十個REDIS。只有你知道你用的具體是哪個REDIS。
另外有時候提供了相關資訊，但是你是通過截圖提供的。
這就很容易引出第一個錯誤：資訊敲錯了。
因為這個，也經常會發生一件很有趣的事情：你反饋一個問題，對方敲錯了查不到有啥問題。你們兩個爭論不休，最後發現你們兩個說的不是一個數據。
截圖沒問題，但是對於關鍵的引數資訊也最好在發完截圖之後，提供一下文字引數。
五、最後
這裡先給大家了三個建議原則：不要手敲資料、資料維持一份、反饋問題提供詳細文字引數。
你有遇到沒遵守這三個建議而產生的問題嗎？
或者你有其他的什麼好的建議，可以說來聽聽，一起學習一下。
-EOF-