Rich Skrenta viết rằng code chính là kẻ thù của chúng ta.
Code thì rất dở. Mó mục nát. Nó yêu cầu phải được bảo trì theo định kỳ. Nó có nhiều bug mà cần phải được phát hiện. Những đặc trưng mới nghĩa là code cũ đã bị điều chỉnh. Bạn càng có nhiều code, thì càng có nhiều chỗ để cho các bug trú ẩn. Thời gian checkout và biên dịch sẽ lâu hơn. Và một nhân viên mới sẽ cần thời gian lâu hơn để có thể hiểu được hệ thống của bạn. Nếu bạn phải tái cấu trúc nó thì sẽ có rất nhiều thứ phải thay đổi.
Code được tạo ra bởi các kỹ sư. Để tạo ra nhiều code hơn thì yêu cầu nhiều kỹ sư hơn. Các kỹ sư có chi phí truyền đạt là n^2, và tất cả phần code mà họ đã bổ sung vào hệ thống trong khi mở rộng khả năng của nó thì cũng làm tăng toàn bộ phí tổn. Bạn nên làm bất cứ điều gì có thể để tăng năng suất của những lập trình viên riêng lẻ thông qua code mà họ viết. Bớt đi những đoạn code làm cùng công việc giống nhau. Số lượng lập trình viên phải thuê sẽ ít đi. Chi phí truyền thông trong tổ chức cũng sẽ giảm đi rất nhiều.
Thực ra code tốt nhất là không code một chút nào cả!
Rich Skrenta gợi ý nó ở đây, nhưng vấn đề thực sự thì không phải là do code. Phần code đó, giống như một em bé sơ sinh, hoàn toàn trong trắng và vô tội trong cái giây phút mà nó được viết vào thế giới này. Code không phải là kẻ thù của chúng ta. Bạn có muốn biết kẻ thù thực sự của bạn là ai không? Bạn hãy đi nhìn vào trong gương. Đó mới là kẻ thù lớn nhất của bạn, chính hắn.
Là một nhà phát triển phần mềm, bạn là kẻ thù lớn nhất của chính mình. Bạn càng sớm nhận ra điều đó, thì bạn sẽ càng sớm trở nên tốt hơn.
Tôi biết bạn có những mục đích tốt đẹp. Tất cả chúng ta đều vậy. Chúng ta là những nhà phát triển phần mềm; chúng ta yêu thích việc viết code. Đó là cái chúng ta làm. Chúng ta chưa bao giờ gặp một vấn đề mà mình không thể giải quyết bằng một vài cuộn băng keo, một sợi dây và một nhúm code. Nhưng Wil Shipley tranh cãi rằng chúng ta nên kiềm chế những khuynh hướng tự nhiên của mình trong việc viết quá nhiều code:
Nền tảng tự nhiên của lập trình chính là tác vụ của chúng ta, là lập trình viên thì bạn phải nhận ra rằng mọi quyết định mình làm đều phải trả giá bằng một cái gì đó. Để trở thành một lập trình viên lão luyện thì bạn phải hiểu cái điều tự nhiên của những đổi chác đó, và phải tỉnh táo trước chúng trong mọi thứ mà chúng ta viết ra.
Trong lập trình, bạn có rất nhiều tiêu chí trong việc đánh giá code:
- Tính khúc chiết của code
- Đặc trưng
- Tốc độ thực thi
- Thời gian tiêu tốn trong việc lập trình
- Sự mạnh mẽ
- Tính mềm dẻo
Bây giờ, nên nhớ rằng tất cả những tiêu chí này ở trong những mặt đối nghịch lẫn nhau. Bạn có thể dành ra 3 ngày để viết một thủ tục thực sự đẹp và nhanh, theo đó bạn đã có được 2 tiêu chí đi lên, nhưng bạn đã dành ra tới 3 ngày trời để làm ra nó, vì vậy tiêu chí “thời gian dùng để lập trình” lại đi xuống.
Vậy khi nào thì tiêu chí nào có giá trị? Làm thế nào để chúng ta có thể tạo ra những quyết định đúng đắn? Câu trả lời hóa ra lại rất giản dị, rất đơn giản, và ai trong chung ta cũng đã từng nghe thấy: Bắt đầu với tính khúc chiết. Tăng những tiêu chí khác theo yêu cầu bằng việc kiểm thử.
Tôi không thể đồng ý nhiều hơn. Tôi cũng đã đưa ra một lời khuyên tương tự khi hô hào các lập trình viên viết code nhỏ hơn. Và tôi đang không nói về một cuộc thi “reductio ad absurdum”, nơi mà chúng ta sử dụng tất cả những mánh khóe thông minh hơn trong những cuốn sách của mình để khiến cho đoạn code bé đi để vừa khít vào trong không gian vật lý nhỏ hơn. Mà tôi đang nói về những chiến lược thực tế và hợp lý để giảm kích thước của code tới mức một lập trình viên riêng lẻ có thể đọc và hiểu được một chương trình làm việc như thế nào. Sau đây chỉ là một ví dụ rất tầm thường về điều mà tôi đang muốn nói tới:
1 2 | if (s == String.Empty) if (s == "") |
Một điều dường như rất hiển nhiên đối với tôi rằng dòng code thứ hai thì tốt hơn bởi vì nó chỉ đơn giản là nhỏ hơn. Và vâng tôi gần như chắc chắn rằng sẽ chạm trán phải những lập trình viên mà sẽ đánh tôi, gần như đến chết, bởi vì họ đã hoàn toàn bị thuyết phục rằng cái kiểu viết String.Empty dài dòng thì theo một cách nào đó thân thiện hơn đối với trình biên dịch. Liệu tôi có nên quan tâm về điều đó. Liệu có bất cứ ai quan tâm về điều đó!
Thật là đau xót cho hầu hết các nhà phát triển phần mềm khi phải thừa nhận điều này, bởi vì họ yêu code rất nhiều, nhưng code tốt nhất thì lại chính là không có code một chút nào cả. Mọi dòng code mới mà bạn sẵn lòng mang vào thế giới này thì code đó phải được debugged, code đó phải được đọc và hiểu, code đó phải được hỗ trợ. Mỗi lần mà bạn viết code mới, bạn nên làm nó một cách miễn cưỡng, dưới sự ép buộc, vì bạn đã hoàn toàn bị kiệt sức bởi tất cả những lựa chọn khác của mình. Code thì chỉ là kẻ thù của chúng ta bởi vì có rất nhiều lập trình viên viết ra những dòng code dở đến mức đáng nguyền rủa. Nếu bạn không thể tránh xa bằng việc không viết code, thì điều tốt nhất tiếp theo là bắt đầu bằng sự khúc chiết.
Nếu bạn yêu việc viết code– thực sự, yêu chân thành việc viết code— thì bạn sẽ yêu nó đủ để viết ra nó ít nhất có thể.
Bài viết được dịch từ blog Coding Horror
Bạn có đam mê ngành thiết kế vi mạch và bạn muốn có mức lương 1000 usd cùng lúc bạn
đang muốn tìm một Trung tâm để học vậy hãy đến với ngành vi mạch tại SEMICON
HotLine: 0972 800 931 or 0938 838 404 Ms Duyên
