Clean Code Vietnamese [PDF]

Zitiervorschau

Trang 1 www.it-ebooks.info

Trang 2

Mã sạch www.it-ebooks.info

Trang 3

Robert C. Martin Series Nhiệm vụ của loạt bài này là cải thiện trạng thái của nghệ thuật thủ công phần mềm. Những cuốn sách trong bộ này là kỹ thuật, thực dụng và quan trọng. Các tác giả là các thợ thủ công có kinh nghiệm cao và các chuyên gia chuyên viết về những gì thực sự hoạt động trong thực tế, trái ngược với những gì có thể hoạt động trên lý thuyết. Bạn sẽ đọc về những gì tác giả đã làm, không phải những gì anh ta nghĩ bạn nên làm. Nếu cuốn sách là về lập trình, sẽ có rất nhiều mã. Nếu cuốn sách nói về quản lý, sẽ là rất nhiều trường hợp nghiên cứu từ các dự án thực tế. Đây là những cuốn sách mà tất cả những học viên nghiêm túc sẽ có trên giá sách của họ. Đây là những cuốn sách sẽ được ghi nhớ vì đã tạo ra sự khác biệt và hướng dẫn chuyên nghiệp để trở thành nghệ nhân thực thụ. Quản lý các dự án Agile Sanjiv Augustine Lập kế hoạch và ước tính nhanh Mike Cohn Làm việc hiệu quả với Mã kế thừa Michael C. Feathers Agile Java ™: Tạo mã với Phát triển theo hướng kiểm tra Jeff Langr Các Nguyên tắc, Mẫu và Thực hành Agile trong C # Robert C. Martin và Micah Martin Phát triển phần mềm Agile: Nguyên tắc, Mẫu và Thực hành Robert C. Martin Mã sạch: Sổ tay về nghề thủ công phần mềm Agile Robert C. Martin UML dành cho lập trình viên Java ™ Robert C. Martin Phù hợp cho việc phát triển phần mềm: Khung cho các bài kiểm tra tích hợp Rick Mugridge và Ward Cunningham Phát triển phần mềm Agile với SCRUM Ken Schwaber và Mike Beedle Kỹ thuật phần mềm cực đoan: Một cách tiếp cận Daniel H. Steinberg và Daniel W. Palmer Để biết thêm thông tin, hãy truy cập Informit.com/martinseries www.it-ebooks.info

Trang 4

Mã sạch

Sổ tay Agile Tay nghề phần mềm Người cố vấn đối tượng: Robert C. Martin Michael C. Feathers Timothy R. Ottinger Jeffrey J. Langr Brett L. Schuchert James W. Grenning Kevin Dean Wampler Object Mentor Inc.

Viết mã sạch là những gì bạn phải làm để gọi mình là một người chuyên nghiệp. Không có lý do hợp lý nào để làm bất cứ điều gì kém hơn khả năng của bạn. Sông Upper Saddle, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Thành phố Mexico www.it-ebooks.info

Trang 5 Nhiều ký hiệu được các nhà sản xuất và người bán sử dụng để phân biệt sản phẩm của họ được tuyên bố là nhãn hiệu. Nơi những ký hiệu đó xuất hiện trong cuốn sách này và nhà xuất bản đã biết về khiếu nại nhãn hiệu, các ký hiệu đã được in hoa đầu tiên hoặc viết hoa tất cả. Các tác giả và nhà xuất bản đã quan tâm đến việc chuẩn bị cuốn sách này, nhưng không bày tỏ hoặc ngụ ý bảo hành dưới bất kỳ hình thức nào và không chịu trách nhiệm về lỗi hoặc thiếu sót. Không có trách nhiệm pháp lý cho những thiệt hại ngẫu nhiên hoặc do hậu quả liên quan đến hoặc phát sinh từ việc sử dụng thông tin hoặc chương trình có ở đây. Nhà xuất bản giảm giá tuyệt vời cho cuốn sách này khi đặt hàng với số lượng lớn để mua số lượng lớn hoặc bán hàng đặc biệt, có thể bao gồm các phiên bản điện tử và / hoặc bìa tùy chỉnh và nội dung dành riêng cho kinh doanh, mục tiêu đào tạo, trọng tâm tiếp thị và sở thích xây dựng thương hiệu. Vui lòng liên lạc để biết thêm thông tin: Doanh nghiệp và Chính phủ Hoa Kỳ (800) 382-3419 [email protected] Để bán hàng bên ngoài Hoa Kỳ, vui lòng liên hệ: Doanh số bán hàng quốc tế [email protected] Bao gồm tài liệu tham khảo và chỉ mục. ISBN 0-13-235088-2 (pbk .: alk. Paper) 1. Phát triển phần mềm nhanh nhẹn. 2. Phần mềm máy tính — Độ tin cậy. I. Tiêu đề. QA76.76.D47M3652 2008 005.1 — dc22 2008024750 Bản quyền © 2009 Pearson Education, Inc. Đã đăng ký Bản quyền. Được in tại Hoa Kỳ. Ấn phẩm này được bảo vệ bởi bản quyền, và phải có sự cho phép từ nhà xuất bản trước bất kỳ hành vi sao chép bị cấm nào, lưu trữ trong hệ thống truy xuất, hoặc truyền tải dưới bất kỳ hình thức nào hoặc bằng bất kỳ phương tiện nào, điện tử, cơ khí, photocopy, ghi âm, hoặc tương tự. Để biết thông tin về quyền, hãy viết thư tới: Pearson Education, Inc Bộ phận Quyền và Hợp đồng 501 Phố Boylston, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-13-235088-4 ISBN-10: 0-13-235088-2 Văn bản được in tại Hoa Kỳ trên giấy tái chế tại Courier ở Stoughton, Massachusetts. In lần đầu tháng 7 năm 2008

www.it-ebooks.info

Trang 6 Đối với Ann Marie: Tình yêu vĩnh cửu của đời tôi. www.it-ebooks.info

Trang 7

Trang này cố ý để trống www.it-ebooks.info

Trang 8 vii

Nội dung Lời nói đầu ... ...............................................x Giới thiệu: ................................................... ......................................... xxv Trên bìa ... ........................................ xxix Chương 1: Mã sạch ............................................. ........................... 1 Sẽ có mã ... ................................. 2 Mã lỗi ... ................................................... 3 Tổng chi phí sở hữu một tin nhắn ........................................... .............4 Thiết kế lại lớn trên bầu trời ............................................ .............. 5 Thái độ................................................. .............................................. 5 Câu hỏi hóc búa cơ bản ... ....................... 6 Nghệ thuật của Quy tắc sạch? ............................................ .......................... 6 Mã sạch là gì? ............................................. ............................. 7 Các trường phái tư tưởng ... ............................... 12 Chúng tôi là tác giả ... ..................................... 13 Quy tắc Hướng đạo sinh .............................................. ............................... 14 Phần tiền truyện và nguyên tắc ... ......................... 15 Kết luận: ................................................... ........................................... 15 Thư mục ... ......................................... 15 Chương 2: Những cái tên có ý nghĩa ............................................. .......... 17 Giới thiệu: ................................................... ......................................... 17 Sử dụng tên có ý định tiết lộ ............................................. ............ 18 Tránh thông tin ... .......................... 19 Tạo sự khác biệt có ý nghĩa ................................................... ............ 20 Sử dụng tên có thể phát âm được ... ................... 21 Sử dụng tên có thể tìm kiếm ... ......................... 22 www.it-ebooks.info

Trang 9 viii Nội dung

Tránh mã hóa .............................................. .................................. 23 Ký hiệu tiếng Hungary: ................................................... .......................... 23 Tiền tố thành viên ... ............................... 24 Giao diện và triển khai ... ........ 24 Tránh lập bản đồ tinh thần ... ........................ 25 Tên lớp ... ......................................... 25 Tên phương pháp ... ..................................... 25 Đừng dễ thương ............................................. ......................................... 26

Chọn một từ cho mỗi khái niệm ............................................. .................. 26 Đừng chơi chữ .............................................. ............................................... 26 Sử dụng tên miền giải pháp .............................................. ................ 27 Sử dụng tên miền có vấn đề .............................................. ................ 27 Thêm ngữ cảnh có ý nghĩa ... ..................... 27 Không thêm ngữ cảnh vô cớ ............................................ ............... 29 Lời cuối ... .......................................... 30 Chương 3: Chức năng .............................................. ........................... 31 Nhỏ! ...................................................... ...................................................... 34 Chặn và thụt lề ................................................... ......................... 35 Làm một việc ... ........................................ 35 Các phần trong chức năng ... ................. 36 Một mức độ trừu tượng cho mỗi hàm ............................................ .36 Đọc mã từ trên xuống dưới: Quy tắc bước xuống .................. 37 Chuyển đổi câu lệnh ... ............................... 37 Sử dụng tên mô tả ... ......................... 39 Đối số hàm .............................................. ............................ 40 Các dạng đơn nguyên chung ................................................... .................. 41 Cờ đối số ... ................................ 41 Chức năng Dyadic ................................................ .............................. 42 Bộ ba ................................................... ............................................... 42 Đối tượng lập luận .............................................. ............................. 43 Danh sách đối số ... ................................. 43 Động từ và Từ khóa ................................................... .......................... 43 Không có tác dụng phụ .............................................. ............................. 44 Kết quả đối số .............................................. ............................ 45 Tách truy vấn lệnh ................................................... .............. 45 www.it-ebooks.info

Trang 10 ix Nội dung

Ưu tiên các trường hợp ngoại lệ trả lại mã lỗi ................................... 46 Trích xuất khối thử / bắt ............................................. .................... 46 Xử lý lỗi là một điều ............................................. ............... 47 Nam châm phụ thuộc Error.java ............................................ .47 Đừng lặp lại chính mình ............................................. ............................ 48 Lập trình có cấu trúc ... ................... 48 Làm thế nào để bạn viết các hàm như thế này? .......................................... 49 Kết luận: ................................................... ........................................... 49 SetupTeardownIncluder ............................................. .................... 50 Thư mục ... ........................................ 52 Chương 4: Nhận xét .............................................. ......................... 53 Nhận xét không bù đắp cho mã xấu ....................................... 55 Giải thích về bản thân bằng mã lệnh .............................................. ...................... 55 Ý kiến tốt ... .................................. 55

Ý kiến pháp lý ... ............................... 55 Bình luận cung cấp thông tin ... ..................... 56 Giải thích ý định ... ......................... 56 Làm rõ................................................. ..................................... 57 Cảnh báo hậu quả ................................................... ................. 58 VIỆC CẦN LÀM: ................................................... ............................. 58 Khuếch đại ................................................... ................................... 59 Javadocs trong API công khai .............................................. ...................... 59 Nhận xét sai ... .................................... 59 Lầm bầm ... ......................................... 59 Nhận xét thừa ... ...................... 60 Nhận xét gây hiểu lầm .............................................. ...................... 63 Nhận xét được ủy quyền ... ........................ 63 Bình luận tạp chí ................................................... ............................ 63 Bình luận tiếng ồn ... .............................. 64 Tiếng ồn đáng sợ ... ...................................... 66 Không sử dụng bình luận khi bạn có thể sử dụng Hàm hoặc một biến .............................................. ......................... 67 Dấu vị trí ................................................... ............................... 67 Đóng dấu ngoặc nhận xét .............................................. .................. 67 Thuộc tính và dòng .................... 68 www.it-ebooks.info

Trang 11 x Nội dung

Mã đã nhận xét .............................................. ........................ 68 Nhận xét HTML ... ............................ 69 Thông tin phi địa phương .............................................. ....................... 69 Quá nhiều thông tin ............................................... ...................... 70 Kết nối không rõ ràng .............................................. ....................... 70 Tiêu đề chức năng ... .............................. 70 Javadocs trong mã không công khai .............................................. .............. 71 Thí dụ................................................. ........................................... 71 Thư mục ... ......................................... 74 Chương 5: Định dạng .............................................. ........................ 75 Mục đích của việc định dạng .............................................. .................. 76 Định dạng dọc ................................................... ............................. 76 Phép ẩn dụ về tờ báo ... ................. 77 Độ mở theo chiều dọc giữa các khái niệm .............................................. 78 Mật độ dọc ...................................................... ................................ 79 Khoảng cách theo phương thẳng đứng ................................................ .............................. 80 Đặt hàng dọc ................................................... .............................. 84 Định dạng ngang ... ........................ 85 Mật độ và độ mở theo chiều ngang ............................................. ...... 86 Căn chỉnh theo chiều ngang ................................................ ....................... 87 Thụt lề ................................................... ....................................... 88

Phạm vi giả ... ................................. 90 Nội quy của Đội ... ........................................... 90 Quy tắc định dạng của Uncle Bob .............................................. .............. 90 Chương 6: Đối tượng và cấu trúc dữ liệu .................................... 93 Tóm tắt dữ liệu ... .................................. 93 Chống đối xứng dữ liệu / đối tượng ............................................ .................. 95 Định luật Demeter .............................................. .............................. 97 Xác tàu bị đắm ................................................ .................................... 98 Các phép lai ... ............................................ 99 Cấu trúc ẩn ... ............................... 99 Đối tượng truyền dữ liệu ................................................... ........................ 100 Bản ghi hoạt động ... ................................. 101 Kết luận: ................................................... ......................................... 101 Thư mục ... ...................................... 101 www.it-ebooks.info

Trang 12 xi Nội dung

Chương 7: Xử lý lỗi ............................................. .............. 103 Sử dụng ngoại lệ thay vì mã trả lại ................................... 104 Viết Tuyên bố Thử-Bắt-Cuối cùng của Bạn Đầu tiên ....................... 105 Sử dụng các ngoại lệ đã bỏ chọn ........................................... ................ 106 Cung cấp ngữ cảnh có ngoại lệ .............................................. ....... 107 Xác định các loại ngoại lệ theo nhu cầu của người gọi .................. 107 Xác định dòng chảy bình thường .............................................. ...................... 109 Đừng trả về giá trị vô nghĩa ............................................. ................................. 110 Không vượt qua số vô giá ............................................. ..................................... 111 Kết luận: ................................................... ......................................... 112 Thư mục ... ...................................... 112 Chương 8: Ranh giới .............................................. ...................... 113 Sử dụng mã của bên thứ ba ............................................. ....................... 114 Khám phá và tìm hiểu ranh giới .............................................. .116 Học log4j ................................................ ................................. 116 Kiểm tra học tập tốt hơn miễn phí ............................................ ... 118 Sử dụng mã chưa tồn tại ........................................... ..... 118 Ranh giới sạch ... .............................. 120 Thư mục ... ...................................... 120 Chương 9: Kiểm tra đơn vị ............................................. .......................... 121 Ba định luật TDD ............................................. ...................... 122 Giữ sạch các bài kiểm tra ................................................... ........................... 123 Kiểm tra Kích hoạt khả năng ............................................. ...................... 124 Kiểm tra sạch ... ......................................... 124 Ngôn ngữ kiểm tra miền cụ thể ............................................. ... 127 Tiêu chuẩn kép ... .............................. 127 Một xác nhận cho mỗi bài kiểm tra .............................................. ............................. 130

Khái niệm đơn cho mỗi bài kiểm tra .............................................. .................... 131 ĐẦU TIÊN ... ............................................ 132 Kết luận: ................................................... ......................................... 133 Thư mục ... ...................................... 133 Chương 10: Lớp học ............................................. ............................ 135 Tổ chức lớp ... ............................ 136 Đóng gói: ................................................... ................................ 136 www.it-ebooks.info

Trang 13 xii Nội dung

Lớp học nên nhỏ! ...................................................... ................ 136 Nguyên tắc trách nhiệm duy nhất .............................................. .138 Sự gắn kết................................................. ......................................... 140 Duy trì kết quả gắn kết trong nhiều nhóm nhỏ .................. 141 Tổ chức để thay đổi ... ...................... 147 Cách ly khỏi sự thay đổi ................................................... ..................... 149 Thư mục ... ...................................... 151 Chương 11: Hệ thống .............................................. .......................... 153 Bạn sẽ xây dựng một thành phố như thế nào? ...................................................... ........ 154 Xây dựng riêng một hệ thống khỏi việc sử dụng nó .................................. 154 Tách chính ................................................... .......................... 155 Nhà máy sản xuất ... ......................................... 155 Hệ thống phụ thuộc .................................................................. ..................... 157 Scaling Up ................................................ .......................................... 157 Mối quan tâm xuyên suốt .............................................. ................... 160 Các proxy Java ................................................................ ........................................ 161 Khung AOP thuần Java .............................................. ............... 163 Các khía cạnh của AspectJ ................................................ ................................. 166 Chạy thử kiến trúc hệ thống ............................................. ..... 166 Tối ưu hóa việc ra quyết định ... ................ 167 Sử dụng các tiêu chuẩn một cách khôn ngoan, khi chúng thêm giá trị có thể chứng minh được ......... 168 Hệ thống cần ngôn ngữ dành riêng cho miền ..................................... 168 Kết luận: ................................................... ......................................... 169 Thư mục ... ...................................... 169 Chương 12: Sự xuất hiện .............................................. .................... 171 Làm sạch thông qua thiết kế nổi bật ............................................. ... 171 Quy tắc thiết kế đơn giản 1: Chạy tất cả các bài kiểm tra ......................................... 172 Quy tắc thiết kế đơn giản 2–4: Tái cấu trúc lại .......................................... ..172 Không trùng lặp ... ................................... 173 Diễn đạt ... .......................................... 175 Các lớp và phương thức tối thiểu .............................................. ........... 176 Kết luận: ................................................... ......................................... 176 Thư mục ... ...................................... 176

Chương 13: Đồng thời .............................................. ................ 177 Tại sao lại sử dụng đồng thời? ...................................................... ......................... 178 Những lầm tưởng và quan niệm sai lầm ................................................... .............. 179 www.it-ebooks.info

Trang 14 xiii Nội dung

Thách thức ... ......................................... 180 Nguyên tắc phòng thủ đồng thời ................................................... ....... 180 Nguyên tắc trách nhiệm đơn lẻ ... ....... 181 Hệ quả: Giới hạn phạm vi dữ liệu ........................................... ..... 181 Hệ quả: Sử dụng bản sao dữ liệu ............................................ ........... 181 Hệ quả: Các chủ đề nên càng độc lập càng tốt ............ 182 Biết thư viện của bạn ... ............................ 182 Bộ sưu tập an toàn theo chuỗi .............................................. ................... 182 Biết các mô hình thực thi của bạn .............................................. ............ 183 Người sản xuất người tiêu dùng............................................... ......................... 184 Người đọc-Người viết: ................................................... ............................... 184 Các triết gia ăn uống ... ....................... 184 Cẩn thận với sự phụ thuộc giữa các phương thức đồng bộ hóa ................. 185 Giữ các phần nhỏ được đồng bộ hóa .............................................. .... 185 Viết đúng mã tắt máy rất khó ..................................... 186 Kiểm tra mã phân luồng ................................................... ...................... 186 Xử lý các lỗi giả mạo là vấn đề phân luồng ứng viên ................. 187 Lấy mã chưa đọc của bạn làm việc đầu tiên .................................... 187 Làm cho mã luồng của bạn trở nên dễ hiểu ............................................ 187 Đặt mã luồng của bạn có thể điều chỉnh được ............................................. ... 187 Chạy với nhiều luồng hơn bộ xử lý ....................................... 188 Chạy trên các nền tảng khác nhau .............................................. .............. 188 Công cụ mã của bạn để thử và buộc thất bại ............................ 188 Mã hóa bằng tay ... .................................... 189 Tự động hóa ................................................... ..................................... 189 Kết luận: ................................................... ......................................... 190 Thư mục ... ...................................... 191 Chương 14: Sàng lọc kế thừa ........................................... 193 Thực hiện Args .............................................. ........................ 194 Tôi đã làm điều này như thế nào? ...................................................... ..................... 200 Args: Bản nháp thô ............................................. ........................ 201 Vì vậy, tôi dừng lại ... .................................... 212 Về chủ nghĩa gia tăng ................................................ ......................... 212 Đối số chuỗi ................................................... .............................. 214 Kết luận: ................................................... ........................................ 250 www.it-ebooks.info

Trang 15 xiv

Nội dung

Chương 15: Nội bộ JUnit ............................................. ............. 251 Khung JUnit ............................................... ........................ 252 Kết luận: ................................................... ......................................... 265 Chương 16: Tái cấu trúc ngày nối tiếp ......................................... 267 Đầu tiên, làm cho nó hoạt động ... .............................. 268 Sau đó thực hiện đúng .............................................. ............................. 270 Kết luận: ................................................... ......................................... 284 Thư mục ... ...................................... 284 Chương 17: Mùi và phương pháp chẩn đoán ............................................ .285 Nhận xét ... ......................................... 286 C1: Thông tin không phù hợp .............................................. ......... 286 C2: Nhận xét lỗi thời .............................................. ..................... 286 C3: Nhận xét dư thừa .............................................. ................. 286 C4: Nhận xét viết kém ............................................. ............. 287 C5: Mã nhận xét ra ... ................. 287 Môi trường ... ..................................... 287 E1: Xây dựng yêu cầu nhiều hơn một bước ......................................... 287 E2: Các thử nghiệm yêu cầu nhiều hơn một bước .......................................... 287 Chức năng ... ........................................... 288 F1: Quá nhiều đối số ............................................. ................... 288 F2: Đầu ra đối số .............................................. ...................... 288 F3: Cờ đối số .............................................. .......................... 288 F4: Chức năng chết .............................................. ........................... 288 Khái quát chung ... .............................................. 288 G1: Nhiều ngôn ngữ trong một tệp nguồn .................................. 288 G2: Hành vi rõ ràng không được thực hiện ...................................... 288 G3: Hành vi không chính xác tại ranh giới ..................................... 289 G4: Các quyền an toàn bị ghi đè .............................................. ................... 289 G5: Sao chép ................................................... ............................... 289 G6: Mã ở mức độ trừu tượng sai ........................................ 290 G7: Các lớp cơ sở tùy thuộc vào các phái sinh của chúng ....................... 291 G8: Quá nhiều thông tin ............................................. ................ 291 G9: Mã chết .............................................. ................................. 292 G10: Tách dọc .............................................. .................. 292 G11: Không nhất quán ................................................... .......................... 292 G12: Lộn xộn ........................................... ..................................... 293 www.it-ebooks.info

Trang 16 xv Nội dung

G13: Khớp nối nhân tạo .............................................. ................... 293 G14: Tính năng đố kỵ .............................................. ............................ 293 G15: Đối số của bộ chọn .............................................. .................. 294 G16: Ý định bị che khuất .............................................. ....................... 295

G17: Trách nhiệm không đúng chỗ .............................................. ......... 295 G18: Tĩnh không phù hợp .............................................. ................. 296 G19: Sử dụng các biến giải thích ............................................. ....... 296 G20: Tên chức năng nói lên tác dụng của chúng .......................... 297 G21: Hiểu thuật toán ............................................. ........ 297 G22: Tạo sự phụ thuộc logic về mặt vật lý ................................... 298 G23: Ưu tiên Đa hình thành If / Else hoặc Switch / Case .................... 299 G24: Tuân theo các quy ước chuẩn ............................................. ... 299 G25: Thay thế các số ma thuật bằng các hằng số có tên .................. 300 G26: Hãy chính xác .............................................. ................................ 301 G27: Cấu trúc so với Công ước ............................................. ........ 301 G28: Đóng gói các điều kiện .............................................. ....... 301 G29: Tránh các điều kiện phủ định ............................................. .... 302 G30: Các chức năng nên làm một việc ........................................... 302 G31: Mối ghép tạm thời ẩn ............................................. ..... 302 G32: Đừng tùy tiện ........................................... ...................... 303 G33: Đóng gói các điều kiện ranh giới ........................................ 304 G34: Chỉ nên giảm thiểu các chức năng Một mức độ trừu tượng .............................................. .................. 304 G35: Giữ dữ liệu có thể định cấu hình ở mức cao ................................ 306 G36: Tránh điều hướng chuyển tiếp ............................................. ...... 306 Java ... ...................................................... ..307 J1: Tránh danh sách nhập dài bằng cách sử dụng ký tự đại diện ............................ 307 J2: Không kế thừa các hằng số ........................................... ................. 307 J3: Hằng số so với Enums ............................................. .............. 308 Tên ... ................................................ 309 N1: Chọn tên mô tả ............................................. ......... 309 N2: Chọn tên ở mức độ trừu tượng thích hợp .......... 311 N3: Sử dụng Danh pháp Chuẩn khi Có thể ........................... 311 N4: Tên rõ ràng .............................................. ................. 312 N5: Sử dụng tên dài cho phạm vi dài .......................................... .312 N6: Tránh mã hóa .............................................. ........................ 312 N7: Tên nên mô tả tác dụng phụ.  ..................................... 313 www.it-ebooks.info

Trang 17 xvi Nội dung

Kiểm tra ... ...................................................... .313 T1: Kiểm tra không đầy đủ .............................................. ......................... 313 T2: Sử dụng Công cụ Bảo hiểm!  ...................................................... ............. 313 T3: Đừng bỏ qua những bài kiểm tra tầm thường .......................................... .................. 313 T4: Một bài kiểm tra bị bỏ qua là một câu hỏi về sự mơ hồ .................. 313 T5: Các điều kiện ranh giới thử nghiệm ............................................. ........... 314 T6: Kiểm tra hoàn toàn gần lỗi ............................................ ........ 314 T7: Các mô hình thất bại đang bộc lộ ........................................... .314 T8: Các mẫu bao phủ thử nghiệm có thể được tiết lộ ............................... 314

T9: Kiểm tra sẽ nhanh chóng ............................................ ..................... 314 Kết luận: ................................................... ......................................... 314 Thư mục ... ...................................... 315 Phụ lục A: Đồng thời II ............................................ ............ 317 Ví dụ về Máy khách / Máy chủ .............................................. ........................ 317 Máy chủ ... ...................................... 317 Thêm luồng ... ........................... 319 Quan sát máy chủ .............................................. ....................... 319 Phần kết luận................................................. ..................................... 321 Các con đường thực hiện có thể có .............................................. ................ 321 Số đường dẫn .............................................. .............................. 322 Đào sâu hơn ................................................ .............................. 323 Phần kết luận................................................. ..................................... 326 Biết thư viện của bạn ... ....................... 326 Khuôn khổ người thực thi .............................................. ...................... 326 Giải pháp không chặn .................................................................. ................... 327 Các lớp an toàn không theo luồng .............................................. .................... 328 Sự phụ thuộc giữa các phương pháp Có thể phá vỡ mã đồng thời .............................................. ............. 329 Chịu đựng thất bại ................................................... .......................... 330 Khóa dựa trên máy khách .............................................. ....................... 330 Khóa dựa trên máy chủ .............................................. ...................... 332 Tăng thông lượng .............................................. ..................... 333 Tính toán thông lượng đơn luồng ...................................... 334 Tính toán thông lượng đa luồng .......................................... 335 Bế tắc ................................................... ............................................ 335 Loại trừ lẫn nhau ................................................ ........................... 336 Khóa & Chờ .................................... 337 www.it-ebooks.info

Trang 18 xvii Nội dung

Không có quyền ưu tiên................................................ ................................ 337 Vòng chờ ...................................................... .................................. 337 Phá vỡ loại trừ lẫn nhau ................................................... ............. 337 Mở khóa và chờ đợi .............................................. ...................... 338 Phá vỡ dự phòng ............................................................... ...................... 338 Ngắt vòng chờ đợi ................................................... .................... 338 Kiểm tra mã đa luồng ... .............. 339 Hỗ trợ công cụ để kiểm tra mã dựa trên chuỗi ................................ 342 Kết luận: ................................................... ......................................... 342 Hướng dẫn: Ví dụ về mã đầy đủ ............................................. ............. 343 Máy khách / Máy chủ được đọc trước .............................................. ............... 343 Máy khách / Máy chủ sử dụng chủ đề ............................................. ............. 346 Phụ lục B: org.jfree.date.SerialDate ...................................... 349

Phụ lục C: Tham khảo chéo về phương pháp chẩn đoán ........................... 409 Phần kết ... ............................................... 411 Mục lục ... ...................................................... ... 413 www.it-ebooks.info

Trang 19 Trang này cố ý để trống www.it-ebooks.info

Trang 20 xix

Lời tựa Một trong những loại kẹo yêu thích của chúng tôi ở đây ở Đan Mạch là Ga-Jol, có hơi cam thảo mạnh bổ sung hoàn hảo cho thời tiết ẩm ướt và thường lạnh của chúng tôi. Một phần sức hấp dẫn của Ga-Jol đối với us Danes là những câu nói khôn ngoan hoặc dí dỏm được in trên nắp của mỗi chiếc hộp. Tôi đã mua một haisáng nay gói đồ ăn ngon và thấy rằng nó mang theo cái nhìn cũ của người Đan Mạch: Ærlighed i små ting er ikke nogen lille ting . "Trung thực trong những việc nhỏ không phải là một việc nhỏ." Đó là một điềm tốt phù hợp với những gì tôi đã muốn nói ở đây. Những điều nhỏ nhặt quan trọng. Đây là một cuốn sách về những mối quan tâm khiêm tốn mà giá trị của nó vẫn không hề nhỏ. Kiến trúc sư Ludwig mies van der Rohe cho biết Chúa ở trong từng chi tiết . Trích dẫn này nhớ lại những lập luận đương đại về vai trò của kiến trúc trong phát triển phần mềm, và rõ ràng trong thế giới Agile. Bob và tôi thỉnh thoảng thấy mình say mê tham gia cuộc đối thoại này. Và vâng, mies van der Rohe đã chú ý đến tiện ích và những hình thức vượt thời gian xây dựng nền tảng kiến trúc vĩ đại. Mặt khác, anh cũng đích thân lựa chọn mọi tay nắm cửa cho mọi ngôi nhà do anh ấy thiết kế. Tại sao? Bởi vì những điều nhỏ nhặt quan trọng. Trong “cuộc tranh luận” đang diễn ra của chúng tôi về TDD, Bob và tôi đã phát hiện ra rằng chúng tôi đồng ý rằng kiến trúc đồ đạc có một vị trí quan trọng trong sự phát triển, mặc dù chúng ta có thể có tầm nhìn về chính xác điều đó có nghĩa là gì. Tuy nhiên, những điều ngụy biện như vậy tương đối không quan trọng, bởi vì chúng tôi có thể chấp nhận rằng các chuyên gia có trách nhiệm cho một thời gian để suy nghĩlập và lập kế hoạch khi bắt đầu một dự án. Những quan niệm về thiết kế vào cuối những năm 1990 chỉ được thúc đẩy bởi các bài kiểm tra và mã đã biến mất từ lâu. Tuy nhiên, sự chú ý đến từng chi tiết là một yếu tố quan trọng hơn nền tảng của sự chuyên nghiệp hơn bất kỳ tầm nhìn lớn nào. Đầu tiên, đó là thông qua thực hành trong nhỏ mà các chuyên gia đạt được sự thành thạo và tin tưởng để thực hành nói chung. Thứ hai, chút nhỏ nhất của kết cấu cẩu thả, của cánh cửa không đóng chặt hoặc hơi gạch quanh co trên sàn nhà, hoặc thậm chí cả bàn làm việc lộn xộn, hoàn toàn xóa tan sự quyến rũ của toàn bộ lớn hơn. Đó là những gì về mã sạch. Tuy nhiên, kiến trúc chỉ là một phép ẩn dụ cho việc phát triển phần mềm và đặc biệt là một phần của phần mềm cung cấp sản phẩm ban đầu giống như một kiến trúc sư mang lại một tòa nhà nguyên sơ. Trong những ngày của Scrum và Agile, trọng tâm là nhanh chóng đưa sản phẩm ra thị trường. Chúng tôi muốn nhà máy chạy với tốc độ cao nhất để sản xuất phần mềm. Đây là những nhà máy của con người: những lập trình viên suy nghĩ, cảm nhận đang làm việc từ một sản phẩm trở lạinhật ký hoặc câu chuyện người dùng để tạo sản phẩm . Phép ẩn dụ về sản xuất luôn tồn tại mạnh mẽ trong Suy nghĩ. Các khía cạnh sản xuất của sản xuất ô tô Nhật Bản, của một dây chuyền lắp ráp thế giới, truyền cảm hứng cho nhiều Scrum. www.it-ebooks.info

Trang 21

xx Lời tựa Tuy nhiên, ngay cả trong ngành công nghiệp ô tô, phần lớn công việc không nằm ở sản xuất mà là ở bảo trì — hoặc tránh nó. Trong phần mềm, 80% hoặc nhiều hơn những gì chúng ta làm được gọi là "Bảo trì": hành động sửa chữa. Thay vì ôm trọng tâm của phương Tây điển hình trên thân sử dụng phần mềm tốt, chúng ta nên suy nghĩ nhiều hơn như những người thợ sửa nhà trong tòa nhà công nghiệp hoặc cơ khí ô tô trong lĩnh vực ô tô. Quản lý Nhật Bản có gì nói về điều đó ? Vào khoảng năm 1951, một cách tiếp cận chất lượng được gọi là Bảo trì Năng suất Toàn diện (TPM) đã ra đời trên cảnh Nhật Bản. Nó tập trung vào bảo trì hơn là sản xuất. Một trong những trụ cột chính của TPM là tập hợp các nguyên tắc được gọi là 5S. 5S là một tập hợp các kỷ luật — và ở đây tôi sử dụng thuật ngữ "kỷ luật" một cách giảng dạy. Các nguyên tắc 5S này trên thực tế nằm ở cơ sởtions of Lean — một từ thông dụng khác trên thị trường phương Tây và ngày càng nổi bật từ thông dụng trong giới phần mềm. Những nguyên tắc này không phải là một lựa chọn. Như chú Bob liên quan đến vấn đề quan trọng của anh ấy, thực hành phần mềm tốt đòi hỏi kỷ luật như vậy: tập trung, sự hiện diện của tâm trí, và suy nghĩ. Nó không phải lúc nào cũng chỉ là làm, về việc thúc đẩy thiết bị nhà máy để đấu với vận tốc tối ưu. Triết lý 5S bao gồm các khái niệm sau: • Seiri , hoặc tổ chức (nghĩ “sắp xếp” bằng tiếng Anh). Biết mọi thứ đang ở đâu — sử dụng các phương pháp tiếp cận như đặt tên phù hợp — là rất quan trọng. Bạn nghĩ rằng việc đặt tên cho số nhận dạng không quan trọng? Đọc tiếp trong các chương sau. • Seiton , hoặc ngăn nắp (nghĩ rằng "hệ thống hóa" trong tiếng Anh). Có một câu nói cổ của người Mỹ: Một nơi cho mọi thứ, và mọi thứ ở đúng vị trí của nó . Một đoạn mã phải ở đâu bạn mong đợi sẽ tìm thấy nó — và nếu không, bạn nên tính toán lại để đạt được nó. • Seiso , hoặc dọn dẹp (nghĩ là “tỏa sáng” trong tiếng Anh): Giữ cho nơi làm việc không bị treo dây điện, dầu mỡ, phế liệu và chất thải. Các tác giả ở đây nói gì về việc xả rác của bạn mã có nhận xét và dòng mã nhận xét ghi lại lịch sử hoặc mong muốn tương lai? Loại bỏ chúng. • Seiketsu , hay tiêu chuẩn hóa: Nhóm thống nhất về cách giữ cho nơi làm việc sạch sẽ. Bạn có nghĩ rằng cuốn sách này nói bất cứ điều gì về việc có một phong cách mã hóa nhất quán và một bộ thực hành trong nhóm? Những tiêu chuẩn đó đến từ đâu? Đọc tiếp. • Shutsuke , hoặc kỷ luật ( tự kỷ luật ). Điều này có nghĩa là có kỷ luật để tuân theo thực hành và thường xuyên phản ánh công việc của một người và sẵn sàng thay đổi. Nếu bạn chấp nhận thử thách — vâng, thử thách — khi đọc và áp dụng cuốn sách này, bạn sẽ hiểu và đánh giá cao điểm cuối cùng. Ở đây, cuối cùng chúng tôi cũng đang lái xe đến gốc rễ của sự chuyên nghiệp có trách nhiệm trong một nghề cần quan tâm đến cuộc sống chu kỳ của một sản phẩm. Khi chúng tôi bảo trì ô tô và các máy móc khác theo TPM, phá vỡgiảm bảo trì — chờ lỗi xuất hiện — là ngoại lệ. Thay vào đó, chúng tôi đi lên một cấp độ: kiểm tra máy hàng ngày và sửa chữa các bộ phận bị mòn trước khi chúng bị hỏng, hoặc tương đương với việc thay dầu 10.000 dặm theo phương ngôn đối với sự hao mòn và hao mòn. Trong mã, refactor không thương tiếc. Bạn có thể cải thiện thêm một cấp nữa, khi phong trào TPM đổi mớihơn 50 năm trước: chế tạo những cỗ máy dễ bảo trì hơn ngay từ đầu. Makviệc nhập mã của bạn có thể đọc được cũng quan trọng như làm cho nó có thể thực thi được. Thực hành cuối cùng, được giới thiệu trong giới TPM vào khoảng năm 1960, là tập trung vào việc giới thiệu toàn bộ máy mới hoặc www.it-ebooks.info

Trang 22 xxi Lời tựa thay thế những cái cũ. Như Fred Brooks khuyên chúng ta, có lẽ chúng ta nên làm lại phần mềm chínhCác khối đồ đạc được làm từ đầu cứ sau bảy năm hoặc lâu hơn để quét sạch các vết rạn nứt. Có lẽ chúng ta nên cập nhật hằng số thời gian của Brooks thành thứ tự tuần, ngày hoặc giờ thay vì nhiều năm. Đó là nơi chi tiết nằm. Có sức mạnh to lớn về chi tiết, nhưng có điều gì đó khiêm tốn và sâu sắc về điều này

cách tiếp cận cuộc sống, như chúng ta có thể mong đợi một cách rập khuôn từ bất kỳ cách tiếp cận nào cho rằng Japarễ nese. Nhưng đây không chỉ là cách nhìn của người phương Đông về cuộc sống; Dân gian Anh và Mỹ khôn ngoandom đầy những lời khuyên nhủ như vậy. Trích dẫn Seiton từ trên chảy ra từ cây bút của một bộ trưởng Ohio, người theo nghĩa đen xem sự gọn gàng “như một phương thuốc cho mọi mức độ xấu xa.” Còn Seiso thì sao? Sạch sẽ bên cạnh sự tin kính . Đẹp như một ngôi nhà, một mớ hỗn độn cái bàn cướp đi vẻ đẹp lộng lẫy của nó. Còn Shutsuke trong những vấn đề nhỏ này thì sao? Người trung thành trong ít là trung thành trong nhiều . Còn về việc háo hức tái yếu tố vào thời điểm có trách nhiệm, củng cố vị trí của một người cho các quyết định “lớn” tiếp theo, thay vì trì hoãn nó? A khâu trong thời gian tiết kiệm chín . Con chim đầu bắt sâu. Đừng trì hoãn cho đến ngày mai những gì bạn có thể làm hôm nay. (Đó là ý nghĩa ban đầu của cụm từ “người chịu trách nhiệm cuối cùng moment ”trong Lean cho đến khi nó rơi vào tay các nhà tư vấn phần mềm . ) Làm thế nào về hiệu chỉnhở chỗ của những nỗ lực nhỏ, cá nhân trong một tổng thể lớn? Cây sồi hùng mạnh từ những quả sồi nhỏ lớn lên. Hoặc làm thế nào về việc tích hợp công việc phòng ngừa đơn giản vào cuộc sống hàng ngày? Một ounce phòng ngừa có giá trị một pound chữa bệnh. Mỗi ngày một quả táo, bác sĩ không tới nhà. Mã sạch tôn vinh nguồn gốc sâu xa của trí tuệ bên dưới nền văn hóa rộng lớn hơn của chúng tôi, hoặc nền văn hóa của chúng tôi như trước đây, hoặc nên có, và có thể chú ý đến từng chi tiết. Ngay cả trong các tài liệu kiến trúc vĩ đại, chúng ta cũng tìm thấy những chiếc cưa có tác dụng trở lại những phụ trợ này chi tiết đặt ra. Hãy nghĩ về tay nắm cửa của mies van der Rohe. Đó là seiri . Đó là sự chú ý cho mọi tên biến. Bạn nên đặt tên cho một biến bằng cách sử dụng cùng một cách mà bạn đặt tên cho đứa con đầu lòng. Như mọi chủ nhà đều biết, sự chăm sóc và trau chuốt liên tục như vậy không bao giờ kết thúc. Kiến trúc sư Christopher Alexander - cha đẻ của các mẫu và ngôn ngữ mẫu - quan điểm bản thân mỗi hành động thiết kế như một hành động sửa chữa nhỏ, cục bộ. Và anh ấy xem sự khéo léo của cấu trúc tốt để trở thành mục tiêu duy nhất của kiến trúc sư; các hình thức lớn hơn có thể được để lại cho các mẫu và ứng dụng của họ bởi cư dân. Thiết kế không ngừng liên tục khi chúng tôi thêm một phòng của một ngôi nhà, nhưng khi chúng tôi chú ý đến việc sơn lại, thay thế những tấm thảm đã sờn hoặc nâng cấp trong bồn rửa nhà bếp. Hầu hết các nghệ thuật đều lặp lại những tình cảm tương tự. Trong tìm kiếm của chúng tôi cho những người khác mô tả ngôi nhà của Đức Chúa Trời như là một trong những chi tiết, chúng ta thấy mình ở trong sự đồng hành tốt của Tác giả người Pháp thế kỷ 19 Gustav Flaubert. Nhà thơ Pháp Paul Valery khuyên chúng ta rằng bài thơ không bao giờ được hoàn thành và phải làm lại liên tục, và ngừng làm việc với nó là sự từ bỏ. Sự bận tâm đến chi tiết như vậy là phổ biến đối với tất cả những nỗ lực xuất sắc. Vì vậy, có thể ở đó hơi mới ở đây, nhưng khi đọc cuốn sách này, bạn sẽ được thử thách để tiếp thu tốt những điều mà bạn đã đầu hàng từ lâu trước sự thờ ơ hoặc mong muốn sự tự nhiên và chính đáng "Phản ứng với sự thay đổi." Thật không may, chúng tôi thường không coi những mối quan tâm như vậy là nền tảng chính của nghệ thuật lập trình. Chúng tôi từ bỏ mã của mình sớm, không phải vì nó đã hoàn thành, mà vì giá trị của chúng tôi hệ thống tập trung nhiều hơn vào hình thức bên ngoài hơn là nội dung của những gì chúng tôi cung cấp. www.it-ebooks.info

Trang 23 xxii Lời tựa Cuối cùng, sự thiếu chú ý này khiến chúng ta phải trả giá: Một xu xấu luôn xuất hiện . Nghiên cứu, không trong trong ngành công nghiệp cũng như trong học thuật, tự hạ mình xuống vị trí thấp kém của việc giữ mã trong sạch. Trở lại trong những ngày tôi làm việc trong tổ chức Nghiên cứu Sản xuất Phần mềm Bell Labs ( Production , thực sự!) chúng tôi đã có một số phát hiện phía sau cho thấy rằng kiểu thụt lề là một trong những chỉ báo có ý nghĩa thống kê nhất về mật độ lỗi thấp. Chúng tôi muốn nó trở thành kiến trúc hoặc ngôn ngữ lập trình hoặc một số khái niệm cao cấp khác nên là nguyên nhân của chất lượng; với tư cách là những người được cho là chuyên nghiệp nhờ vào

thành thạo các công cụ và phương pháp thiết kế cao cả, chúng tôi cảm thấy bị xúc phạm bởi giá trị mà nhà máy đómáy sàn, người viết mã, thêm vào thông qua ứng dụng đơn giản nhất quán của một thụt đầu dòng Phong cách. Để trích dẫn cuốn sách của chính tôi 17 năm trước, phong cách như vậy phân biệt sự xuất sắc với năng lực đơn thuần. Thế giới quan của người Nhật hiểu được giá trị cốt yếu của cuộc sống hàng ngày công nhân và hơn thế nữa, của các hệ thống phát triển nhờ vào những điều đơn giản, hàng ngày hành động của những người lao động đó. Chất lượng là kết quả của hàng triệu hành động chăm sóc quên mình — không chỉ của bất kỳ phương pháp tuyệt vời nào từ trên trời giáng xuống. Những hành động này đơn giản không có nghĩa là rằng chúng đơn giản và hầu như không có nghĩa là chúng dễ dàng. Dù sao họ cũng là kết cấu của sự vĩ đại và hơn thế nữa, của vẻ đẹp, trong bất kỳ nỗ lực nào của con người. Bỏ qua chúng thì không chưa hoàn toàn là con người. Tất nhiên, tôi vẫn là người ủng hộ tư duy ở phạm vi rộng hơn, và đặc biệt là giá trị của các phương pháp tiếp cận kiến trúc bắt nguồn từ kiến thức miền sâu và khả năng sử dụng phần mềm. Cuốn sách không nói về điều đó — hoặc, ít nhất, nó không rõ ràng về điều đó. Cuốn sách này có một cái hay hơn thông điệp có độ sâu sắc không nên bị đánh giá thấp. Nó phù hợp với cưa hiện tại của những người thực sự dựa trên mã như Peter Sommerlad, Kevlin Henney và Giovanni Asproni. “Mã là thiết kế” và “Mã đơn giản” là thần chú của họ. Trong khi chúng ta phải hãy cẩn thận để nhớ rằng giao diện là chương trình và cấu trúc của nó có nhiều để nói về cấu trúc chương trình của chúng tôi, điều quan trọng là phải liên tục áp dụng lập trường khiêm tốn rằng thiết kế nằm trong mã. Và trong khi làm lại trong phép ẩn dụ sản xuất dẫn đến chi phí, làm lại trong thiết kế dẫn đến giá trị. Chúng ta nên xem mã của chúng ta như một khớp nối đẹp đẽ những nỗ lực cao cả của thiết kế — thiết kế như một quá trình, không phải là một điểm cuối tĩnh. Nó nằm trong mã các chỉ số kiến trúc của sự khớp nối và sự gắn kết phát ra. Nếu bạn nghe Larry Constantine mô tả sự khớp nối và sự gắn kết, anh ấy nói về mặt mã — không phải khái niệm trừu tượng cao cảcepts mà người ta có thể tìm thấy trong UML. Richard Gabriel khuyên chúng ta trong bài luận của anh ấy, “Tính trừu tượng Descant ”rằng trừu tượng là xấu xa. Mã là chống lại cái ác, và mã sạch có lẽ là thần thánh. Trở lại với hộp Ga-Jol nhỏ của tôi, tôi nghĩ điều quan trọng cần lưu ý là người Đan Mạch sự khôn ngoan khuyên chúng ta không chỉ để ý đến những điều nhỏ nhặt, mà còn phải trung thực trong những việc nhỏ. nhiều thứ. Điều này có nghĩa là trung thực với mã, trung thực với đồng nghiệp của chúng tôi về trạng thái mã và hơn hết là trung thực với bản thân về mã của chúng tôi. Chúng tôi đã cố gắng hết sức để "Để khu cắm trại sạch sẽ hơn chúng tôi thấy"? Chúng tôi đã xác định lại mã của mình trước khi kiểm tranhập vào? Đây không phải là những mối quan tâm ngoại vi mà là những mối quan tâm nằm ngay trung tâm của Giá trị linh hoạt. Một phương pháp được khuyến nghị trong Scrum là tính toán lại là một phần của vấn đề cept của "Xong." Cả kiến trúc và mã sạch đều không nhấn mạnh vào sự hoàn hảo, chỉ dựa trên sự trung thực và làm tốt nhất có thể. Sai lầm là con người; để tha thứ, thiêng liêng. Trong Scrum, chúng tôi thực hiện mọiđiều có thể nhìn thấy. Chúng tôi không khí quần áo bẩn của mình. Chúng tôi trung thực về trạng thái mã của chúng tôi vì www.it-ebooks.info

Trang 24 xxiii Lời tựa mã không bao giờ là hoàn hảo. Chúng ta trở thành con người hoàn chỉnh hơn, xứng đáng hơn với thần thánh và gần gũi hơn đến sự tuyệt vời đó trong các chi tiết. Trong nghề nghiệp của mình, chúng tôi rất cần mọi sự giúp đỡ có thể. Nếu mặt bằng cửa hàng sạch sẽ giảm tai nạn và các công cụ cửa hàng được tổ chức tốt sẽ tăng năng suất, vì vậy tôi là tất cả chúng. Đối với cuốn sách này, nó là ứng dụng thực tế tốt nhất của các nguyên tắc Lean vào phần mềm I đã từng thấy trong bản in. Tôi mong đợi không ít từ nhóm nhỏ suy nghĩ thực tế này. các viduals đã cùng nhau phấn đấu trong nhiều năm không chỉ để trở nên tốt hơn mà còn là món quà kiến thức của họ đối với ngành trong các công trình như bây giờ bạn tìm thấy trong tay của bạn. Nó để lại thế giới tốt hơn một chút so với tôi tìm thấy trước khi chú Bob gửi cho tôi bản thảo. Sau khi hoàn thành bài tập này với những hiểu biết sâu sắc, tôi chuẩn bị dọn dẹp bàn làm việc của mình.

James O. Coplien Mørdrup, Đan Mạch www.it-ebooks.info

Trang 25 Trang này cố ý để trống www.it-ebooks.info

Trang 26 xxv

Giới thiệu Cửa nào đại diện cho mã của bạn? Cánh cửa nào đại diện cho đội của bạn hoặc công ty của bạn? Tại sao chúng ta lại ở trong phòng đó? Đây chỉ là một đánh giá mã thông thường hay chúng tôi đã tìm thấy một luồng vấn đề khủng khiếp ngay sau khi phát trực tiếp? Chúng ta đang gỡ lỗi trong hoảng loạn, đang nghiền ngẫm mã mà chúng tôi nghĩ đã hiệu quả? Khách hàng bỏ đi ngày một đông và người quản lý thở phào Sao lại với sự cho phép của Thom Holwerda. http://www.osnews.com/story/19266/WTFs_m (c) 2008 F ocus Shift

www.it-ebooks.info

Trang 27 xxvi Giới thiệu cổ của chúng tôi? Làm thế nào chúng ta có thể đảm bảo rằng chúng ta sẽ đến sau cánh cửa bên phải khi hành trình đến khó khăn? Câu trả lời là: sự khéo léo . Có hai phần để học nghề thủ công: kiến thức và công việc. Bạn phải đạt được kiến thức về các nguyên tắc, mẫu, thực hành và kinh nghiệm học mà một người thợ thủ công biết, và bạn cũng phải mài dũa kiến thức đó vào ngón tay, mắt và ruột của mình bằng cách làm việc chăm chỉ và đang luyện tập. Tôi có thể dạy bạn vật lý của việc đi xe đạp. Thật vậy, toán học cổ điển là tương đối đơn giản. Trọng lực, ma sát, mô men động lượng, khối tâm, v.v. thứ tư, có thể được chứng minh với ít hơn một trang đầy đủ các phương trình. Đưa ra những công thức tôi có thể chứng minh cho bạn thấy rằng đi xe đạp là thực tế và cung cấp cho bạn tất cả kiến thức mà bạn cần thiết để làm cho nó hoạt động. Và bạn vẫn sẽ bị ngã trong lần đầu tiên leo lên chiếc xe đạp đó. Mã hóa không có gì khác biệt. Chúng tôi có thể viết ra tất cả các nguyên tắc "cảm thấy tốt" về sạch sẽ mã và sau đó tin tưởng bạn thực hiện công việc (nói cách khác, để bạn gục ngã khi bắt đầu xe đạp), nhưng sau đó loại giáo viên nào sẽ tạo ra chúng tôi, và loại học sinh điều đó sẽ làm cho bạn? Không. Đó không phải là cách mà cuốn sách này sẽ hoạt động. Học cách viết mã sạch là một công việc khó khăn . Nó đòi hỏi nhiều hơn là chỉ kiến thức về nguyên tắc và khuôn mẫu. Bạn phải đổ mồ hôi cho nó. Bạn phải tự thực hành nó, và xem bản thân thất bại. Bạn phải xem những người khác thực hành nó và thất bại. Bạn phải thấy họ vấp ngã và tìm lại các bước của họ. Bạn phải thấy họ đau đớn trước các quyết định và thấy cái giá họ phải trả đưa ra những quyết định sai lầm. Hãy chuẩn bị để làm việc chăm chỉ khi đọc cuốn sách này. Đây không phải là một cuốn sách "cảm thấy hay" bạn có thể đọc trên máy bay và hoàn thành trước khi hạ cánh. Cuốn sách này sẽ giúp bạn làm việc, và làm việc chăm chỉ . Bạn sẽ làm công việc gì? Bạn sẽ đọc mã — rất nhiều mã. Và bạn sẽ được thử thách để nghĩ xem điều gì đúng về mã đó và điều gì sai với nó. Bạn sẽ được yêu cầu làm theo khi chúng tôi tách các mô-đun ra và đặt chúng trở lại

lại với nhau. Điều này sẽ tốn thời gian và công sức; nhưng chúng tôi nghĩ rằng nó sẽ đáng giá. Chúng tôi đã chia cuốn sách này thành ba phần. Một số chương đầu tiên mô tả các hoàng tửmật mã, các mẫu và cách viết mã sạch. Có khá nhiều mã trong những các chương, và chúng sẽ khó đọc. Họ sẽ chuẩn bị cho bạn phần thứ hai để đến. Nếu bạn đặt cuốn sách xuống sau khi đọc phần đầu tiên, chúc bạn may mắn! Phần thứ hai của cuốn sách là phần khó hơn. Nó bao gồm một số nghiên cứu điển hình về ngày càng phức tạp. Mỗi nghiên cứu điển hình là một bài tập trong việc làm sạch một số mã — trong số chuyển đổi mã có một số vấn đề thành mã có ít vấn đề hơn. Các chi tiết trong phần này là dữ dội . Bạn sẽ phải lật đi lật lại giữa tường thuật và danh sách mã. Bạn sẽ phải phân tích và hiểu mã chúng tôi đang làm việc và xem xét lý do của chúng tôi để thực hiện mỗi thay đổi chúng tôi thực hiện. Dành một chút thời gian bởi vì điều này sẽ khiến bạn mất nhiều ngày . Phần thứ ba của cuốn sách này là phần thưởng. Nó là một chương duy nhất chứa danh sách các heusự mạo hiểm và mùi được thu thập trong khi tạo ra các nghiên cứu điển hình. Khi chúng tôi đi qua và làm sạch mã trong các nghiên cứu điển hình, chúng tôi đã ghi lại mọi lý do cho các hành động của mình dưới dạng www.it-ebooks.info

Trang 28 xxvii Giới thiệu heuristic hoặc mùi. Chúng tôi đã cố gắng hiểu phản ứng của chính mình đối với mã chúng tôi đang đọc và thay đổi, và làm việc chăm chỉ để nắm bắt lý do tại sao chúng tôi cảm thấy những gì chúng tôi cảm thấy và làm những gì chúng tôi đã làm. Kết quả là một cơ sở kiến thức mô tả cách chúng ta suy nghĩ khi viết, đọc và mã sạch. Cơ sở kiến thức này có giá trị hạn chế nếu bạn không đọc kỹ thông qua các nghiên cứu điển hình trong phần thứ hai của cuốn sách này. Trong những nghiên cứu điển hình đó, chúng tôi quan tâm đếnchú thích đầy đủ từng thay đổi mà chúng tôi đã thực hiện với các tham chiếu chuyển tiếp đến kinh nghiệm học. Những điều này chotham chiếu phường xuất hiện trong dấu ngoặc vuông như sau: [H22]. Điều này cho phép bạn thấy bối cảnh trong mà những kinh nghiệm học đó đã được áp dụng và viết ra! Không phải bản thân những người nghiên cứu kinh nghiệm mới là rất có giá trị, đó là mối quan hệ giữa những khám phá đó và những quyết định rời rạc mà chúng ta được thực hiện trong khi làm sạch mã trong các nghiên cứu điển hình . Để giúp bạn thêm về những mối quan hệ đó, chúng tôi đã đặt một tham chiếu chéo ở cuối của cuốn sách hiển thị số trang cho mọi tài liệu tham khảo chuyển tiếp. Bạn có thể sử dụng nó để nhìn lên từng nơi đã áp dụng một kinh nghiệm nhất định. Nếu bạn đọc phần đầu tiên và phần thứ ba và bỏ qua các nghiên cứu điển hình, thì bạn sẽ đã đọc một cuốn sách "cảm thấy tốt" khác về cách viết phần mềm tốt. Nhưng nếu bạn lấy thời gian để làm việc thông qua các nghiên cứu điển hình, theo từng bước nhỏ, từng phút quyết định — nếu bạn đặt mình vào vị trí của chúng tôi và buộc bản thân phải suy nghĩ theo cùng con đường mà chúng tôi nghĩ, sau đó bạn sẽ hiểu biết phong phú hơn nhiều về các nguyên tắc, mô hình, cách tices và heuristics. Họ sẽ không còn là kiến thức "cảm thấy tốt" nữa. Họ sẽ chạm vào ruột, ngón tay và trái tim của bạn. Họ sẽ trở thành một phần của bạn theo cách tương tự rằng một chiếc xe đạp trở thành một phần mở rộng của ý chí của bạn khi bạn đã thành thạo cách đi nó.

Sự nhìn nhận Ảnh minh họa Cảm ơn hai nghệ sĩ của tôi, Jeniffer Kohnke và Angela Brooks. Jennifer chịu trách nhiệm cho những bức ảnh tuyệt đẹp và sáng tạo ở đầu mỗi chương và cả những bức chân dung của Kent Beck, Ward Cunningham, Bjarne Stroustrup, Ron Jeffries, Grady Booch, Dave Thomas, Michael Feathers, và tôi. Angela chịu trách nhiệm về những bức tranh khéo léo tô điểm cho các phần bên trong của mỗi chương. Cô ấy đã thực hiện khá nhiều bức ảnh cho tôi trong nhiều năm, bao gồm nhiều bức bên trong-

các mẹo trong Thiết bị phần mềm Agile: Nguyên tắc, Mẫu và Thực hành . Cô ấy cũng là của tôi đứa con đầu lòng mà tôi rất hài lòng. www.it-ebooks.info

Trang 29 Trang này cố ý để trống www.it-ebooks.info

Trang 30 xxix

Trên trang bìa Hình ảnh trên bìa là M104: The Sombrero Galaxy. M104 nằm ở Xử Nữ và là chỉ cách chúng ta dưới 30 triệu năm ánh sáng. Tại lõi của nó là một lỗ đen siêu lớn nặngcó khối lượng khoảng một tỷ mặt trời. Hình ảnh có khiến bạn liên tưởng đến vụ nổ của mặt trăng quyền năng Klingon Praxis không? Tôi nhớ rất rõ cảnh trong Star Trek VI cho thấy một vòng các mảnh vụn bay ở xích đạo tránh xa vụ nổ đó. Kể từ cảnh đó, vòng xích đạo đã trở thành một hiện vật phổ biến trong các vụ nổ phim khoa học viễn tưởng. Nó thậm chí còn được thêm vào sự bùng nổ của Alderaan trong các phiên bản sau này của bộ phim Chiến tranh giữa các vì sao đầu tiên . Điều gì đã làm cho vòng này hình thành xung quanh M104? Tại sao nó có một trung tâm lớn như vậy phình ra và một hạt nhân nhỏ và sáng như vậy? Tôi nhìn nó như thể là lỗ đen trung tâm mất mát và thổi bay lỗ hổng 30.000 năm ánh sáng ở giữa thiên hà. Khốn nạn cho bất kỳ các nền văn minh có thể nằm trong con đường của sự phá vỡ vũ trụ đó. Các lỗ đen siêu lớn nuốt chửng toàn bộ các ngôi sao trong bữa trưa, chuyển đổi một phân số khá lớn tỷ khối của chúng thành năng lượng. E = MC  2 là đủ đòn bẩy, nhưng khi M là khối lượng sao: Coi chưng! Có bao nhiêu ngôi sao rơi đầu vào con vẹt đó trước khi con quái vật được thỏa mãn? Kích thước của khoảng trống trung tâm có thể là một gợi ý? Hình ảnh M104 trên trang bìa là một sự kết hợp của pho- ánh sáng khả kiến nổi tiếng đồ thị từ Hubble (bên phải) và gần đây hình ảnh hồng ngoại từ quỹ đạo Spitzer đài quan sát (bên dưới, bên phải). Đó là tia hồng ngoại hình ảnh cho chúng ta thấy rõ bản chất của chiếc nhẫn của thiên hà. Trong ánh sáng khả kiến, chúng ta chỉ nhìn thấy cạnh trước của chiếc nhẫn trong hình bóng. Các central phình ra che lấp phần còn lại của vòng. Nhưng trong tia hồng ngoại, các hạt nóng trong vòng tỏa sáng qua phần phình trung tâm. Các hai hình ảnh kết hợp cho chúng ta một cái nhìn mà chúng ta đã chưa từng thấy trước đây và ngụ ý rằng nó đã lâu rồi là một địa ngục hoành hành của hoạt động. Ảnh bìa: © Kính viễn vọng Không gian Spitzer

www.it-ebooks.info

Trang 31 Trang này cố ý để trống www.it-ebooks.info

Trang 32 1

1 Mã sạch Bạn đang đọc cuốn sách này vì hai lý do. Đầu tiên, bạn là một lập trình viên. Thứ hai, bạn muốn để trở thành một lập trình viên giỏi hơn. Tốt. Chúng tôi cần những lập trình viên giỏi hơn. www.it-ebooks.info

Trang 33 2 Chương 1: Mã sạch Đây là một cuốn sách về lập trình hay. Nó chứa đầy mã. Chúng tôi sẽ xem xét mã từ mọi hướng khác nhau. Chúng tôi sẽ nhìn xuống nó từ trên xuống, nhìn lên nó từ dưới cùng và xuyên qua nó từ trong ra ngoài. Vào lúc chúng ta hoàn thành, chúng ta sẽ biết một rất nhiều về mã. Hơn nữa, chúng ta sẽ có thể phân biệt giữa mã tốt và mã xấu mã. Chúng tôi sẽ biết cách viết mã tốt. Và chúng tôi sẽ biết cách chuyển đổi mã xấu thành mã tốt.

Sẽ có mã Người ta có thể tranh luận rằng một cuốn sách về mã bằng cách nào đó đi sau thời đại — mã đó không còn vấn đề; mà chúng ta nên quan tâm đến các mô hình và yêu cầu thay thế. Thật vậy, một số người đã gợi ý rằng chúng ta sắp kết thúc mã. Điều đó sớm tất cả mã sẽ được tạo ra thay vì được viết. Đơn giản là không cần lập trình viên vì business mọi người sẽ tạo ra các chương trình từ các thông số kỹ thuật. Vô lý! Chúng tôi sẽ không bao giờ loại bỏ mã, bởi vì mã đại diện cho các chi tiết của các yêu cầu. Ở một mức độ nào đó, những chi tiết đó không thể bị bỏ qua hoặc trừu tượng hóa; Họ phải là được chỉ định. Và xác định các yêu cầu một cách chi tiết để máy có thể thực hiện chúng là lập trình . Một đặc điểm kỹ thuật như vậy là mã . Tôi hy vọng rằng mức độ trừu tượng của các ngôn ngữ của chúng ta sẽ tiếp tục tăng lên. Tôi cũng hy vọng rằng số lượng ngôn ngữ dành riêng cho miền sẽ tiếp tục tăng. Điều này sẽ là một điều tốt. Nhưng nó sẽ không loại bỏ mã. Thật vậy, tất cả các thông số kỹ thuật được viết ở cấp cao hơn và ngôn ngữ dành riêng cho miền sẽ là mã! Nó vẫn sẽ cần chặt chẽ, chính xác, trang trọng và chi tiết đến mức máy móc có thể hiểu và Thực hiện nó. Những người nghĩ rằng một ngày nào đó mã đó sẽ biến mất giống như các nhà toán học hy vọng một ngày nào đó sẽ khám phá ra một toán học mà không cần phải chính thức. Họ đang hy vọng rằng một ngày nào đó chúng ta sẽ khám phá ra cách tạo ra những cỗ máy có thể làm những gì chúng ta muốn thay vì hơn những gì chúng tôi nói. Những cỗ máy này sẽ phải có thể hiểu chúng ta tốt đến mức chúng có thể chuyển các nhu cầu được chỉ định một cách mơ hồ thành các chương trình thực thi hoàn hảo đáp ứng chính xác những nhu cầu đó. Điều này sẽ không bao giờ xảy ra. Ngay cả con người, với tất cả trực giác và óc sáng tạo của mình, đã có thể tạo ra các hệ thống thành công từ những cảm giác mơ hồ của khách hàng. Thật vậy, nếu kỷ luật về đặc tả yêu cầu đã dạy chúng ta bất cứ điều gì, thì đó là các yêu cầu được chỉ định rõ cũng chính thức như mã và có thể hoạt động như các thử nghiệm thực thi của mã! Hãy nhớ rằng mã thực sự là ngôn ngữ mà cuối cùng chúng ta thể hiện yêu cầuments. Chúng tôi có thể tạo các ngôn ngữ gần với yêu cầu hơn. Chúng tôi có thể tạo ra các công cụ giúp chúng tôi phân tích cú pháp và tập hợp các yêu cầu đó thành các cấu trúc chính thức. Nhưng chúng tôi sẽ không bao giờ loại bỏ độ chính xác cần thiết — vì vậy sẽ luôn có mã. www.it-ebooks.info

Trang 34 3 Mã xấu

Mã xấu Gần đây tôi đã đọc lời tựa cho Kent Beck's cuốn sách Các mô hình thực hiện.  1 Anh ấy nói, “. . . điều này cuốn sách dựa trên một tiền đề khá mong manh: rằng vấn đề mã tốt. . . . ” Một tiền đề mong manh ? Tôi không đồng ý! Tôi nghĩ tiền đề đó là một trong những tiền đề mạnh mẽ, được hỗ trợ và quá tải của tất cả các tiếng ồn trong nghề của chúng tôi (và tôi nghĩ Kent biết điều đó). Chúng tôi biết mã tốt quan trọng bởi vì chúng tôi đã phải đối phó quá lâu với sự thiếu hụt của nó. Tôi biết một công ty, vào cuối những năm 80, đã viết một ứng dụng giết người . Nó rất phổ biến và rất nhiều các chuyên gia đã mua và sử dụng nó. Nhưng sau đó chu kỳ phát hành bắt đầu kéo dài. Lỗi không sửa chữa từ bản phát hành này sang bản tiếp theo. Thời gian tải tăng lên và sự cố tăng lên. Tôi nhớ ngày tôi tắt sản phẩm một cách thất vọng và không bao giờ đã sử dụng nó một lần nữa. Công ty đã ngừng kinh doanh một thời gian ngắn sau đó. Hai thập kỷ sau, tôi gặp một trong những nhân viên đầu tiên của công ty đó và hỏi anh ta chuyê ̣n gì đã xảy ra. Câu trả lời khẳng định nỗi sợ hãi của tôi. Họ đã đưa sản phẩm đến thị trường và đã tạo ra một mớ hỗn độn lớn trong mã. Khi họ ngày càng thêm nhiều tính năng, mã ngày càng trở nên tồi tệ hơn cho đến khi họ không thể quản lý được nữa. Đó là điều tồi tệ mã đã đưa công ty đi xuống. Đã bạn đã bao giờ bị cản trở đáng kể theo mã xấu? Nếu bạn là một lập trình viên của bất kỳ kinh nghiệm nào thì bạn đã cảm thấy trở ngại này nhiều lần. Thật vậy, chúng tôi có tên cho nó. Chúng tôi gọi nó là lội . Chúng tôi lội qua mã xấu. Chúng tôi khẩu hiệu qua một mớ hỗn độn brambles và cạm bẫy tiềm ẩn. Chúng tôi đấu tranh để tìm ra con đường của mình, hy vọng một số gợi ý, một số manh mối, về những gì đang xảy ra; nhưng tất cả những gì chúng ta thấy ngày càng nhiều mã vô tri. Tất nhiên bạn đã bị cản trở bởi mã xấu. Vậy thì - tại sao bạn lại viết nó? Bạn có cố gắng đi nhanh không? Bạn có đang vội không? Có lẽ vậy. Có lẽ bạn cảm thấy rằng bạn không có thời gian để làm tốt công việc; rằng sếp của bạn sẽ tức giận với bạn nếu bạn lấy thời gian để xóa mã của bạn. Có lẽ bạn chỉ cảm thấy mệt mỏi khi làm việc với chương trình này và muốn nó kết thúc. Hoặc có thể bạn đã xem xét tồn đọng của những thứ khác mà bạn đã quảng cáophải hoàn thành và nhận ra rằng bạn cần kết hợp mô-đun này lại với nhau để có thể chuyển sang phần tiếp theo. Tất cả chúng ta đã làm được. Tất cả chúng tôi đã xem xét mớ hỗn độn mà chúng tôi vừa tạo ra và sau đó đã chọn để nó Một ngày khác. Tất cả chúng tôi đều cảm thấy nhẹ nhõm khi thấy chương trình lộn xộn của mình hoạt động và quyết định rằng 1. [Beck07].

www.it-ebooks.info

Trang 35 4 Chương 1: Mã sạch làm việc lộn xộn còn hơn không. Tất cả chúng tôi đã nói rằng chúng tôi sẽ quay lại và dọn dẹp nó sau. Của Tất nhiên, những ngày đó chúng ta chưa biết đến định luật của LeBlanc: Sau này không bao giờ bằng .

Tổng chi phí sở hữu một tin nhắn Nếu bạn đã là một lập trình viên hơn hai hoặc ba năm, bạn có thể đã bị chậm lại đáng kể bởi mã lộn xộn của người khác. Nếu bạn đã là một lập trình viên trong hơn hai hoặc ba năm, bạn có thể đã bị chậm lại bởi mã lộn xộn.

Mức độ chậm lại có thể là đáng kể. Trong khoảng một hoặc hai năm, các nhóm đang di chuyển rất nhanh khi bắt đầu một dự án có thể thấy mình đang di chuyển như một con ốc sên tốc độ. Mỗi thay đổi mà họ thực hiện đối với mã sẽ phá vỡ hai hoặc ba phần khác của mã. Không thay đổi là tầm thường. Mọi bổ sung hoặc sửa đổi đối với hệ thống đều yêu cầu rằng xoắn và thắt nút được "hiểu" để có thể thêm nhiều rối, xoắn và thắt nút. Theo thời gian, đống rác ngày càng lớn, sâu và cao đến mức họ không thể dọn dẹp được. Đó không có cách nào cả. Khi tình trạng lộn xộn hình thành, năng suất của nhóm tiếp tục giảm, tiệm cận gần bằng không. Khi năng suất giảm, cấp quản lý sẽ làm điều duy nhất họ có thể làm được; họ bổ sung thêm nhân viên vào dự án với hy vọng tăng năng suất. Nhưng nhân viên mới đó là không thành thạo trong thiết kế của hệ thống. Họ không biết sự khác biệt giữa một sự thay đổi phù hợp với ý định thiết kế và thay đổi cản trở ý định thiết kế. Hơn nữa, họ và tất cả những người khác trong nhóm phải chịu áp lực khủng khiếp để tăng năng suất. Vì thế tất cả chúng ngày càng tạo ra nhiều mớ hỗn độn hơn, khiến năng suất ngày càng tiến xa về con số không. (Xem Hình 1-1.) Hình 1-1 Năng suất so với thời gian www.it-ebooks.info

Trang 36 5 Tổng chi phí sở hữu một tin nhắn

Thiết kế lại lớn trên bầu trời Cuối cùng cả đội nổi dậy. Họ thông báo với ban quản lý rằng họ không thể tiếp tục phát triển trong cơ sở mã đáng sợ này. Họ yêu cầu thiết kế lại. Ban quản lý không muốn chi tiêu các nguồn lực về thiết kế lại hoàn toàn mới của dự án, nhưng họ không thể phủ nhận rằng sản xuất nó là khủng khiếp. Cuối cùng, họ tuân theo yêu cầu của các nhà phát triển và cho phép thiết kế lại lớn trên bầu trời. Một đội hổ mới được chọn. Mọi người đều muốn tham gia đội này vì đó là một màu xanh lá câydự án thực địa. Họ bắt đầu lại và tạo ra một thứ gì đó thực sự đẹp đẽ. Nhưng chỉ tốt nhất và sáng nhất được chọn cho đội hổ. Mọi người khác phải tiếp tục duy trì hệ thống hiện tại. Bây giờ hai đội đang trong một cuộc đua. Đội hổ phải xây dựng một hệ thống mới mọi thứ mà hệ thống cũ làm. Không chỉ vậy, họ phải theo kịp những thay đổi liên tục được tạo cho hệ thống cũ. Quản lý sẽ không thay thế cái cũ hệ thống cho đến khi hệ thống mới có thể làm mọi thứ mà hệ thống cũ làm. Cuộc đua này có thể diễn ra trong một thời gian rất dài. Tôi đã thấy nó mất 10 năm. Và vào lúc nó xong, các thành viên ban đầu của đội hổ đã biến mất từ lâu và các thành viên hiện tại yêu cầu hệ thống mới phải được thiết kế lại vì nó rất lộn xộn. Nếu bạn đã trải qua dù chỉ một phần nhỏ của câu chuyện tôi vừa kể, thì bạn đã biết rằng dành thời gian giữ cho mã của bạn sạch sẽ không chỉ hiệu quả về chi phí; đó là vấn đề của sinh tồn chuyên nghiệp.

Thái độ Bạn đã bao giờ lội qua một đống lộn xộn đến mức phải mất hàng tuần để làm những gì đáng lẽ phải có mất nhiều giờ? Bạn đã thấy những gì đáng lẽ phải là thay đổi một dòng, được thực hiện thay thế trong hàng trăm mô-đun khác nhau? Các triệu chứng này đều quá phổ biến. Tại sao điều này xảy ra với mã? Tại sao mã tốt lại nhanh chóng biến thành mã xấu? Chúng tôi có rất nhiều lời giải thích cho nó. Chúng tôi phàn nàn rằng các yêu cầu đã thay đổi theo cách cản trở thiết kế ban đầu. Chúng tôi than phiền vì lịch trình quá chặt chẽ để làm mọi thứ đúng. Chúng ta đổ lỗi cho những người quản lý ngu ngốc và những khách hàng không khoan dung và những kiểu tiếp thị vô dụng và chất khử trùng điện thoại. Nhưng lỗi, Dilbert thân mến, không phải ở các vì sao của chúng ta, mà là ở chính chúng ta. Chúng tôi không chuyên nghiệp. Đây có thể là một viên thuốc đắng để nuốt. Làm thế nào mà lộn xộn này có thể là lỗi của chúng tôi ? Vậy còn

yêu cầu? Còn về lịch trình? Còn những người quản lý ngu ngốc và vô dụng thì sao các loại tiếp thị? Họ không chịu một số trách nhiệm? Không. Các nhà quản lý và nhà tiếp thị tìm đến chúng tôi để biết thông tin họ cần lời hứa và cam kết; và ngay cả khi họ không nhìn chúng ta, chúng ta cũng không nên ngại ngùng về việc nói với họ những gì chúng tôi nghĩ. Người dùng tìm đến chúng tôi để xác thực cách thức các yêu cầu sẽ phù hợp với hệ thống. Các nhà quản lý dự án tìm đến chúng tôi để giúp đưa ra lịch trình. Chúng tôi www.it-ebooks.info

Trang 37 6 Chương 1: Mã sạch đồng lõa sâu sắc trong việc lập kế hoạch của dự án và chia sẻ rất nhiều các phản ứngsự nhanh nhẹn cho bất kỳ thất bại nào; đặc biệt là nếu những thất bại đó liên quan đến mã xấu! "Nhưng chờ đã!" bạn nói. "Nếu tôi không làm những gì người quản lý của tôi nói, tôi sẽ bị sa thải." Chắc là không. Hầu hết các nhà quản lý muốn sự thật, ngay cả khi họ không hành động như vậy. Hầu hết các nhà quản lý muốn tốt mã, ngay cả khi họ đang ám ảnh về lịch trình. Họ có thể bảo vệ lịch trình và yêu cầu với đam mê; nhưng đó là công việc của họ. Nhiệm vụ của bạn là bảo vệ mã bằng niềm đam mê. Để lái xe đến điểm này về nhà, điều gì sẽ xảy ra nếu bạn là bác sĩ và có một bệnh nhân yêu cầu rằng bạn dừng tất cả việc rửa tay ngớ ngẩn để chuẩn bị cho cuộc phẫu thuật vì nó đang quá nhiều thời gian? 2 Rõ ràng bệnh nhân là ông chủ; và bác sĩ tuyệt đối nên từ chối tuân thủ. Tại sao? Bởi vì bác sĩ biết nhiều hơn bệnh nhân về các nguy cơ của bệnh dễ dàng và nhiễm trùng. Sẽ là không chuyên nghiệp (đừng bận tâm đến tội phạm) nếu bác sĩ tuân thủ bệnh nhân. Vì vậy, việc các lập trình viên làm theo ý muốn của những người quản lý không chuyên nghiệp cũng là không chuyên nghiệp. hiểu những rủi ro của việc làm lộn xộn.

Câu hỏi hóc búa cơ bản Các lập trình viên phải đối mặt với một câu hỏi hóc búa về các giá trị cơ bản. Tất cả các nhà phát triển có hơn một vài năm kinh nghiệm biết rằng những lộn xộn trước đó làm chậm họ. Và tất cả các nhà phát triển đều cảm thấy áp lực phải thực hiện các vụ lộn xộn để đáp ứng thời hạn. Tóm lại, họ không mất thời gian đi nhanh! Các chuyên gia chân chính biết rằng phần thứ hai của câu hỏi hóc búa là sai. Bạn sẽ không thực hiện thời hạn bằng cách làm cho lộn xộn. Thật vậy, tình trạng lộn xộn sẽ làm bạn chậm lại ngay lập tức, và sẽ buộc bạn phải bỏ lỡ thời hạn. Cách duy nhất để đưa ra thời hạn — cách duy nhất để đi nhanh — là luôn giữ cho mã sạch nhất có thể.

Nghệ thuật của Quy tắc sạch? Giả sử bạn tin rằng mã lộn xộn là một trở ngại đáng kể. Hãy nói rằng bạn chấp nhận rằng cách duy nhất để nhanh chóng là giữ cho mã của bạn sạch sẽ. Sau đó, bạn phải tự hỏi mình: "Làm thế nào tôi có viết mã sạch không? ” Cố gắng viết mã sạch sẽ không tốt nếu bạn không biết nó là gì nghĩa là mã phải sạch! Tin xấu là viết mã sạch giống như vẽ một bức tranh. Hầu hết chúng ta biết khi nào một bức tranh được vẽ tốt hay xấu. Nhưng có thể nhận ra nghệ thuật tốt từ xấu không có nghĩa là chúng ta biết vẽ. Vì vậy, cũng có thể nhận ra mã sạch từ mã bẩn không có nghĩa là chúng ta biết cách viết mã sạch! 2. Khi rửa tay lần đầu tiên được đề nghị cho các bác sĩ bởi Ignaz Semmelweis vào năm 1847, nó đã bị từ chối vì lý do các bác sĩ quá bận rộn và không có thời gian để rửa tay giữa các lần khám bệnh.

www.it-ebooks.info

Trang 38 7 Tổng chi phí sở hữu một tin nhắn Viết mã sạch yêu cầu sử dụng có kỷ luật của vô số kỹ thuật nhỏ được áp dụng thông qua cảm giác “sạch sẽ” có được một cách cẩn thận. “Code-sense” này là chìa khóa.

Một số người trong chúng ta được sinh ra với nó. Một số người trong chúng ta phải đấu tranh để có được nó. Nó không chỉ cho chúng tôi xem mã tốt hay xấu, nhưng nó cũng cho chúng ta thấy chiến lược áp dụng pline để chuyển đổi mã xấu thành mã sạch. Một lập trình viên không có “code-sense” có thể nhìn vào một mô-đun lộn xộn và nhận ra lộn xộn nhưng sẽ không biết phải làm gì với nó. Một lập trình viên có "code-sense" sẽ nhìn tại một mô-đun lộn xộn và xem các tùy chọn và biến thể. “Code-sense” sẽ giúp điều đó grammer chọn biến thể tốt nhất và hướng dẫn anh ấy hoặc cô ấy vẽ một chuỗi hành vi bảo toàn các phép biến hình để đi từ đây đến đó. Tóm lại, một lập trình viên viết mã sạch là một nghệ sĩ có thể chụp một màn hình trống thông qua một loạt các biến đổi cho đến khi nó là một hệ thống được mã hóa trang nhã.

Mã sạch là gì? Có lẽ có rất nhiều định nghĩa đối với lập trình viên. Vì vậy, tôi đã hỏi một số rất lập trình viên nổi tiếng và có kinh nghiệm sâu sắc những gì họ nghĩ. Bjarne Stroustrup, người phát minh ra C ++ và tác giả của Lập trình C ++ Ngôn ngữ Tôi thích mã của mình phải thanh lịch và hiệu quả.  Các logic nên đơn giản để làm cho nó khó để lỗi ẩn, các phụ thuộc tối thiểu để bảo trì dễ dàng, xử lý lỗi hoàn thành theo một chiến lược rõ ràng, và theo hình thức gần với tối ưu để không bị cám dỗ mọi người làm cho mã lộn xộn với unprincicam kết tối ưu hóa.  Mã sạch làm một việc tốt.

Bjarne sử dụng từ "thanh lịch". Đó là khá một từ! Từ điển trong MacBook ® của tôi cung cấp các định nghĩa sau: làm hài lòng duyên dáng và phong cách về ngoại hình hoặc phong cách; đẹp một cách khéo léo và đơn giản. Chú ý nhấn mạnh vào từ “làm hài lòng”. Rõ ràng Bjarne nghĩ rằng mã sạch được làm hài lòng đến đọc. Đọc nó sẽ khiến bạn mỉm cười như một chiếc hộp nhạc được chế tác tốt hoặc thiết kế đẹp ô tô sẽ. Bjarne cũng đề cập đến hiệu quả— gấp đôi . Có lẽ điều này không làm chúng ta ngạc nhiên từ người phát minh ra C ++; nhưng tôi nghĩ có nhiều thứ hơn là ham muốn tốc độ. Chu kỳ lãng phí là không phù hợp, họ không hài lòng. Và bây giờ hãy lưu ý từ mà Bjarne sử dụng www.it-ebooks.info

Trang 39 số 8 Chương 1: Mã sạch để mô tả hậu quả của sự kém cỏi đó. Anh ấy sử dụng từ “cám dỗ”. Có một sâu sự thật ở đây. Mã xấu cám dỗ sự lộn xộn để phát triển! Khi những người khác thay đổi mã xấu, họ có xu hướng Làm cho nó tồi tệ hơn. Thực dụng Dave Thomas và Andy Hunt nói điều này theo một cách khác. Họ đã sử dụng metaphor của cửa sổ bị hỏng. 3 Một tòa nhà với các cửa sổ bị vỡ trông có vẻ như không ai quan tâm nó. Vì vậy, những người khác ngừng quan tâm. Chúng cho phép nhiều cửa sổ bị hỏng hơn. Cuối cùng họ chủ động phá vỡ chúng. Họ làm bong tróc mặt tiền bằng graffiti và để rác thải thành đống bài giảng. Một cửa sổ bị hỏng bắt đầu quá trình phân rã. Bjarne cũng đề cập rằng việc xử lý lỗi phải được hoàn tất. Điều này đi đến chỗ ... pline của sự chú ý đến các chi tiết. Xử lý lỗi viết tắt chỉ là một cách tạo ra gammers bóng trên các chi tiết. Rò rỉ bộ nhớ là một, các điều kiện chủng tộc vẫn khác. Đặt tên không phù hợp nhưng khác. Kết quả là mã sạch thể hiện sự chú ý chi tiết. Bjarne kết thúc với khẳng định rằng mã sạch làm tốt một việc. Nó không phải là tình cờ rằng có rất nhiều nguyên tắc thiết kế phần mềm có thể được đúc kết thành

lời khuyên nhủ. Nhà văn này đến nhà văn khác đã cố gắng truyền đạt suy nghĩ này. Mã lỗi cố gắng làm quá nhiều, nó có mục đích lẫn lộn và mục đích không rõ ràng. Mã sạch được chú trọng . Mỗi chức năng, mỗi lớp, mỗi mô-đun thể hiện một thái độ duy nhất mà vẫn hoàn toàn không bị phân tán và không bị ô nhiễm bởi các chi tiết xung quanh. Grady Booch, tác giả của Object Phân tích và thiết kế định hướng với Các ứng dụng Mã sạch rất đơn giản và trực tiếp.  Mã sạch đọc như văn xuôi được viết tốt.  Mã sạch không bao giờ che khuất ý định của nhà thiết kế mà thay vào đó là đầy trừu tượng rõ ràng và đường thẳng kiểm soát.

Grady đưa ra một số điểm giống như Bjarne, nhưng anh ấy có quan điểm về khả năng đọc . Tôi đặc biệt thích quan điểm của anh ấy rằng mã sạch sẽ đọc như văn xuôi được viết tốt. Nghĩ lại về một cuốn sách thực sự hay mà bạn đã đọc. Hãy nhớ cách các từ biến mất để được thay thế bằng hình ảnh! Nó giống như xem một bộ phim, phải không? Tốt hơn! Bạn đã thấy các nhân vật, bạn nghe thấy âm thanh, bạn đã trải nghiệm những điều kỳ diệu và hài hước. Đọc mã sạch sẽ không bao giờ giống như đọc Chúa tể của những chiếc nhẫn . Tuy nhiên, lítphép ẩn dụ ary không phải là một phép ẩn dụ xấu. Giống như một cuốn tiểu thuyết hay, mã sạch sẽ thể hiện rõ ràng mườisions trong vấn đề cần giải quyết. Nó sẽ xây dựng những căng thẳng đó lên cao trào và sau đó đưa ra 3. http://www.pragmaticprogrammer.com/booksellers/2004-12.html

www.it-ebooks.info

Trang 40 9 Tổng chi phí sở hữu một tin nhắn người đọc rằng “Aha! Tất nhiên!" khi các vấn đề và căng thẳng được giải quyết trong tiết lộ của một giải pháp rõ ràng. Tôi thấy việc Grady sử dụng cụm từ "trừu tượng rõ ràng" là một oxymoron hấp dẫn! Xét cho cùng, từ “sắc nét” gần như là một từ đồng nghĩa với “cụ thể”. Từ điển MacBook của tôi giữ định nghĩa sau đây về “sắc nét”: dứt khoát nhanh chóng và thực tế, không chần chừtation hoặc chi tiết không cần thiết. Mặc dù có vẻ giống nhau về ý nghĩa, những từ mang một thông điệp mạnh mẽ. Mã của chúng tôi phải là vấn đề thực tế chứ không phải suy đoán. Nó chỉ nên chứa những gì cần thiết. Độc giả của chúng tôi nên nhận ra rằng chúng tôi đã quyết định. “Big” Dave Thomas, người sáng lập của OTI, cha đỡ đầu của Chiến lược Eclipse Mã sạch có thể được đọc và được nâng cao bởi nhà phát triển khác với tác giả ban đầu của nó.  Nó có đơn vị và nghiệm thu.  Nó có ý nghĩa những cái tên.  Nó cung cấp một cách thay vì nhiều cách để làm một việc.  Nó có ít depencác cơ quan, được xác định rõ ràng, và cung cấp một API rõ ràng và tối thiểu.  Mã phải được biết chữ vì tùy thuộc vào ngôn ngữ, không phải tất cả thông tin cần thiết có thể được thể hiện rõ ràng chỉ trong mã.

Big Dave chia sẻ mong muốn của Grady về khả năng đọc đượcity, nhưng với một bước ngoặt quan trọng. Dave khẳng định rằng mã sạch giúp người khác dễ dàng nâng cao mã. Điều này có vẻ hiển nhiên, nhưng nó có thểkhông được nhấn mạnh quá mức. Rốt cuộc, có một sự khác biệt giữa mã dễ đọc và mã dễ thay đổi. Dave gắn kết sự sạch sẽ với các bài kiểm tra! Mười năm trước, điều này sẽ khiến rất nhiều người nhướng mày. Nhưng kỷ luật về Phát triển theo hướng kiểm tra đã có tác động sâu sắc đến

và đã trở thành một trong những ngành cơ bản nhất của chúng tôi. Dave nói đúng. Mã, không có thử nghiệm, không phải là sạch sẽ. Cho dù nó có trang nhã đến đâu, cho dù nó có thể đọc được và tích hợp ... sible, nếu nó không thử nghiệm, nó là ô uế. Dave sử dụng từ tối thiểu hai lần. Rõ ràng anh ấy coi trọng mã nhỏ, đúng hơn là hơn mã lớn. Thật vậy, đây là một quy tắc phổ biến trong suốt phiên bản phần mềmchắc chắn kể từ khi thành lập. Nhỏ hơn là tốt hơn. Dave cũng nói rằng mã nên biết chữ . Đây là một tham chiếu mềm cho Knuth biết chữ lập trình.  4 Kết quả là mã phải được soạn thảo ở dạng sao cho nó có thể đọc được bởi con người. 4. [Knuth92].

www.it-ebooks.info

Trang 41 10 Chương 1: Mã sạch Michael Feathers, tác giả của Working Hiệu quả với Mã kế thừa Tôi có thể liệt kê tất cả những phẩm chất mà tôi nhận thấy ở mã sạch, nhưng có một chất lượng bao trùm dẫn đến tất cả chúng.  Luôn làm sạch mã có vẻ như nó được viết bởi một người quan tâm. Không có gì rõ ràng mà bạn có thể làm để lam no tôt hơn. Tất cả những điều đó đã được suy nghĩ về tác giả của mã và nếu bạn cố gắng tưởng tượng những cải tiến, bạn sẽ quay trở lại bạn đang ở đâu, ngồi đánh giá cao mã ai đó để lại cho bạn — mã do ai đó để lạimột người quan tâm sâu sắc đến nghề thủ công.

Một từ: quan tâm. Đó thực sự là chủ đề của Cuốn sách này. Có lẽ một phụ đề thích hợp sẽ là Cách Chăm sóc Mã . Michael đánh nó vào đầu. Mã sạch là mã đã được chăm sóc. Ai đó đã dành thời gian để giữ cho nó đơn giản và có trật tự. Họ đã chú ý thích đáng đến các chi tiết. Họ đã quan tâm. Ron Jeffries, tác giả của Lập trình cực đoan Đã cài đặt và lập trình cực đoan Những cuộc phiêu lưu trong C # Ron bắt đầu lập trình sự nghiệp của mình ở Fortran tại Bộ Tư lệnh Không quân Chiến lược và đã viết mã trong hầu hết mọi ngôn ngữ và trên hầu hết mọi máy móc. Nó trả tiền để xem xét lời nói của mình một cách cẩn thận. Trong những năm gần đây, tôi bắt đầu và gần kết thúc, với Beck's quy tắc của mã đơn giản.  Theo thứ tự ưu tiên, mã đơn giản: • Chạy tất cả các bài kiểm tra; • Không chứa trùng lặp; • Thể hiện tất cả các ý tưởng thiết kế có trong hệ thống; • Giảm thiểu số lượng các thực thể như lớp, các phương thức, hàm và những thứ tương tự. Trong số này, tôi chủ yếu tập trung vào sự trùng lặp. Khi điều tương tự được thực hiện lặp đi lặp lại, đó là một dấu hiệu cho thấy trong đầu chúng ta có một ý tưởng không được thể hiện rõ trong mã.  Tôi cố gắng để tìm ra nó là gì. Sau đó, tôi cố gắng diễn đạt ý tưởng đó rõ ràng hơn. Tính biểu cảm đối với tôi bao gồm những cái tên có ý nghĩa và tôi có khả năng thay đổi tên của mọi thứ nhiều lần trước khi tôi ổn định. Với các công cụ mã hóa hiện đại như Eclipse, đổi tên khá rẻ, vì vậy tôi không gặp khó khăn gì khi thay đổi.  Biểu cảm đi

www.it-ebooks.info

Trang 42

11 Tổng chi phí sở hữu một tin nhắn ngoài tên, tuy nhiên. Tôi cũng xem xét liệu một đối tượng hoặc phương thức có đang thực hiện nhiều hơn một Điều. Nếu đó là một đối tượng, có lẽ nó cần được chia thành hai hoặc nhiều đối tượng.  Nếu đó là một , tôi sẽ luôn sử dụng cấu trúc lại Phương pháp trích xuất trên nó, dẫn đến một phương thức điều đó nói rõ hơn những gì nó làm, và một số điểm phụ cho biết nó được thực hiện như thế nào. Sự trùng lặp và biểu cảm đưa tôi đi một chặng đường dài để tìm hiểu những gì tôi cho là sạch sẽ mã và cải thiện mã bẩn chỉ với hai điều này có thể tạo ra sự khác biệt lớnence.  Tuy nhiên, có một việc khác mà tôi biết là phải làm, khó hơn một chút giải thích. Sau nhiều năm làm công việc này, đối với tôi dường như tất cả các chương trình đều được tạo thành từ rất các yếu tố tương tự. Một ví dụ là "tìm những thứ trong một bộ sưu tập."  Cho dù chúng ta có một dữ liệucơ sở của các bản ghi nhân viên hoặc một bản đồ băm gồm các khóa và giá trị, hoặc một mảng các mục của một số loại, chúng tôi thường thấy mình muốn một món đồ cụ thể từ bộ sưu tập đó. Khi tôi tìm thấy điều đó xảy ra, tôi thường sẽ kết thúc việc triển khai cụ thể trong một phương thức trừu tượng hơn hoặc lớp học.  Điều đó mang lại cho tôi một vài lợi thế thú vị. Tôi có thể triển khai chức năng ngay bây giờ với một cái gì đó đơn giản, chẳng hạn như bản đồ băm, nhưng vì bây giờ tất cả các tham chiếu đến tìm kiếm đó được bao phủ bởi sự trừu tượng nhỏ của tôi, tôi có thể thay đổi việc triển khai bất kỳ lúc nào tôi muốn. Tôi có thể tiến lên nhanh chóng trong khi vẫn bảo toàn khả năng thay đổi sau này. Ngoài ra, phần tóm tắt của bộ sưu tập thường thu hút sự chú ý của tôi đến những gì "thực sự" tiếp tục và giúp tôi không đi vào con đường thực hiện thu thập tùy tiện hành vi khi tất cả những gì tôi thực sự cần là một vài cách khá đơn giản để tìm thấy những gì tôi muốn. Giảm sự trùng lặp, tính biểu cảm cao và sớm xây dựng được các câu chuyện trừu tượng đơn giản. Đó là những gì tạo nên mã sạch cho tôi.

Ở đây, trong một vài đoạn văn ngắn, Ron đã tóm tắt nội dung của cuốn sách này. Không sự trùng lặp, một sự vật, tính biểu cảm, sự trừu tượng nhỏ. Mọi thứ đều ở đó. Ward Cunningham, người phát minh ra Wiki, người phát minh ra Fit, người phát minh ra eXtreme Lập trình. Động lực đằng sau Mẫu thiết kế. Smalltalk và OO lãnh đạo tư tưởng. Cha đỡ đầu của tất cả những người quan tâm đến mã. Bạn biết rằng bạn đang làm việc trên mã sạch khi mỗi thói quen bạn đọc hóa ra là khá nhiều Bạn mong đợi.  Bạn có thể gọi nó là mã đẹp khi mã cũng làm cho nó giống như ngôn ngữ được thực hiện cho vấn đề.

Những phát biểu như thế này là đặc trưng của Ward. Bạn đọc nó, gật đầu và sau đó tiếp tục chủ đề tiếp theo. Nghe có vẻ hợp lý, quá rõ ràng, đến nỗi nó hầu như không đăng ký như một thứ gì đó thâm thúy. Bạn có thể nghĩ rằng đó là khá nhiều những gì bạn mong đợi. Nhưng chúng ta hãy xem xét kỹ hơn nhìn. www.it-ebooks.info

Trang 43 12 Chương 1: Mã sạch “. . . khá nhiều những gì bạn mong đợi. ” Lần cuối cùng bạn thấy một mô-đun là khá nhiều những gì bạn mong đợi? Có nhiều khả năng là các mô-đun bạn nhìn vào sẽ là khó hiểu, phức tạp, rối? Không phải là đi sai hướng là quy tắc? Bạn không quen với việc thất bại về việc cố gắng nắm bắt và nắm giữ các chuỗi lý luận phát ra từ toàn bộ hệ thốngtem và dệt theo cách của họ thông qua mô-đun bạn đang đọc? Lần cuối cùng bạn là khi nào đọc qua một số mã và gật đầu theo cách bạn có thể đã gật đầu tại tuyên bố của Ward? Ward hy vọng rằng khi bạn đọc mã sạch, bạn sẽ không ngạc nhiên chút nào. Thật vậy, bạn thậm chí sẽ không tốn nhiều công sức. Bạn sẽ đọc nó, và nó sẽ là những gì bạn hy vọng. Nó sẽ rõ ràng, đơn giản và hấp dẫn. Mỗi mô-đun sẽ tạo tiền đề cho tiếp theo. Mỗi phần cho bạn biết cách viết tiếp theo. Các chương trình được rằng sạch rất

được viết sâu sắc mà bạn thậm chí không nhận thấy nó. Nhà thiết kế làm cho nó trông lố bịchđơn giản đến mức như tất cả các thiết kế đặc biệt. Và quan niệm của Ward về cái đẹp thì sao? Tất cả chúng ta đều chống lại sự thật rằng lan của chúng tagu thời trang không được thiết kế cho các vấn đề của chúng tôi. Nhưng lời tuyên bố của Ward đã gây trở ngại cho chúng tôi. Anh ấy nói rằng mã đẹp làm cho ngôn ngữ giống như nó được tạo ra cho vấn đề ! Vì thế đó là chúng tôi có trách nhiệm để làm cho ngôn ngữ cái nhìn đơn giản! Ngôn ngữ lớn ở khắp mọi nơi, hãy cẩn thận! Nó không phải là ngôn ngữ làm cho các chương trình có vẻ đơn giản. Đó là lập trình viên làm cho ngôn ngữ có vẻ đơn giản!

Trường học trong tưởng tượng Còn tôi (chú Bob) thì sao? Tôi nghĩ gì mã sạch là? Cuốn sách này sẽ cho bạn biết, một cách ghê tởm chi tiết, những gì tôi và đồng bào của tôi nghĩ về mã sạch. Chúng tôi sẽ cho bạn biết những gì chúng tôi nghĩ tạo ra tên biến sạch, hàm sạch, sạch lớp học, v.v. Chúng tôi sẽ trình bày những ý kiến này như làlutes, và chúng tôi sẽ không xin lỗi vì sự ngoan cố của chúng tôi. Đối với chúng tôi, vào thời điểm này trong sự nghiệp của chúng tôi, họ là absođàn luýt. Họ là trường phái suy nghĩ của chúng tôi về sạch sẽ mã. Không phải tất cả các võ sĩ đều đồng ý về điều tốt nhất võ thuật hoặc kỹ thuật tốt nhất trong một môn võ nghệ thuật. Thường thì các võ sĩ bậc thầy sẽ hình thành trường tư tưởng riêng và tập hợp sinh viên để học hỏi từ họ. Vì vậy, chúng ta thấy Gracie Jiu Jistu , được thành lập và giảng dạy bởi gia đình Gracie ở Brazil. Chúng tôi thấy Hakkoryu Jiu Jistu , được thành lập và được dạy bởi Okuyama Ryuho ở Tokyo. Chúng tôi thấy Jeet Kune Do , được thành lập và giảng dạy bởi Lý Tiểu Long ở Hoa Kỳ. www.it-ebooks.info

Trang 44 13 Chúng tôi là tác giả Học sinh của những cách tiếp cận này đắm mình trong những lời dạy của người sáng lập. Họ cống hiến hết mình để học những gì mà vị sư phụ cụ thể đó dạy, thường là để ... sự giảng dạy của bất kỳ bậc thầy nào khác. Sau đó, khi các sinh viên phát triển trong lĩnh vực nghệ thuật của họ, họ có thể trở thành học viên của một bậc thầy khác để họ có thể mở rộng kiến thức và thực hành. Một số cuối cùng tiếp tục trau dồi kỹ năng, khám phá các kỹ thuật mới và sáng lập các trường học riêng. Không có trường phái khác nhau nào là hoàn toàn đúng . Tuy nhiên, trong một trường học cụ thể, chúng tôi hành động như thể những lời dạy và kỹ thuật là đúng. Rốt cuộc, có một cách đúng để luyện tập tice Hakkoryu Jiu Jitsu, hoặc Jeet Kune Do. Nhưng sự đúng đắn này trong một trường học không phải là vô hạicoi thường những lời dạy của một trường khác. Hãy coi cuốn sách này là một mô tả về Trường học Mã sạch của Cố vấn Đối tượng . Các kỹ thuật và dạy trong là cách mà chúng ta thực hành của chúng tôi nghệ thuật. Chúng tôi sẵn sàng tuyên bố rằng nếu bạn làm theo những lời dạy này, bạn sẽ được hưởng những lợi ích mà chúng tôi đã được hưởng, và bạn sẽ học cách viết mã sạch sẽ và chuyên nghiệp. Nhưng đừng mắc sai lầm nghĩ rằng bằng cách nào đó chúng ta “đúng” theo bất kỳ nghĩa tuyệt đối nào. Có những trường khác và những bậc thầy khác có nhiều tuyên bố về tính chuyên nghiệp như chúng tôi. Nó sẽ yêu bạn để học hỏi từ họ. Thật vậy, nhiều khuyến nghị trong cuốn sách này đang gây tranh cãi. Bạn sẽ thăm dòbly không đồng ý với tất cả chúng. Bạn có thể không đồng ý với một số người trong số họ. Tốt rồi. Chúng tôi không thể yêu cầu thẩm quyền cuối cùng. Mặt khác, các khuyến nghị trong cuốn sách này là những điều mà chúng tôi đã suy nghĩ rất lâu và khó khăn. Chúng tôi đã học chúng qua nhiều thập kỷ

kinh nghiệm và thử và sai lặp lại. Vì vậy, cho dù bạn đồng ý hay không đồng ý, nó sẽ là một xấu hổ nếu bạn không nhìn thấy, và tôn trọng, quan điểm của chúng tôi.

Chúng tôi là tác giả Trường @author của Javadoc cho chúng ta biết chúng ta là ai. Chúng tôi là tác giả. Và một điều về tác giả là họ có độc giả. Thật vậy, các tác giả có trách nhiệm giao tiếp tốt với độc giả của họ. Lần tới khi bạn viết một dòng mã, hãy nhớ rằng bạn là tác giả, viết cho người đọc, những người sẽ đánh giá nỗ lực của bạn. Bạn có thể hỏi: Thực sự đọc được bao nhiêu mã? Không phải hầu hết các nỗ lực đều đi vào viết nó? Bạn đã bao giờ phát lại một phiên chỉnh sửa chưa? Trong những năm 80 và 90, chúng tôi có những biên tập viên như Emacs theo dõi mọi lần gõ phím. Bạn có thể làm việc trong một giờ và sau đó phát lại toàn bộ chỉnh sửa phiên như một bộ phim tốc độ cao. Khi tôi làm điều này, kết quả thật hấp dẫn. Phần lớn quá trình phát lại là cuộn và điều hướng đến các mô-đun khác! Bob vào mô-đun. Anh ta cuộn xuống chức năng cần thay đổi. Anh dừng lại, cân nhắc các lựa chọn của mình. Ồ, anh ta đang cuộn lên đầu mô-đun để kiểm tra việc khởi tạo một biến. Bây giờ anh ấy cuộn xuống và bắt đầu nhập.

www.it-ebooks.info

Trang 45 14 Chương 1: Mã sạch Rất tiếc, anh ấy đang xóa những gì anh ấy đã nhập! Anh ấy gõ lại. Anh ấy lại xóa nó đi! Anh ta gõ một nửa thứ khác nhưng sau đó xóa đi! Anh ấy cuộn xuống một hàm khác gọi hàm mà anh ấy đang thay đổi để xem nó như thế nào gọi là. Anh ấy cuộn lại và nhập mã giống như anh ấy vừa xóa. Anh ta dừng lại. Anh ấy lại xóa mã đó! Anh ấy bật lên một cửa sổ khác và nhìn vào một lớp con.  Chức năng đó có bị ghi đè không?

. . . Bạn nhận được sự trôi dạt. Thật vậy, tỷ lệ thời gian dành cho việc đọc và viết là hơn 10: 1. Chúng tôi liên tục đọc mã cũ như một phần của nỗ lực viết mã mới. Bởi vì tỷ lệ này rất cao, chúng tôi muốn việc đọc mã trở nên dễ dàng, ngay cả khi nó khiến viết khó hơn. Tất nhiên không có cách nào để viết mã mà không đọc nó, vì vậy hãy làm cho nó dễ đọc thực sự làm cho nó dễ viết hơn . Không có lối thoát khỏi logic này. Bạn không thể viết mã nếu bạn không thể đọc surlàm tròn mã. Mã bạn đang cố gắng viết hôm nay sẽ khó hoặc dễ viết tùy thuộc vào độ khó hay dễ đọc của mã xung quanh. Vì vậy, nếu bạn muốn đi nhanh, nếu bạn muốn hoàn thành nhanh chóng, nếu bạn muốn mã của mình dễ viết, hãy làm cho nó dễ dàng đọc.

Quy tắc hướng đạo sinh Nó không đủ để viết mã tốt. Mã phải được giữ sạch sẽ theo thời gian. Chúng tôi có tất cả đã thấy mã bị thối rữa và xuống cấp theo thời gian. Vì vậy, chúng ta phải có vai trò tích cực trong việc ngăn chặn suy thoái. Hội Nam Hướng đạo Hoa Kỳ có một quy tắc đơn giản mà chúng ta có thể áp dụng cho nghề nghiệp của mình. Để khu cắm trại sạch hơn bạn đã tìm thấy.  5

Nếu tất cả chúng ta đã kiểm tra mã của mình gọn gàng hơn một chút so với khi chúng ta kiểm tra, thì mã đơn giản là không thể thối rữa. Việc dọn dẹp không cần phải là một cái gì đó lớn lao. Thay đổi một biến đặt tên cho tốt hơn, chia nhỏ một hàm quá lớn, loại bỏ một hàm nhỏ sao chép, xóa một câu lệnh if tổng hợp . Bạn có thể tưởng tượng làm việc trong một dự án mà mã đơn giản trở nên tốt hơn theo thời gian thông qua? Bạn có tin rằng bất kỳ lựa chọn nào khác là chuyên nghiệp? Thật vậy, không liên tục

cải thiện một phần nội tại của tính chuyên nghiệp? 5. Điều này được phỏng theo lời nhắn từ biệt của Robert Stephenson Smyth Baden-Powell đối với các Hướng đạo sinh: “Hãy cố gắng và rời khỏi thế giới này a tốt hơn một chút so với bạn tìm thấy nó. . . ”

www.it-ebooks.info

Trang 46 15 Thư mục

Phần tiền truyện và nguyên tắc Theo nhiều cách, cuốn sách này là “phần tiền truyện” của cuốn sách tôi viết năm 2002 có tựa đề Phần mềm Agile Phát triển: Nguyên tắc, Mô hình và Thực hành (PPP). Cuốn sách về PPP liên quan đến chính nó với các nguyên tắc của thiết kế hướng đối tượng và nhiều phương pháp được sử dụng bởi các cấu các nhà phát triển sional. Nếu bạn chưa đọc PPP, thì bạn có thể thấy rằng nó tiếp tục câu chuyện nói bởi cuốn sách này. Nếu bạn đã đọc nó, thì bạn sẽ tìm thấy nhiều tình cảm của cuốn sách đó lặp lại trong cuốn sách này ở cấp độ mã. Trong cuốn sách này, bạn sẽ tìm thấy những tài liệu tham khảo lẻ tẻ về các nguyên tắc thiết kế khác nhau. Những bao gồm Nguyên tắc trách nhiệm duy nhất (SRP), Nguyên tắc đóng mở (OCP) và Nguyên tắc Đảo ngược Phụ thuộc (DIP) cùng những nguyên tắc khác. Những nguyên tắc này được mô tả trong chiều sâu trong PPP.

Phần kết luận Sách về nghệ thuật không hứa hẹn biến bạn thành nghệ sĩ. Tất cả những gì họ có thể làm là cung cấp cho bạn một số các công cụ, kỹ thuật và quy trình suy nghĩ mà các nghệ sĩ khác đã sử dụng. Vì vậy, cuốn sách này cũng có thểkhông hứa sẽ biến bạn trở thành một lập trình viên giỏi. Nó không thể hứa sẽ cung cấp cho bạn “mã cảm giác”. Tất cả những gì nó có thể làm là cho bạn thấy quy trình suy nghĩ của các lập trình viên giỏi và các thủ thuật, công nghệniques và các công cụ mà họ sử dụng. Cũng giống như một cuốn sách về nghệ thuật, cuốn sách này sẽ có đầy đủ các chi tiết. Sẽ có rất nhiều mã. Bạn sẽ thấy mã tốt và bạn sẽ thấy mã xấu. Bạn sẽ thấy mã xấu được chuyển thành mã tốt mã. Bạn sẽ thấy danh sách các kinh nghiệm học, các nguyên tắc và kỹ thuật. Bạn sẽ thấy ví dụ sau thí dụ. Sau đó, tùy thuộc vào bạn. Hãy nhớ câu chuyện cười cũ về người nghệ sĩ vĩ cầm trong buổi hòa nhạc đã bị lạc trên đường đến một trung tâm ... mance? Anh ta dừng một ông già ở góc đường và hỏi ông ta làm thế nào để đến Carnegie Hall. Ông lão nhìn người nghệ sĩ vĩ cầm và cây đàn vĩ cầm được kẹp dưới cánh tay ông ta, và nói: "Thực ... tice, con trai. Thực hành!"

Thư mục [Beck07]: Các mẫu triển khai , Kent Beck, Addison-Wesley, 2007. [Knuth92]: Lập trình chữ , Donald E. Knuth, Trung tâm Nghiên cứu Ngôn ngữ và Thông tin, Đại học Leland Stanford Junior, 1992. www.it-ebooks.info

Trang 47 Trang này cố ý để trống www.it-ebooks.info

Trang 48 17

2 Tên có ý nghĩa

bởi Tim Ottinger

Giới thiệu Tên có ở khắp mọi nơi trong phần mềm. Chúng tôi đặt tên cho các biến, các hàm của chúng tôi, các đối số của chúng tôi, các lớp và các gói. Chúng tôi đặt tên cho các tệp nguồn của mình và các thư mục chứa chúng. Chúng tôi đặt tên cho các tệp jar và tệp chiến tranh và tệp tai của chúng tôi. Chúng tôi đặt tên và đặt tên và đặt tên. Bởi vì chúng tôi làm www.it-ebooks.info

Trang 49 18 Chương 2: Những cái tên có ý nghĩa rất nhiều, chúng ta nên làm tốt hơn. Sau đây là một số quy tắc đơn giản để tạo những cái tên hay.

Sử dụng tên có ý định tiết lộ Có thể dễ dàng nói rằng những cái tên nên bộc lộ ý định. Điều chúng tôi muốn gây ấn tượng với bạn là chúng tôi rất nghiêm túc về điều này. Việc chọn những cái tên hay tuy mất thời gian nhưng tiết kiệm được nhiều thời gian hơn. Vì vậy, hãy cẩn thận với tên của bạn và thay đổi chúng khi bạn tìm thấy những tên tốt hơn. Mọi người đọc mã của bạn (bao gồm cả bạn) sẽ hạnh phúc hơn nếu bạn làm vậy. Tên của một biến, hàm hoặc lớp, phải trả lời tất cả các câu hỏi lớn. Nó sẽ cho bạn biết tại sao nó tồn tại, nó làm gì và nó được sử dụng như thế nào. Nếu một tên yêu cầu một comthì cái tên không tiết lộ ý định của nó. int d; // thời gian trôi qua tính bằng ngày Tên d không tiết lộ gì. Nó không gợi lên cảm giác về thời gian đã trôi qua, cũng không phải ngày. Chúng tôi

nên chọn một tên chỉ định những gì đang được đo lường và đơn vị của phép đo đóđề cập: int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;

Chọn tên thể hiện ý định có thể giúp bạn dễ hiểu và dễ thay đổi hơn nhiều mã. Mục đích của mã này là gì? danh sách công khai getThem () { List list1 = new ArrayList (); cho (int [] x: theList) nếu (x [0] == 4) list1.add (x); danh sách trả về1; }

Tại sao rất khó để biết mã này đang làm gì? Không có biểu thức phức tạp. Khoảng cách và thụt lề hợp lý. Chỉ có ba biến và hai hằng đề cập. Thậm chí không có bất kỳ lớp ưa thích hoặc phương thức đa hình nào, chỉ là một danh sách mảng (hoặc có vẻ như vậy). Vấn đề không phải là sự đơn giản của mã mà là sự không rõ ràng của mã (đồng xu cụm từ): mức độ mà ngữ cảnh không rõ ràng trong chính mã. Mã ngụ ýđiều đó đòi hỏi chúng ta phải biết câu trả lời cho những câu hỏi như: 1. Những loại thứ gì trong danh sách ? 2. Ý nghĩa của chỉ số con thứ 0 của một mục trong Danh sách ? 3. Ý nghĩa của giá trị 4 là gì? 4. Tôi sẽ sử dụng danh sách đang được trả về như thế nào? www.it-ebooks.info

Trang 50 19 Tránh thông tin sai lệch

Câu trả lời cho những câu hỏi này không có trong mẫu mã, nhưng chúng có thể có đã . Giả sử rằng chúng tôi đang làm việc trong một trò chơi quét mìn. Chúng tôi thấy rằng hội đồng quản trị là một danh sách các ô được gọi là danh sách . Hãy đổi tên nó thành gameBoard . Mỗi ô trên bảng được biểu diễn bằng một mảng đơn giản. Chúng tôi còn thấy rằng số 0 chỉ số dưới là vị trí của giá trị trạng thái và giá trị trạng thái bằng 4 có nghĩa là “được gắn cờ”. Chỉ bằng cách đặt tên cho các khái niệm này, chúng tôi có thể cải thiện mã đáng kể: public List getFlaggedCells () { Danh sách flaggedCells = new ArrayList (); cho (int [] cell: gameBoard) if (ô [STATUS_VALUE] == FLAGGED) flaggedCells.add (ô); trả về flaggedCells; }

Lưu ý rằng tính đơn giản của mã không thay đổi. Nó vẫn có cùng một số toán tử và hằng số, với số lượng cấp lồng nhau chính xác. Nhưng mã đã trở nên rõ ràng hơn nhiều. Chúng ta có thể đi xa hơn và viết một lớp đơn giản cho các ô thay vì sử dụng một mảng int s. Nó có thể bao gồm một chức năng tiết lộ ý định (gọi nó là Được gắn thẻ ) để ẩn số ma thuật bia. Nó dẫn đến một phiên bản mới của hàm: danh sách công khai getFlaggedCells () { Danh sách flaggedCells = new ArrayList (); cho (Ô ô: gameBoard) if (cell.isFlagged ()) flaggedCells.add (ô); trả về flaggedCells; }

Với những thay đổi tên đơn giản này, không khó để hiểu chuyện gì đang xảy ra. Đây là sức mạnh của việc lựa chọn những cái tên hay.

Tránh thông tin sai lệch Lập trình viên phải tránh để lại các manh mối sai làm che khuất ý nghĩa của mã. Chúng ta nên tránh những từ có nghĩa cố định khác với ý nghĩa của chúng ta. Ví dụ, hp , aix , và sco sẽ là các tên biến kém vì chúng là tên của Unix platcác dạng hoặc biến thể. Ngay cả khi bạn đang mã hóa một cạnh huyền và hp trông giống như một chữ viết tắt haytion, nó có thể không đúng định dạng. Không đề cập đến một nhóm tài khoản dưới dạng Danh sách tài khoản trừ khi đó thực sự là Danh sách . Danh sách từ có nghĩa là một cái gì đó cụ thể cho các lập trình viên. Nếu thùng chứa tài khoản thực sự không phải là một Danh sách , nó có thể dẫn đến kết luận sai. 1 Vì vậy accountGroup hoặc chùmOfAccounts hoặc chỉ là tài khoản thuần túy sẽ tốt hơn. 1. Như chúng ta sẽ thấy ở phần sau, ngay cả khi vùng chứa là một Danh sách, có lẽ tốt hơn là không nên mã hóa loại vùng chứa vào tên.

www.it-ebooks.info

Trang 51 20 Chương 2: Những cái tên có ý nghĩa Hãy cẩn thận khi sử dụng các tên khác nhau theo những cách nhỏ. Mất bao lâu để phát hiện ra sự khác biệt tinh tế giữa XYZControllerForEnoughHandlingOfStrings trong một mô-đun và ở đâu đó xa hơn một chút, XYZControllerForEnoughStorageOfStrings ? Các các từ có hình dạng giống nhau một cách đáng sợ. Đánh vần các khái niệm tương tự tương tự là thông tin . Sử dụng cách viết không phù hợp là disthông tin . Với môi trường Java hiện đại, chúng tôi tận hưởng khả năng hoàn thành mã tự động. Chúng tôi viết một vài ký tự của tên và nhấn một số tổ hợp phím nóng (nếu có) và được được thưởng bằng một danh sách các hoàn thành có thể có cho tên đó. Sẽ rất hữu ích nếu tên cho những thứ rất giống nhau sắp xếp cùng nhau theo bảng chữ cái và nếu sự khác biệt là rất rõ ràng, bởi vì nhà phát triển có thể chọn một đối tượng theo tên mà không thấy nhận xét hoặc thậm chí danh sách các phương thức được cung cấp bởi lớp đó. Một ví dụ thực sự khủng khiếp về những cái tên không phù hợp là việc sử dụng chữ L viết thường hoặc

chữ hoa O làm tên biến, đặc biệt là sự kết hợp. Tất nhiên, vấn đề là chúng trông gần như hoàn toàn giống các hằng số một và số không. int a = l; nếu (O == l) a = O1; khác l = 01;

Người đọc có thể nghĩ đây là một sự liên quan, nhưng chúng tôi đã kiểm tra mã khi mọi thứ rất phong phú. Trong một trường hợp, tác giả của mã đề xuất sử dụng một phông chữ khác để sự khác biệt rõ ràng hơn, một giải pháp sẽ phải được chuyển giao cho tất cả các nhà phát triển tương lai dưới dạng truyền miệng hoặc trong một tài liệu bằng văn bản. Vấn đề được chinh phục có tính hoàn thiện và không cần tạo ra các sản phẩm công việc mới bằng cách đổi tên đơn giản.

Làm cho ý nghĩa Sự khác biệt Lập trình viên tạo ra vấn đề cho họbản thân khi họ chỉ viết mã cho satisfy một trình biên dịch hoặc trình thông dịch. Ví dụ, bởi vì bạn không thể sử dụng cùng một tên để giới thiệu đến hai thứ khác nhau trong cùng một phạm vi, bạn có thể bị cám dỗ để thay đổi một cái tên một cách tùy ý. Đôi khi điều này được thực hiện bằng cách viết sai chính tả, dẫn đến tình huống sửa lỗi chính tả dẫn đến không biên dịch được. 2 Không đủ để thêm chuỗi số hoặc các từ nhiễu, mặc dù trình biên dịch hài lòng. Nếu các tên phải khác nhau, thì chúng cũng phải có nghĩa khác. 2. Hãy xem xét, ví dụ, hành động thực sự ghê tởm là tạo một biến có tên klass chỉ vì lớp tên đã được sử dụng cho một cái gì đó khác.

www.it-ebooks.info

Trang 52 21 Sử dụng tên có thể phát âm Đặt tên theo dãy số (a1, a2, .. aN) ngược lại với đặt tên có chủ đích. Như là tên không sai định dạng — chúng không có định dạng; họ không cung cấp manh mối cho ý định của tác giả. Xem xét: public static void copyChars (char a1 [], char a2 []) { for (int i = 0; i