<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>codereview - 标签 - 菠菜眾長</title><link>https://lruihao.cn/tags/codereview/</link><description>codereview - 标签 - 菠菜眾長</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>1024@lruihao.cn (Lruihao)</managingEditor><webMaster>1024@lruihao.cn (Lruihao)</webMaster><lastBuildDate>Thu, 04 Mar 2021 21:04:18 +0000</lastBuildDate><atom:link href="https://lruihao.cn/tags/codereview/" rel="self" type="application/rss+xml"/><item><title>Code Review 怎麼做？新手工程師如何提升「程式碼品質」</title><link>https://lruihao.cn/posts/codereview/</link><pubDate>Thu, 04 Mar 2021 21:04:18 +0000</pubDate><author>Lruihao</author><guid>https://lruihao.cn/posts/codereview/</guid><description><![CDATA[<h2 id="程式碼的持續優化">程式碼的持續優化</h2>
<p>對一個入門的工程師來說，掌握程式語法與模仿範例實作是基本的能力。那有了這樣的基本能之後，要如何寫出更好的程式呢？怎樣才能夠成為一個「優秀」的新手工程師呢？事實上，寫出會動的程式不難，但想寫出好的程式其實是需要刻意練習的。大部分的人會建議要「多練習、多實作」，但我認為在大量練習之外，適時的「優化程式」也是提升「程式碼品質」重要的關鍵。而在「優化程式」可以分成兩個角度：</p>
<ol>
<li>程式執行效能更好</li>
<li>程式碼結構更精簡</li>
</ol>
<p>程式執行效能就是從速度跟空間來思考，執行時間越短、變數佔用空間越小。而程式碼結構則會從可讀性和精簡來衡量，例如：變數的命名有沒有意義、程式碼有沒有冗余、繁瑣的部分等等。只不過新手很容易停留在寫出程式的喜悅以及受到固有的解題思考，而忽略優化的過程。</p>
<p>透過「Code Review」是推薦新手的方法，經由反饋與討論來找出程式中可優化的空間。</p>
<h2 id="code-review-的關注點">Code Review 的關注點</h2>
<p>以我自己的經驗來說，Review 一份專案的時候會關注：</p>
<ol>
<li>程式能不能正常操作，有没有什么明显的错误？（低標）</li>
<li>程式碼當中有沒有奇怪的地方？（優化）</li>
</ol>
<p>第一個關注點是程式碼的低標，結果正確與可正常運行一定是最重要的。如果程式無法運行動或存在很明顯的問題，那再多的優化都沒有意義。除了確保執行之外，同時也會檢查一下是否有低級的邏輯失誤或是安全性的疑慮，像是資料庫沒有正確關閉或密碼明碼沒有加密之類的問題。</p>
<p>第二個關注點是「程式碼品質提升」的部分，我會把它定義成程式運作上沒有問題，但看起來很不舒服或執行效率很差的部分。大致上可以從以下幾點下手：</p>
<ol>
<li>命名有沒有意義/不一致</li>
<li>資料庫的正規化情況</li>
<li>是否存在特別複雜的程式片段（例如多次的資料庫查詢、多層的迴圈使用）</li>
<li>重複的程式碼有沒有定義成 <code>function</code></li>
<li>冗長的程式碼能不能拆分成 <code>function</code></li>
</ol>
<p>不過一次的 Code Review 建議著重在 3 - 5 個優化地方，比較容易聚焦在優化的品質。根據時程的壓力，決定 Code Review 迭代的次數。</p>
<h2 id="從架構的規劃到細節的優化">從架構的規劃到細節的優化</h2>
<p>在拿到一份程式碼時，通常會先掃過一眼程式的檔案結構，是否有不該上傳的檔案或缺漏。</p>
<p>以這個例子來說，第一眼會覺得檔案配置蠻結構化的。但再多看一點會發現存在幾個冗餘的檔案，例如：<code>-filesqqqq</code>、<code>diff</code>，甚至 <code>/icon</code> 資料夾也不該放在最上層。</p>
<p>進入程式的第一步先從 <code>package.json</code> 檔案開始，確認一下專案的基本資訊是否完整、使用到的套件與版本，以及程式的進入點是什麼。然後打開進入點的檔案（通常會命名成 <code>app</code> 或 <code>main</code>），通常有幾個點需要注意：「套件的載入順序」會建議從第三方套件 → 自定義的模組 → 程式內的變數這樣順序定義；「善用 MVC 的架構」將非主程式的部分依照功能拆分模組，避免檔案資訊量太雜亂。接著就會從 <code>Router</code> → <code>Controller</code> → <code>Service</code> → <code>View</code> 的流程一個一個功能，以下分享一些存在優化空間的程式碼：</p>
<ol>
<li>善用工具，已有的工具，不用自己手刻</li>
<li>變數名稱不建議用大寫開頭（通常是用在 Class 的命名）</li>
<li>保持優化的空間與彈性</li>
</ol>
<p>「優化其實是一種取捨」，不需要也不應該追求一步到位。開發往往都是在品質跟產出做取捨，初期可以把開發目標放在「先求可以動，再求持續優化」的節奏上。新手需要在意的點有幾下兩點：</p>
<ol>
<li>很容易把重點全部放在程式碼的產出上而忽略的程式碼的品質。</li>
<li>停留在做出成果的喜悅，而停滯了優化的步調。</li>
</ol>
<p>因此，會建議在開發當下就「多想」兩秒鐘，感覺可優化但來不及的部分先在旁邊加個註解提醒自己。另外也養成一段時間回頭看之前的程式碼的習慣，試著刻意找出可以優化改進的部分。專案的提交可能會有期限，但程式碼的優化沒有盡頭。面對相同的專案與程式碼，唯有透過不停的迭代優化才能打造更好的程式，同時也見證了你和程式一起變得更好的過程。所以建立逐步優化的空間，養成持續提升程式碼品質的習慣，才是一個新手工程師需要修煉的心法。</p>
]]></description></item></channel></rss>