Nguyên tắc nhỏ của tôi là khi tôi phải làm điều gì đó lần thứ ba, đã đến lúc viết một kịch bản nhỏ để tự động hóa nó, hoặc suy nghĩ lại về cách tiếp cận của tôi.
Tôi không tạo ra một "công cụ" đầy đủ vào thời điểm này, chỉ là một đoạn script nhỏ (thường là bash hoặc python; perl cũng sẽ hoạt động hoặc thậm chí PHP) tự động hóa những gì tôi đã làm thủ công trước đó. Về cơ bản, đây là một ứng dụng của nguyên tắc DRY (hoặc nguyên tắc Nguồn đơn Sự thật, về bản chất là giống nhau) - nếu bạn phải thay đổi hai tệp nguồn song song, phải có một sự thật chung mà chúng chia sẻ, và đó là sự thật phải được đưa ra và lưu trữ ở một nơi trung tâm. Thật tuyệt nếu bạn có thể giải quyết vấn đề này bằng cách tái cấu trúc, nhưng đôi khi, điều này không khả thi và đó là nơi các tập lệnh tùy chỉnh xuất hiện.
Sau đó, tập lệnh có thể hoặc không phát triển thành một công cụ toàn diện, nhưng tôi thường bắt đầu với một tập lệnh rất cụ thể với rất nhiều thứ được mã hóa cứng vào nó.
Tôi ghét công việc nặng nề với một niềm đam mê, nhưng tôi cũng tin tưởng mạnh mẽ rằng đó là một dấu hiệu của thiết kế xấu hoặc không chính xác. Lười biếng là một phẩm chất quan trọng trong một lập trình viên, và tốt hơn hết là bạn nên trải qua thời gian dài để tránh công việc lặp đi lặp lại.
Chắc chắn, đôi khi số dư là âm - bạn dành ba giờ để cấu trúc lại mã của mình hoặc viết một tập lệnh để tiết kiệm cho bạn một giờ làm việc lặp đi lặp lại; nhưng thông thường, sự cân bằng là tích cực, vì vậy nếu bạn xem xét các chi phí không rõ ràng trực tiếp: thất bại của con người (con người thực sự tồi tệ trong công việc lặp đi lặp lại), cơ sở mã nhỏ hơn, khả năng duy trì tốt hơn do giảm dư thừa, tự làm tài liệu tốt hơn, tương lai nhanh hơn phát triển, mã sạch hơn. Vì vậy, ngay cả khi cán cân xuất hiện tiêu cực ngay bây giờ, cơ sở mã sẽ phát triển hơn nữa và công cụ mà bạn đã viết để tạo các biểu mẫu web cho ba đối tượng dữ liệu sẽ vẫn hoạt động khi bạn có ba mươi đối tượng dữ liệu. Theo kinh nghiệm của tôi, sự cân bằng thường được ước tính có lợi cho công việc nặng nề, có thể là do các nhiệm vụ lặp đi lặp lại dễ ước tính hơn và do đó được ước tính thấp, trong khi tái cấu trúc, tự động hóa và trừu tượng hóa được coi là ít dự đoán và nguy hiểm hơn, và do đó được ước tính quá mức. Rốt cuộc, việc tự động hóa không quá khó.
Và sau đó có nguy cơ thực hiện nó quá muộn: thật dễ dàng để cấu trúc lại ba lớp đối tượng dữ liệu hoàn toàn mới thành hình và viết một tập lệnh tạo biểu mẫu web cho chúng và khi bạn đã thực hiện điều đó, thật dễ dàng để thêm 27 lớp nữa cũng làm việc với kịch bản của bạn. Nhưng gần như không thể viết tập lệnh đó khi bạn đã đạt đến điểm có 30 lớp đối tượng dữ liệu, mỗi lớp có các mẫu web viết tay và không có sự thống nhất giữa chúng (còn gọi là "tăng trưởng hữu cơ"). Duy trì 30 lớp đó với các hình thức của chúng là một cơn ác mộng của mã hóa lặp đi lặp lại và thay thế tìm kiếm bán thủ công, việc thay đổi các khía cạnh phổ biến mất gấp ba mươi lần, nhưng viết một kịch bản để giải quyết vấn đề, đó sẽ là một bữa ăn trưa không có trí tuệ khi dự án bắt đầu bây giờ là một dự án hai tuần đáng sợ với triển vọng đáng sợ của một hậu quả kéo dài một tháng bao gồm sửa lỗi, giáo dục người dùng và thậm chí có thể từ bỏ và trở lại với cơ sở mã cũ. Trớ trêu thay, việc viết ra mớ hỗn độn 30 lớp mất nhiều thời gian hơn giải pháp sạch sẽ có, bởi vì bạn có thể đã đi theo kịch bản thuận tiện mọi lúc. Theo kinh nghiệm của tôi, tự động hóa công việc lặp đi lặp lại quá muộn là một trong những vấn đề lớn trong các dự án phần mềm lớn dài hạn. bởi vì bạn có thể đã cưỡi kịch bản thuận tiện mọi lúc. Theo kinh nghiệm của tôi, tự động hóa công việc lặp đi lặp lại quá muộn là một trong những vấn đề lớn trong các dự án phần mềm lớn dài hạn. bởi vì bạn có thể đã cưỡi kịch bản thuận tiện mọi lúc. Theo kinh nghiệm của tôi, tự động hóa công việc lặp đi lặp lại quá muộn là một trong những vấn đề lớn trong các dự án phần mềm lớn dài hạn.
