<dd id="dbjz6"><noscript id="dbjz6"></noscript></dd>
    <th id="dbjz6"></th>
      1. <dd id="dbjz6"></dd>
        1. 老鳥眼中菜雞程序員的代碼全是Bug?

          當初大家起點都差不多,工作N年后,有些人依然停留在菜雞,有些人卻已成為大牛,所有的事情,都是一點一滴習慣養成。讓我們看看菜雞程序員是如何寫代碼的?有可能找到你當初的影子,甚至是現在的影子。

          1、命名不規范

          命名很隨意,當時寫代碼特別High,什么奇奇怪怪的命名都有的:yyds,xxxx,j1,j2……jn,llst,完全意識不到全名規范的價值和意義。

          2、日志不規范

          日志?

          那是什么鬼東西,能吃么?    

          曾經有一個從文思海輝出來的小伙伴,三年后端工程師經驗,出了問題不知道怎么解決。只好重啟。找我來協助,問他,怎么錯了? 不知道。 日志呢? 沒有。  

          暈,那怎么解決問題,神仙也搞不定啊。   

          后來才知道,他們解決問題都是本地改代碼然后直接部署,重新訪問看錯誤消失沒,沒有消失就繼續在本地改源碼。

          老鳥眼中菜雞程序員的代碼全是Bug?

          3、拒絕寫接口和假數據

          一個菜雞不可怕,可怕的是菜雞遇到菜雞。曾經有一個項目中的兩個菜雞,一個前端一個后端,他們很歡快的調接口,根本不寫文檔 ,兩個人效率特別高。直到有一天,發現項目可能做不完了,需要另外兩個前端菜雞協助一下。新來的兩個菜雞要獲取后端的數據,不知道接口的Url地址,不知道Get還是Post,不知道發送的參數和返回值。就這樣寫!我壓根沒想到可以這么寫代碼,兩個菜雞很開心!拍手稱快:通了,通了,通了!我說你們通什么呢?他們說接口終于通了!原來他們兩個參考之間的頁面,硬生生的一次一次不停的嘗試,就這樣把接口猜出來了!這就是編程的樂趣嗎?

          還有不寫假數據。曾經有一個馬姓小哥,對趙姓小哥信誓旦旦的說:3天,給我3天時間 ,我把真數據給你。于是趙姓小哥信以為真。就這樣,3天又3天,3天又3天,3天又3天,3天又3天,3天又3天……整整一個半月,趙姓小哥都沒有拿到全部的數據!

          4、不寫單元測試

          確切來說,是不按TDD的方式開發。在現在IDE這么強大的情況下,先寫單元測試的習慣,不僅僅是代碼的嚴謹性,也是效率的代名詞啊。可是很多菜雞理解不了單元測試的價值,沒關系,等到代碼重構,需求變更的時候,就哭都哭不出來了!好的單元測試,你的邏輯必然會清楚。

          5、先集成,再測試,再放棄

          很多時候,菜雞在引入第三方的庫,框架,接口或者是服務的時候,最喜歡的事情就是直接和自己原有的代碼集成在一起。結果 是什么呢?突然間不能用了,跑不起來了,不知道問題出在哪了,根本分不清倒底是第三方的問題還是自己的問題。好的方法是什么?先跑通官方提供的Demo,再想辦法一點一點加上自己的業務。

          6、理不清楚邏輯,邊做邊猜

          前端在這里的問題特別多,做支付,不清楚支付的流程,分不清楚定義,總以為前端就是接口處理好數據展示好就拉倒。很多菜雞都會有這種習慣,這樣不好,先把邏輯處理好,弄清楚流程,再去動手才好。

          7、不做方案

          不做方案代表什么含義呢?就是完全憑直覺行走啊。

          跟閉上眼逛窯子一樣。寫代碼的好習慣應該是先在腦袋里把所有的需求細節過一遍,實現細節拿出來。上個月就有一個張姓小菜雞,做一個匿名評論的功能。基本上沒有什么經驗,腦子也不好使,給出的方式是什么你們猜得到么?用戶刷新一次就往用戶表里插入一條數據,密碼默認昵稱隨機。不多說了都是淚,我見過太多讓人目瞪狗呆的方案了,看著滿屏的代碼,你怎么幫他調錯調優,最好的方式就是全部重寫。做方案的好處太多了。

          8、不關注性能

          不關注性能也是新人很容易犯的錯。什么是性能呢。對后端來說就是TPS響應時間,對前端來說就是響應時間。很多新人程序員的習慣就是把東西做出來,然后再優化。最后就是東西做出來了,優化留給別人了。對性能的關注也是晉升中級程序員最關鍵的技能點。在寫代碼的時候,有經驗的工程師已經知道了這個方法這個函數這個功能點的性能怎么樣,瓶頸在哪里。

          9、害怕重構

          “程序員最大的勇氣就是看自己三個月之前寫的代碼。”其實重構并不應該是在幾個月之后重構,最好的方式是實時重構。寫一天代碼,70%的時間都放到重構上都不過份。而新人呢,磕磕跘跘的完成一個功能,就跟多米諾骨牌做成的大黃蜂一樣,你敢動一下他的代碼試試?他會跟你拼命。你讓他自己動一行代碼試試?不重構在某種程度上也意味著你的代碼實現無法重塑。

          10、做出來就好,不考慮優雅的方案

          有個詞叫做最佳實踐,其實編碼規范和最佳實踐,是編程功底的重要體現。優雅方案可以認為是最佳實踐的升級版,它和上面說到的不斷的重構是相輔相成的。

          不好的方案是什么呢?硬編碼居多,沒有可擴展性,用很丑陋的方式完成了功能。上次他們去做了一個關于試聽課的方案,一個人能試聽多少節課,正常的邏輯應該是在用戶的表里加一個字段來表示。需求是寫著邀請幾個人,可以試聽多少節課,所以他們判斷試聽多少節課就直接在通過邀請人的表里查詢去做。完全沒考慮到以后如果我變換了試聽課的判斷條件怎么辦?實際上這是應該拆解成兩部分,一個是試聽課的產生條件,這是一個獨立的模塊,加一個是試聽課的確認。像這種例子太多了,也和不做方案,不考慮擴展性有關系。

          11、不考慮未來需求的變化

          工程師的水準,其實可以分成以下幾個階段:

          • 面向功能編程    
          • 面向性能編程    
          • 面向未來編程  

          工程師拿到需求的第一件事,應該聚集在以下幾個問題:

          • 第一 哪些需求是我之前完成過的?
          • 第二 哪些需求是有可能變化的?  
          • 第三 有幾種方案,分別支持什么樣的需求變化?    

          但是差一點的程序員就考慮不到那么遠,一個是對業務不熟悉,判斷不出來哪些需求可能會產生變化,一個是對可選的方案掌握的不多,根本就沒有什么可選的余地,還有就是沒有這種思維習慣,分不清楚哪些是現在要完成的,哪些是未來可能會支持或者是變動的。

          12、遇到問題的時候不會試錯

          這也是新手常見的問題。很多時候新人會遇到問題,解決不了,去找一個有經驗的工程師,這個有經驗的工程師呢,大概也未曾遇到這種情況,但是他解決問題的思路清楚啊。一會兒試試這個,一會兒刪刪那段代碼,很快就跑通了。解決問題是一個很見功底的技術點,而且是有很多方法論的,之前總結過一些,簡單列舉過來:

          上一頁12下一頁
          ?

          留言

          1. #1

            TiAmo(2021-12-04 10:12:52)
            寫的很好,感謝您的分享

          chinesemature老熟妇oldman