編譯 | 云昭
這周一，小編偶然看到了一篇角度很奇特的、有關(guān)日本代碼風(fēng)格的文章。
雖說現(xiàn)在 Vibe Coding 盛行，很多老鐵們都不那么關(guān)注代碼本身了，但若要真的讓 AI 工具編寫含金量組足夠的代碼，反而對于開發(fā)者的“代碼審美”提出了更高的要求。
這篇文章的作者是一位老鳥后端工程師 Sohail Saifi，也在用各種 AI Coding 工具。近三年里他研究了日本和硅谷程序員的代碼風(fēng)格，這篇文章就是研究成果的總結(jié)。
他發(fā)現(xiàn)：日本程序員的 coding style 非常不同，而且更穩(wěn)定、更有效比如，他們甚至?xí)屢粋€團隊花兩天時間去修復(fù)一個僅影響 0.1% 用戶的邊界問題。
“因為他們把代碼當作豐田凱美瑞來對待，而不是特斯拉?！?/p>
“在西方，寫代碼是為了快速上線功能；在日本，寫代碼是為了讓系統(tǒng)運行幾十年。上線只是開始?！?/p>
文章一經(jīng)發(fā)布，就很快引起了網(wǎng)友的熱議，贏得了高達 6100 的點贊，173 條評論。
圖片
評論中一方面，許多硅谷程序員在評論中表示不服，另一方面，很多網(wǎng)友對于日本的這種“快即是慢”的代碼寫作風(fēng)格表示認同。
話不多說，讓咱們撇看心中的成見，一起來看看這篇熱文。
日本軟件系統(tǒng)為什么最穩(wěn)定
在過去三年里，我一直在研究日本的軟件開發(fā)實踐。而我的發(fā)現(xiàn)，完全顛覆了我對編寫代碼的認知。
當西方程序員還在追逐最新的 JavaScript 框架、為縮進到底用 Tab 還是空格爭論不休時，日本程序員卻在悄悄打造全球最穩(wěn)定、最可維護的軟件系統(tǒng)之一。他們的做法甚至可能會讓硅谷程序員翻白眼。
秘訣是什么？他們把代碼當作豐田凱美瑞來對待，而不是特斯拉。
一種改變一切的哲學(xué)
Monozukuri：「制造之道」
在日本，有一個理念叫做 monozukuri（ものづくり），意思是「制造之道」或「匠人精神」。它不只適用于實體產(chǎn)品的制造，更是一種強調(diào)工藝、持續(xù)改進、并對創(chuàng)作過程本身引以為傲的哲學(xué)。
ps：Monozukuri，直譯就是制造東西的意思。在現(xiàn)代語境下，Monozukuri 意指一種精益求精的工匠精神，是對制造過程、產(chǎn)品質(zhì)量、團隊協(xié)作與持續(xù)改進的高度重視和執(zhí)著追求。
日本程序員不是在寫代碼，他們是在“雕刻”代碼。
我曾采訪日本某大型科技公司的高級工程師中村宏（化名），他這樣說：
「在西方，寫代碼是為了快速上線功能；在日本，寫代碼是為了讓系統(tǒng)運行幾十年。上線只是開始?！?/p>
這套心態(tài)的轉(zhuǎn)變非常深刻。與其“快速試錯”，他們更傾向于“慢慢構(gòu)建，盡量不出錯”。
Kaizen：「每天進步 1%」
你或許聽說過 kaizen（改善）這個詞，原本用于企業(yè)流程優(yōu)化。但日本程序員將其直接應(yīng)用到代碼中。
他們不會搞大刀闊斧的重構(gòu)或“技術(shù)債償還沖刺”，而是每天做一點微小的改進。每一次提交，都改善一點點。
來看例子：
// 西方式寫法：計劃下一次迭代時重構(gòu)整個模塊
function processUserData(users) {
// 200 行越來越復(fù)雜的代碼
return results;
}
// 日本式寫法：今天改進 1%，明天再來一點
function processUserData(users) {
const validUsers = filterValidUsers(users); // 提取了一個小函數(shù)
return processValidUsers(validUsers);
}日本程序員不會等待“批準”來改進代碼，也不搞“技術(shù)債沖刺”。他們就是每天持續(xù)優(yōu)化一點點。
「豐田生產(chǎn)方式」的程序員版本
Just-In-Time：「按需開發(fā)」
他們借鑒了豐田著名的生產(chǎn)系統(tǒng)：Just-In-Time（JIT）按需制造。與其預(yù)先構(gòu)建可能永遠不會用到的功能，他們只在真正需要時才構(gòu)建。
// 西方式寫法：預(yù)先構(gòu)建一堆可配置選項
class DataProcessor {
constructor(options = {}) {
this.enableCaching = options.enableCaching || false;
this.enableValidation = options.enableValidation || false;
this.enableLogging = options.enableLogging || false;
this.maxRetries = options.maxRetries || 3;
this.timeout = options.timeout || 5000;
// 還有15個“以防萬一”的選項
}
}
// 日本式寫法：先解決今天的問題
class DataProcessor {
process(data) {
return this.validateAndTransform(data);
}
}「未來的復(fù)雜性來了再加，現(xiàn)在只管把今天的事情做好?！?/p>
Jidoka：「停線精神」
在豐田工廠，任何工人都可以因發(fā)現(xiàn)瑕疵而按下“急停按鈕”，整個產(chǎn)線會立刻停下。日本的開發(fā)團隊也遵循這一原則：
一旦發(fā)現(xiàn)問題，全體停工，優(yōu)先解決。
沒有“下個迭代修吧”，沒有“先上線后補丁”。
我曾見過一個團隊花兩天時間去修復(fù)一個僅影響 0.1% 用戶的邊界問題。問他們?yōu)槭裁床缓雎詴r，組長回答：
「一旦我們默認小問題無所謂，就會開始容忍缺陷。久而久之，缺陷會變成常態(tài)?！?/p>
所以他們的系統(tǒng)幾乎沒有線上 bug。
語言劣勢，變成可讀性優(yōu)勢
簡單的變量名
你可能以為日本程序員用全日文變量名，其實并不是：
// 想象中的寫法
const ユーザー = getUsers();
const データ = processData(ユーザー);
// 實際寫法
const userList = getUsers();
const processedData = transformData(userList);
// 注釋用日文解釋業(yè)務(wù)邏輯
// 業(yè)務(wù)ロジック: ユーザーの権限を確認してからデータを変換する因為大多數(shù)日本工程師的英文并不流利，他們傾向于使用更簡單、直白、沒有炫技的變量名。這反而提升了可讀性。
| 注釋文化
他們大量寫注釋。不是因為代碼差，而是因為他們把注釋當作給未來維護者（可能是五年后的自己）寫的文檔。
// 西方式寫法：代碼自解釋
const result = users.filter(u => u.age >= 18 && u.status === 'active')
.map(u => ({ id: u.id, name: u.name }));
// 日本式寫法：加注解釋業(yè)務(wù)含義
// ビジネスルール: 18歳以上のアクティブユーザーのみを?qū)澫螭趣工?const eligibleUsers = users.filter(user => {
const isAdult = user.age >= 18;
const isActive = user.status === 'active';
return isAdult && isActive;
});
// 畫面表示用のデータ形式に変換
const displayData = eligibleUsers.map(user => ({
id: user.id,
name: user.name
}));結(jié)果是：即使 10 年后，這段代碼依然能維護下去。
軟件開發(fā)中的「七大浪費」
借鑒豐田制造理論，日本程序員總結(jié)出“七種浪費”：
- 未完成的工作：寫了但沒測、沒部署的代碼。
- 多余的功能：沒人用的 feature。
- 反復(fù)學(xué)習(xí)：因為缺文檔或代碼混亂而重復(fù)理解。
- 交接：不同團隊之間的“扔鍋”式協(xié)作。
- 等待：審批、代碼審查、依賴延遲。
- 任務(wù)切換：在多個項目之間頻繁跳轉(zhuǎn)。
- 缺陷：最浪費的就是修 bug，所以他們防患于未然。
「侘寂」寫法：不完美之美，擁抱演化
侘寂（Wabi-Sabi）是一種日本美學(xué)，強調(diào)“不完美之美”。日本程序員不追求完美代碼，而是寫“可逐步進化的代碼”。
小編這里解釋下“侘寂”（日語：わびさび / 發(fā)音：wabi-sabi），是日本美學(xué)中極為核心、也極富哲思的一個概念，漢語中很難有一個精確的中文對應(yīng)詞，大致是“不完美之美”的意思?？梢赃@樣體感一下，比如：
一只有裂痕但修補過的陶碗，比一只嶄新的碗更有溫度。因為有歲月、使用過的痕跡。等等。
// 西方寫法：預(yù)判未來需求
class DataValidator {
validate(data, rules, options, context, metadata) {
// 太多參數(shù)以應(yīng)對所有情況
}
}
// 日本寫法：從簡單開始，未來再擴展
class DataValidator {
validate(data) {
if (!data) returnfalse;
if (!data.email) returnfalse;
returntrue;
}
}他們知道需求會變，與其預(yù)判未來，不如為“變化”做好準備。
「反省會」：持續(xù)反思的文化
每個項目結(jié)束后，他們都會舉行 hansei（反?。h。不是為了追責，而是集體回顧：“下次如何做得更好？”
我曾旁聽一場反省會，他們花了 30 分鐘討論一個函數(shù)。不是因為它出錯，而是它“可以更清晰”。
他們提出了三個改進點：
- 改變量名更清楚
- 加一句注釋解釋業(yè)務(wù)含義
- 拆出一個小工具函數(shù)
看似微不足道，但積累 100 次這樣的小改進后，代碼庫就會煥然一新。
結(jié)果不會騙人
任天堂：30 年前寫的代碼仍在用。不是因為他們懶得重寫，而是代碼寫得足夠好，根本不用重寫。
對比數(shù)據(jù)（日本團隊 vs 西方團隊）：
- 生產(chǎn)環(huán)境 bug 少 60%
- 維護時間減少 40%
- 新功能交付快 25%
- 開發(fā)者滿意度高 80%
為什么日本式代碼更有效？
復(fù)利效應(yīng)
每天 1% 的改善會復(fù)利增長。西方團隊每 3-5 年重寫系統(tǒng)，日本團隊幾十年持續(xù)演化。
可持續(xù)節(jié)奏
沒有“996”或“爆肝上線”，他們保持可持續(xù)節(jié)奏，做出更理性的決策，寫出更持久的代碼。
長遠思維
當你希望代碼運行 20 年，而不是 2 年時，你的選擇就會不一樣：
- 你會選擇清晰，而不是聰明
- 你會選擇可靠的技術(shù)，而不是最新的潮流
如何把這些哲學(xué)用到你的代碼中？
- 從 Kaizen (改善)開始：每天改善一點點。堅持 30 天。
- 實踐 Jidoka（停線精神）：發(fā)現(xiàn) bug 別只修復(fù)，要找出防止它再次發(fā)生的方法。
- 擁抱侘寂：別追求完美，寫出可演化、易維護的代碼。
- 做 Hansei（反?。好看蔚Y(jié)束，花 30 分鐘團隊反思“什么可以更好”。
真正的挑戰(zhàn)是文化轉(zhuǎn)變
技巧很容易學(xué)，但從“上線第一”切換到“長久為先”，才是最難的部分。
日本程序員懂得一個簡單的道理——最快的“快”，是從來不用“慢”下來。
而不被迫慢下來的唯一方式，就是一開始就別留下讓你慢下來的“技術(shù)債”。
你的代碼不應(yīng)該像一家瘋狂擴張的初創(chuàng)公司，而應(yīng)該像一座打理良好的日式庭院——穩(wěn)、靜、美、可持續(xù)。
評論區(qū)炸鍋：太保守了，這不是日本獨有的
就如開頭所介紹的，這篇文章引起了許多網(wǎng)友的討論。有人共鳴，有人質(zhì)疑。共鳴的朋友站出來說：我就是這樣寫代碼的程序員！
圖片
質(zhì)疑的網(wǎng)友則回應(yīng)說：其實這些思維風(fēng)格也存在于西方。
圖片
還有一位網(wǎng)友認為：其實上面說的50%的理念，其實都寫在敏捷宣言里。
圖片
甚至有網(wǎng)友直接開懟，表示：日本模式也有很大的局限。
現(xiàn)實中并沒有什么廣泛使用的日本開發(fā)的軟件。內(nèi)部使用倒是有（比如豐田）。因為他們?nèi)狈δ欠N“大膽試錯、獨立探索”的文化。還有一種“尊重權(quán)威”的氛圍，讓人們不敢質(zhì)疑現(xiàn)狀……
圖片
另有網(wǎng)友質(zhì)疑：如果日本方法這么好，為什么他們沒做出全球爆款？其實任天堂就是活例。問題也許不在“模式”，而在語言、市場與文化壁壘。
當然，勸架的網(wǎng)友顯得更加睿智：
我現(xiàn)在腦海里浮現(xiàn)出兩個跨洋而立的公司，如同兄弟一樣聯(lián)手：西方的敢于質(zhì)疑與挑戰(zhàn)，東方的古老智慧則以清晰和諧協(xié)調(diào)一切。
各位網(wǎng)友表面上看是實在對比日本和西方程序員的編寫風(fēng)格，其實是在探討兩種編程文化：一種是穩(wěn)定壓倒一切，另一種是大膽創(chuàng)新。跟國別關(guān)系不大。
這其實就是企業(yè)版的 slow is smooth, smooth is fast。
所以，小編在最后把問題留給評論區(qū)的大佬們，各位認同哪種風(fēng)格？你見過像任天堂那樣 30 年都不用重寫的代碼嗎？在 Vibe Coding 時代，哪種風(fēng)格更值得提倡呢？
歡迎拍磚。
