pragmatic-programmer-2

Chủ Đề 5: Phần Mềm “Đủ Tốt”

"Phấn đấu để tốt hơn, đôi khi chúng ta làm hỏng điều vốn đã tốt." — Shakespeare, King Lear 1.4

Có một câu chuyện đùa (khá cũ) về một công ty đặt mua 100.000 vi mạch IC từ một nhà sản xuất Nhật Bản. Trong bản yêu cầu có ghi rõ tỷ lệ lỗi: một chip trên 10.000. Vài tuần sau, đơn hàng đến: một hộp lớn chứa hàng ngàn IC, và một hộp nhỏ chỉ chứa đúng mười chiếc. Gắn trên hộp nhỏ là tấm nhãn: “Đây là những chiếc bị lỗi.”

Giá mà chúng ta thực sự có thể kiểm soát chất lượng như vậy. Nhưng thực tế thì không cho phép chúng ta tạo ra phần mềm hoàn toàn hoàn hảo, đặc biệt là không có lỗi. Thời gian, công nghệ và yếu tố con người luôn chống lại điều đó.

Tuy nhiên, điều này không nhất thiết phải gây nản lòng. Như Ed Yourdon đã mô tả trong một bài viết trên IEEE Software (When good-enough software is best), bạn có thể rèn luyện bản thân để viết phần mềm “đủ tốt” — đủ tốt cho người dùng, cho những người bảo trì sau này, và cho chính sự an tâm của bạn. Khi làm vậy, bạn sẽ năng suất hơn, người dùng sẽ hài lòng hơn, và đôi khi sản phẩm còn tốt hơn nhờ thời gian phát triển ngắn hơn.

Trước khi đi sâu hơn, cần làm rõ rằng “đủ tốt” không có nghĩa là cẩu thả hoặc kém chất lượng. Mọi hệ thống đều phải đáp ứng yêu cầu của người dùng để thành công, đồng thời đáp ứng các tiêu chuẩn cơ bản về hiệu năng, quyền riêng tư và bảo mật. Chúng tôi chỉ khuyến khích để người dùng tham gia vào việc quyết định khi nào sản phẩm đủ đáp ứng nhu cầu của họ.

Đưa Người Dùng Vào Các Quyết Định Đánh Đổi

Thông thường bạn viết phần mềm cho người khác. Bạn có thể hỏi họ muốn gì, nhưng đã bao giờ hỏi họ muốn phần mềm tốt đến mức nào chưa? Đôi khi bạn không có lựa chọn, như khi làm việc trên máy tạo nhịp tim, hệ thống lái tự động hoặc thư viện cấp thấp sẽ được dùng rộng rãi — khi đó yêu cầu sẽ rất khắt khe.

Nhưng nếu bạn đang phát triển một sản phẩm hoàn toàn mới, ràng buộc sẽ khác: bộ phận marketing có những lời hứa phải giữ, người dùng cuối có thể đã lên kế hoạch dựa trên lịch bàn giao, và công ty chắc chắn có hạn chế về dòng tiền. Thật thiếu chuyên nghiệp nếu bỏ qua nhu cầu này chỉ để thêm tính năng hoặc “mài dũa” mã thêm một lần nữa. Nhưng cũng sẽ thiếu chuyên nghiệp nếu hứa hẹn lịch không khả thi và cắt xén tiêu chuẩn kỹ thuật chỉ để kịp hạn.

Phạm vi và chất lượng sản phẩm bạn tạo ra cần được thảo luận như một phần của yêu cầu hệ thống.

Mẹo 8: Xem Chất Lượng Là Một Yêu Cầu

Nhiều người dùng sẵn sàng chấp nhận phần mềm còn vài điểm thô ráp hôm nay hơn là phải chờ một năm để có bản hoàn hảo với đầy đủ chuông và còi (và thực tế, nhu cầu của họ sau một năm có thể đã khác). Nếu đưa sản phẩm sớm để họ trải nghiệm, phản hồi của họ thường giúp bạn có giải pháp cuối cùng tốt hơn.

Biết Khi Nào Nên Dừng

Lập trình có nhiều điểm giống hội họa. Bạn bắt đầu với tấm toan trống và nguyên liệu cơ bản, kết hợp khoa học, nghệ thuật và kỹ thuật để tạo nên tác phẩm. Bạn phác thảo, tạo nền, thêm chi tiết và thường xuyên lùi lại để đánh giá. Đôi khi bạn bỏ hẳn tác phẩm để bắt đầu lại.

Nhưng họa sĩ sẽ nói rằng mọi công sức đều bị phá hỏng nếu không biết khi nào nên dừng. Thêm lớp này chồng lớp khác, chi tiết đè lên chi tiết sẽ khiến bức tranh chìm trong lớp sơn.

Đừng phá hỏng một chương trình tốt chỉ vì cố trang trí hoặc tinh chỉnh quá mức. Hãy chuyển sang việc khác và để mã tự đứng vững. Nó sẽ không bao giờ hoàn hảo, và điều đó là bình thường.

Các Phần Liên Quan

Chủ đề 45: Hố Sâu Yêu Cầu
Chủ đề 46: Giải Các Câu Đố Bất Khả Thi

Thử Thách

Xem các công cụ phần mềm và hệ điều hành bạn thường dùng. Bạn có thấy bằng chứng rằng nhà phát triển sẵn sàng phát hành sản phẩm chưa hoàn hảo? Là người dùng, bạn sẽ chọn: (1) chờ họ sửa hết lỗi, (2) dùng phần mềm phức tạp và chấp nhận có lỗi, hay (3) chọn phần mềm đơn giản hơn với ít lỗi hơn?
Xem xét tác động của việc chia nhỏ hệ thống (modular hóa) đến thời gian giao hàng. Mất nhiều hay ít thời gian hơn để đưa hệ thống nguyên khối đạt chất lượng so với hệ thống chia nhỏ theo module hoặc microservices? Ưu và nhược điểm của mỗi cách?
Nghĩ về phần mềm phổ biến bị feature bloat (thừa tính năng). Điều này khiến mỗi tính năng mới tiềm ẩn thêm lỗi và lỗ hổng, đồng thời làm khó sử dụng các tính năng chính. Bạn có đang rơi vào bẫy này không?

Chủ Đề 6: Danh Mục Kiến Thức Của Bạn

"Đầu tư vào kiến thức luôn mang lại lợi nhuận tốt nhất." — Benjamin Franklin

Ông Ben Franklin vĩ đại — chưa bao giờ thiếu những câu châm ngôn sâu sắc. Nếu chúng ta chỉ cần đi ngủ sớm và dậy sớm, chúng ta sẽ trở thành lập trình viên xuất sắc — đúng không? Chim dậy sớm có thể bắt được sâu, nhưng chuyện gì sẽ xảy ra với con sâu dậy sớm?

Tuy nhiên, trong trường hợp này, Ben đã nói rất đúng. Kiến thức và kinh nghiệm của bạn là tài sản chuyên môn quan trọng nhất hằng ngày.

Đáng tiếc, đó là những tài sản sẽ hết hạn. Kiến thức của bạn trở nên lỗi thời khi các kỹ thuật, ngôn ngữ và môi trường mới được phát triển. Sự thay đổi của thị trường có thể khiến kinh nghiệm của bạn trở nên lạc hậu hoặc không còn liên quan. Với tốc độ thay đổi ngày càng nhanh trong xã hội công nghệ, điều này có thể xảy ra rất nhanh.

Khi giá trị kiến thức của bạn giảm, giá trị của bạn đối với công ty hoặc khách hàng cũng giảm. Chúng ta muốn ngăn điều này xảy ra.

Khả năng học những điều mới là tài sản chiến lược quan trọng nhất của bạn. Nhưng làm sao để học cách học, và làm sao biết nên học gì?

Danh Mục Kiến Thức Của Bạn

Chúng ta xem tất cả các kiến thức lập trình viên biết về máy tính, lĩnh vực ứng dụng họ làm việc và tất cả kinh nghiệm của họ như một danh mục kiến thức. Quản lý danh mục này tương tự như quản lý danh mục tài chính:

Nhà đầu tư nghiêm túc đầu tư đều đặn — biến nó thành thói quen.
Đa dạng hóa là chìa khóa cho thành công dài hạn.
Cân bằng giữa các khoản đầu tư an toàn và các khoản đầu tư rủi ro cao nhưng tiềm năng lợi nhuận cao.
Mua khi giá thấp và bán khi giá cao.
Xem xét và điều chỉnh danh mục định kỳ.

Muốn thành công trong sự nghiệp, bạn phải đầu tư vào danh mục kiến thức của mình theo các nguyên tắc này.

Tin tốt là việc quản lý loại đầu tư này là một kỹ năng có thể học được. Mẹo là hãy bắt đầu và biến nó thành thói quen. Tạo một lịch trình mà bạn tuân theo cho đến khi bộ não tự động tiếp nhận kiến thức mới.

Xây Dựng Danh Mục Của Bạn

Đầu tư đều đặn: Dù ít hay nhiều, hãy đầu tư vào kiến thức một cách đều đặn. Thói quen quan trọng hơn số lượng.
Đa dạng hóa: Càng biết nhiều lĩnh vực khác nhau, bạn càng có giá trị. Đừng chỉ dừng ở công nghệ bạn đang dùng.
Quản lý rủi ro: Đừng đặt tất cả trứng vào một giỏ. Hãy cân bằng giữa công nghệ rủi ro cao và công nghệ an toàn.
Mua khi thấp, bán khi cao: Học công nghệ mới trước khi nó phổ biến có thể mang lại lợi thế lớn.
Xem xét và điều chỉnh: Luôn rà soát và cập nhật kiến thức.

Mẹo 9: Đầu Tư Đều Đặn Vào Danh Mục Kiến Thức

Mục Tiêu

Học ít nhất một ngôn ngữ mới mỗi năm: Giúp bạn mở rộng tư duy và tránh lối mòn.
Đọc một cuốn sách kỹ thuật mỗi tháng: Hiểu sâu hơn về các chủ đề liên quan hoặc ngoài dự án.
Đọc cả sách phi kỹ thuật: Hiểu con người — người dùng, đồng nghiệp, hacker.
Tham gia lớp học: Các khóa học tại trường, online hoặc hội thảo.
Tham gia nhóm người dùng và meetup: Tránh cô lập và mở rộng mối quan hệ.
Thử môi trường mới: Ví dụ chuyển từ Windows sang Linux, hoặc ngược lại.
Luôn cập nhật: Đọc tin tức và bài viết về công nghệ ngoài lĩnh vực hiện tại của bạn.

Quan trọng là tiếp tục đầu tư. Khi đã thành thạo một công nghệ, hãy học công nghệ khác. Quá trình học sẽ mở rộng tư duy và tạo ra những khả năng mới, kể cả khi không dùng trực tiếp.

Cơ Hội Học Hỏi

Đọc nhiều, theo sát những phát triển mới nhất, và khi không biết câu trả lời — hãy tìm kiếm. Hỏi người khác, tìm trên web, hoặc tìm chuyên gia. Việc này giúp bạn mở rộng mạng lưới và đôi khi tìm ra giải pháp cho các vấn đề khác.

Luôn mang theo thứ gì đó để đọc vào những lúc rảnh như khi chờ đợi. Đừng lãng phí thời gian chết.

Tư Duy Phản Biện

Mẹo 10: Phân Tích Phê Phán Những Gì Bạn Đọc và Nghe

Hỏi “Tại sao?” năm lần: Đào sâu nguyên nhân gốc rễ.
Ai được lợi?: Theo dõi lợi ích để phân tích.
Bối cảnh là gì?: Không có giải pháp chung cho tất cả.
Khi nào/ở đâu áp dụng được?: Xem xét cả hệ quả lâu dài.
Tại sao đây là vấn đề?: Hiểu mô hình ẩn sau.

Với danh mục kiến thức rộng và khả năng tư duy phản biện, bạn sẽ hiểu các câu trả lời phức tạp.

Thử Thách

Học một ngôn ngữ mới trong tuần này.
Đọc một cuốn sách mới (hoàn thành cuốn hiện tại trước).
Nói chuyện công nghệ với những người ngoài dự án hoặc công ty của bạn.