Cách đúng để quản lý các tập lệnh của nhà phát triển là gì?

Các nhà phát triển tạo ra các kịch bản để giúp đỡ trong công việc của họ. Ví dụ: để chạy Maven với một số tham số nhất định, để tiêu diệt các tác vụ nền không cần thiết mọc lên trong quá trình phát triển hoặc để kết nối với một máy chủ nhất định. Các tập lệnh không phải là tập lệnh xây dựng cốt lõi cũng không được sử dụng trong máy chủ Tích hợp liên tục của chúng tôi.

Cách tốt nhất để quản lý chúng là gì? Để đặt chúng vào một thư mục (có thể /scripts) và kiểm tra chúng vào Git? Để duy trì chúng riêng biệt trong một số máy chủ tập tin?

Đối số để coi chúng là mã nguồn là chúng là nguồn và có thể thay đổi. Lập luận cho việc không làm điều đó là chúng chỉ là các công cụ phụ trợ và không phải tất cả các nhà phát triển đều cần bất kỳ tập lệnh cụ thể nào (ví dụ: các tập lệnh dành riêng cho Linux nơi một số nhà phát triển làm việc trên Windows).

Các tập lệnh của nhà phát triển cũng đi vào kiểm soát phiên bản, bởi vì thông thường các tập lệnh này cũng phụ thuộc vào các mục trong kiểm soát phiên bản, ví dụ: đường dẫn tệp.

Nếu các tập lệnh này được phiên bản, chúng cũng sẽ hoạt động cho tất cả các nhà phát triển để tránh việc mọi nhà phát triển viết tập hợp các tập lệnh của riêng mình, điều này sẽ trở thành một địa ngục bảo trì.

Ngoài ra, các lỗi hoặc cải tiến của các tập lệnh này sẽ tự động được triển khai cho mọi nhà phát triển thông qua kiểm soát phiên bản.

Ngoài câu trả lời của @ simon.

Không phải tất cả trong công nghệ phần mềm là về lập trình, thiết kế hoặc mô hình hóa. Có vô số nhiệm vụ chúng tôi thực hiện liên tục trong ngày làm việc. Bạn đã đề cập đến một - xây dựng dự án bên ngoài IDE - nhưng còn nhiều thứ nữa.

Các nhà phát triển có kinh nghiệm / chủ động có xu hướng tự động hóa các nhiệm vụ này. Một số, thậm chí xây dựng các công cụ khi các tác vụ này trở thành một phần của SDLC và chúng rất tẻ nhạt - và dễ bị lỗi - phải làm bằng tay. Các chương trình rất giỏi làm những công việc lặp đi lặp lại, bất kể chúng tẻ nhạt đến mức nào. Chúng ta - con người - không tốt đến thế.

Những công cụ / tập lệnh này có tác dụng phụ tích cực khác

1. Năng suất
2. Chuyển giao kiến ​​thức
3. Tự chủ (cho người mới)

Vì vậy, vâng, các tập lệnh nên có trong SCM và chúng phải là một công cụ nữa trong hộp công cụ của nhà phát triển.

Về thư mục /scriptstôi sẽ nói rằng nó không thành vấn đề. Để đơn giản, tôi để chúng trong thư mục gốc của dự án để tất cả các tuyến được khai báo trong các tập lệnh đều liên quan đến thư mục của dự án. Nếu tôi cần truy cập vào các thư mục hoặc tệp bên ngoài, tôi tạo các liên kết mềm .

Những điều cần xem xét trước khi kiểm tra các tập lệnh vào SCM.

• Để bảo mật, hãy đảm bảo rằng các tập lệnh không có thông tin được mã hóa cứng - lý tưởng nhất là các tập lệnh nên được tham số hóa tốt -

• Hãy chắc chắn rằng các tập lệnh không làm những điều kỳ lạ đối với hệ thống, ví dụ như để thực thi các lệnh không thể hoàn tác (điển hình nhất rm -rf).

• Vì những thứ này trở thành một phần của nguồn dự án, tài liệu được đánh giá cao.

• Kịch bản không phải là khoa học tên lửa. Làm cho kịch bản súc tích. Thay vì một người cai trị tất cả ... và trong bóng tối trói buộc họ , hãy làm nhiều hơn, nhỏ hơn và súc tích. Như thể bạn đang áp dụng SRP.

Tôi sẽ đưa ra một ý kiến ​​tiêu cực hơn một chút. Một mặt, các tập lệnh dành cho nhà phát triển chung chung, hiệu quả và hữu ích nên được chia sẻ với các nhà phát triển khác và cách tốt nhất để làm điều đó là để chúng nằm cùng mã trong cùng một kho lưu trữ.

Tuy nhiên tôi sẽ đặt một thanh cao để vào để có các tập lệnh được cam kết. Kịch bản là mã, giống như chính phần mềm. Điều đó có nghĩa là chúng cần được xử lý tương tự như các đoạn mã khác:

• Đi qua kiểm tra mã
• Đã kiểm tra và tự động nếu có thể
• Được xem xét khi thực hiện các thay đổi đối với cơ sở mã (cụ thể, nếu một tập lệnh được nhiều nhà phát triển sử dụng, thực hiện thay đổi phá vỡ tập lệnh sẽ gây ra nhiều xung đột)
• Duy trì (với tất cả mọi thứ đòi hỏi - ưu tiên, thời gian, tài liệu, vv).

Có một số cân nhắc thêm áp dụng cho các tập lệnh hơn là cho chính phần mềm:

• Đầu tiên và quan trọng nhất, việc thuyết phục tổ chức và các bên liên quan của mình đầu tư vào việc duy trì các kịch bản giúp cho các nhà phát triển dễ dàng hơn rất nhiều. Điều đó có nghĩa là khó có thời gian hơn để đáp ứng các tiêu chí trên - thật dễ dàng để viết một tập lệnh phù hợp với môi trường của bạn, nhưng tham số hóa nó, làm cho nó ổn định, ghi lại tài liệu tốn nhiều thời gian hơn. Điều này có nghĩa là các tập lệnh có thể và sẽ trở thành mã chết trừ khi nhà phát triển có thể biện minh cho việc giữ tập lệnh hiện tại.
• Rất ít khả năng nhiều nhà phát triển sẽ đủ quen thuộc với một tập lệnh phức tạp để duy trì nó hoặc nhiều nhà phát triển cảm thấy quyền sở hữu mã. Khi nhà phát triển ban đầu rời đi, việc tìm người khác để sở hữu có thể khó khăn (và việc tìm kiếm và biện minh thời gian để họ tìm hiểu cách thức hoạt động của kịch bản có thể còn khó hơn).
• Nhiều khả năng một tập lệnh sẽ tương tác với máy phát triển và xây dựng môi trường theo một cách nào đó. Cũng có khả năng là bạn sẽ có nhiều nhà phát triển với nhiều môi trường khác nhau. Nếu một kịch bản gây rối môi trường vì nó không được duy trì đúng cách hoặc không được xem xét trường hợp góc, thì bạn không chỉ phá vỡ bản dựng hàng đêm của phần mềm, bạn có khả năng phải trả tiền cho nhà phát triển một ngày hoặc nhiều công việc hơn để có được môi trường trở lại bình thường. Điều này có thể gây ra máu baad và mất niềm tin.
• Bởi vì các tập lệnh thường nằm ngoài chính phần mềm, việc duy trì chúng có thể là một thách thức. Nếu các tập lệnh không chạy mặc dù tự động hóa, rất dễ để chúng bị cũ hoặc bị lãng quên, tại thời điểm đó, chúng đã trở thành mã chết và chỉ là nợ công nghệ mà ai đó sẽ cần phải có thời gian để dọn dẹp.

Tóm lại, các tập lệnh có thể rất hữu ích cho một nhà phát triển riêng lẻ, nhưng việc chia sẻ sau đó như là một phần của cơ sở mã có thể là một nhiệm vụ khó khăn hơn nhiều và có thể gây ra nhiều vấn đề hơn là được giải quyết.