Là ngôn ngữ năng động bất lợi cho sự phát triển nhanh?

Từ những gì tôi đã đọc phát triển nhanh thường liên quan đến tái cấu trúc hoặc đảo ngược mã kỹ thuật thành sơ đồ. Tất nhiên có nhiều hơn thế, nhưng nếu chúng ta xem xét các thực tiễn dựa trên hai phương pháp này, liệu các ngôn ngữ được gõ động có bất lợi?

Có vẻ như các ngôn ngữ được gõ tĩnh sẽ giúp việc tái cấu trúc và đảo ngược kỹ thuật dễ dàng hơn nhiều.

Là tái cấu trúc hoặc (tự động) kỹ thuật đảo ngược khó khăn nếu không phải là không thể trong các ngôn ngữ gõ động? Các dự án trong thế giới thực nói gì về việc sử dụng các ngôn ngữ được gõ động cho phương pháp nhanh?

Về mặt lý thuyết, các ngôn ngữ động đều bất lợi, bởi vì chúng chỉ định ít hơn về cách thức hoạt động của mã (các ràng buộc là gì) và do đó, việc tái cấu trúc có thể được thực hiện tự động ít hơn và các vấn đề phát sinh cũng không thể được phát hiện tự động .

Nhưng tất cả những thứ khác không bằng nhau. Các ngôn ngữ động phổ biến nhất cho phép mã rất nhỏ gọn nhưng dễ hiểu, thường làm cho sự phát triển trong chúng nhanh hơn và làm cho logic (có thể thay đổi trong tái cấu trúc) dễ dàng phát hiện hơn. Vì vậy, mặc dù bạn có thể mất một số lợi thế tương đối khi làm việc bằng ngôn ngữ động, bạn vẫn có thể đi ra phía trước, đặc biệt nếu bạn dự định thực hiện tái cấu trúc bằng tay.

Mặt khác, tồn tại các ngôn ngữ được gõ tĩnh với các ưu điểm cơ bản giống như các ngôn ngữ động (nghĩa là nhỏ gọn và dễ hiểu - với các loại chủ yếu được suy luận, nhưng rất nhiều ở đó): Haskell có lẽ là ví dụ hàng đầu, nhưng OCaML / F #, Scala, và những người khác cũng nằm trong danh mục này. Thật không may, vì chúng ít được sử dụng nhiều hơn các ngôn ngữ gõ tĩnh phổ biến nhất, nên chúng không có nhiều bộ công cụ cho chúng (ví dụ: để tái cấu trúc).

Vì vậy, như một điểm mấu chốt, tôi nghĩ bạn sẽ làm đầy đủ với các phương pháp nhanh nhẹn trong hầu hết các ngôn ngữ; Tôi sẽ không nói rằng có một người chiến thắng rõ ràng ngay bây giờ vì thực tế chưa bắt kịp với lý thuyết.

Tái cấu trúc tự động được phát minh trong Smalltalk, một ngôn ngữ được gõ động. Vì vậy, không, không thể tái cấu trúc tự động trong một ngôn ngữ được gõ động. Làm thế nào nó là khó khăn phụ thuộc nhiều hơn vào các yếu tố khác bên cạnh kỷ luật đánh máy. C ++ và Java đều được gõ tĩnh, nhưng các công cụ tái cấu trúc chỉ thực sự tồn tại cho Java. Smalltalk với nội tâm và cú pháp đơn giản của nó là một ứng cử viên thực sự tốt cho các công cụ tái cấu trúc.

Trong một số cách, gõ động thực sự làm cho việc tái cấu trúc dễ dàng hơn. Nếu bạn có một bộ thử nghiệm tốt, bạn có thể chắc chắn rằng các phép tái cấu trúc của bạn không bị hỏng bất kỳ thứ gì. Một cơ sở mã được gõ động thường nhỏ hơn. Ngoài ra, tái cấu trúc có xu hướng ảnh hưởng đến ít mã hơn. Hoàn toàn nỗ lực liên quan đến việc tái cấu trúc thủ công một cơ sở mã động ít hơn so với cơ sở mã tĩnh.

Tái cấu trúc được phát minh trong các ngôn ngữ động. Công cụ tái cấu trúc tự động được phát minh bằng các ngôn ngữ động. IDE được phát minh bằng các ngôn ngữ động. Một số phương pháp Agile được phát minh bằng các ngôn ngữ động.

Tôi thực sự không thấy bất kỳ vấn đề.

Chúng ta quên mất, cách làm việc "Agile" được gọi là Lập trình cực đoan (XP) đã được tạo ra trong một dự án Smalltalk (và Smalltalk chắc chắn được coi là một ngôn ngữ "động").

Đây là một trường hợp nghiên cứu về sử dụng công nghiệp một công cụ tái cấu trúc được cung cấp với một ngôn ngữ được gõ động:

Một ứng dụng Smalltalk rất lớn đã được phát triển tại Cargill để hỗ trợ hoạt động của thang máy hạt và các hoạt động giao dịch hàng hóa liên quan. Ứng dụng khách Smalltalk có 385 cửa sổ và hơn 5.000 lớp. Khoảng 2.000 lớp trong ứng dụng này đã tương tác với khung truy cập dữ liệu sớm (khoảng năm 1993). Khung công tác tự động thực hiện ánh xạ các thuộc tính đối tượng vào các cột của bảng dữ liệu.

Phân tích cho thấy mặc dù việc tra cứu động đã tiêu tốn 40% thời gian thực hiện của máy khách, nhưng điều đó là không cần thiết.

Một giao diện lớp dữ liệu mới được phát triển yêu cầu lớp nghiệp vụ cung cấp thuộc tính đối tượng để ánh xạ cột trong một phương thức được mã hóa rõ ràng. Thử nghiệm cho thấy giao diện này là đơn đặt hàng có cường độ nhanh hơn. Vấn đề là làm thế nào để thay đổi 2.100 người dùng lớp doanh nghiệp của lớp dữ liệu.

Một ứng dụng lớn đang được phát triển không thể đóng băng mã trong khi chuyển đổi giao diện được xây dựng và thử nghiệm. Chúng tôi đã phải xây dựng và kiểm tra các phép biến đổi trong một nhánh song song của kho lưu trữ mã từ luồng phát triển chính. Khi phép chuyển đổi được kiểm tra đầy đủ, thì nó được áp dụng cho luồng mã chính trong một thao tác.

Ít hơn 35 lỗi được tìm thấy trong 17.100 thay đổi. Tất cả các lỗi đã nhanh chóng được giải quyết trong khoảng thời gian ba tuần.

Nếu các thay đổi được thực hiện thủ công, chúng tôi ước tính rằng sẽ mất 8.500 giờ, so với 235 giờ để phát triển các quy tắc chuyển đổi.

Nhiệm vụ đã được hoàn thành trong 3% thời gian dự kiến ​​bằng cách sử dụng Quy tắc viết lại. Đây là một cải tiến theo hệ số 36.

từ chuyển đổi của một lớp dữ liệu ứng dụng, Will Will Loew-Blosser OOPSLA 2002

Ngoài ra - "Công cụ để thực hiện các thay đổi không thể - trải nghiệm với một công cụ để chuyển đổi các chương trình Smalltalk lớn"

Nguyên tắc của bạn nghĩ âm thanh cho tôi chính xác .

Các ngôn ngữ được gõ mạnh như C # là ứng cử viên tốt cho cơ sở mã liên tục cần bao thanh toán lại. Về cơ bản hầu hết các công cụ bao thanh toán lại (như Resharper, JustCode, v.v.) trên thị trường đều rất hiệu quả trong các ngôn ngữ lập trình được gõ tĩnh.

Các dự án trong thế giới thực nói gì về việc sử dụng các ngôn ngữ được gõ động cho phương pháp nhanh?

Đối với nhóm phát triển thực hành phương pháp Agile / Scrum, rất hữu ích (thậm chí quan trọng) để có bộ công cụ tái bao thanh toán tốt dưới lớp giáp. Mặt khác, tất cả những thay đổi đột ngột trong lần chạy nước rút sắp tới có thể là một cơn ác mộng phải sửa đổi hoặc thiết kế lại.

Do đó, phương pháp nhanh không cung cấp lợi thế cho các ngôn ngữ được nhập tĩnh hoặc động một lần. Những gì nó cung cấp là một cách tiếp cận lặp đi lặp lại để xây dựng một ứng dụng vững chắc.