部落格
KomuraSoft LLC 針對網站製作、SEO、Google 廣告運用、Windows 開發、既有資產活用與故障調查，分享可在實務中活用的觀點。
全站 AI 搜尋
搜尋關鍵字會傳送至 Cloudflare AI Search 以產生結果,請勿輸入個人資料。
-
ADR(Architecture Decision Record)入門 ── 在小規模開發中留下「為何採用此設計」的最小做法
程式碼不會說明「為什麼這樣做」。本文說明如何用ADR(Architecture Decision Record)以「1個決定=1個檔案」的Markdown留下設計判斷的理由,並附上範本、該寫/不該寫的判斷表與實例。
-
DLL・COM 介面的向後相容性 ── 哪些變更會破壞呼叫端的判斷表
DLL 或 COM 元件的哪些變更會破壞呼叫端？本文整理二進位相容・原始碼相容・行為相容三層，依變更內容列出判斷表、COM 介面不可變的鐵則，以及 semver 的運用方式，作為實務指南彙整。
-
為業務應用程式的 DB 結構做版本管理 ── 防止「各客戶端 DB 不一致」的遷移實踐
為分散在各客戶端的業務應用程式 DB 結構做版本管理的實務指南。整理 PRAGMA user_version 與前進遷移的 C# 實作、EF Core Migrations・DbUp・自行實作的判斷表，一直到兩階段發佈。
-
WinForms / WPF 應用程式的 CI/CD 實務 ── 用 GitHub Actions 把從建置到簽章・發布全部自動化
本文整理用 GitHub Actions 為 WinForms / WPF 應用程式建置 CI/CD 的實務指南，內容涵蓋在 windows-latest 上進行建置+測試的最小 YAML、以標籤驅動的版本編號、透過 signtool 整合簽章，以及依 MSI/MSIX/ClickOnce/xcopy 分類的 C...
-
省力化投資補助金能否讓FAX收單網路化 ── 使用一般型的收發訂單系統投資思路
FAX 收單的網路化・自動匯入,有可能成為中小企業省力化投資補助金(一般型)的檢討對象。本文說明目錄訂購型與一般型的差異、收發訂單系統為何符合省力化投資、加薪要件等注意事項。
-
為沒有測試的遺留業務應用程式安全地動手修改 ── 特性化測試與重構的實踐
為了在沒有測試的業務應用程式上安全地進行修改，本文以 C# 為例，說明固定目前行為的特性化測試（黃金主檔法）步驟、建立接縫（seam）的方法，以及不將重構與功能新增混在一起的運用規則。
-
別忘了先決定「要幾秒才滿意」── 用 IPA「非功能要求分級」整理非功能需求
「速度太慢」「故障應對超出預期」等糾紛，大多源自忘記事先決定非功能需求。本文以發包方也能理解的方式，解說 IPA「非功能要求分級」的六大項目、分級表與模型系統的使用方法，以及現實可行的活用方式。
-
使用補助金的系統開發推進方式 ── 從核准決定回推的時程與事業計畫書製作實務
使用補助金的系統開發，推進方式與一般開發有所不同。本文從實務角度解說以核准決定日為起點的回推時程、獲選與核准決定的差異、為核銷撥款做準備的資金周轉，以及事業計畫書製作的分工。
-
委託開發的規格書，維持 Excel 就好嗎 ── 作為交付物的格式選擇方式
委託開發中交付的規格書・設計文件，維持 Excel 方格紙的形式真的好嗎？本文從驗收・維護的角度整理 Excel 規格書的問題點，並解說從 Word 或 Markdown 生成等能夠成立為交付物的格式選擇方式。
-
系統開發外包能否使用補助金 ── 依目的分類的制度地圖與發包前應了解的陷阱(2026年度版)
系統開發外包能否使用補助金？本文從發包方的角度，整理「IT導入補助金無法用於客製化開發」的原因、以ものづくり補助金為代表依目的分類的制度地圖，以及核准決定前禁止發包這項陷阱。