文章

有一點說法我覺得是沒錯的，那就是未來，尤其是現在的 AI 時代，招聘的整個方式和體系都一定會逐漸改變。因為所謂的古法程式設計，它帶來的收益會越來越低...

• ai運用

我之前提到過 基於過程的質量控制 ，其實從 How Anthropic runs large-scale code migrations with Claude Code | Claude by...

• ai運用

談一下我自己對於「到底要不要看程式碼」的看法吧。 其實對我來講，我是主張「不要一行一行去讀程式碼」的立場的，這點在基於過程的質量控制裡面就談到過...

• ai運用

rust本身比較有意思的地方是，他是一個強型別-記憶體安全的語言，所以說很多東西都會規定的很死，通過一定的動態犧牲，帶來了較大的安全性和穩健性...

• 隨筆

我最近一直在想rust的特性，這種強編譯時驗證的語言可以把大部分潛在問題都攔截在編譯期，意味著哪怕不寫測試，它只要寫出來天然就是一個自帶測試的語言，這種高度可驗證的特性讓其非常適合 ai 時代...

• ai運用

分散式的關鍵問題在於使系統在運作中逐漸收斂到一致，核心有三個因素：設定的預期校準點、觀測、誤差。我們希望的是縮小貫徹和校準點之間的誤差，因此每次測量後就可以得到應該修正的方向，然後不斷迭代收斂...

• 設計模式與架構

我對單一職責（SRP）的啟發式理解是「能單測，沒有副作用，一個函式只做一件事」，當然我知道這不完全嚴謹。但作為快速判斷我覺得是好的。 能單測...

• 設計模式與架構

我現在越來越認為， Agent take 開發需要依賴於一套足夠的質量控制過程來保證。這就像製造業中的 QA 一樣，對關鍵部位進行抽樣，或者是對整個流程控制進行管控...

• ai運用

將複雜軟體設計類比到生物上，確實極有啟發性。尤其是複雜系統的自組織原則——既然對於一個大型的生物系統來說，它可以在不需要掌握全局資訊的情況下就運作良好...

• 設計模式與架構

level-triggered 跟 edge-triggered 的區分還挺有意思的，這是非同步I/O中的重要概念，指的就是觸發的模式...

• 設計模式與架構

pnpm workspace 是個很有意思的用法，可以把各個子目錄正式化為統一管理的程式模組，讓各個模組存在轉為可以通過 @xxx/xxx 形式引入的包...

• 設計模式與架構

FROM 的主表一般就是左表，而 LEFT JOIN本質上就是取左表+兩表交集的部分，剩下的右表未交集部分則直接為null；而INNER JOIN則是直接取交集，兩表都有的才返回...

• 隨筆

Andrej Karpathy: From Vibe Coding to Agentic Engineering w/ Stephanie Zhan - YouTube Stop Prompting...

• ai運用

在Al時代，每個程式設計師都活成了自己最討厭的那種team leader: 1.半年不寫一行程式碼，程式設計能力嚴重退化，還自詡「我也是搞技術的」 2.開會的時候把一線開發乾的活全說成是自己的功勞...

• ai運用

抽象是好的，這沒錯，能隱藏複雜實現背後的細節，而只將結果暴露出來——但這一切是有代價的。對於使用者來説，一般情況下我們希望達到的結果是方便和便捷，不需要理解背後的一切即可用一個呼叫解決問題...

• 設計模式與架構

這個有點意思，叫做「語言整合查詢」（Language Integrated Query），可以在C#裡用類似sql的查詢方法，只要是列舉類都可以用這個...

• 隨筆

這就像一個中間截流管，可以説是Observable的中介軟體。裡面預定義了一些RxJS的處理方法，可以讓我們對返回的結果進行截留，然後按我的要求進行一個預處理...

• Angular

Angular有一個地方和React不太一樣，這裡的屬性變動本身就會觸發重新渲染，在React那邊就必須要狀態。而另一個方面則是這裡的服務函式，這個是全局單例，所有元件共享狀態...

• Angular

這是一個專門用來記錄子元件Input變化的類，一般是和ngOnChanges搭配，作為元素傳入方法內。裡面是巢狀的鍵值對，分別是屬性名：SimpleChange（注意少了個s），下面是結構...

• Angular

Observable的pipe那裡説到了供水，但那邊只是被動的供水——如果我想要中間往裡面加水並讓所有吃水者都喝上新的水呢？比如從地下水換成山泉水，帶有甘甜的滋味（嗯......）...

• Angular

通過漸進披露的模式把入口文件作為目錄，然後不斷建立分層索引的模式來進行逐漸的展現。就像OpenAI這篇文章説的一樣，AGENTS.md/CLAUDE.md應該是一份地圖，而不是全面的手冊...

• ai運用

我最近確實是發現了，全端開發確實能讓人洞察到更多東西，尤其是那些前端和後端分別不同的坑和雷點。前端的bug有時候純粹是後端背鍋，比如出錯了卻只説出錯，而完全不提為什麼出錯，導致前端除錯除的寸步難行...

• 隨筆

反射在有些地方看上去有點像是委託，但兩者的差異還是蠻大的。委託的關鍵是編譯器安全，而反射則是犧牲了編譯時的安全檢查，而帶來了執行時的靈活性：它通過字串來呼叫或取到指定的物件...

• 設計模式與架構

angular的設計原則和react最大的差別是，後者基本是state就是一切，但前者會把各種功能包裝好，signal雖然很像state，但實踐中似乎很少直接操作signal...

• Angular

這裡有個坑，這倆是不能並用的，響應式表單內如果要單獨加ngModel，就必須給他加上單獨模式。因為響應式表單本身就自帶雙向繫結，都加的話就會衝突...

• Angular

C#的委託，事實上在DI裡面就已經在用了。假設我定義了一個func型別，叫A，然後在下面A()，這裡雖然我沒顯示寫delegete關鍵字，這就已經是委託了...

• 設計模式與架構

不懂ioc只會把DI用成臃腫的工廠模式——比如XML,JSON,TXT的格式轉換，在裡面new了一堆內容，並用列舉switch來判斷——但完全可以ioc，定義一個泛型，讓外部給入...

• 設計模式與架構

我現在發現，與其將各種狀態都耦合在程式碼內部，不如用資料庫做統一的、共用的持久狀態管理。這樣各個功能模組彼此之間就可以去耦合，而以模組——抽象的單位積木——為存在彼此只關注資料...

• 設計模式與架構

Angular 的這個 Service 看上去用法跟 Hook 是很像的。不過它們最大的差別就是：React 裡的 Hook 只能在元件裡面共享狀態...

• Angular

angular確實是把訂閱者-接收者貫徹始終，包括子傳父在內也是利用了Observable的機制，子層發布一個事件，而父層則訂閲這個事件，等待其觸發後來執行相應的回調...

• Angular

Strangler Fig 是一種寄生植物，會逐漸纏繞並吸取宿主的營養，最終讓宿主枯萎，自己蓬勃生長取而代之，謂之「絞殺」...

• 設計模式與架構

約束（Harness，或者說韁繩、馬鞍，限制馬的工具）工程，是個很有意思的概念，看上去更像是上下文工程的延申——核心的關鍵是把對agent的上下文約束，進展到整個環境約束...

• ai運用

ts這個裝飾器從本質上來說仍然是一個高階函式，和py的裝飾器在使用場景上是差不多的：當我需要給某個物件進行一個「包裝」，但又不想整個重寫這個原有的方法時，那我就要用裝飾器...

• TS

雙向繫結的模板寫法，在Angular裡其實算是個一次性的語法糖，本質上就是一次性繫結資料，資料變動觸發事件回調並更新的操作，給全部封裝在了一起，那就是預設的香蕉盒子寫法。 而這個當然是可以自主控制的...

• Angular

CRTP是個很有意思的東西，全稱是泛型基類（Curiously Recurring Template Pattern），也就是限定子類輸入型別的基類...

• 設計模式與架構

DI的核心點就是定義結構，而這個一般有兩種用法 介面 interface 抽象類 abstract class 核心的關鍵是DI容器需要知道自己處理物件的結構體，這樣才能進行後續處置...

• 設計模式與架構

這倆最大的區別其實就是後者多了一個響應式的現代前端框架——以前是控制器去控制頁面更新，完全要手操，但現在只要資料變更，框架自動接管，這就是響應式更新...

• 設計模式與架構

A家的最新研究其實已經證明了我之前的想法，尤其是跟學習科學結合在一起，我們就會發現：學習新東西的確需要一些「有效的困難」。如果你完全一帆風順，說明這個東西可能不在學習區，或者說你根本沒在學習...

• ai運用

plan 和 sdd 適合的場景是： 你知道該做什麼 或者你相信 AI 會做什麼 用akr的話來說的話，就是這種提前決定好情況和流程的ai使用，最適合情況已知而且非常成熟的情況下來做...

• ai運用

這篇研究也挺有意思的，裡面表明，就算是agents.md這樣的上下文檔案，也不總是什麼都往裡面寫就是最好的。這就是典型的上下文汙染問題...

• ai運用

依賴注入（DI）真的蠻有意思的，本質上來說就是一種更加抽象的封裝，把整個類變得更加通用化或單純化。比如我需要一個轉換器，比起把那些資料直接寫死在裡面，不如從外面傳入——但這裡還只是資料...

• 設計模式與架構

目前來看靜態建構函式就是比較好的辦法了，單例和基類的操作目前有點用不太到，畢竟也沒什麼共享的變動資料，基類的話，只有一個服務，強行去寫反而有點過度設計...

• 設計模式與架構

這個有點意思，本質上也是一種高階函式的運用，即將自己的對外介面暴露為接受一個key和func\<key,V>。這裡的key即是當前func的元素，V是C#型別宣告定義下的輸出型別...

• 設計模式與架構

組合優於繼承的關鍵因素是去耦合，或者説，就像積木一樣的模組，而狀態則通過外部因素給入——大部分情況下采用靜態方法就足夠了，但少數情況下可能需要的是一個組合類，下面許多方法共享同樣的狀態——但是...

• 設計模式與架構

能用「有一個」描述就用組合，只有「是一個」才用繼承。 我對這句話的理解是，如果彼此之間沒有實際意義上的繼承關係和依賴關係，而只是為了程式碼複用，那麼直接採用組合是最好的方法...

• 設計模式與架構

這個地方有點意思，那就是繼承和約束，似乎有一點相通的意思，而且說到底，繼承本身也意味著對結構體本身的繼承，本質就是一種約束...

• 設計模式與架構

依賴注入這種設計哲學的核心依然是圍繞著一個關鍵詞——解耦。介面簡單，核心複雜。抽象對外暴露的就是簡單，而具體的過程則被封裝在實現之中...

• 設計模式與架構

響應式頁面主要指的是資料流的響應，但是對於前端的整個頁面展示來講，它其實是靜態網頁。 像現在比較知名的 SPA（單頁面應用），基本上都是靜態頁面...

• 隨筆

\<T>泛型物件應該是靜態語言中比較難以理解的一個概念。但就其本質而言，它就像是一個佔位符：通過告訴編譯器這裡未來會有某個型別——它既可以是已有的型別，也可以是自定義的型別...

• TS

如果要取得某方法返回值的型別，這裡有一個快速的解法。 typeof A指的就是：獲取後面 A 值的型別。前面那個 ReturnType 是 TypeScript 內建的一大堆型別推斷工具之一...

• TS

解構賦值一般是對某個物件進行使用的。簡單來說，就是將其中的屬性拆分出來，然後將其賦值給局部變數。這個在函式中，有時會寫成一個不是很好讀的形式，但也是使用比較多的，這裡要記錄一下...

• TS

有點意思，claude code用的應該是agent team，而不是單個agent。上層會先梳理需求，然後產生中間 prompt和todo list，最終在將任務分工下去，然後最終匯總...

• ai運用

確實有一種觀點認為全棧工程師雖然很好，但問題是知識只有廣度而沒有深度，不夠專業化。從某種程度上我其實贊同這一點，但另一方面，我認為這種看法只側重了表象，而忽略了其他核心因素： 存在一個職業叫作架構師...

• 隨筆

我知道洋蔥模型：請求全部進來之後，出去時也會從這裡走一段。 中介軟體的話，用我的理解，有點像是 Python 裡面的 @ 裝飾器。在所有函式被呼叫之前都會先走一遍這裡...

• 隨筆

一般的話，微服務之間都有一些相應的微服務框架，其核心點是通過 RPC 通訊進行來回的呼叫。 目前比較成熟的框架有： gRPC 還有阿里家的Apache Dubbo-這個可能更好用...

• 隨筆

我覺得運用LLM的關鍵點是讓自己跳脫出單純的寫程式碼這樣的固化思維——將自己作為一個規劃任務的主管，或者是微操大師去監察任務，而不是單純的讓自己成為一個局外人...

• ai運用

當時用agno主要目的就是實現agent功能： 實際上一開始我們的技術方案裡面沒有這個，最早設想的是單純prompt工程加基於ragflow的知識庫 但客戶突然需求變更，提出了更復雜的查詢和儲存需求...

• 隨筆

防抖很重要，尤其是在前後端有網路IO的情況下，如果使用者每次操作都要往後端發一個請求，那流量費和後端伺服器壓力就會很大。標準處置方法就是加個延遲，使用者在這個時間段內的連續操作...

• 隨筆