Clean code tiếng việt Chap 1 - clean code chap 1 bản tiếng việt

Trước hết, bạn đọc cuốn sách này bởi hai lý do:

Thứ nhất, bạn đang 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 thật giỏi. Tuyệt vời! Chúng tôi cần lập trình viên giỏi.

Clean code là một quyển sách nói về những cách để bạn code tốt hơn. Chúng ta sẽ xem xét code trên nhiều phương diện, từ trên xuống dưới, từ dưới lên trên, và từ trong ra ngoài. Khi xong việc, chúng ta sẽ được biết thêm rất nhiều về code. Từ đó, chúng ta sẽ nói về sự khác biệt giữa good code và bad code.

There Will Be Code(Sẽ vẫn có mã )

Nhiều người cho rằng việc viết code sau vài năm nữa sẽ không còn là vấn đề. Rằng chúng ta cần quan tâm đến những mô hình và các yêu cầu là đủ. Thực tế một số người đang cho rằng việc viết code dần đến lúc phải kết thúc, code sẽ được tạo ra thay vì được viết hay gõ. Và rồi, lập trình viên sẽ không cần thiết nữa bởi những khách hàng kinh doanh sẽ tự tạo ra các chương trình bằng cách nhập các thông số kỹ thuật.

Oh. Điều này là vô lý! Code sẽ không bao giờ bị loại bỏ bởi vì code đại diện cho chi tiết, nội dung của các yêu cầu từ khách hàng. Ở một mức độ nào đó, những chi tiết, nội dung đó không thể mang tính trừu tượng hóa mà cần sự rõ ràng. Và việc thiết lập các nội dung mà máy tính có thể hiểu và thi hành chính là việc lập trình(viết code).

Hy vọng rằng mức độ trừu tượng của các ngôn ngữ lập trình sẽ tiếp tục tăng, có thêm nhiều ngôn ngữ hơn nữa. Đó là một dấu hiệu rất tốt,Nhưng nó không thể loại bỏ việc viết code. Dù có nhiều những công cụ hỗ trợ nhưng việc viết code nó vẫn phải được thực hiện một cách nghiêm túc, chính xác để máy tính có thể hiểu được và thực hiện.

Có nhiều người nghĩ là việc viết code một ngày nào đó sẽ biến mất. Khi mà máy tính có thể hiểu được những yêu cầu mơ hồ và thực hiện nó một cách chính xác. Họ mơ rằng sẽ có một ngày chúng ta sẽ tạo ra được một cỗ máy có thể làm được những gì chúng ta muốn. Dĩ nhiên, chuyện đó chỉ xãy ra trong phim viễn tưởng.

"<yoastmark

Điều đó là phi thực tế!

Hãy nhớ một điều rằng code là một ngôn ngữ mà trong đó, công việc cuối cùng của chúng ta là thể hiện những yêu cầu.

Nhưng chúng ta sẽ không bao giờ loại bỏ code – so there will always be code!

Bad Code(Code rởm)

Tác giả nói là có đọc phần mở đầu của quyển Implementation Patterns.1 của Kent Beck. Ông ấy nói rằng “…cuốn sách này dựa trên một tiền đề khá mong manh: đó là vấn đề code sạch…” và tác giả không đồng ý với nó.Tác giả cho rằng good code chính là tiền đề lớn nhất trong lĩnh vực lập trình. Đội ngũ của tác giả đã phải mặt với vấn đề ‘good code’ quá lâu.

Tiếp theo là một ví dụ về một ứng dụng, nó rất phổ biến. Nhưng sau đó, những quá trình cập nhật sửa lỗi bắt đầu bị kéo dài ra, có nhiều lỗi thì không được sửa từ phiên bản này qua phiên bản khác, thời gian tải và sự cố cũng theo đó mà tăng lên nhiều hơn. Tác giả cũng đã ngưng sử dụng sản phẩm trong sự thất vọng và không dùng lại nó nữa. Một thời gian sau, công ty đó cũng ngừng hoạt động.

Hai mươi năm sau, tác giả gặp một trong những nhân viên ban đầu của công ty đó và hỏi anh ta chuyện gì đã xãy ra. Câu trả lời đã khiến tác giả lo sợ : Họ đã đưa sản phẩm ra thị trường cùng với một đống code hỗn độn trong đó. Khi các tính năng mới được thêm vào ngày càng nhiều, code của ứng dụng càng ngày càng tệ, đến mức không thể kiểm soát được nữa. Tác giả gọi đó là những dòng code bad(rởm).

Bạn là lập trình viên và bạn đã bao giờ bị những dòng mã bẩn gây khó dễ chưa? Nếu bạn là một lập trình viên có kinh nghiệm, chắc hẳn bạn đã từng trải qua cảm giác đó một vài lần. Chính xác hơn là lội qua mã bẩn. Bơi trong một mớ lộn xộn với những cái bug được giấu kín.

Nếu bạn đã từng bị những dòng code “rởm” cản trở như tôi miêu tả, vậy thì – tại sao bạn lại tạo ra nó?

Có thể bạn cố gắng làm nhanh hơn? Bạn đã vội vàng? Hoặc bạn cảm thấy bạn không có đủ thời gian để hoàn thành nó. Rằng sếp sẽ tức giận nếu bỏ thời gian làm sạch mà không làm cho xong kịp dealine. Cũng có lẽ bạn đã quá mệt mỏi với cái chương trình chết tiệt này và muốn kết thúc nó ngay. Và tự nhủ rằng sẽ quay lại và dọn dẹp nó ngay sau đó.

Cái giá của sự lộn xộn(The Total Cost of Owning a Mess)

Code bẩn sẽ làm cho công việc chậm lại một cách đáng kể.

Cái giá của sự lộn xộn(The Total Cost of Owning a Mess)

Code bẩn sẽ làm cho công việc chậm lại một cách đáng kể.

Năng suất làm việc theo đó giảm dần và tiệm cận về 0.

Khi hiệu suất giảm, người quản lý cần làm công việc của họ – thêm nhiều thành viên mới với hy vọng cải thiện tình trạng. Nhưng những nhân viên mới thường sẽ không nắm rõ cách hoạt động hoặc thiết kế của hệ thống. Vậy là, càng làm việc, họ càng tạo ra nhiều code rối, và đưa cả nhóm (một lần nữa) dần tiến về 0.

Đập đi để xây lại

Cuối cùng, cả nhóm quyết định cần phải thiết kế lại.Dĩ nhiên người quản lý không muốn mất thêm tài nguyên cho việc tái khởi động dự án, nhưng họ cũng không thể phủ nhận sự thật rằng hiệu suất làm việc của cả nhóm đang rất thấp. Cuối cùng, họ chấp nhận theo yêu cầu của các lập trình viên và cho phép bắt đầu lại dự án.

Một team hổ mới được lựa chọn. Mọi người đều muốn vào team này bởi vì đây là một dự án mới. Nhưng chỉ những người giỏi nhất và có triển vọng mới được lựa chọn. Những người còn lại sẽ tiếp tục bảo trì hệ thống hiện tại.

Bây giờ thì cả hai team đều đang ở trong một cuộc đua. Nhóm mới thì phải xây dựng một hệ thống mới với những chức năng của hệ thống cũ, và những thay đổi cho hệ thống cũ. Ban quản lý sẽ không thay đổi hệ thống cũ cho tới khi hệ thống mới hoàn thành và đáp ứng được yêu cầu.

Cuộc đua này có khi sẽ phải diễn ra trong một thời gian rất dài. Tôi đã từng thấy một cuộc đua như vậy, nó mất đến 10 năm để kết thúc. Và tại thời điểm đó, những thành viên ban đầu của nhóm mới đã nghỉ việc. Các thành viên hiện tại đang yêu cầu thiết kế lại hệ thống vì code của nó đã trở thành một mớ hỗn độn.

Việc dành thời gian để giữ cho code sạch đẹp không chỉ là câu chuyện về chi phí, mà đó còn là vấn đề sống còn của lập trình viên.

Thái độ (Attitude)

Bạn đã bao giờ bơi qua một đống code lộn tùng phèo trong vài tuần trong khi chỉ cần một vài giờ để xử lý nó? Những gì bạn thấy là thay đổi một dòng thay vì thực hiện ở hàng trăm module khác nhau. Nếu thật vậy, bạn không hề cô đơn, ngoài kia có hàng trăm ngàn lập trình viên như bạn.

Tại sao chuyện này lại xảy ra? Tại sao từ Good Code nhanh chóng bị mục nát trở thành Bad Code? Có rất nhiều lý do, các yêu cầu thay đổi theo hướng ngăn cản thiết kế ban đầu, lịch làm việc quá chặt chẽ và khách hàng không khoan nhượng,… Nhưng lỗi ở trong chính chúng ta.

Một lập trình viên không chuyên nghiệp, bạn sẽ đổ lỗi cho những yêu cầu thay đổi chóng mặt của khách hàng, deadline của manager,..

Để giải thích điều này, hãy tưởng tượng bạn là bác sĩ và có một bệnh nhân yêu cầu bạn hãy ngưng việc rửa tay để chuẩn bị cho phẫu thuật, bởi việc rửa tay mất quá nhiều thời gian. Rõ ràng bệnh nhân là thượng đế, nhưng bác sĩ sẽ luôn từ chối yêu cầu này. Vì sao? Vì bác sĩ biết nhiều hơn bệnh nhân về những nguy cơ về bệnh tật và nhiễm trùng. Thật là ngu ngốc khi bác sĩ lại đồng ý với những yêu cầu như vậy.

Vậy nên là một lập trình viên chuyên nghiệp bạn cần bảo vệ Code của mình (mặc dù chậm Deadline nhưng vẫn phải sạch) trước ông manager. Vì ông manager cũng như tay bệnh nhân kia, chả biết quái gì về Code sạch và cái giá phải trả cho hàng loạt Code bẩn.

Vấn đề nan giải (The Primal Conundrum)

Cách duy nhất để hoàn thành đúng hạn – cách duy nhất để bước đi vững vàng – là giữ cho code luôn sạch sẽ nhất khi bạn còn có thể.

Nghệ thuật viết mã sạch (The Art of Clean Code?)

Làm thế nào để viết Code sạch?

Viết Code sạch là một nghệ thuật, đơn giản bạn có thể nhìn vào và nhận biết đâu là Code sạch, đâu là Code bẩn. Nếu bạn không biết ý nghĩa của việc code sạch, tốt nhất bạn không nên viết nó.

Đề viết code sạch sẽ yêu cầu sự khổ luyện liên tục những kỹ thuật nhỏ khác nhau, và sự cần cù sẽ được đền đáp bằng “sạch sẽ” của code. Khi có được giác quan nhận biết được đâu là Code sạch đâu là Code bẩn, và có thể biến Code bẩn thành Code sạch, có được cảm giác và lựa chọn thay đổi tốt nhất.

Tóm lại, lập trình viên viết code “sạch đẹp” như là một nghệ sĩ. Họ có thể tạo ra các hệ thống thân thiện chỉ từ một màn hình trống rỗng.

Mã sạch là gì (What Is Clean Code?)

Có rất nhiều định nghĩa về code sạch. Vì vậy chúng tôi phóng vấn một số lập trình viên nổi tiếng và nhiều kinh nhiệm về lĩnh vực này.

Bjarne Stroustrup (Cha đẻ C++) và là tác giả của quyển The C++ Programming Language:

“Tôi thích code của tôi trông thanh lịch và hiệu quả. Sự logic nên được thể hiện rõ ràng để làm cho các lỗi khó lẫn trốn, sự phụ thuộc được giảm thiểu để dễ bảo trì, các lỗi được xử lý bằng các chiến lược rõ ràng, và hiệu năng thì gần như tối ưu để không lôi kéo người khác tạo nên code rối bằng những cách tối ưu hóa tạm bợ. Code sạch sẽ tạo nên những điều tuyệt vời”.

Grady Booch, tác giả quyển Object Oriented Analysis and Design with Applications

“Đơn giản và rõ ràng. Code sạch được đọc như đọc văn xuôi được viết trôi chảy. Không làm lu mờ đi mục đích thiết kế, nhưng vẫn đầy đủ các khái niệm trừu tượng hóa rõ ràng và những dòng mã đơn giản dễ hiểu.”

Michael Feathers , tác giả quyển Working Effectively with Legacy Code:

“ Tôi có thể liệt kê tất cả những phẩm chất mà tôi thấy trong code sạch, nhưng tất cả chúng được bao quát bởi một điều – code sạch trông như được viết bởi những người tận tâm”…

Mình đã tóm tắt nội dung những ý chính của chương này. Mọi người có góp ý để lại comment bên dưới giúp mình nhé.

Bài viết cùng chủ đề: