Làm thế nào nên xử lý các tập lệnh ném đi có ích

Bạn biết nó diễn ra như thế nào: có một số nhiệm vụ lặp đi lặp lại nhỏ mà bạn đã tìm ra cách để tự động hóa nhanh chóng 95% công việc. Bạn tạo một tập lệnh, chạy nó, sửa thủ công đầu ra và bạn đã hoàn thành. Tất nhiên, bạn không cam kết kịch bản, vì nó không phù hợp với yêu cầu chất lượng của công ty (nó không có tài liệu, cũng không có bất kỳ thử nghiệm nào).

Một thời gian sau bạn thấy một đồng nghiệp đang làm một nhiệm vụ tương tự. Bạn nói "Này! Tôi đã tạo một kịch bản cho điều đó. Hãy để tôi xem nó. [Có vẻ] Ồ, nó đã được lưu trên máy tính xách tay trước của tôi nên tôi không có nó nữa. Quá tệ."

Các tập lệnh này thường có thể tiết kiệm rất nhiều thời gian và là người lãnh đạo của nhóm, tôi muốn chúng được lưu trữ trong kiểm soát phiên bản. Tuy nhiên, nếu tôi áp đặt các tiêu chuẩn khắt khe tương tự như phần còn lại của cơ sở mã cho các tập lệnh này, tôi sợ hầu hết các nhà phát triển sẽ giữ chúng cho riêng mình.

Tùy chọn duy nhất khác mà tôi có thể đưa ra là cho phép các nhà phát triển lưu trữ các tập lệnh trong một phần đặc biệt của kiểm soát phiên bản, trong đó không có kiểm soát chất lượng (giống như GitHub Gists). Rủi ro là những người khác sẽ không thể sử dụng mã bởi vì họ không thể tìm hoặc hiểu nó.

Làm thế nào vấn đề này có thể được giải quyết? Hay nó không nên được giải quyết?

Tùy chọn duy nhất khác mà tôi có thể đưa ra là cho phép các nhà phát triển lưu trữ các tập lệnh trong một phần đặc biệt của kiểm soát phiên bản, trong đó không có kiểm soát chất lượng (giống như GitHub Gists). Rủi ro là những người khác sẽ không thể sử dụng mã bởi vì họ không thể tìm hoặc hiểu nó.

Làm thế nào vấn đề này có thể được giải quyết? Hay nó không nên được giải quyết?

Vấn đề không thể được giải quyết.

Có một sự khác biệt lớn giữa việc chia sẻ mã bằng lời nói khi bạn tình cờ thấy rằng một đồng nghiệp đang gặp một khó khăn đặc biệt và chia sẻ nó đơn giản bằng cách đưa nó vào một thư viện mà tất cả đều có quyền truy cập.

Sự khác biệt là, trong trường hợp đầu tiên, bạn đang đóng vai trò của người sáng tạo và thủ thư với kiến ​​thức ngầm về vấn đề và mã bạn có để giải quyết nó, trong khi trong trường hợp thứ hai, những vai trò đó không có mặt.

Các tiêu chuẩn chung về mã của bạn có thể được thiết kế để loại bỏ vai trò của người thủ thư trong công ty của bạn và đảm bảo rằng thư viện vẫn có thể tự điều hướng cho tất cả những người đến.

Với số lượng lớn mã tồn tại lâu dài (như đặc trưng của hầu hết các sản phẩm phần mềm cốt lõi), thời gian và nỗ lực là hợp lý để duy trì khả năng nhiều thế hệ công nhân tiếp tục làm việc với toàn bộ tòa nhà. Trong các công ty có doanh thu nhân viên cao, một "thế hệ" nhân viên có thể ít như mọi năm hoặc hai năm.

Nhưng tất nhiên, việc đạt được các tiêu chuẩn "không thủ thư" đó phải trả giá bằng thời gian và công sức khổng lồ cho những người tạo ra thư viện ngay từ đầu, và nó vẫn đòi hỏi thời gian và nỗ lực đáng kể từ những người sau này sử dụng và điều hướng thư viện (mặc dù không phải là nỗ lực tương tự như tạo lại toàn bộ tòa nhà từ đầu, có thể đã mất nhiều thế hệ).

Mặt khác, hầu hết các kịch bản nhanh và bẩn này sẽ được viết để hoàn thành những việc đơn giản một cách nhanh chóng - có lẽ trên cơ sở một lần. Họ không phức tạp hoặc sáng tạo mạnh mẽ.

Bạn nói rằng họ "tiết kiệm thời gian", nhưng tất nhiên điều này chỉ đúng khi chúng không được viết theo tiêu chuẩn cao hơn, không có thủ thư, tiêu chuẩn. Chúng là đồ gá xây dựng cá nhân của những người đã tạo ra chúng - đòn bẩy tạm thời và giàn giáo của nỗ lực của con người, không phải là sản phẩm bền cuối cùng.

Có thể kiểm tra chúng trong kiểm soát phiên bản, để người tạo có một nơi nào đó để lưu trữ và bảo quản chúng một cách có hệ thống - nhưng cũng cần phải rõ ràng rằng chúng đại diện cho sản phẩm mà người tạo của chúng vẫn còn giám sát.

Nếu bạn có thể đọc mã của họ và ngay lập tức xem những gì nó làm, thì càng nhiều càng tốt. Nhưng đó là thư viện cá nhân của người sáng tạo và họ không được tổ chức theo tiêu chuẩn mà người khác phải có thể nhìn thấy những gì nó làm mà không cần tham khảo đến người tạo.

Đây không phải là một "rủi ro" do nhóm chịu trách nhiệm, hơn bất kỳ việc sắp xếp các hiệu ứng cá nhân trong nhà của bạn là một "rủi ro" đối với những người có thể muốn hỏi họ mượn. Ngược lại, việc lập chỉ mục toàn bộ nội dung trong nhà của bạn, sắp xếp chúng theo cách thức và cung cấp hướng dẫn sử dụng cho mọi hạng mục, là một rủi ro nghiêm trọng đối với việc sử dụng nhà hiệu quả liên tục của chính bạn.

Tôi cảm nhận được nỗi đau của bạn. Tôi muốn nói rằng có một phần riêng biệt trong repo của bạn có lẽ là tùy chọn để lưu trữ các tập lệnh này. Tuy nhiên, điều này chỉ giải quyết được một phần của vấn đề. Bây giờ bạn có chúng được lưu trữ ở đâu đó, nhưng không có cách nào tốt để đồng nghiệp của bạn biết họ đang ở đó.

Theo kinh nghiệm của tôi với tư cách là một nhà tư vấn cho một công ty nơi các kịch bản phong phú và được viết cho các khách hàng khác nhau và thường trên trang web, việc tìm ra những gì đã có là khó!

Bạn nên tìm cách chia sẻ những gì bạn đã xây dựng.

Trong công ty của chúng tôi, vì chúng tôi không lớn như vậy, chúng tôi kiểm tra những thứ như tập lệnh vào repo của chúng tôi, nhưng cũng gửi một email toàn công ty để thông báo cho các đồng nghiệp của chúng tôi về một giải pháp mới. Bằng cách này, ít nhất mọi người đều biết những gì đã có ngoài đó và ai cần liên lạc nếu họ cần.

Những người khác đã giải thích làm thế nào và tại sao để đảm bảo rằng các tập lệnh 'hữu ích' của bạn có thể được thực hiện đủ tốt để đi vào repo. Tôi chỉ định chen vào và nói rằng điều quan trọng không kém là đảm bảo rằng, nếu họ không đủ tốt để vào repo thì họ phải bị ném đi.

Nói cách khác, họ đủ tốt để đi vào repo hoặc họ không và phải bị ném ra ngoài. Nếu chúng không bị ném ra ngoài, chúng trở thành một gánh nặng không thể quản lý và cuối cùng không thể quản lý được.

Trước tiên tôi sẽ bắt đầu bằng cách nói rằng nếu các nhà phát triển của bạn miễn cưỡng đóng góp mã vì các tiêu chuẩn của bạn, thì các tiêu chuẩn của bạn quá khắt khe hoặc bạn nên cải thiện chất lượng và đạo đức làm việc của các nhà phát triển. Nếu đây là các tập lệnh nhỏ, không cần phải nỗ lực nhiều để đưa ra một vài nhận xét. Các nhà phát triển nên viết mã có thể đọc được theo mặc định và nếu không, vấn đề thực sự nằm ở nhân sự của bạn.

Để trả lời câu hỏi của bạn, bạn có một vài lựa chọn:

1. Nếu các tập lệnh đủ chung chung, bạn có thể lưu trữ chúng trong một kho lưu trữ riêng. Nếu các kịch bản rất tập trung vào dự án, điều này có thể không hoạt động.
2. Lưu trữ các tập lệnh trong cùng một kho lưu trữ trong một thư mục của riêng họ. Ví dụ, tại công ty của tôi, các dự án của chúng tôi thường có một cli/thư mục chứa một số tập lệnh dòng lệnh, thường được chạy một lần để khởi tạo môi trường, nhập một số dữ liệu nhất định, v.v.
3. Đây có thể là một lựa chọn kém tùy thuộc vào nhu cầu của bạn là gì, nhưng nếu bạn có một số lý do bạn không thể cam kết mã không tuân theo các tiêu chuẩn của bạn và / hoặc bạn có các nhà phát triển không sẵn sàng viết kịch bản nếu họ phải tuân theo các tiêu chuẩn đó, bạn có thể lưu trữ các tệp trên một ổ đĩa chung hoặc một cái gì đó tương tự. Đây có thể không phải là giải pháp tốt nhất nếu bạn cần tất cả các lợi ích của kiểm soát nguồn - tuy nhiên nó có thể có lợi trong một số trường hợp (cảm ơn Doc Brown vì chỉnh sửa này)

Với một trong hai tùy chọn đầu tiên, bạn có thể chọn ban hành các tiêu chuẩn mã hóa lỏng lẻo hơn trên kho lưu trữ khác hoặc thư mục.

Bắt đầu chính thức hóa các quy trình của bạn.

Bạn không đưa ra nhiều manh mối về việc các tập lệnh này đang được sử dụng để làm gì, nhưng tôi cho rằng bạn có nhiều nhiệm vụ triển khai và bảo trì khác nhau hoặc các bản sửa lỗi dữ liệu phổ biến được đưa ra cho các nhà phát triển để thực hiện vì chúng là những kiến ​​thức đủ để sửa nhiều thứ?

Bạn nên cố gắng để trở nên chuyên nghiệp hơn về điều này.

• Viết ra những nhiệm vụ này là gì và các bước để hoàn thành chúng.
• Xuất bản tài liệu đó trên một số trang web nội bộ hoặc mạng nội bộ
• Ghi lại tần suất thực hiện nhiệm vụ và thời gian trong một hệ thống bán vé.
• Tự động hóa các bước thủ công với một chương trình, nhưng đừng bỏ qua kiểm soát nguồn, kiểm tra, hỗ trợ, v.v. Phát triển một công cụ quản trị phù hợp.
• Cố gắng sử dụng các công cụ của bên thứ 3 thay vì phát triển các giải pháp của riêng bạn nếu có thể. Nó sẽ làm cho nó dễ dàng hơn cho tuyển dụng mới

Mục tiêu là làm cho quá trình hoàn toàn là một chức năng vẹt mà bất cứ ai cũng có thể làm bằng cách làm theo tài liệu hoặc chạy công cụ.

Sau đó, bạn có thể chuyển các nhà phát triển của mình trở lại viết các tính năng cho sản phẩm của bạn và thuê một số nhân viên hỗ trợ để giải quyết các vấn đề hàng ngày

Hầu như bất kỳ tập lệnh nào cũng có thể có tiềm năng sử dụng lại theo cách này hay cách khác. Nhưng tiềm năng đó ban đầu sẽ không rõ ràng - đó chính xác là lý do tại sao nó được coi là vứt bỏ vào thời điểm đó.

Cung cấp cho nhóm của bạn giải pháp kho lưu trữ giống như Github, không kiểm soát chất lượng, để khuyến khích việc sử dụng và ngăn chặn mất tiềm năng đó.

Nhưng cũng có một hoặc nhiều kho lưu trữ cho các công cụ / tiện ích chung, với kiểm soát chất lượng phù hợp tại chỗ.

Chỉ khi các tập lệnh được lưu trữ trong kho lưu trữ đó được tham chiếu thì tiềm năng sử dụng lại của chúng mới bắt đầu làm sáng tỏ. Đó là khi việc sử dụng lại được chính thức hóa nên bắt đầu, được giới thiệu bởi các nhà phát triển riêng lẻ nhận ra tiềm năng đó hoặc bởi bạn nếu các tài liệu tham khảo xảy ra trong bối cảnh nhóm. Nó có thể xảy ra ở lần tham chiếu đầu tiên hoặc có thể ở lần tiếp theo (nghĩa là khi tiềm năng sử dụng lại được xác nhận là cao hơn), tùy thuộc vào khả năng, lịch trình, tải của đội, v.v.

Rủi ro là những người khác sẽ không thể sử dụng mã bởi vì họ không thể tìm hoặc hiểu nó.

Các tài liệu tham khảo tự chăm sóc findvấn đề. Tác giả của kịch bản và / hoặc người đưa ra tài liệu tham khảo có thể giúp giải understandquyết vấn đề. Nếu không - hoặc tiềm năng sử dụng lại không thực sự ở đó hoặc hiểu mã sẽ chỉ là một phần của nỗ lực / chi phí tái sử dụng được chính thức hóa.

Khi đã được xác định, nỗ lực tái sử dụng được chính thức hóa sẽ xuất hiện trên màn hình radar của đội và kết quả cuối cùng sẽ rơi vào kho lưu trữ các công cụ / tiện ích chung. Đó là khi (các) tập lệnh vứt bỏ tương đương mà từ đó việc sử dụng lại có nguồn gốc có thể bị xóa (nếu tiềm năng của chúng đã cạn kiệt).

Tập trung cụ thể vào mã viết xấu nhưng chức năng; có một lập luận rất mạnh mẽ để không đưa những thứ này vào một kho lưu trữ.

Tôi có một bộ sưu tập các đoạn trong thư mục Dropbox cá nhân của mình. Nó chứa những thứ tôi thấy hữu ích:

• Một ví dụ về kho lưu trữ chung chung của EF
• Một serializer / deserializer đơn giản
• Một ứng dụng nhỏ liên kết hai tệp CSV và xuất ra tệp CSV mới.

Tuy nhiên:

• Ví dụ EF thiếu một đơn vị thực hiện công việc và không chứa gì ngoài các tùy chọn CRUD thô sơ nhất.
• Trình tuần tự hóa dựa trên XmlSerializer cũ và không thể đổi nó lấy bất kỳ thứ gì khác. Nó cũng có một vấn đề tham khảo tròn lớn.
• Ứng dụng được mã hóa cứng để tìm a.csv và b.csv trong thư mục ứng dụng và xuất ra ab.csv được mã hóa cứng trong cùng thư mục. Không có kiểm tra nếu các tập tin tồn tại, không có xử lý nullreference.

Mặc dù tôi vẫn sử dụng các đoạn mã này thường xuyên khi tôi cần nhanh chóng thực hiện một cái gì đó, nhưng chúng không thể tái sử dụng hoặc xây dựng tốt. Có nhiều lý do tại sao điều này không thể được đưa vào kiểm soát phiên bản của công ty chúng tôi:

• Không tự viết tài liệu.
• Ít đến không có phong cách mã hóa nào khác ngoài hackstyle của riêng tôi.
• Không xử lý lỗi.
• Không phải tất cả các cạm bẫy là rõ ràng (ví dụ: các tham chiếu vòng tròn trong serializer)

Nhưng đặc điểm chung nhất của tất cả các đoạn này:

• Ngay cả khi tôi tạo tài liệu, có lẽ bạn sẽ mất nhiều thời gian hơn để đọc và hiểu nó hơn là tự mình làm một cái gì đó!

Những đoạn trích này rất tốt cho tôi sử dụng, vì cá nhân tôi nhớ chúng được sử dụng cho mục đích gì, cách sử dụng chúng và bất kỳ cạm bẫy nào tôi gặp phải.
Nhưng nếu tôi cho người khác quyền truy cập vào các đoạn này, mà không có tôi, thì họ sẽ không nghĩ rằng những đoạn này có ích gì.

Các đoạn chỉ là một phần mở rộng kinh nghiệm của tôi với tư cách là một nhà phát triển. Không có tôi, những đoạn này là rác. Tôi chỉ sử dụng đoạn trích vì tôi không thể nhớ toàn bộ cú pháp của lớp xuống ký tự cuối cùng. Nhưng tôi nhớ ý định và cạm bẫy, thậm chí rất lâu sau khi sử dụng đoạn trích cuối cùng.

Nghĩ theo cách này:

Băng keo rất linh hoạt, nó có thể giải quyết nhiều vấn đề. Tuy nhiên, những điều đã được giải quyết bằng cách sử dụng băng keo thường được coi là khó coi. Nếu IKEA bao gồm băng keo trong tất cả các gói phẳng của họ, trong khi nó thực sự có thể giúp một số người cần nó, thì nó cũng sẽ tuyên bố mạnh mẽ về sự tin tưởng của IKEA về chất lượng của đồ nội thất mà họ đã bán cho bạn.

Vì lý do tương tự, các công ty không nên cho phép các đoạn mã hack trong kiểm soát phiên bản của họ, vì điều này khiến chất lượng của sản phẩm bị nghi ngờ.