Một nghiên cứu trường hợp thú vị về các vấn đề của các dự án nhân rộng sử dụng ngôn ngữ động và diễn giải có thể được tìm thấy trong Beginning Scala của David Pollak.
Tôi bắt đầu tìm kiếm một cách để thể hiện mã trong não theo cách đơn giản hơn, trực tiếp hơn. Tôi tìm thấy Ruby và Rails. Tôi cảm thấy được giải thoát. Ruby cho phép tôi thể hiện các khái niệm trong ít dòng mã hơn. Rails dễ sử dụng hơn rất nhiều so với Spring MVC, Hibernate và các khung web Java Java được sắp xếp hợp lý khác. Với Ruby và Rails, tôi đã thể hiện nhiều hơn những gì trong đầu mình trong một khoảng thời gian ngắn hơn. Nó tương tự như sự giải phóng mà tôi cảm thấy khi tôi chuyển từ C ++ sang Java ...
Khi các dự án Ruby và Rails của tôi phát triển vượt quá vài nghìn dòng mã và khi tôi thêm các thành viên trong nhóm vào các dự án của mình, những thách thức của ngôn ngữ động trở nên rõ ràng.
Chúng tôi đã dành hơn một nửa thời gian viết mã để kiểm tra và phần lớn năng suất mà chúng tôi thấy đã bị mất khi viết bài kiểm tra . Hầu hết các thử nghiệm sẽ không cần thiết trong Java vì hầu hết các thử nghiệm đều hướng đến việc đảm bảo rằng chúng tôi đã cập nhật người gọi khi chúng tôi tái cấu trúc mã bằng cách thay đổi tên phương thức hoặc số tham số. Ngoài ra, tôi thấy rằng làm việc trong các đội có sự kết hợp giữa hai đến bốn thành viên trong nhóm, mọi thứ đã diễn ra tốt đẹp trong Ruby, nhưng khi chúng tôi cố gắng đưa các thành viên mới vào đội, các kết nối tinh thần rất khó truyền tải cho các thành viên mới của nhóm .
Tôi đã đi tìm một ngôn ngữ mới và môi trường phát triển. Tôi đang tìm kiếm một ngôn ngữ có tính biểu cảm như Ruby nhưng an toàn và hiệu suất cao như Java ...
Như bạn có thể thấy, những thách thức lớn trong việc mở rộng dự án cho tác giả hóa ra là trong quá trình phát triển thử nghiệm và chuyển giao kiến thức.
Cụ thể, tác giả đi sâu vào chi tiết hơn trong việc giải thích sự khác biệt trong cách viết kiểm tra giữa các ngôn ngữ được gõ động và tĩnh trong Chương 7. Trong phần "Poignantly Killing Bunnies: Dwemthy's Stairs" thảo luận về cổng Scala của một ví dụ Ruby cụ thể:
Tại sao Lucky Stiff ... giới thiệu một số khái niệm siêu lập trình của Ruby trong Dwemthy Array trong đó một con thỏ chiến đấu với một loạt các sinh vật. N8han14 đã cập nhật ví dụ để làm việc trong Scala ...
So với mã Ruby, các phần thư viện của mã Scala phức tạp hơn. Chúng tôi đã phải làm rất nhiều công việc để đảm bảo các loại của chúng tôi là chính xác. Chúng tôi đã phải viết lại các thuộc tính của Creature theo cách thủ công trong các lớp DupMonster và CreatureCons. Đây là công việc nhiều hơn method_missing. Chúng tôi cũng đã phải làm một số lượng công việc khá lớn để hỗ trợ tính bất biến trong Sinh vật và Vũ khí của chúng tôi.
Mặt khác, kết quả mạnh hơn nhiều so với phiên bản Ruby. Nếu chúng tôi phải viết các bài kiểm tra cho mã Ruby của chúng tôi để kiểm tra trình biên dịch Scala đảm bảo cho chúng tôi, chúng tôi sẽ cần nhiều dòng mã hơn. Ví dụ, chúng ta có thể chắc chắn rằng Thỏ của chúng ta không thể sử dụng Rìu. Để có được sự đảm bảo này trong Ruby, chúng tôi phải viết một bài kiểm tra để đảm bảo rằng việc gọi |^thỏ không thành công. Phiên bản Scala của chúng tôi đảm bảo rằng chỉ các Vũ khí được xác định cho một Sinh vật nhất định mới có thể được sử dụng bởi Sinh vật đó, thứ gì đó đòi hỏi rất nhiều phản xạ thời gian chạy trong Ruby ...
Đọc ở trên có thể khiến người ta nghĩ rằng khi các dự án ngày càng lớn hơn, việc viết bài kiểm tra có thể trở nên cồng kềnh. Lý do này sẽ sai, bằng chứng là các ví dụ về các dự án rất lớn thành công được đề cập trong chính câu hỏi này ("Python được sử dụng thành công cho ... YouTube").
Điều quan trọng là, nhân rộng các dự án không thực sự đơn giản. Các dự án lớn, có tuổi thọ cao có thể "đủ khả năng" cho quá trình phát triển thử nghiệm khác nhau, với các bộ thử nghiệm chất lượng sản xuất, các nhóm phát triển thử nghiệm chuyên nghiệp và các công cụ nặng khác.
Các bộ thử nghiệm Youtube hoặc Bộ tương thích Java chắc chắn có một cuộc sống khác so với các thử nghiệm trong một dự án hướng dẫn nhỏ như Dwemthy Array .