今天寫的筆記，都是公開文檔。我會推薦都去看看。有些原則不一定需要遵守，保留彈性。內容與我之前寫的筆記也有關，最好先完整閱讀一個，且最好是買本Bob大叔的clean code。

無瑕的程式碼 JavaScript

連結：https://hackmd.io/@trylovetom/SJnKIrajH

受到Bob大叔的clean code啟發，是clean code的js版本。除了提到一些原則外，另有提及一些JS生態使用的工具。筆記僅簡單紀錄紀個我感興趣的部份，推薦要寫JS的還是去完整閱讀。

注意！你不必嚴格遵守每一項原則，有些甚至不被大眾所認同。雖然這只是份指南，卻是來自《無暇的程式碼》作者的多年結晶。

軟體工程只發展了五十年，仍然有很多地方值得去探討。當軟體與建築一樣古老時，也許會有一些墨守成規的原則。但現在，先讓這份指南當試金石，作為你和團隊的 JS 程式碼標準。

還有一件事情：知道這些原則，並不會立刻讓你成為出色的開發者，長期奉行它們，不代表你能高枕無憂不再犯錯。但是，千里之行，始於足下，時常與志同道合們進行討論（Code Review），改善不完備之處。不要因為自己寫出來的程式碼很糟糕而害怕分享，而是要畏懼自己居然寫出了這樣的程式碼！

評估程式碼好壞的方法

透過計算閱讀程式碼時的咒罵次數，來評估軟體品質

這方法與「可不可以不要寫糙 code」有異曲同工之妙。

協助維持軟體品質的工具

這個好像很酷！推薦加入書籤裡。

嘗試與想法 里氏替換原則 Liskov Substitution Principle

在 里氏替換原則 Liskov Substitution Principle 一節給的糟糕範例有下面註解：

function renderLargeRectangles(rectangles) {
  rectangles.forEach(rectangle => {
    rectangle.setWidth(4);
    rectangle.setHeight(5);
    const area = rectangle.getArea(); // 糟糕：結果為 25，應該為 20 才正確
    rectangle.render(area);
  });
}

const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);

// > 譯者附註
// > setWidth 與 setHeight 方法無法被繼承，使用上的不一致，更造成了結果錯誤。

我不認為// 糟糕：結果為 25，應該為 20 才正確有錯，實際上 適當的範例 的執行結果也是一樣的，僅僅是 適當的範例 更好而已。不應該提供 正方形 有setWidth和setHeight兩個方法，卻做同樣的事 情。與矩形分開來更為清晰。

提問的智慧

連結：https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way

同樣會推薦也閱讀當中提到的文章：

• 如何有效地報告錯誤
• 語意化版本 2.0.0

如何有效地報告錯誤**** ，我並沒有紀錄什麼筆記，但是看了卻與此篇一樣非常有感覺，當中也有一些我會犯的錯誤。同樣也只簡單紀錄些我想紀錄的話語：

首先你應該明白，黑客們喜愛有挑戰性的問題，或者能激發他們思維的好問題。如果我們並非如此，那我們也不會成為你想詢問的對象。如果你給了我們一個值得反覆咀嚼玩味的好問題，我們自會對你感激不盡。好問題是激勵，是厚禮。好問題可以提高我們的理解力，而且通常會暴露我們以前從沒意識到或者思考過的問題。對黑客而言，“好問題！“是誠摯的大力稱讚。

絕對，永遠不要指望黑客們閱讀使用封閉格式編寫的文檔，像是微軟公司的 Word 或 Excel 文件等。大多數黑客對此的反應就像有人將還在冒熱氣的豬糞倒在你門口階梯上時你的反應一樣。即便他們能夠處理，他們也很厭惡這麼做。

以上兩點超級認同！！

所以，界定一下你的問題，使專家花在辨識你的問題和回答所需要付出的時間減到最少，這技巧對你有用答案相當有幫助──但這技巧通常和簡化問題有所區別。因此，問我想更好的理解X，可否指點一下哪裡有好一點的說明？通常比問你能解釋一下X嗎？更好。如果你的程式碼不能運作，通常請別人看看哪裡有問題，比要求別人替你改正要明智得多

有些問題真的可以立馬解釋。

最有效描述程式問題的方法是提供最精簡的臭蟲展示測試示例（bug-demonstrating test case）。什麼是最精簡的測試示例? 那是問題的縮影；一小個程式片段能剛好展示出程式的異常行為，而不包含其他令人分散注意力的內容。怎麼製作最精簡的測試示例？如果你知道哪一行或哪一段程式碼會造成異常的行為，複製下來並加入足夠重現這個狀況的程式碼（例如，足以讓這段程式碼能被編譯/直譯/被應用程式處理）。如果你無法將問題縮減到一個特定區塊，就複製一份程式碼並移除不影響產生問題行為的部分。總之，測試示例越小越好（查看話不在多而在精一節）。

別把自己家庭作業的問題貼上來
黑客們很擅長分辨哪些問題是家庭作業式的問題；因為我們中的大多數都曾自己解決這類問題。同樣，這些問題得由你來搞定，你會從中學到東西。你可以要求給點提示，但別要求得到完整的解決方案。

即使你很急也不要在標題寫緊急
這是你的問題，不是我們的。宣稱緊急極有可能事與願違：大多數黑客會直接刪除無禮和自私地企圖即時引起關注的問題。更嚴重的是，緊急這個字（或是其他企圖引起關注的標題）通常會被垃圾信過濾器過濾掉 – 你的問題可能永遠將無法得到解答。

這兩個不J4，但下一個真的是…

問題解決後，加個簡短的補充說明
問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注，應該在那裡貼一個說明比較恰當。
最理想的方式是向最初提問的話題回覆此消息，並在標題中包含已修正，已解決或其它同等含義的明顯標記。在人來人往的郵件列表裡，一個看見討論串問題 X和問題的X - 已解決的潛在回覆者就明白不用再浪費時間了（除非他個人覺得問題 X的有趣），因此可以利用此時間去解決其它問題。
如果你自己不是技術專家或者黑客，那就相信我們，這種感覺對於那些你向他們求助的大師或者專家而言，是非常重要的。問題懸而未決會讓人灰心；黑客們渴望看到問題被解決。好人有好報，滿足他們的渴望，你會在下次提問時嘗到甜頭。

問題懸而未解是令人難過痛苦的。就算沒成功也應該回報，成功了更應該回報。解決問題的感覺是最大的回饋。如果你的問題解不解決都沒關係，那就不要問。

黑客從某種角度來說是擁有豐富知識但缺乏人情味的傢伙；我相信他是對的，如果我像個乞討者那樣提問，不論我是誰，一定會惹惱某些人或者被他們忽視。他建議我記下這件事，這直接導致了本指南的出現。

這可能是我需要注意的…

如何更好地回答問題
態度和善一點。問題帶來的壓力常使人顯得無禮或愚蠢，其實並不是這樣。
對初犯者私下回覆。對那些坦誠犯錯之人沒有必要當眾羞辱，一個真正的新手也許連怎麼搜尋或在哪找常見問題都不知道。

阿勒？看這份指南我到底是提問的人還是回答問題的人？
恩，好像都是。提問的部份也有我會犯的錯，卻對這份指南超有感覺。

團隊的推進器 — 開放與學習

7日的寫作松自我挑戰，別人系列裡的其中一篇：團隊的推進器 — 開放與學習。

刻意練習把學習分成三個階段

• 初學者：有目的的練習、突破、反省及改進
• 中級：有了基礎之後便開始刻意練習，重點在透過模仿去學習並理解大師思維
• 大師級：在領域中無人可學的時候，就得自己拓展新的觀點

再附個 達克效應 的圖：

• 筆記
• 看完不會變大師