- Cập nhật code
Có một bài báo châm biếm được lan truyền trên Internet trong nhiều năm qua có tên là “Nếu kiến trúc sư phải làm việc giống một lập trình viên”. Nó được viết dưới dạng một lá thư từ một người sở hữu nhà gửi yêu cầu cho kiến trúc sư về ngôi nhà mong muốn.
Dưới đây là một đoạn trích dẫn:
“Hãy giúp tôi thiết kế và xây dựng một căn nhà. Tôi chưa rõ mình đang muốn gì, nên hãy làm theo ý hiểu của bạn. Nhà của tôi cần phải có khoảng từ 2 đến 45 phòng ngủ. Bản thiết kế cần đảm bảo các phòng ngủ có thể được bỏ đi hoặc thêm vào tuỳ ý. Tôi sẽ đưa ra quyết định khi nhìn vào thiết kế của bạn. Tôi cũng cần bạn phải đưa ra ước tính về chi phí cho mỗi lựa chọn để tôi có thể đưa ra quyết định.”
Đây chỉ là một bài châm biếm nhưng rất giống với cách mà các lập trình viên nhận được những yêu cầu về phần mềm. Do việc có thể thay đổi sau khi hoàn thành, nên những nhà quản lý cho rằng làm như vậy không có gì khó và họ không cần phải nêu ra cụ thể mong muốn của mình.
Qua thời gian, các lập trình viên đã cố hết sức để đáp ứng bằng cách thêm vào những lớp trừu tượng để những thành phần trong đó có thể được thay đổi, ghép nối, cập nhật hoặc hoán đổi dễ dàng.
Cấp quản lý muốn như vậy vì họ có thể ra mắt sản phẩm trong thời gian ngắn mà không phải đưa ra những yêu cầu quá cụ thể mà chính họ cũng chưa hình dung được.
Các lập trình viên chấp nhận việc này để không bị sa thải.
2. Tái sử dụng code
Cách để cải thiện chất lượng code mà không ảnh hưởng đến kế hoạch đó giảm thiểu số lượng code chuyên biệt, thay vào đó là những dòng code đã được sử dụng và kiểm thử trước đó. Chúng ta gọi đó là những thư viện, frameworks, templates.
Bạn hẳn không còn lạ gì đồ chơi Lego, trong đó bạn có thể tạo ra những mô hình phức tạp bằng cách kết hợp những mảnh ghép có thể tái dụng với những mảnh ghép chuyên biệt. Bạn có thể tạo ra bất kỳ thứ gì nếu có đủ những mảnh ghép cần thiết. Có một vài đoạn cần tạo hình cụ thể và rất nhiều hướng dẫn về cách kết hợp chúng để tạo ra được mô hình mong muốn.
Tái sử dụng code cũng tương tự như vậy. Phát triển phần mềm trở thành quá trình làm quen với những thành phần khác nhau và làm sao để kết hợp chúng.
Code có thể được tái sử dụng bởi vì sự trừu tượng. Giống như những mảnh ghép Lego có cùng một kết cấu và khớp nối để có thể gắn vào với nhau.
3. Tính năng, tính năng, tính năng
Tôi từng phát triển 1 ứng dụng được quản lý bởi 1 người rất thiếu quyết đoán. Tôi luôn nhận được hai phương án riêng biệt cho mỗi lần tôi hỏi rằng “Ông muốn ứng dụng làm thế này hay thế kia?”. Ví dụ: ông muốn các dữ liệu trong mỗi mục báo cáo được sắp xếp theo hàng dọc hay hàng ngang?
Và ông ta sẽ trả lời rằng “cả hai”. Ông ta không thể đưa ra quyết định vì luôn sợ rằng mình sẽ mắc sai lầm. Vì vậy nên ông ta luôn yêu cầu làm cả hai và thiết kế để ứng dụng có thể thay đổi tuỳ ý.
Ông ấy muốn sau này mình có thể thay đổi càng nhiều càng tốt.
Hệ quả là điều này sẽ nhân đôi việc viết code và kiểm thử để đảm bảo chất lượng.
Chưa hết, mỗi lần ông ta nói “làm cả hai” thì số kịch bản cần kiểm thử cũng nhân đôi bởi vì tôi cần đảm bảo rằng tính năng mới sẽ hoạt động trơn tru khi chạy cùng với những tính năng trước đó.
Lập trình viên không thể chỉ nói không khi quản lý muốn thêm tính năng mới. Họ chỉ có thể nói “Đây là chi phí về thời gian và tiền bạc để làm theo ý của bạn, bạn có chắc là muốn tiếp tục không?”
