Lợi thế thực sự khi sử dụng Moo (se) trên Perl OO

Question

Tôi hiện đang làm việc tại một công ty, nơi chúng tôi đang phát triển Perl. Tuy nhiên mã thực sự lộn xộn, sử dụng thành ngữ Perl thực sự cũ, vì vậy tôi đã quyết định từ từ dọn dẹp và dạy đồng nghiệp của tôi về Hiện đại :: Perl, thiết kế phần mềm tốt, OOP - trừu tượng, khớp nối, thừa kế, nguyên tắc RẮN vv Tôi có một bất lợi, rằng tôi đang làm việc ở đây chỉ trong một tháng, vì vậy tôi khá mới ở đây.

Câu hỏi của tôi là: liệu tôi có thể (nếu như vậy) thuyết phục họ xem xét chuyển sang Moo (se) từ đồng bằng Perl OO? Ưu điểm của nó là gì? Tôi cần những lý do thực sự tốt để họ cân nhắc.

Có hiệu quả chi phí lớn khi sử dụng các mô-đun đó không? Tôi biết từ kinh nghiệm, rằng nó rất thoải mái khi sử dụng những mô-đun đó (cũng là những đặc điểm thực sự tốt), nhưng tôi sợ rằng họ sẽ từ chối chuyển đổi vì lý do hiệu suất.

So. Có một lợi thế và làm thế nào bạn sẽ mô tả nó cho các nhà phát triển Perl, những người đang bị mắc kẹt trong thời kỳ trước năm 2000?

Answer 1

Tôi muốn bắt đầu bằng cách yêu cầu - đồng nghiệp của bạn có đánh giá cao ý nghĩa của những điều khoản này và lý do tại sao chúng là những điều tốt? Luôn luôn có một thử thách khó khăn trong việc áp dụng một mô hình mới, bởi vì NGAY CẢ NẾU 'cách mới' của bạn là theo mọi cách tốt hơn ... bạn sẽ tạo ra một codebase cũ mà vẫn phải được duy trì. Hoặc làm lại.

Thuyết phục người nào đó 'đi OO' nếu họ đã xây dựng sự hiểu biết Perl của họ từ việc viết mã bash cho đến khi hack ... có thể là một thách thức. Họ cũng có thể - khá chính xác - chỉ ra rằng trong khi có những lợi thế để chuyển đổi, "mẫu số chung thấp nhất" được áp dụng. Có rất nhiều người biết 'non-Moose' perl so với những người biết 'Moose'.(Tuy nhiên, điều này có thể mang lại lợi ích cho bạn - chỉ ra rằng đó là một chuyên môn kỹ thuật hữu ích giúp cải thiện khả năng làm việc trong tương lai của họ)

Có một lý do tại sao các tập lệnh shell vẫn được sử dụng hôm nay - đó là vì chúng đơn giản, giải pháp đơn giản và dễ tiếp cận cho một vấn đề trước mắt.

Vì vậy, trước hết - giới thiệu các nguyên tắc khoa học máy tính của bạn. Đưa đồng nghiệp của bạn 'mua vào' cho những thứ bạn phác thảo. Điều này sẽ mất thời gian. Có lẽ rất nhiều thời gian. Nếu kiểu mã không thay đổi trong 15 năm, điều đó có nghĩa là các lập trình viên có cảm giác thoải mái với mọi thứ.

Sau đó, bạn cần chứng minh cho đồng nghiệp của mình lý do tại sao 'cách của bạn' đủ tốt hơn để họ bận tâm tìm hiểu nó. Những thứ 'mới' luôn xuất hiện và luôn có ai đó muốn thử một điều mới mẻ và thú vị. Bạn sẽ giống như người này với họ. Theo như họ đang quan tâm, 'phong cách nhà' hiện tại hoạt động tốt.

Bạn có thể thấy rằng việc triển khai tính năng mới trong phong cách mới của bạn là thuyết phục. Làm cho họ 'mua vào' để bạn làm nó như một bằng chứng về khái niệm. Bạn có thể tìm thấy một số lập trình viên khác như ý tưởng quá.

Nhưng bất kể - bạn phải chấp nhận khả năng rất thực tế mà không ai muốn trả nợ kỹ thuật của 'di sản' bạn sẽ tạo ra bằng cách thực hiện việc này. Có rất nhiều lợi thế kinh doanh bằng cách có một bộ giới hạn các mô hình mã hóa được sử dụng trong tổ chức của bạn. Bạn cần phải suy nghĩ về việc làm thế nào có cả hai trong dịch vụ sẽ làm việc ra ngoài.

Đây không phải là một cuộc thảo luận mới mặc dù - Lập trình OO luôn có những người không nhìn thấy điểm nào - họ thấy chi phí, không phải là lợi ích. Lý do chúng tôi sử dụng OO không phải vì nó hiệu quả hơn. Đó là vì đó là một cách hay để xây dựng mã mạnh mẽ, đáng tin cậy và có thể kiểm chứng. Đây sẽ là 'sân' của bạn để áp dụng Moose. Tôi sẽ đề nghị bạn xem xét các hình thức thử nghiệm khác nhau, và chuẩn bị bản demo của một bộ kiểm thử, vì đây là những thứ mà hầu hết các lập trình viên ghét :)

Answer 2

Đối với Moose cụ thể, có một số cuộc thảo luận thú vị về hiệu suất trên PerlMonks và Stackoverflow. Ý chính của nó có vẻ là Moose có một hình phạt khởi đầu đáng kể, nhưng không nhiều sau đó.

Tuy nhiên, tôi nghĩ có một câu hỏi lớn hơn ở đây: Khi nào bạn nên viết lại mã hiện tại?

Có hai ngưỡng khác nhau để xem xét khi lựa chọn một công cụ/phương pháp mới:

1. Công cụ/phương pháp XYZ là có lợi, vì vậy chúng ta nên sử dụng nó khi viết mã mới.
2. Công cụ/phương pháp XYZ rất có lợi khi chúng ta phải viết lại mã hiện có để sử dụng nó.

Nhiều, nhiều người đã phạm sai lầm khi viết lại toàn bộ một chuỗi mã hoàn hảo tốt bằng cách sử dụng mô hình ưa thích của họ, khi mô hình hiện tại vẫn ổn. Không chỉ là công việc lãng phí này, nó có nguy cơ giới thiệu các lỗi mới và làm cho sản phẩm cuối cùng tồi tệ hơn trước đây.

Thay đổi hệ thống đối tượng mà cơ sở mã hiện có sử dụng gần với viết lại mã cơ bản. Đây là một chi phí lớn và rủi ro, và bạn cần một lý do rất tốt để làm điều đó. Không chỉ là "Moose đẹp hơn khi viết mã trong".

Khi đến lúc viết một đoạn mã mới hoàn toàn tách biệt với mã cũ, đó có thể là thời điểm tốt để thử Moose. Nhưng tôi nghi ngờ rằng việc thay đổi tất cả các mã hiện tại là không thực sự chính đáng. (Ngoài ra, từ góc độ thực sự khiến mọi người lắng nghe ý tưởng của bạn, những thay đổi gia tăng nhỏ sẽ hoạt động tốt hơn nhiều, dù sao).