Lập trình thực dụng

Bài viết được dịch từ blog Coding Horror

Như đã đề cập trong một bài viết trước đây rằng tôi có giới thiệu tác giả Andrew Hunt của nhóm lập trình viên pragmatic programmer nổi tiếng đến nói chuyện trực tiếp với nhóm chúng tôi. Anh ta tình cờ lại sống trong vùng này, điều đó khiến cho mọi việc rất thuận lợi. Tôi phải thừa nhận rằng mình không biết nhiều về những gã này cho tới khi tôi tình cờ xem qua bài thuyết trình Làm Thế Nào Để Giữ Công Việc Của Bạn của họ vào cuối năm ngoái khi tôi đang tìm kiếm thông tin về xu hướng offshoring (gia công ra nước ngoài). Đó là một trong những cách xử lý tốt nhất của chủ đề offshoring, vì vậy tôi đã rất vui mừng khi có thể mời Andy đến thuyết trình và nói thêm về một số vấn đề riêng với tư cách cá nhân.

Bạn hãy xử lý hoặc khoanh vùng bất kỳ lỗi nào dù nhỏ nhất trong hệ thống, để tránh việc dẫn đến những hậu quả khôn lường.Bạn hãy xử lý hoặc khoanh vùng bất kỳ lỗi nào dù nhỏ nhất trong hệ thống, để tránh việc dẫn đến những hậu quả khôn lường.

Trong lúc anh ta ở đây, tôi cũng đã nhờ anh ta viết tặng vào cuốn sách The Pragmatic Programmer của anh ta mà tôi đã mua:

Chính bởi vì những lập trình viên giống như bạn mà xu hướng off-shoring hoạt động!“Chính bởi vì những lập trình viên giống như bạn mà xu hướng off-shoring hoạt động!” 🙂 Andy

Trước khi bạn bắt đầu ngạc nhiên, thì chính tôi đã nhờ anh ta viết ra câu đó. Nó thì để cho vui bởi vì đó là sự thật.

The Pragmatic Programmer là một cuốn sách tuyệt vời, và dứt khoát nó sẽ nằm trong danh sách những cuốn sách mà tôi đề xuất bạn nên đọc. Nó chỉ là tương đối… thực dụng. Đây là một đoạn trích từ cuốn sách đó ở phần Thuyết Cửa Sổ Vỡ (Broken Window Theory). Tôi đã quan sát thấy điều này mỗi ngày tại nơi làm việc của mình, và tôi chưa bao giờ nhận ra nó là gì cho tới khi tôi đọc về thuyết này trong cuốn sách của Andy và Dave:

Trong những thành phố, một số tòa nhà thì rất sạch và đẹp, trong khi một số khác thì cũ kỹ và mục nát. Tại sao vậy? Các nhà nghiên cứu trong lĩnh vực tội phạm và sự đổ nát của thành phố đã khám phá ra một số nguyên nhân gây nên điều này, một trong số nguyên nhân khiến một tòa nhà sạch sẽ, nguyên vẹn và có người sống trở thành một tòa nhà bị bỏ hoang tàn tạ rất nhanh: đó là do một ô cửa sổ bị vỡ.

Một ô cửa sổ vỡ, bị để mặc không được sửa chữa trong một khoảng thời gian dài, tạo ra cho những cư dân trong tòa nhà đó một cảm giác của sự bỏ rơi — một cảm giác mà sức mạnh của nó ngày càng tăng lên dẫn đến người ta không thèm quan tâm về ngôi nhà đó nữa. Vì vậy sẽ có những ô cửa sổ khác bị vỡ. Mọi người bắt đầu vứt rác bừa bãi. Mấy tay trẻ trâu sẽ đến vẽ bậy các hình graffiti lên tường. Những sự phá hủy nghiêm trọng về cấu trúc bắt đầu xảy ra. Chỉ trong một thời gian ngắn, tòa nhà đó đã trở nên bị hư hại vượt quá cả mong muốn sửa chữa của người chủ của nó. Và cái cảm giác bỏ rơi dần trở thành hiện thực.

Thuyết “Ô Cửa Sổ Vỡ” (Broken Window Theory) này đã truyền cảm hứng cho các sở cảnh sát ở thành phố New York và nhiều thành phố lớn khác tập trung xử lý những vấn đề nhỏ trong trật tự để không xảy ra những vấn đề lớn. Và nó đã có hiệu quả: việc tập trung vào giải quyết những vấn đề nhỏ như cửa sổ vỡ, hình vẽ bậy bạ trên tường, và những sự vi phạm nhỏ nhặt khác đã làm giảm đáng kể số lượng các vụ phạm tội nghiêm trọng như giết người.

Đừng để “những ô cửa sổ vỡ” (thiết kế tồi, những quyết định sai lầm, hoặc code viết dở) mà không được sửa chữa. Hãy sửa bất cứ bug nào sớm nhất có thể khi nó được phát hiện ra. Nếu bạn không có đủ thời gian để có thể sửa chữa nó một cách đúng đắn, thì bạn hãy đánh dấu nó lại. Có lẽ bạn có thể comment cái đoạn code bị lỗi đó, hoặc hiển thị một thông điệp là “Not Implemented”, hoặc thay thế bằng một dữ liệu giả vào đó. Hãy làm một số hành động để ngăn ngừa nó bị phá hủy nhiều hơn và chỉ ra rằng bạn đang kiểm soát được tình hình.

Chúng tôi đã từng nhìn thấy những hệ thống sạch sẽ, nhiều chức năng đã bị hư hỏng một cách nhanh chóng một khi các ô cửa sổ bắt đầu vỡ. Có những yếu tố khác có thể đóng góp vào sự hư hỏng của phần mềm, và chúng ta sẽ bàn về các yếu tố đó trong một phần khác, nhưng việc bỏ bê sẽ làm tăng tốc độ mục nát của phần mềm hơn bất kỳ những nhân tố nào khác.

Bạn có thể nghĩ rằng không một ai lại có đủ thời gian để cứ đi mà dọn dẹp tất cả những mảnh vỡ của một dự án. Nếu bạn còn tiếp tục nghĩ như vậy, thì tốt hơn bạn nên lên kế hoạch bỏ luôn nó, hoặc chuyển sang một vùng khác. Đừng để cho điều này xảy ra.

Nếu bạn thích thú với điều trên, thì bạn có thể cũng thích các mục như:

.. và bạn sẽ muốn sở hữu một bản copy của cuốn sách đó.

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

9 comments on “Lập trình thực dụng

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s