iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 3
2
Modern Web

跟著 YDKJS 作者 Kyle Simpson 打造全新 JavaScript Mindset系列 第 3

[day02] Kyle Simpson :「 Code is for Humans 」(下)

在大家說「我重寫比較快」的時候,其實更多是不了解程式邏輯,因為你心裏想「如果是自己重寫至少自己可以知道」

Why? 因為你沒有用你的 code 溝通你的想法。

// 可能是 amazon 的運費之類的
var shippingCost = base * rate + extra

// ***********

var shippingCost = (base * rate) + extra
// linter: unnecessary parens

你可能寫過類似下面的 code ,然後被 linter 修改成上面的。
這時候問問自己, linter 是給誰看的?

我們之前寫 code,主要都是給電腦看的。

這理所當然,萬分合理,因為我們想的都是如何優化、如何提高效能,當然都是給電腦看的。

但是你試想,對於同一個問題,有多少種解法?
我們怎麼決定無數個解法之中,哪個解法是最好的?效率最快的?

i++ or ++i 哪一個效能比較好? 如果你知道 ++i 用比較少 register 所以效率好,那麼你要改寫所有 for 迴圈改成 ++i?

或是說,如果有一個 scope 產生的 bug,有可能是電腦解析錯誤嗎?還是人類理解錯誤才會有 bug ?

Code is for communicating ideas with other people

我們用程式碼來彼此交流想法

我們寫的 code 已經不是組合語言,所以絕對不是「最快的」,
透過抽象化,我們可以用 code 來交流想法,所以無數種解法裡面,如果能清楚溝通就是好的 code ,能夠清楚理解我們就不用看到每一行 code 都要重寫。

你收到一個商業需求,你花很多時間整理好,寫成code。
寫成能動大家都會寫,但是你應該是要把 code 清晰地,讓別人可以理解你整理過的想法,這才是好的 code。
如果 code 清晰地寫好邏輯,如果有 bug 或是你在寫 code 沒注意到的地方,別人在幫你 review 的時候也能夠快速幫你找到問題或是盲點。

否則,當別人要修改或是未來的自己回來修改 code,那個人又要重新整理一次需求,組織想法,這時候又有時間壓力,他就會說「讓我重寫吧!」


你不了解的 code 你就不會信任,反之你不信任的 code 代表你不了解。

很多類似的數據,反正工程師花最多時間的一定不是「寫 code」

不要寫 write-only 的 code!
也不要拿code寫詩 ⋯⋯ 比如 Perl詩經

練習思考自己 code 可讀性的問題

  • 重構
  • 可讀性好的命名
  • 可讀性好的結構
  • 過一段時間(不要太久,怕你忘掉)回來看有沒有「更有意義的」方式重構你的 code

抱怨

和老闆溝通,如果你不這樣做,你就會回去之前提到那個「重寫」的地獄。
如果老闆不能溝通,你可以考慮離開地獄。

註:
facebook performance review 中,Initiative 也是很重要的能力,You Know Direction。
所以不要認為工程師不必和老闆、PM溝通。
我的 medium 心得有提到工程師需要的能力,可以跳到中後段

了解你的工具,了解 JavaScript。你才可以把 code 寫好。

一個簡單的問題

var x = 40;

x++   // (40?)
x     // 41

++x   // (42?)
x     // 42

很多人寫 code 是從其他程式經驗來的,所以這邊很容易可以回答 ++ 運算規則 ,基於 x = x + 1 ,差別是先執行再 +1 還是 先馬上 +1 在執行。

然後,一個 JS最常被抱怨的型別改變問題:

var x = "5";
x = x + 1 // "51"   ok,字串相加


var y = "5" ;
y++;  //??  預測應該和上面一樣, 字串相加
y;    //??
var y = "5" ;
y++;  //5  ????????????
y;    //6  ?????????????

這時候發現 y 不如預期時,
抱怨「JavaScript 設計什麼爛語言,垃圾」

但是,回想以前寫 java , c or c++ 有問題,都覺得是自己沒看好文件或是了解不夠深入,

只有寫 JavaScript 的時候會怪 JavaScript 設計很爛。

JavaScript 的來源是 ECMA-262 specification
所以有問題先查 specification 看是否符合預期

然後思考:

  1. 和 spec 不一樣 => bug :(
  2. 和 spec 一樣,但還是有 bug => 思考的邏輯錯誤

這邊是 ++ 的 spec,可以發現:

  1. 像是 *演算法 一樣,有步驟的
  2. 一條敘述裡面有其他連結,那個連結裡面又是另一則演算法
  3. 有可能會一直在某些步驟裡面循環

*註:演算法,可以想成摺紙的「步驟」

因為很多步驟巢狀疊在一起,所以很多人就 pass 不看了。
這邊抓字面大概看一下

應該是先轉數字,才做運算。

所以可以思考:

var y = "5" ;
y++;  // y 從字串變成數字 5  
y;    // 變數字後 + 1 = 6  

這樣就會和預期結果一樣了。


上一篇
[day01] 誰是 Kyle Simpson ? Code is for ... ? (上)
下一篇
[day03] 初步介紹 JavaScript 以及 Overview
系列文
跟著 YDKJS 作者 Kyle Simpson 打造全新 JavaScript Mindset31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言