跳到主要內容

[鐵人賽] JS 基本解說,變數型別,宣告 - Node.js Day 6

JS 基本解說,變數型別,宣告

前言

前面已經有建立基本的 Node.js ,以及第一個基本範例,在開發 Node.js 之前,讓我們先建立 JavaScript 應該要知道的一些基本觀念。

本文開始

在進入 node.js 開發之前,還是必須要說, node.js 雖然稱為 node.js ,不過本質在開發上還是在寫 JavaScript。對於 JavaScript 的基本認知還是要有。

基本型態

JavaScript 有以下幾種基本型態。
  • Boolean
  • Number
  • String
  • null
  • undefined
變數宣告的方式,就是使用 var,結尾使用『;』,如果需要連續宣告變數,可以使用 『,』 做為連結符號。
// 宣告 x 為 123, 數字型態
var x=123;

// 宣告 a 為456, b 為 'abc' 字串型態
var a=456,
    b='abc';

布林值

布林,就只有兩種數值, true, false
var a=true,
    b=false;

數字型別

Number 數字型別,可以分為整數,浮點數兩種,
var a=123,
    b=123.456;

字串型別

字串,可以是一個字,或者是一連串的字,可以使用 ‘’ 或 “” 做為字串的值。
var a="a",
    a='abc';

運算子

基本介紹就是 +, -, *, /
邏輯運算就是 && (and), || (or), ^ (xor),
比較式就是 >, <, !=, !==, ==, ===, >=, <=

判斷式

這邊突然離題,加入判斷式來插花,判斷就是 if,整個架構就是,
if (判斷a) {
    // 判斷a 成立的話,執行此區域指令
} else if (判斷b) {
    // 判斷a 不成立,但是 判斷b 成立,執行此區域指令
} else {
    // 其餘的事情在這邊處理
}
整體架構就如上面描述,非 a 即 b的狀態,會掉進去任何一個區域裡面。
整體的判斷能夠成立,只要判斷轉型成 Boolean 之後為 true,就會成立。
大家可以這樣子測試,
Boolean(判斷);

應用

會突然講 if 判斷式,因為,前面有提到 Number, String 兩種型態,但是如果我們測試一下,新增一個 test.js
var a=123,
    b='123';

if (a == b) {
    console.log('ok');
}
編輯 test.js 完成之後,執行底下指令
node test.js
// print: ok
輸出結果為 ok。
這個結果是有點迥異, a 為 Number, b 為 String 型態,兩者相比較,應該是為 false 才對,到底發生什麼事情?
這其中原因是,在判斷式中使用了 == , JavaScript 編譯器,會自動去轉換變數型態,再進行比對,因此 a == b 就會成立,如果不希望轉型產生,就必須要使用 === 做為判斷。
if (a === b) {
    console.log('ok);
} else {
    console.log('not ok');
}
// print: not ok

轉型

如果今天需要將字串,轉換成 Number 的時候,可以使用 parseInt, parseFloat 的方法來進行轉換,
var a='123';

console.log(typeof parseInt(a, 10));
使用 typeof 方法取得資料經過轉換後的結果,會取得,
number
要注意的是,記得 parseInt 後面要加上進位符號,以免造成遺憾,在這邊使用的是 10 進位。

後記

在本篇中,先講解變數的宣告,以及 Boolean, Number, String 幾種形態,以及 if 判斷式怎麼使用,在 JavaScript 這種弱型態的語言當中,有些時候會因為自動轉型造成 debug 的麻煩,因此也稍微提到在實際開發可能會遇到的問題。
前面基本型態有提到 null, undefined ,明天我們繼續聊聊這兩種在 JavaScript 型別中,難以判定的型態。

留言

這個網誌中的熱門文章

npm 還可以看影片,沒想到真的有人這麼做

 還真的有人做這件事情, 庆余年2剛上線,有一位小哥竟然利用 npm 包的機制,將整套高清視頻都搬上來了。 https://x.com/fengmk2/status/1791498406923215020 圖片來源, https://x.com/fengmk2/status/1791498406923215020/photo/1 此 Package 出處 https://www.npmjs.com/package/lyq2?activeTab=versions 截圖留念, 機制說明 NPM(Node Package Manager)是一個流行的 JavaScript 軟件包管理器,用於管理和分發 Node.js 應用的依賴。它允許開發者將自己的代碼打包成「包」,並上傳到 NPM 的公共註冊表,供其他開發者下載和使用。這個過程通常包括以下步驟: 創建 NPM 包 :開發者將自己的代碼和相關文件打包成一個 NPM 包。 上傳到註冊表 :將包上傳到 NPM 的公共註冊表。 下載和使用 :其他開發者可以通過 NPM 命令行工具下載並安裝這些包。 這位小哥利用這一機制,可能是通過將整套高清視頻文件打包成 NPM 包並上傳到公共註冊表。其他人只需通過簡單的 NPM 命令即可下載這些視頻文件。 影響 版權問題 :這種行為涉及明顯的版權侵犯。高清視頻通常受到版權保護,未經授權的分發和下載都是非法的。 NPM 註冊表的可靠性 :這類內容的出現可能會損害 NPM 註冊表的可靠性和聲譽。NPM 註冊表是開發者分享和使用代碼的重要平台,如果充斥著這些不合法的內容,會影響其公信力。 潛在的安全風險 :將視頻文件偽裝成 NPM 包可能會帶來潛在的安全風險。下載這些包的用戶可能會無意中下載到惡意軟件或其他有害內容。 技術濫用 :這一行為展示了技術的濫用,原本為了方便開發者分享和使用代碼的機制,被用來分發非法內容,會對整個開發者社區造成負面影響。 歡迎留言給我,讓我們得到更多討論,一起回饋更多可能。 如果對於技術架構或者技術開發有相關需要顧問教育訓練服務或專案開發,聯絡方式如下,或者是與皇漢科技 EXMA-Square 進行聯繫。 FB: https://www.facebook.com/clonncd/ Twitter: https://twitter.com/clonncd 熱血漢誌: htt

面試者如何挑戰大工程師時代來臨?

面試者如何挑戰大工程師時代來臨? 全世界都在倡導轉職成為工程師,似乎轉職成為工程師就成為職場的救贖,真的是如此嗎?讓老衲來杠給各位聽。 最近有位好久不見的小朋友,是 2000 年出生的小蔡,對於即將面臨到面對職場的挑戰開始關心起技術,他開始尋找比較適合自己的領域,同時也開始在思考到底為了接下來的就職小蔡該如何準備。 詢問我說是不是可以考慮軟體開發工程師這條路線 對於他的詢問,反而引起我的注意, 這讓我開始思考並映射於最近招募的經驗,軟體開發此領域是不是對於每個人都是可以擔任的職啀,這邊分享一些自己的看法希望對各位有所幫助。 全民工程師這件事情 在全球景氣低迷的狀況下,的確特別在這一年大家會很有感覺萬物齊漲,薪水不漲,薪資就是一直停滯不前。 很多時候,在不同的領域中,會發現整個薪資就算是擔任了管理職務主管你也會面臨到薪資的強大屏障在自己面前。 這個時候, 軟體工程師年薪百萬口號 似乎就成了一種救贖。 好像成為了工程師就可以達到年薪百萬,在家輕鬆工作,不用打卡也不用受到風吹雨淋,隨時想工作就可以工作,每個月又有固定薪水入帳,感受到類財富自由,人生的美好。 如果能夠爭取到跨國公司的職位,這份薪水有可能還可以上看每個月十多萬以上,甚至是往上也是極度有可能的事情,人生美好層次又再度提高了起來。 但這件事情是真的每個人都可以達到嗎? 還是這就是另外一種性存者偏差呢? 亦或者這些人其實是金字塔頂端的小眾? 每份履歷都像是同一種履歷 最近在最近幾年在面試工程師的時候特別會看到許多轉職者,一開始履歷裡面看到相關的作品一開始會覺得十分的驚艷, Wow, 現在的新手就可以做到如此精美的畫面,這些畫面是我當初用 Bootstrap 也做不出來的東西,許多的互動體驗好的一個不行,做出來的頁面配色和對齊也是極致。 但是隨著時間推移,多看了幾封履歷之後,就會發現在各大技術養成學院出來的學生履歷成果內容如出一轍,在面試的過程中也會詢問許多關於框架的底層概念,和比較技術觀念的時候,甚至是許多框架的核心概念,就很容易露出馬腳。 很多面試者會 一問三不知 ,透過許多引導,但殘酷的是連關鍵字是什麼都也無法推敲出來,更不用說在小組裡面到底怎麼樣合作,許多不同線上產品的比較,使用者流程,使用者後面的互動邏輯等,幾乎是風吹一片倒,只能

初級工程師的迷霧:解析開發中常見的困擾與挑戰

在我和工程團隊的共事歷程中,我注意到初級工程師經常遇到的問題。這些問題,無論在面對簡單或複雜的挑戰時,都能體現出來。歸納起來會有常見以下幾個面向。 簡單的問題 發現許多初級工程師在面臨簡單或複雜的問題時,常有可能會遇到困難,時常會有一種繞圈圈的氛圍, 常見問題分別有, 問題本質 首先是對於問題本質上並沒有釐清完成的目標,以及問題本身是要解決什麼樣的商業問題,客戶問題,導致於因為總總原因,做了 scope 過大,或者,花了過多時間進行 over design 的問題發生。 過度依賴套件 發現在新手開發中,會發現為了解決單一問題,卻引用了一大包的 libary 或者引用了不適合此問題的套件。在求解的過程中,容易導致要解決套件的問題,而忘記了要解決的問題是什麼。 複雜的問題 我們在面對複雜的問題時,經常會因為缺乏策略與經驗而感到困惑,反而在處理看似簡單的問題時,卻可能因為過度依賴套件或缺乏組合技巧,而陷入泥淖。不論是複雜或是簡單的問題,我們都需要找到更有效的解決方式。 不論是經常過度依賴套件求解,又或者複雜的問題不知道如何拆解。因此導致新手可能會感到無所適從,不知道如何運用組合技巧。因此,他們往往在處理看似簡單的問題時,容易陷入困境,導致專案的時程延宕。 特別是各自工程師都有開發壓力時,身為新手開發者就更難與資深開發者進行討論,從中汲取前輩的經驗,轉化成自身的價值發生。 解決的方向 上述的問題,自己再開發的時候也或多或少會發生,當然在新入門者更是容易深陷其中,不知如何自拔。 除了參與社群,從傾聽到互動的過程中,從前輩的經驗進行思考及內化的過程。 在 AI Generated 時代,我們可以透過 LLM 透過適當的思考方式和問答過程,逐步的逼近答案,也許是一條可以進行的道路。 這裡,會以透過內部訓練的經驗,提出如何以 ChatGPT 這樣的工具為例,提升對於新手工程師的幫助。 透過 ChatGPT,我們可以解決許多類似的問題。例如,我們可以透過 ChatGPT 建立一個問答系統,進行問題分析,或是請 ChatGPT 提出最適合的工具和方法來解決問題,尤其是那些可以透過使用基礎 function 就能處理的簡單問題。這不僅能讓我們避免過度依賴套件,更能發掘並利用基礎工具的能力。 工商時間 7/3 (週