Tóm tắt/ Review sách: "The Clean Coder" - Robert C.Martin

Giới thiệu:

The clean coder là một trong những quyển sách các lập trình viên nên đọc, được viết bởi Robert C.Martin hay còn gọi là Uncle Bob, một người cực kỳ nổi tiếng trong giới lập trình trên thế giới. Sách này là một quyển dành cho Lập trình viên nhưng không nói về khía cạnh kỹ thuật mà nói về khía cạnh nghề nghiệp.

Trong 14 chương bạn sẽ được tác giả kể lại những mẫu chuyện mà chính ông đã trải qua trong quá trình phát triển sự nghiệp của bản thân mình và đưa ra những lời khuyên, những bài học xương máu mà ông rút ra được từ những câu chuyện đó. Sau đây mình sẽ tóm tắt lại những nội dung mà mình thấy hay nhất sau khi đọc hết 14 chương của quyển này (trong gần 3 tháng @@)

Nội dung:

Summary chap 1: Professionalism

Chương này nói về một từ có thể coi là chuẩn mực mà ai cũng muốn đạt tới - professionalism: tính chuyên nghiệp. Và tác giả đã định nghĩ từ chuyên nghiệp như sau:

“Chuyên nghiệp đơn giản là biết chịu trách nhiệm”

và lấy một hình mẫu điển hình cho devoloper chuyên nghiệp như sau:

"If a nonprofessional makes an error, the employer cleans up the mess. But when a professional makes a mistake, he cleans up the mess.”

Ngoài ra trong chương này, Uncle Bob còn nhắc đến một vấn đề nữa đó là “Work Ethic” - Đạo đức làm việc. Sự nghiệp của bạn là trách nhiệm của bạn chứ ko phải của employer. Sẽ có một số ông chủ sẽ training cho bạn, mua sách cho bạn đọc, cử bạn đến các conference, điều đó rất tốt nhưng bạn ko bao giờ được lầm tưởng rằng đó là trách nhiệm của họ. Một tuần bạn làm cho những ông chủ 5 ngày, mỗi ngày 8h thì hãy sử dụng hết 40h đó để giải quyết việc của employer chứ không phải của bạn. Uncle Bob khuyên rằng, mỗi tuần nên giành 60h để làm việc, trong đó 40h cho employer, 20h còn lại để phát triển sự nghiệp cá nhân bằng cách đọc sách, thực hành, học những điều mới….

Summary chap 2: Saying No

Chương này tóm gọn lại thành một câu như sau: “Một lập trình viên chuyên nghiệp là người phải biết nói “Không””.

Quote: "Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no."

Summary chap 3: Saying Yes

Chương này dường như nội dung ngược lại với chương 2, chương này nói về việc nó “có” - saying yes. Trong chương này Bob giới thiệu thế nào là một lời cam kết - commitment. Ông cho rằng cam kết gồm 3 phần: Say-mean-do. Ngoài ra tác giả còn mô tả một lời cam kết sẽ có dạng thế nào? Đó là “I will….by…” -“ Tôi sẽ làm gì đó vào lúc nào”. Ví dụ: Tôi sẽ hoàn thành tính năng đó trước thứ 2 tuần sau. Cam kết thể hiện rõ ràng rằng: bạn sẽ thực hiện một việc gì đó vào một thời gian rõ ràng.

Kết luận cuối cùng của ông rằng: “Một lập trình viên CHUYÊN NGHIỆP không nhất thiết phải say yes với bất kì điều gì họ được hỏi. Nhưng họ sẽ tìm ra cách tốt nhất để say yes. Và một khi họ đã say yes thì họ dùng ngôn ngữ CAM KẾT để thể hiện rằng không có một chút nghi ngờ nào tồn tại trong lời họ đã hứa”

Summary chap 4: Coding

Chương này tác giả đưa ra một số điều mà ông trải qua khi lập trình. Ví dụ như một số nguyên tắc khi lập trình là

Code của bạn phải chạy được. Bạn phải là người hiểu rõ vấn đề đang giải quyết là gì và giải quyết nó như thế nào
Code của bạn phải giải quyết được vấn đề mà khách hàng đặt ra
Code của bạn phải “fit” với hệ thống đang tồn tại
Code của bạn phải dễ đọc đối với các dev khác

Summary chap 5: Test driven development

Chương này nói hoàn toàn về TDD cũng như unit test. Ông nêu ra 3 luật của TDD đó là:

Bạn không được phép viết bất cứ dòng production code nào cho đến khi bạn có unit test đầu tiên fail
Bạn không được phép viết nhiều hơn 1 unit test mà đủ để fail và không compile của là fail
Bạn không được phép viết production code mà vượt quá phạm vi của unit test

Khi bạn áp dụng 3 luật này, một cách triệt để thì bạn đang vận dụng được TDD vào sản phầm của mình. Điều đó đảm bảo rằng mỗi phần product đều fit với test đi kèm như "kháng thể fit với kháng nguyên"

Ngoài ra khi áp dụng TDD bạn sẽ có một số lợi ích như sau:

Tính chắc chắn (Certainty): Khi bạn thay đổi bất cứ dòng code nào và chạy unit test, nếu tất cả pass thì có nghĩ rằng bạn chắc chắn những thay đổi của bạn không hề phá hỏng bất kì gì trong sản phẩm và sự chắc chắn này đủ để bạn ship product đến stage tiếp theo
Giảm được tỷ lệ lỗi (Defect injection rate)
Sự can đảm: Đây là một trong những lợi ích quan trọng nhất của TDD - một khi bạn đã có một bộ unit test tinh tưởng được, thì mọi lo lắng về việc thay đổi sẽ biến mất.
Documentation: Thay vì phải viết những tài liệu dài dòng, thì unit test chính là những tài liệu mô tả thiết kế mức thấp nhất của hệ thống. Và cũng là loại low-level document có thể tồn tại
Design: Khi thực hiện TDD hay unit test, sẽ rất khó khăn nếu bạn viết test cho một hàm mà nó gọi một hàm khác. Nói cách khác, để tránh việc khó khăn khi bạn viết unit test bạn phải nghĩ đến việc bạn có một kiến trúc code tốt

Summary chap 6: Practicing

Chương này tác giả Uncle Bob tập trung nói về những phương pháp mà lập trình viên thực hành. Ông ẩn dụ việc thực hành của dev như là việc luyện tập trong học võ. Trong luyện tập võ, có các hoạt động như Kata, Wasa và Randori. Cụ thể:

Kata: Kata trong lập trình là một chuỗi các thao tác gõ phím và di chuyển chuột để mô phỏng việc giải quyết một vấn đề nào đó. Ví dụ như giải một số các bài toán đơn giản như sort hay search. Việc lặp đi lặp lại các kata sẽ luyện cho não bộ và ngon tay chuyển động và phản ứng. Có rất nhiều nơi để dev luyện tập các kata, điển hình là http://katas.softwarecraftsmanship.org/archive.
Wasa: là một dạng kata-2-người. Lập trình viên thực hành Wasa tương tự như việc chơi bóng bàn.Hai lập trình viên lựa chọn 1 kata hay 1 vấn đề. Một người viết unit test và người còn lại viết code để pass test đó và sau đó 2 người đổi vai trò cho nhau.
Randori: tương tự wasa-2-người. Một “đề bài” hay vấn đề sẽ được chiếu lên màn hình, một người viết unittest rồi người khác làm cho test pass rồi viết unit test mới

Mở rộng kinh nghiệm, những lập trình viên chuyên nghiệp thường thiếu sự đa dạng trong những vấn đề họ giải quyết bởi vì công việc của họ thườn gắn chặt với 1 ngôn ngữ hay platform nào đó. Việc không mở rộng kinh nghiệm sẽ khiến CV của bạn trở nên nghèo nàn đồng thời có lẽ sẽ “làm hạn chế” mindset của bạn. Vì thế, một trong những cách mở rộng tập kinh nghiệm bản thân đó là đóng góp vào các dự án open-source. Bạn có thể tham gia đóng góp vào rất nhiều dự án có sẵn trên github…

Kết luận: Lập trình viên chuyên nghiệp là người luôn luyện tập và thời gian họ thực hành là thời gian riêng của họ chứ không phải giờ làm. “Thực hành là những điều bạn làm mà không được trả công. Tuy nhiên nếu làm điều đó thì bạn sẽ sẽ được trả và trả công xứng đáng"

Summary chap 7: Acceptance test

Requirement là một trong những vấn đề thường gặp nhất trong giao tiếp dev và BA hay stakeholder. Stakeholder hay client chỉ nêu ra những thứ họ cần trong khi dev chỉ làm ra những thứ được mô tả bởi client. Trong thực tế việc giao tiếp để lấy requirement cực kỳ khó khăn và quá trình thường xảy ra lỗi. Business thì mong muốn biết mình sẽ nhận được gì trước khi chạy dự án, còn dev lại muốn biết chính xác output của họ sẽ là gì trước khi estimate dự án. Cả 2 bên đều cần có 1 sự chính xác mà gần như ko thể đạt được nhưng lại tốn nhiều thời gian để làm điều đó.

Có một sự thật là bạn show một tính năng cho business nghĩa là bạn cung cấp cho họ thêm thông tin mà trước đây họ chưa hề có và việc đó ảnh hưởng đến cách họ hiểu về toàn bô hệ thống. Dẫn đến, bạn làm càng chính xác requirement thì hệ thống bạn làm nên càng ít liên quan đến requirement đó

Trong quá trình giao tiếp luôn có những nhập nhằng xảy ra và một lập trình viên chuyên nghiệp có trách nhiệm đảm bảo mọi sự nhập nhằng không rõ ý đều phải bị loại bỏ khỏi requirement. Và acceptance test được sinh ra để làm điều đó. Acceptance test là những test được viết ra bởi sự cộng tác giữa dev và stakeholder để định nghĩa khi nào một requirement được gọi là done ( hoàn thành ).

Summary chap 8: Test strategy

Kiểm thử hệ thống là một điều tốt, tuy nhiên, với chỉ unit test và acceptance test không thôi chưa đủ. Cái cần mà mỗi team phát triển sản phẩm chuyên nghiệp cần đó là một “chiến lược kiểm thử” (test strategy) đủ tốt để có thể đạt được mục tiêu “QA should find nothing”

Chương này tình bày về một số loại test mà khi phát triển sản phẩm cần thực hiện được mô tả qua một kim tự tháp - The test automation pyramid

Trong kim tự tháp này bao gồm Unit test, Component test, Integration test, System test và Manual Exploratory test. Mỗi loại test này có từng chức năng và được thiết kế bởi những vị trí khác nhau trong team phát triển.

TDD và Acceptance test rất hữu ích và cần thiết, nhưng xét cho cùng nó cũng chỉ là một phần của test strategy. Và để đảm bảo được mục tiêu “QA should find nothing” thì cần thiết phải xây dựng và thực hiện một test pyramid như trên. Cuối cùng, những test trên phải được thực hiện thường xuyên để đủ lấy được những phản hồi từ người dùng cũng như đảm bảo hệ thống chạy đúng

Summary chap 9: Time management

Đối với chúng ta, thời gian rất đáng quý, và lập trình viên cũng vậy. Chương này nói về việc quản lý thời gian cũng như giữ được sự tập trung để có thể làm tốt nhất công việc - coding.

Họp: Có 2 sự thật về những cuộc hop: Một là, họp rất cần thiết; Hai là, họp cực kỳ tốn thời gian. Mỗi người time gia họp sẽ mất chi phí chừng 200$/hour. Lập trình viên chuyên nghiệp phải biết được chi phí đắt đỏ của việc họp và sẵn sàng từ chối những cuộc họp nếu nó không đem lại những lợi ích lập tức và đáng kể. Một số nguyên tắc chính:

Từ chối (Declining): Khi bạn nhận một lời mời họp, đừng đồng ý trừ khi sự có mặt của bạn cần thiết cho công việc hiện tại của bạn
Rời khỏi (Leaving): Nguyên tắc đơn giản, khi cuộc họp quá chán, hãy rời khỏi nó (một cách lịch sự)
Có lịch trình và mục tiêu rõ ràng (Have an Agenda and a Goal): Để sử dụng hiệu qủa thời gian của những người tham dự cuộc họp, cần có một agenda rõ ràng về chủ đề cũng như mục đích của buổi họp

Còn đối với những buổi họp của Agile, đối với Scrum daily, mỗi người tham gia phải trả lời 3 câu hỏi thần thánh, mỗi câu hỏi ko nên quá 20s. Vậy nên SCRUM daily không nên kéo dài quá 15min.

Đối với Sprint planning, tác giả nêu ra 1 nguyên tắc: Thời gian planning cho mỗi sprint không nên kéo dài hơn 5% tổng thời gian của sprint đó. Tức là với sprint 1 tuần thì thời gian planning tối đa là 2h

Đối với demo và cải tiến, hai cuộc họp này rất dễ xảy ra phát sinh thời gian, nên tốt nhất nên dùng 20 min cho cuộc họp cải tiến và 25 min cho demo. Và lưu ý, nên sắp xếp 2 buổi họp này vào 45 min cuối cuả ngày kết thúc sprint

Sự tập trung: Lập trình là một công việc trí óc và nó đòi hỏi sự tập trung cao độ. Chúng ta nên code lúc mà sự tập trung tăng cao và hãy làm những việc ít hiệu suất hơn những lúc còn lại. Sự tập trung là "một tài nguyên phân rã”, nếu nó đang có mà bạn không tận dụng được thì nó sẽ mất. Ví dụ, khi bạn đang tập trung cao độ vào buổi họp thì sau khi họp xong, bạn sẽ không đủ tập trung để code. Việc lo lắng hay sự xao nhãng cũng là những nguyên nhân gây mất tập trung. Vì vậy, tác giả có đề xuất một số các để có được sự tập trung như sau:

Ngủ: Những người chuyên nghiệp quản lý lịch ngủ của họ để đảm bảo ràng họ sẽ có sự tập trung cao nhất vào sáng làm việc hôm sau
Caffein: Caffein trong cà phê hay nước tăng lực là một trong những cách giữ sự tập trung hiệu quả cũng như chống buồn ngủ. Nhưng phải cẩn thận, caffein có thể thêm một số thứ không liên quan vào thời điểm tập trung cao của bạn; quá nhiều caffein có thể dẫn đến bạn đặt sự tập trung của bạn vào sai hướng 😀
Tái tạo sự tập trung: Sự tập trung có thể được tái tạo bằng cách “mất tập trung” - de-focussing. Bạn có thể đi dạo, nói chuyện với đồng nghiệp, đọc báo, hay thiền để lấy lại sự tập trung. Khi sự tập trung đã mất thì bạn không thể bắt buộc cơ thể bạn tập trung trở lại. Bạn vẫn có thể code khi đang mất tập trung nhưng bạn sẽ phải re-work vào ngày hôm sau hay đống code đó sẽ trở nên messy sau vài tuần hay vài tháng
Muscle focus: Băng cách nào đó muscle focus có thể giúp tái tạo sự tập trung. Bạn có thể tập vài động tác võ, hay yoga từ đó giúp cơ thể lấy lại được sự tập trung tinh thần.

Time boxing and tomatos: Phần này giới thiệu về một phương pháp quản lý thời gian khá hay tên là Pomodoro. Cơ bản là sẽ chia thời gian thành từng box nhỏ 25min, và cố gắng tập trung trong 25 min đó, sau mỗi box sẽ nghỉ 5 min và tiếp tục đến box khác. Mình sẽ có bài viết về phương pháp này sau^^
Sự né tránh (Avoidance): có một hiện tượng mọi ng rất hay gặp đó là Đảo ưu tiên - Priority Inversion. Khi bị hiện tượng này người ta thường tìm một nguyên nhân nào đó để né tránh công việc hiện tại. Bạn tự thuyết phục bạn thân rằng có một việc khác gấp hơn việc bạn đang làm và bạn tăng ưu tiên cho việc đó để trì hoãn việc bạn đang làm với đúng độ ưu tiên. Điều này rõ ràng là rất thiếu chuyên nghiệp. Người chuyên nghiệp sẽ đánh giá độ ưu tiên của từng task mà không để ý đến những nỗi sợ hãi hay mong muốn cá nhân, và cố gắng thực hiện những task đó theo đúng thứ tự của nó.

Summary chap 10: Estimation

Theo Uncle Bob, estimation là những hoạt động rất đơn giản nhưng cũng rất khủng khiếp mà lập trình viên phải đối mặt. Những giá trị kinh doanh phụ thuộc vào nó. Danh tiếng của lập trình viên dựa vào nó và những lo lắng cũng như thất bại cũng từ nó mà ra.

Ông cho rằng, estimation được nhìn nhận bởi 2 góc nhìn khác nhau. Business coi estimation như là là những commitment hay lời cam kết còn dev lại coi estimation là những dự đoán.

Cam kết nói về những thứ bạn phải đạt được, hay nói về sự chắc chắn. Những lập trình viên chuyên nghiệp không bao giờ cam kết nếu họ không chắc chắn là họ sẽ đạt được

Estimation là những dự đoán. Không có cam kết ngầm định trong estimation, không có lời hứa nào trong estimate. Nguyên nhân sinh ra estimation đơn giản là chúng ta không biết chắc chắn mất bao lâu để hoành thành một việc. Và nguyên nhân dẫn đến ta ước lượng sai là vì ta không hiểu được bản chất thực của estimaition là gì. ĐÓ LÀ SỰ PHÂN PHỐI XÁC XUẤT

Lập trình viên chuyên nghiệp phải là ngừoi vẽ ra ranh giới rõ ràng giữa estimation và commitment

Trong chương này ông còn giới thiệu một phương pháp tính toán estimation dựa vào phương pháp PERT. Cách này dựa vào 3 thông số chính để tính toán estimation là O - Optimistic estimate; N - Nominal estimate và P - Pessimistic estimate. Ngoài ra còn có một số phương pháp estimate task trong team dựa trên kỹ thuật estimation wideband delph như: Flying fingers, Planning poker, Affinity Estimation và Trivariate estimate.

Cuối cùng, ông khẳng định, estimate luôn đầy những sai lầm. Vì vậy, để giảm bớt những sai lầm khi estimate, Uncle Bob khuyên chung ta nên áp dụng nguyên tắc số lớn: bằng cách chia nhỏ task thành những phần nhỏ hơn, sau đó estimate từng task nhỏ đó độc lập với nhau

Summary chap 11: Pressure

Chương này nói về một thứ khá hay gặp ở lập trình viên - Áp lực. Vậy làm thế nào để tránh được áp lực? Uncle Bob cho rằng cách tốt nhất để trách áp lực là tránh xa những tình huống dẫn đến áp lực. Ông đề xuất một số cách cụ thể sau:

Về cam kết: Lập trình viên chuyên nghiệp sẵn sàng giúp đỡ Biz tìm cách tốt nhất để đạt mục tiêu - là những thứ đã cam kết với khách hàng. NHƯNG không cần thiết phải chấp nhận những cam kết mà biz đã đưa ra với họ
“Không nên ở dơ” - Staying clean: Chúng ta có thể tránh pressure bằng cách giữ hệ thống, code và thiết kế “sạch” nhất có thể
Những nguyên tắc-kỷ luật khi khủng hoảng xảy ra: Lựa chọn một nguyên tắc kỷ luật mà làm bạn cảm thấy ổn nhất nếu khủng hoảng xảy ra. Luôn luôn làm theo những nguyên tắc đó dù bất kỳ điều gì xảy ra. Việc theo những nguyên tắc kỹ luật một cách chặt chẽ là cách để bạn tránh việc rơi vào khủng hoảng

Xử lý áp lực: Đầu tiên là không được hoảng loạn. Quản lý sự căng thẳng của bạn, càng vội vã càng dẫn bạn vào ngõ cụt. Thay vào đó hay bình tĩnh và chậm rãi nghĩ về vấn đề, sau đó vẽ ra những kết quả có thể có, rồi hướng đến kết quả hợp lý nhất.

Ngoài ra, giao tiếp cũng là cách giúp bạn giải quyết áp lực, hãy kể cho team hay lead của bạn biết về vấn đề mình gặp phải. Show ra kế hoạch kết nhất của bạn để giải quyết vấn đề đó. Bạn sẽ được hướng dẫn.

Tin tưởng vào nguyên tắc kỷ luật đã chọn.

Tìm sự giúp đỡ: Khi căng thẳng lên cao, hãy tìm một đồng nghiệp mà có thể bắt cặp cùng bạn, điều này sẽ giúp bạn làm nhanh hơn và ít lỗi hơn. Ngược lại, nếu thấy người khác đang bị áp lực, hãy đề nghị giúp đỡ họ.

Summary chap 12: Collaboration

Phần lớn phần mềm được tạo ra bởi team, team hoạt động hiệu quả khi những thành viên trong team đó hợp tác với nhau một cách chuyên nghiệp.

Có một điều tồi tệ diễn ra là những lập trình viên tự chôn sống mình trong ngôi mộ của công nghệ một cách rất hạnh phúc trong khi xung quanh anh ta, công ty/dự án, hay việc kinh doanh đang sụp đổ. Đối với lập trình viên thì thật tốt khi anh ta theo đuổi những đam mê với những thứ anh ta làm, nhưng cũng tốt không kém nếu anh ta để tâm đến những business goals của những người trả tiền lương cho anh ta.

Bên cạnh đó, lập trình viên là những người rất khó làm việc với những lập trình viên khác. Điều này dẫn đến những hậu quả tồi tệ. Một trong những dấu hiệu của team hoạt động không hiểu quả đó là mỗi lập trình viên trong team tự xây dựng những bức tường xung quanh code của mình và không để bất kỳ ai chạm vào nó. Đó chính là công thức dẫn đến thảm hoạ.

Lập trình viên chuyên nghiệp là những người không né tránh việc người khác làm việc trên code của họ. Thay vào đó, họ sẵn sàng học hỏi từ người khác bằng việc tham gia vào những phần khác nhau của hệ thống.

Summary chap 13: Teams and projects

Sẽ thật vô lý khi bắt một lập trình viên làm việc nửa thời gian cho dự án này, nửa thời gian cho dự án khác, mà đặc biệt khi 2 dự án đó có 2 PM, 2 BA, …

Việc xây dựng team cần có thời gian, các thành viên cần xây dựng mối quan hệ, học cách làm việc chung, hiểu được điểm mạnh điểm yếu của nhau để team có được sự gắn kết.

Team khó xây dựng hơn dự án. Vì vậy, một tổ chức chuyên nghiệp sẽ đẩy các dự án về các team gắn kết đã có sẵn thay vì xây dựng team xung quanh dự án. Khi đó cả team sẽ làm dự án này sang dự án khác và cũng có thể làm nhiều hơn 1 dự án cùng lúc. Mục đích chính của xây dựng team chính là sự gắn kết, và khi đã có sự gắn kết và hoạt động như một guồng máy thì có team có thể hoàn thành nhiều dự án khác nhau.

Summary chap 14: Mentoring, Apprenticeship and Craftmanship

Chương cuối của quyển sách nói về Mentoring, học việc và sự thạo nghề trong ngành phần mềm. Tác giả còn phân loại ra các cấp bậc của developer: Master, Journeyman, Apparentice/Intern. Và cuối cùng, Uncle Bob nói về định nghĩ người thạo nghề (craftman) và sự thạo nghề (craftmanship). Người thạo nghề là người làm việc nhanh nhưng không vội, đưa ra những estimate hợp lý và đảm bảo làm những gì đã cam kết. Người thạo nghề là người biết khi nào cần “say no" khi nào cần cố gắng để "say yes”. Người thạo nghề chính là người chuyên nghiệp!

Kết luận:

Với cách viết với văn phong để giản, Uncle Bob đã đem lại với cá nhân mình rất nhiều bài học quý giá. Bản thân mình cuốn sách này rất thích hợp cho các bạn sinh viên mới ra trường, nó giúp cho các bạn định hình được mindset công việc, những điều mà chắc có lẽ bạn sẽ không được dạy trên ghế nhà trường.

PS: Đây là lần đâu tiên viết review sách của mình, đúng hơn là tóm tắt sách nên chắc chắn sẽ có những sai sót, mong mọi người thông cảm và cho mình nhận xét để những bài viết sau thêm tốt hơn. Thanks!