前言
當我們談論「Windows 程式設計」時，通常包含兩個層面：
- 執行程式的「運行環境」：探討程式如何在 Windows 系統上運作。
- 撰寫程式的「開發環境」：著重於如何利用 Windows 工具進行開發。
本文將側重於後者的介紹。對於程式設計的初學者而言，深入熟悉並掌握自己的開發環境，是奠定扎實架構的第一步。
把 Windows 當成運行環境 (Runtime Environment)
在開發應用程式時，必須根據程式目的與目標使用者族群，選擇最合適的使用者介面（UI）。世界上沒有一種介面能夠完美適用於所有的核心情境。
桌面應用程式：以圖形介面為核心
Windows 的系統文化一向以圖形介面（GUI）為重。雖然近年來微軟引入了 WSL（適用於 Linux 的 Windows 子系統），大幅補足了自身在命令列環境的短板，但絕大多數的終端使用者仍習慣操作視覺化視窗。因此，原生的 Windows 應用程式至今依然以圖形介面為主主流。
網頁應用程式：以瀏覽器為媒介
當我們開發網頁程式時，實際的部署與執行目標是 Windows 上的網頁瀏覽器（Web Browser）。由於現代瀏覽器大都具備跨平台特性，因此在撰寫網頁程式時，程式碼與 Windows 底層系統的關聯性並不高。
行動應用程式：以手機為目標
同理，當我們開發行動應用程式（Mobile App）時，最終的運行目標是智慧型手機（如 iOS 或 Android 系統）。在此情境下，Windows 僅作為開發工具，程式運行本身與 Windows 系統的關聯性極低。
把 Windows 當成開發環境 (Development Environment)
當開發者將 Windows 作為開發環境時，首要任務是選擇合適的程式語言，並建置該語言的開發生態系。這類技術細節通常會隨語言而異，甚至隨著語言版本的更迭而有所變動。
跨越語言的共通核心知識
儘管各語言的建置細節不同，但有許多底層開發知識是完全共通的，例如：
- 檔案系統與路徑觀念
- 命令列環境的操作
- 系統環境變數與設置
- 文字編輯器與整合開發環境（IDE）
- 版本控制系統（如 Git）
當你掌握了多種語言後，就會發現這類「基礎建設」的知識一通百通，對任何語言的開發都一體適用。
開發環境與目標環境的解耦
在 Windows 上進行開發，並不意味著程式最終必須運行在 Windows 上。舉例來說，開發者可以在 Windows 的 WSL（Linux 子系統）中撰寫應用程式，並直接部署到雲端 Linux 伺服器。在這個過程中，整個開發與部署流程幾乎與原生 Windows 的命令列環境沒有交集。
原生 Windows 程式的跨平台開發建議
即使目標是開發原生的 Windows 程式，也可以利用 MSYS2 等工具來移植 Unix / Linux 專案，不一定非要依賴 Windows 原生的命令列工具（如 PowerShell 或 CMD）。
在處理自動化與建置腳本時，有以下兩點核心建議：
- 避免平行維護兩套腳本：不要為了 Windows 和 Linux 分別寫一套功能相同的自動化腳本。建置腳本屬於內部工具，與產品核心功能無關，重複維護會造成巨大的時間成本。
- 採用共通技術鏈：建議採取 Unix 優先（Unix-first） 的腳本策略，或是直接引入 CMake、Gradle 這類現代跨平台建置工具，來達到「一份腳本，跨平台通用」的效果。
選擇程式語言
選擇程式語言是一個老生常談的主題，且實際的選擇往往非常個人化。與其由琴子直接告訴讀者該選什麼，不如提供方向，讓讀者根據自身需求，自然找到最適合的語言。
命令列腳本語言 (Shell Script)
這類語言主要用於撰寫自動化建置與維運工具，與產品本身的核心特性幾乎無關。
自從筆者將開發環境轉移至 WSL 後，編寫 Windows 原生腳本的機會已大幅減少。以下僅針對過往的實務經驗給予建議：
- Batch：幾乎無法作為主要的生產力工具。其語法過於老舊，往往需要使用奇特的撰碼技巧，才能勉強達到 POSIX sh 的基本功能。
- PowerShell：如果要管理 Windows 伺服器，這是必學工具。除此之外，建議直接忽略它。其獨特的「物件串流」特性不符合直覺，若非頻繁編寫，極難維持記憶。
通用型腳本語言 (General-Purpose Scripting)
這是程式初學者的主戰場。這類語言兼具命令列自動化與應用程式開發的能力。
傳統上，微軟在此領域的發展並不突出。然而近年來，微軟做過最成功的軟體成就之一便是 TypeScript，它如今已成為 JavaScript 的實質延伸標準。如果有開發網頁程式的需求，TypeScript 屬於必學技術。
- 若想同時兼顧 Unix 與 Windows 環境，Python 與 TypeScript 是目前最顯而易見的高效益方案。
- 如果主要在 WSL 環境下工作，Perl 與 Ruby 依然相當實用
- 在內容管理系統（如 WordPress）與傳統 Web 領域，PHP 仍佔有一席之地，但若要拓展至其他領域，則建議直接轉換技術棧。
應用程式語言 (Application Languages)
這是企業技術棧（Enterprise Tech Stack）的主戰場，涵蓋了桌面程式、行動 App 以及後端系統的開發。對於初學者而言，在程式尚未面臨真正的效能瓶頸之前，通常不需要過早深入這個領域。
目前企業級市場傳統上仍由 Java（含 Kotlin） 與 C# 兩大陣營瓜分，而近年來 Golang 的迅速崛起也相當值得關注。
系統程式語言 (System Languages)
除非需要編寫核心演算法、追求極致效能，或是需要將程式碼打包成動態連結函式庫，否則不需涉足此領域。除非有極為明確的理由，不建議將整個應用程式都用系統語言撰寫，這會導致開發時程拉長。
以下列出一些常見技術棧：
- C：除非是投入嵌入式系統（Embedded Systems）開發，否則不應手刻 C 程式碼。由於缺乏現代基礎組件，很多輪子都要自己造，開發成本極高。
- C++：對於習慣 C 生態圈的開發者來說，它是兼具底層效能與高階抽象語法的選擇。
- Pascal：語言本身的嚴謹特性非常好，但現代生態系相對弱小。選擇它需要耐心地查資料，如今已鮮少作為商業開發的主力語言。
- Rust：作為兼顧記憶體安全的 C++ 替代品，近年備受推崇。但開發者需要花費大量精力適應編譯器，整體的開發時程通常偏長。
Windows 作為開發環境的議題
Windows 本質上是為終端使用者設計的作業系統，若將其作為開發平台，操作體驗上往往不若 Unix 順暢。相對地，Unix 的核心假設是「使用者本身即是開發者」，因此設計上極具靈活性，卻也造成一般使用者難以上手的門檻。
本節將從開發者的視角，深入探討 Windows 作為開發平台時會面臨的幾大核心議題。
命令列環境與工具鏈的弱勢
由於 Windows 長期著重於圖形介面的發展，曾有很長一段時間忽略了對命令列環境的改良；反觀 Unix 的命令列工具生態系則極其豐富。
- 工具與腳本的連動性：功能強大的命令列腳本語言，必須搭配豐富且標準化的命令列工具鏈（如 grep, awk, sed 等）才能發揮綜效。Windows 在這兩者上過往皆處於弱勢。
- 微軟的折衷方案：近年微軟引入了 WSL，這讓渴望強大命令列環境的開發者得以直接調用原生 Linux 資源。嚴格來說，這個歷史痛點並非真正「解決」了，而是巧妙地「繞過去」了。
與 C 語言生態圈的整合斷層
不同的語言技術棧，對系統底層的依賴程度截然不同：
- 託管架構（Managed Code）：像 Java 或 .NET (C#) 這類平台，其虛擬機與執行時期環境本身就具備相當優異的效能。即使完全不依賴原生 C 語言函式庫，也能獲得高效的執行速度，因此這類語言與作業系統底層的依賴度較低。
- 高階腳本語言：像 Perl、Ruby 甚至是 Python 等語言，其許多高效能模組實質上是包裝了以 C 語言實作的底層函式庫。若純粹依賴腳本邏輯運算，效能往往偏慢。因此，這類語言對作業系統的 C 執行時期環境 高度依賴。
然而，Windows 對 C 語言編譯與運行環境的整合度遠不及 Unix。這項缺陷連帶波及了上述依賴 C 底層的高階語言。
生態圈碎片化與編譯困局
為了克服 Windows 缺乏統一 C 環境的問題，導致了以下現象：
- 重複造輪子：在 Windows 上，許多高階語言的安裝檔都會各自重新打包一套 MinGW 工具箱 與常見的 C 函式庫。這導致開發者的硬碟裡往往重複下載了多份結構相同的開發工具。
- 隱藏的編譯門檻：社群熱門套件通常會提供預先編譯好的二進位版本，日常開發時這些問題往往被隱藏了起來。然而，一旦開發者需要在 Windows 環境下從原始碼開始編譯軟體或函式庫時，往往會面臨極其繁瑣的配置過程。
結語
對現代開發者而言，Windows 作為開發平台雖有其歷史包袱，但隨著 WSL 的成熟與跨平台建置工具的普及，作業系統本身的邊界已逐漸模糊。
理解開發環境與執行環境的解耦，並學會借力使力，如利用 Unix 優先思維來補足 Windows 的短板，是每個 Windows 平台上的程式設計者從「跨入門檻」到「走向專業」的必經之路。