如何成為優(yōu)秀的開發(fā)者

本篇內(nèi)容主要講解“如何成為優(yōu)秀的開發(fā)者”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何成為優(yōu)秀的開發(fā)者”吧!

 1.三法則

三法則是一個代碼重構的經(jīng)驗法則，用來決定什么時候應該用新的代碼/程序/方法來替換一段復制的代碼。

它規(guī)定，允許你復制粘貼一次代碼，但當同一代碼復制三次時，應提取到一個新的程序中。主要的概念是使代碼/程序/方法能夠在項目中通用，這樣它就可以在很多地方重復的使用。

2.穩(wěn)定才是王道

在結構和編碼方式上保持一致。這可以幫助你提高代碼的可讀性和可維護性。

嘗試并提出一致性的編碼標準，這有助于保持一致性，最好精確到你的變量的命名習慣。另一個重要的是代碼程序的結構，它應該是顯而易見的，開發(fā)人員需要做出一些改變或添加一些新的東西。

3.減少嵌套

If中的if可能會使代碼結構變得很亂，而且很快就很難讀懂。有時你可能無法繞過這個問題，但一定要看看你的代碼結構。對于 else if  來說也是一樣的，要盡可能避免if嵌套，因為這有時會使代碼更難讀。

衛(wèi)語句(又稱 提前返回 /提前退出)是幫助解決這一問題的有效方法!衛(wèi)語句只是用于檢查先決條件，可以是一個返回語句，也可以是一個異常。

沒有使用衛(wèi)語句示例：

if (account != null)  {      if (order != null)      {          if (order.term == Term.Annually)          {              // term annually          }          else if (order.term == Term.Monthly)          {              // term monthly          }          else          {              throw new InvalidEnumArgumentException(nameof(term));          }      }      else      {          throw new ArgumentNullException(nameof(subscription));      }  }

使用衛(wèi)語句示例：

if (account == null)  {          throw new ArgumentNullException(nameof(account));  }  if (order == null)  {      throw new ArgumentNullException(nameof(order));  }  if (order.term == Term.Annually)  {      // term annually (return here)  }  if (order.term == Term.Monthly)  {      // term monthly (return here)  }  throw new InvalidEnumArgumentException(nameof(order.term));

4.從全局出發(fā)去考慮

對項目整體有個認知是非常重要的，這能使小細節(jié)更容易跟進。一旦你了解了項目的整體結構，小細節(jié)就不需要再去花太多時間去研究。

5.花點時間思考下命名的問題

在編碼中給變量、方法或對象命名是困擾我們的事情之一，這可以是給一個類、方法甚至是一個變量命名。一個優(yōu)秀的開發(fā)者會花時間考慮相關的變量名，因為他們知道這有助于提高可讀性!

6.技術負債是不好的

要求高點可以幫助解決這個問題。盡量一次寫好你的代碼邏輯，否則你就得反復的去重構。

技術債務是軟件開發(fā)中的一個概念，它反映了由于現(xiàn)在選擇一種簡單的(有限的)解決方案，而不是使用會花費較長時間的更好的方法而導致的額外返工的成本。

7.過高的評估

根據(jù)您所處部門的不同，您未必喜歡這一點。但優(yōu)秀的開發(fā)人員往往會高估任務，因為他們知道事情大概要花多長時間，然后會給預期再增加一個緩沖的時間，這樣可以幫助你把事情做好。

這可以真正幫助你解決上面的觀點——  "技術債務是不好的"。如果你低估或預估了一個比較理想的時間，實際上可能會無法完成，甚至會遺留一些技術債務。因為你的期望只是盡快的完成并能夠使其正常運行，而不是使代碼干凈且易于維護。

8.文檔和注釋

文檔和注釋有助于幫助自己或者他人更容易的理解和使用。你會聽到一些有經(jīng)驗的人在說，我們能不能把這個過程記錄下來，或者代碼審查失敗，因為接口沒有相關注釋等。

9.敢于刪除不好的或沒用的代碼

你經(jīng)常會看到很多不太自信的開發(fā)人員將大量代碼注釋掉并留在那里。版本控制是有目的!優(yōu)秀的開發(fā)人員不會回避刪除應用程序中沒用的代碼。

10.花時間檢查編寫的代碼

優(yōu)秀的開發(fā)人員將花費更多的時間在代碼審查上，并且知道代碼審查的重要性。

• 盡早的發(fā)現(xiàn)BUG;

• 提高開發(fā)人員的技能，并讓團隊其他成員也養(yǎng)成這樣的習慣;

• 知識分享;

• 一致的設計和實現(xiàn)。

我見過的最好的代碼評審過程是：

• 1個風險不大的小任務應該由1個開發(fā)人員進行審查;

• 中型/大型更改或有風險的更改應由3位開發(fā)人員進行審核，其中一位是其辦團隊中的高級開發(fā)人員;

• 一個風險極高的修改或是正在開發(fā)的新功能，應該舉行一個會議，3個開發(fā)人員至少有一個是首席開發(fā)人員，然后一起去看每一行，并提出建議。

11.編寫測試用例

您會注意到，經(jīng)驗更豐富，實力更強的開發(fā)人員會花更多時間編寫好測試用例。良好的測試用例可以幫助您更有信心地擴展或修改程序代碼，并有助于減少bug的產(chǎn)生。

12.花時間去設計

在深入研究代碼或寫代碼之前，請先進行仔細考慮，然后將其分解為小塊。這有助于幫你如何將所有東西組合在一起，并為創(chuàng)建更簡潔的代碼做更多準備。

13.要注重技術實現(xiàn)原理而不是語法

這是個大問題! 他們喜歡學習基礎知識大于注重語法。這可以幫助他們更有效的發(fā)現(xiàn)問題，也可以幫助他們更明白的google問題。

14.讓谷歌成為你的好朋友

他們是Googling的專家，能更好的找到解決問題的方法。因為上面提到他們更專注于基礎知識而不是語法，所以他們知道該搜索哪些谷歌術語，如果你執(zhí)著于學習語法，這是很難做到的!

15.先實現(xiàn)功能再優(yōu)化

一些初級開發(fā)人員，似乎一開始就花了很多時間讓編寫的代碼看起來很漂亮，這樣如果最后發(fā)現(xiàn)它們無法正常工作就陷入尷尬。優(yōu)秀的開發(fā)人員會在早些時候只實現(xiàn)功能，這樣把細節(jié)處理好之前可以盡早的發(fā)現(xiàn)問題，有利于保證項目更加順利的進行。

16.風險管理和解決問題

高級開發(fā)人員可以把控風險，通過設計模式的應用提煉出復雜的問題，并且根據(jù)過去的經(jīng)驗，可以獨立解決不同的問題。

17.多問

優(yōu)秀的開發(fā)人員想了解的多一點。即使聽起來很簡單，他們也不介意提出問題。這些可能是與技術或業(yè)務相關的問題。了解業(yè)務需求有助于他們編寫更好的代碼!他們對自己的能力充滿信心，因此不怕問問題。

18.盡可能地將邏輯從數(shù)據(jù)庫中分離出來

這一點要看你構建的應用類型，只有在不會影響性能的情況下才可以。

他們知道要把數(shù)據(jù)庫查詢控制在簡單的CRUD操作中。

Create, read (aka retrieve), update, and delete

然后，業(yè)務邏輯層應該將這些內(nèi)容整合在一起。這有助于開發(fā)人員知道在哪里尋找業(yè)務邏輯。如果在數(shù)據(jù)庫查詢和代碼中有邏輯，這很快就會變得混亂。

19.保持代碼簡潔

他們知道保持代碼簡單是最好的方法。即使這意味著有時要多寫代碼。您將看到許多初級開發(fā)人員編寫如下所示的代碼：

return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];

到此，相信大家對“如何成為優(yōu)秀的開發(fā)者”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！