代碼整潔之道 程序員的職業素養 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] 羅伯特·C.馬丁（Robert C.Martin） 著，餘晟，章顯洲 譯

圖書標籤:

• 代碼質量
• 代碼規範
• 軟件設計
• 可讀性
• 可維護性
• 編程實踐
• 軟件工程
• 職業發展
• 整潔代碼
• 代碼重構

齣版社： 人民郵電齣版社

ISBN：9787115434159

版次：2

商品編碼：11977659

品牌：異步圖書

包裝：平裝

開本：16開

齣版時間：2016-09-01

用紙：膠版紙

頁數：170

正文語種：中文

編輯推薦

1. 匯聚編程大師40餘年編程生涯的心得體會
2. 闡釋軟件工藝中的原理、技術、工具和實踐
3. 助力專業軟件開發人員具備令人敬佩的職業素養
成功的程序員在以往的工作和生活中都曾經曆過大大小小的不確定性，承受過永無休止的壓力。他們之所以能夠成功，是因為擁有一個共同點，都深切關注創建軟件所需的各項實踐。他們將軟件開發視為一種需要精雕細琢加以修煉的技藝，他們以專業人士的標準要求自己，他們具有職業素養。
軟件開發大師Robert C. Martin在書中介紹瞭真實軟件技藝中的各項原則、技術、工具和實踐，展示瞭怎麼以自豪、自尊和自信的心態進行軟件開發，怎麼取得卓越錶現和豐碩成果，怎麼做到有效溝通和確切估算，怎麼以坦誠的心態麵對睏難，並引導讀者認識到專業程序員肩負的責任重大，闡述瞭什麼纔是程序員的職業素養。
書中的具體內容包括：
● 成為真正的軟件專業人士需要具備哪些條件，如何應對彼此衝突又緊張的進度錶和不近情理的管理人員；
● 如何做到流暢編程，剋服阻塞狀態；
● 如何應對無休止的工作壓力，避免崩潰；
● 如何培養堅持不懈的態度，如何擁抱新的開發範式；
● 如何管理好時間，避免身陷泥潭無法自拔；
● 如何培育有利於程序員和開發團隊茁壯成長的環境；
● 什麼時候應該說“不”，怎麼說；
● 什麼時候應該說“是”，承諾意味著什麼。
軟件強大、優雅而實用，讓人驚嘆不已，不論是開發者還是用戶都樂於使用這樣的軟件。它們並非是由機器編寫齣來的，而是齣自那些對軟件技藝擁有堅定信念的專業軟件開發者之手。本書將幫助讀者成為專業軟件開發者中的一員，並贏得隻有他們纔能擁有的榮譽感和成就感。

內容簡介

本書是編程大師“Bob 大叔”40餘年編程生涯的心得體會的總結，講解要成為真正專業的程序員需要具備什麼樣的態度，需要遵循什麼樣的原則，需要采取什麼樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為後來者引路，助其職業生涯邁上更高颱階。

作者簡介

作者介紹
Robert C. Martin，軟件開發大師，設計模式和敏捷開發先驅，敏捷聯盟首任主席，C++ Report前主編，被後輩程序員尊稱為“Bob大叔”。20世紀7 0年代初成為職業程序員，後創辦Object Mentor公司並任總裁。Martin還是一名多産的作傢，至今已發錶數百篇文章、論文和博客文章。除本書外，還著有《代碼整潔之道》《敏捷軟件開發：原則、模式和實踐》《UML：Java程序員指南》等。他創辦瞭cleancoders.com網站，專為軟件開發人員提供教育視頻。

譯者介紹
餘晟，混跡軟件開發和互聯網行業多年，目前在滬江網負責研發和架構管理工作。業餘喜愛閱讀、思考，關注工程師的全麵發展，探索更聰明的技術方案，樂於幫助外界更多理解IT行業的約束、規律和習慣。
章顯洲，螞蟻金服高級項目專傢，業餘以技術翻譯作為個人修煉與迴饋軟件開發社區的途徑。自2009年來，翻譯和與人閤譯多本技術管理書籍，偶爾也會齣現在技術社區聚會上作一些分享。近年來主要緻力於螞蟻金服基礎設施和架構升級方麵的項目集管理。

目錄

必讀引言 1
第1章　專業主義　7
1．1　清楚你要什麼　8
1．2　擔當責任　8
1．3　首先，不行損害之事　10
1．3．1　不要破壞軟件功能　10
1．3．2　不要破壞結構　12
1．4　職業道德　13
1．4．1　瞭解你的領域　14
1．4．2　堅持學習　16
1．4．3　練習　16
1．4．4　閤作　17
1．4．5　輔導　17
1．4．6　瞭解業務領域　17
1．4．7　與雇主/客戶保持一緻　18
1．4．8　謙遜　18
1．5　參考文獻　18
第2章　說“不”　19
2．1　對抗角色　21
2．2　高風險時刻　24
2．3　要有團隊精神　25
2．3．1　試試看　26
2．3．2　消極對抗　28
2．4　說“是”的成本　30
2．5　如何寫齣好代碼　35
第3章　說“是”　37
3．1　承諾用語　39
3．1．1　識彆“缺乏承諾”的徵兆　40
3．1．2　真正的承諾聽起來是怎樣的　40
3．1．3　總結　43
3．2　學習如何說“是”　43
3．2．1　“試試”的另一麵　43
3．2．2　堅守原則　44
3．3　結論　46
第4章　編碼　47
4．1　做好準備　48
4．1．1　淩晨3點寫齣的代碼　49
4．1．2　焦慮時寫下的代碼　50
4．2　流態區　51
4．2．1　音樂　52
4．2．2　中斷　53
4．3　阻塞　53
4．4　調試　55
4．5　保持節奏　57
4．5．1　知道何時應該離開一會　58
4．5．2　開車迴傢路上　58
4．5．3　洗澡　58
4．6　進度延遲　58
4．6．1　期望　59
4．6．2　盲目衝刺　59
4．6．3　加班加點　60
4．6．4　交付失誤　60
4．6．5　定義“完成”　61
4．7　幫助　61
4．7．1　幫助他人　61
4．7．2　接受他人的幫助　62
4．7．3　輔導　62
4．8　參考文獻　63
第5章　測試驅動開發　65
5．1　此事已有定論　66
5．2　TDD的三項法則　67
5．3　TDD的優勢　68
5．3．1　確定性　68
5．3．2　缺陷注入率　68
5．3．3　勇氣　69
5．3．4　文檔　69
5．3．5　設計　70
5．3．6　專業人士的選擇　70
5．4　TDD的局限　70
5．5　參考文獻　71
第6章　練習　73
6．1　引子　73
6．1．1　10的22次方　74
6．1．2　轉變　75
6．2　編程柔道場　76
6．2．1　卡塔　77
6．2．2　瓦薩　78
6．2．3　自由練習　78
6．3　自身經驗的拓展　79
6．3．1　開源　79
6．3．2　關於練習的職業道德　79
6．4　結論　80
6．5　參考文獻　80
第7章　驗收測試　81
7．1　需求的溝通　81
7．1．1　過早精細化　83
7．1．2　遲來的模糊性　83
7．2　驗收測試　85
7．2．1　“完成”的定義　85
7．2．2　溝通　88
7．2．3　自動化　88
7．2．4　額外工作　89
7．2．5　驗收測試什麼時候寫，由誰來寫　90
7．2．6　開發人員的角色　90
7．2．7　測試的協商與被動推進　91
7．2．8　驗收測試和單元測試　93
7．2．9　圖形界麵及其他復雜因素　93
7．2．10　持續集成　94
7．3　結論　95
第8章　測試策略　97
8．1　QA應該找不到任何錯誤　98
8．1．1　QA也是團隊的一部分　98
8．1．2　需求規約定義者　98
8．1．3　特性描述者　98
8．2　自動化測試金字塔　98
8．2．1　單元測試　99
8．2．2　組件測試　100
8．2．3　集成測試　100
8．2．4　係統測試　101
8．2．5　人工探索式測試　102
8．3　結論　102
8．4　參考文獻　102
第9章　時間管理　103
9．1　會議　104
9．1．1　拒絕　104
9．1．2　離席　105
9．1．3　確定議程與目標　105
9．1．4　立會　106
9．1．5　迭代計劃會議　106
9．1．6　迭代迴顧和DEMO展示　107
9．1．7　爭論/反對　107
9．2　注意力點數　108
9．2．1　睡眠　108
9．2．2　咖啡因　108
9．2．3　恢復　109
9．2．4　肌肉注意力　109
9．2．5　輸入與輸齣　109
9．3　時間拆分和番茄工作法　110
9．4　要避免的行為　110
9．5　死鬍同　111
9．6　泥潭　111
9．7　結論　112
第10章　預估　113
10．1　什麼是預估　115
10．1．1　承諾　115
10．1．2　預估　115
10．1．3　暗示性承諾　117
10．2　PERT　118
10．3　預估任務　120
10．4　大數定律　122
10．5　結論　123
10．6　參考文獻　123
第11章　壓力　125
11．1　避免壓力　127
11．1．1　承諾　127
11．1．2　保持整潔　127
11．1．3　危機中的紀律　128
11．2　應對壓力　128
11．2．1　不要驚慌失措　128
11．2．2　溝通　129
11．2．3　依靠你的紀律原則　129
11．2．4　尋求幫助　129
11．3　結論　129
第12章　協作　131
12．1　程序員與人　133
12．1．1　程序員與雇主　133
12．1．2　程序員與程序員　135
12．2　小腦　137
12．3　結論　138
第13章　團隊與項目　139
13．1　隻是簡單混閤嗎　139
13．1．1　有凝聚力的團隊　140
13．1．2　如何管理有凝聚力的 團隊　141
13．1．3　項目承包人的睏境　142
13．2　結論　142
13．3　參考文獻　143
第14章　輔導、學徒期與技藝　145
14．1　失敗的學位教育　145
14．2　輔導　146
14．2．1　DIGI-COMP I，我的 第一颱計算機　146
14．2．2　高中時代的ECP-18　148
14．2．3　非常規輔導　150
14．2．4　艱難的錘煉　150
14．3　學徒期　151
14．3．1　軟件學徒期　152
14．3．2　現實情況　154
14．4　技藝　154
14．5　結論　155
附錄　工具　157

《代碼整潔之道：程序員的職業素養》 引言 在軟件開發這個日新月異的行業中，技術的迭代速度令人目不暇接。然而，不變的核心卻是代碼的質量和開發者的專業素養。我們往往會花費大量的時間和精力去學習新的編程語言、框架和工具，卻忽略瞭那些支撐起優秀軟件的基石——簡潔、清晰、可維護的代碼，以及與之相輔相成的、高度職業化的開發態度。 本書並非一本關於某個特定編程語言的教程，也不是對某種框架的深入剖析。它聚焦於軟件開發中最根本、最持久的價值：如何寫齣優雅、易懂、易於修改的代碼，以及如何在日常工作中培養嚴謹、負責、高效的職業習慣。我們相信，真正的程序員不僅僅是代碼的編寫者，更是軟件的守護者和建設者。這本書的目標，就是幫助你成為這樣一名優秀的開發者。 第一部分：優雅的代碼，從何而來？ “代碼是寫給人看的，隻是順便讓機器執行。”這句看似簡單的陳述，卻道齣瞭代碼質量的核心——可讀性。我們花費大量時間閱讀和理解他人的代碼，也花費大量時間閱讀和理解自己的代碼。如果代碼晦澀難懂，那麼維護、調試和擴展將成為一場噩夢。 1. 命名之道：清晰的錶達，無聲的語言 一個好的名字，勝過韆言萬語。在代碼中，命名是傳達意圖的最直接方式。本書將深入探討如何為變量、函數、類、接口等選擇恰當、富有描述性的名稱。我們將學習如何避免使用含糊不清、容易引起誤解的縮寫，如何遵循語言和團隊的命名約定，以及如何讓名字本身就成為一份文檔，引導讀者理解代碼的邏輯。 明確意圖： 名稱應清晰地反映其所代錶的實體或操作的目的。例如，`calculateTotalAmount` 比 `calcAmt` 更具信息量。 避免誤導： 不要使用具有誤導性的名稱，即使它們在技術上是正確的。例如，一個名為 `users` 的列錶，如果實際存儲的是 `customers`，就會造成混淆。 一緻性： 在整個項目中保持命名風格的一緻性，這有助於降低認知負擔。 避免“魔法數字”： 用具有描述性的常量代替字麵量數字，如 `MAX_RETRIES = 3`，而不是直接在代碼中使用 `3`。 2. 函數與方法的藝術：小巧、專注、純粹 函數是代碼的基本構建塊，而函數設計的優劣直接影響著代碼的可讀性、可測試性和可復用性。本書將指導你如何設計齣小巧、單一職責的函數，每個函數隻做一件事情，並且把它做好。 短小精悍： 函數應該盡可能短。如果一個函數需要很多行代碼，它可能承擔瞭過多的責任。 單一職責原則 (SRP)： 每個函數隻應關注一個特定的任務。這使得函數更容易理解、測試和修改。 少參數： 過多的參數會使函數調用變得復雜且易於齣錯。考慮將參數組織成對象或使用其他設計模式。 避免副作用： 純函數（沒有副作用的函數）更容易理解和測試，因為它們的輸齣隻取決於輸入，不依賴於外部狀態。 命名清晰： 函數的名稱應清晰地錶明其功能，如同動詞短語。 3. 注釋的智慧：錦上添花，而非掩蓋瑕疵 注釋是為瞭彌補代碼的不足，而非替代清晰的代碼。本書將教你如何正確地使用注釋，讓它們成為有價值的補充，而不是代碼的負擔。 解釋“為什麼”，而非“是什麼”： 好的代碼本身就能說明“是什麼”，注釋應該解釋代碼背後的設計決策、復雜邏輯或潛在風險。 避免冗餘注釋： 不要注釋那些顯而易見的代碼。例如，`// Increment x by 1` 這樣的注釋是多餘的。 維護注釋： 過時的注釋比沒有注釋更糟糕。確保注釋與代碼同步更新。 TODO 和 FIXME： 閤理使用這些標記來指示需要後續處理的代碼部分。 4. 格式與布局：無聲的溝通，優雅的錶達 代碼的格式和布局是開發者之間無聲的溝通。一緻、整潔的格式可以極大地提升代碼的可讀性，減少不必要的爭論。 一緻的縮進和換行： 遵循團隊或語言的統一風格，讓代碼結構清晰可見。 空白的使用： 閤理使用空白來分隔邏輯塊，使代碼更易於閱讀。 代碼的組織： 將相關的代碼塊放在一起，使用空行來區分不同的邏輯單元。 文件和類的組織： 保持文件和類的閤理大小，避免單個文件承載過多功能。 第二部分：職業素養，鑄就卓越 除瞭編寫整潔的代碼，程序員的職業素養是決定其能否在職業生涯中走得更遠、成就更高的關鍵因素。它關乎態度、責任、協作和持續學習。 1. 測試驅動開發 (TDD)：寫代碼前先思考 測試驅動開發不僅僅是一種編碼技巧，更是一種思維方式。它鼓勵開發者在編寫實際代碼之前，先編寫測試用例。 先寫失敗的測試： 認識到你的代碼還沒有實現所需的功能。 寫最小的生産代碼： 編寫剛好能通過測試的代碼。 重構： 在測試通過後，對代碼進行改進，使其更整潔、更優。 帶來的好處： TDD 不僅能保證代碼的質量，還能幫助我們更好地理解需求，減少設計缺陷，並提供可靠的迴歸測試。 2. 異常處理：優雅地應對錯誤 錯誤是軟件開發中不可避免的一部分。如何優雅地處理異常，是衡量一個開發者成熟度的重要標準。 捕獲盡可能具體的異常： 避免捕獲過於寬泛的異常，這可能會隱藏真正的問題。 提供有用的錯誤信息： 確保異常信息能夠幫助開發者快速定位和解決問題。 不要吞噬異常： 除非有充分的理由，否則不要簡單地忽略異常。 使用異常鏈： 在將異常傳遞給上層時，保留原始異常的信息。 不要用異常來控製程序流程： 異常應該用於處理異常情況，而不是正常的業務邏輯。 3. 錯誤處理與日誌記錄：追蹤問題，洞察真相 除瞭異常處理，有效的錯誤處理和日誌記錄機製對於構建健壯的係統至關重要。 記錄關鍵信息： 日誌應包含足夠的信息，以便在齣現問題時進行分析，例如時間戳、用戶ID、請求ID、錯誤級彆和詳細的錯誤描述。 選擇閤適的日誌級彆： DEBUG、INFO、WARN、ERROR 等級彆應被正確使用。 避免在日誌中記錄敏感信息： 保護用戶隱私。 日誌的定期審查： 定期審查日誌，以便及時發現潛在問題。 4. 邊界與空值處理：滴水不漏的健壯性 軟件的健壯性體現在對各種邊界條件和空值的妥善處理。 處理輸入驗證： 確保所有外部輸入都經過嚴格的驗證。 明確處理空值： 對於可能為空的輸入，要明確地考慮其影響。 考慮邊界情況： 例如，處理空集閤、最大/最小值、空字符串等。 使用斷言（Assertions）： 在開發階段使用斷言來檢查代碼不應達到的狀態，提前暴露邏輯錯誤。 5. 持續重構：永不止步的改進 代碼並非一成不變，隨著需求的演變和對業務理解的深入，代碼也需要不斷地進行重構。 “兩粒三振”原則： 當你需要修改一段代碼三次時，就應該考慮進行重構。 小步快跑： 每次重構都應是微小的、可控的改動。 測試的支撐： 確保有足夠的測試來保障重構的安全性。 重構的目標： 提高代碼的可讀性、可維護性、可擴展性，降低復雜度。 6. 學習與成長：擁抱變化，精進不怠 技術的世界瞬息萬變，作為一名程序員，持續學習是保持競爭力的唯一途徑。 擁抱新技術： 保持對新語言、新框架、新工具的關注和學習。 閱讀優秀的代碼： 從開源社區、同事的代碼中學習。 參與技術分享： 分享自己的經驗，也在交流中學習。 反思與總結： 定期迴顧自己的工作，總結經驗教訓。 7. 團隊協作：共同的願景，協作的力量 軟件開發往往是團隊的協作成果。良好的團隊閤作能夠極大地提升開發效率和項目質量。 溝通是關鍵： 清晰、及時、坦誠的溝通是解決問題的基石。 尊重他人： 尊重團隊成員的意見和貢獻。 代碼評審： 積極參與代碼評審，既能發現問題，也能從中學習。 共同承擔責任： 團隊的成功或失敗，是所有成員共同的結果。 結論 《代碼整潔之道：程序員的職業素養》並非一本告訴你如何“更快”寫代碼的書，而是一本告訴你如何“更好”寫代碼，以及如何成為一名“更好”的程序員的書。它所倡導的理念，貫穿於我們日常工作的每一個環節。當你開始在命名上精益求精，在函數設計上追求極緻，在注釋上言簡意賅，在格式上賞心悅目時，你就是在走嚮卓越。當你開始擁抱測試驅動的開發，優雅地處理異常，細緻地進行日誌記錄，嚴謹地處理邊界條件，以及不懈地進行重構時，你就是在塑造自己的職業生涯。 這本書不僅僅是提供瞭一套方法論，更是在傳遞一種價值觀：對代碼的敬畏，對質量的追求，對職業的責任。願每一位閱讀此書的開發者，都能從中獲得啓迪，在代碼的世界裏，留下自己優雅而持久的印記。

評分☆☆☆☆☆

我是一位剛入行不久的初級程序員，對於編程的世界充滿瞭好奇和探索的欲望。在學習過程中，我常常感到迷茫，不知道如何纔能成為一名真正優秀的程序員。偶然的機會，我得知瞭《代碼整潔之道 程序員的職業素養》這本書，抱著試一試的心態購買瞭。讀完這本書，我感到豁然開朗。它從根本上改變瞭我對編程的認知。我明白瞭，編寫齣能夠運行的代碼隻是第一步，更重要的是編寫齣易於理解、易於維護的代碼。這本書中的許多建議，都非常實用，比如如何給變量和函數起一個清晰的名字，如何將復雜的邏輯分解成小的、可管理的單元，以及如何通過注釋來增強代碼的可讀性。這些內容，對於我這樣還在成長階段的程序員來說，無疑是寶貴的財富。

評分☆☆☆☆☆

我一直堅信，技術本身是沒有邊界的，但優秀程序員的特質卻是可以學習和培養的。而《代碼整潔之道 程序員的職業素養》，正是這樣一本能夠幫助我們塑造特質的書籍。它從不同的角度，拆解瞭“代碼整潔”的內涵，並將其升華到瞭“程序員的職業素養”的層麵。閱讀時，我被作者對代碼精益求精的態度所摺服，也被他對行業發展的深刻洞察所吸引。書中對於重構的闡述，更是讓我看到瞭如何在一個成熟的項目中，逐步優化代碼，提升其可讀性和可維護性。這本書的價值，在於它能夠引發讀者對自身編程習慣的深度反思，並提供一套係統性的解決方案，幫助開發者在職業生涯中不斷精進，最終成為一名受人尊敬的“代碼工匠”。

評分☆☆☆☆☆

剛拿到這本書，就覺得它散發著一種沉甸甸的分量，封麵設計簡潔而有力，沒有花哨的圖案，直接點明瞭主題。翻開扉頁，一股油墨的清香撲鼻而來，這種久違的紙質閱讀體驗，本身就是一種享受。我一直認為，成為一名優秀的程序員，除瞭精湛的技術，更重要的是職業素養的沉澱。很多時候，我們在追求算法的極緻、架構的優雅時，卻忽略瞭代碼本身的可讀性、可維護性，以及團隊協作的默契。這本書的齣現，恰好填補瞭我在這方麵的認知空白。它並非一本枯燥的技術手冊，而是像一位經驗豐富的老友，用娓娓道來的方式，分享他多年的編程心得。我相信，通過閱讀這本書，我能更好地審視自己的編程習慣，不斷打磨自己的技術，讓每一行代碼都閃爍著智慧的光芒，成為一名真正值得信賴的開發者。

評分☆☆☆☆☆

說實話，我平時閱讀的書籍類型比較駁雜，但對編程相關的書籍，我總是抱著一種嚴謹的態度。這本《代碼整潔之道 程序員的職業素養》，在朋友的強烈推薦下纔入手。不得不說，它的內容真的讓我眼前一亮。這本書並沒有一味地灌輸晦澀的理論，而是通過大量的實例，深入淺齣地講解瞭什麼是“乾淨的代碼”，以及如何寫齣“乾淨的代碼”。我尤其喜歡它對於命名規範、函數設計、錯誤處理等方麵的論述，這些都是我們在日常開發中最容易被忽視，卻又至關重要的環節。閱讀過程中，我時常會停下來，反思自己過去的代碼，確實存在不少可以改進的地方。這本書就像一麵鏡子，照齣瞭我作為程序員的不足，同時也為我指明瞭前進的方嚮。

評分☆☆☆☆☆

這本書的精髓，在於它對“程序員的職業素養”這一概念的深刻解讀。它不僅僅是在教你如何寫齣“乾淨”的代碼，更是在引導你思考作為一名程序員，應該具備怎樣的職業道德和工作態度。我讀到瞭一些關於代碼審查、團隊協作、持續學習的內容，這些都讓我深受啓發。在快節奏的軟件開發環境中，我們常常為瞭趕進度而犧牲代碼質量，殊不知，這隻會給未來的維護帶來更大的麻煩。這本書提醒我，真正的專業在於對細節的極緻追求，在於對質量的毫不妥協。它讓我意識到，寫齣好的代碼，不僅是為瞭讓彆人看懂，更是為瞭對自己負責，對項目負責，對整個團隊負責。

評分☆☆☆☆☆

多年以來，當程序員們推選齣新，最愛的計算機圖書時，這本書中是位於前列，正如自然界裏，珍珠齣自細沙，對，杜麗的魔力

評分☆☆☆☆☆

一般般吧一般般吧一般般吧一般般吧一般般吧

評分☆☆☆☆☆

好！（此評論雖然纔一個字，但語法嚴謹，用詞工整，結構巧妙，朗朗上口，可謂言簡意賅，足見評論人紮實的文字功底，以及信手拈來的寫作技巧和慘絕人寰的創造能力，令人佩服佩服，再加上以感嘆號收尾，實在是點睛之筆，再看右邊點贊數，更加肯定這位作傢的吸引能力之強，絕對是前無古人後無來者之輩！）

評分☆☆☆☆☆

∧＿∧　∧＿∧

評分☆☆☆☆☆

第4章包含AVL樹刪除算法的實現。

評分☆☆☆☆☆

第7章包含基數排序的相關內容，並給齣瞭下界證明。

評分☆☆☆☆☆

感覺當然是因為主觀體驗因人而異，但能去掉這兩個沒營養的錶情然後正麵告訴我你用的是什麼機械鍵盤和你對比的薄膜鍵盤是什麼嗎？覺得我說的不對你可以直接否定或者反駁，刷多幾個錶情和為什麼並不會讓自己的話更有說服力。

評分☆☆☆☆☆

但是，但是……，拿一個中型程序來說，裏麵數據長度是韆奇百怪的，有1字節，2字節，以及4字節的，甚至放的是一個整數錶（拿C這種高級語言來說，就是一個int型數組）。但是這些數據的長度，匯編器是無法知道的，隻有開發人員自己纔知道。所以在代碼中需要格外關注數據長度，並且在每次讀寫過程中，都需要嚴格遵守這種開發人員自定義的數據語義。如果不小心，很容易齣錯。

評分☆☆☆☆☆

書不錯，活動的時候買的300-200的時候買的，比當當的200-100便宜不少