Цікаве тематичне дослідження з питань масштабування проектів, які використовують динамічну та інтерпретовану мову, можна знайти у « Початковій скалі » Девіда Поллака.
Я почав шукати спосіб виразити код у своєму мозку більш простим, прямим способом. Я знайшов Рубі та Рейки. Я почувався звільненим. Рубі дозволив мені висловити поняття в набагато меншій кількості рядків коду. Rails було набагато простіше у використанні, ніж Spring MVC, Hibernate та інші «спрощені» веб-рамки Java. За допомогою Рубі та Рейлів я міг висловити набагато більше того, що було в моїй голові за коротший проміжок часу. Це було схоже на визволення, яке я відчував, коли перейшов з C ++ на Java ...
Оскільки мій проект Ruby and Rails виріс за кілька тисяч рядків коду, і коли я додав членів команди до своїх проектів, проблеми динамічних мов стали очевидними.
Ми витратили більше половини нашого тесту на написання часу на кодування, і значна частина підвищення продуктивності, яку ми побачили, була втрачена під час написання тестів . Більшість тестів були б непотрібними на Java, оскільки більшість з них були спрямовані на те, щоб ми оновили абонентів, коли ми перевстановили код, змінивши назви методів або кількість параметрів. Крім того, я виявив, що робота над командами, де було розумове поле між двома та чотирма членами команди, у Рубі все пішло добре, але, коли ми намагалися залучити нових членів до команди, розумові зв’язки важко було передати новим членам команди .
Я пішов шукати нове середовище мови та мови. Я шукав мову, настільки виразну, як Рубі, але настільки ж безпечну та високопродуктивну, як Java ...
Як бачите, основні виклики в масштабуванні проектів для автора виявилися в розробці тесту та передачі знань.
Зокрема, автор розглядає більше деталей, пояснюючи відмінності в тестовому написанні між динамічно та статично типізованими мовами у розділі 7. У розділі "Шкірно вбиваючи зайчиків: сходи Демті" автор обговорює порт "Скала" певного прикладу Рубі:
Чому Лакі Стіфф ... вводить деякі метапрограмування Рубі в масив Демті, в якому кролик бореться з масивом істот. N8han14 оновив приклад роботи в Scala ...
Порівняно з кодом Рубі, бібліотечні частини коду Scala були складнішими. Нам довелося зробити багато роботи, щоб переконатися в правильності наших типів. Нам довелося вручну переписати властивості Creature у класах DupMonster та CreatureCons. Це більше роботи, ніж method_missing. Нам також довелося провести неабияку роботу, щоб підтримати незмінність наших істот і зброї.
З іншого боку, результат виявився набагато потужнішим, ніж версія Ruby. Якби нам довелося писати тести для нашого коду Ruby, щоб перевірити, в чому нас запевняє компілятор Scala, нам знадобиться набагато більше рядків коду. Наприклад, ми можемо бути впевнені, що наш Кролик не міг володіти Сокирою. Щоб отримати цю впевненість у Рубі, нам доведеться написати тест, який гарантує, що виклик |^на Кролика не вдається. Наша версія Scala гарантує, що для цієї істоти може використовуватися лише зброя, визначена для даної істоти, що вимагатиме багато часу відображення в Рубі ...
Читання вище може змусити задуматися, що в міру збільшення проектів ще більше, тестове написання може стати непомітно громіздким. Це міркування було б помилковим, про що свідчать приклади успішних дуже великих проектів, згаданих у цьому самому питанні ("Python успішно використовується для ... YouTube").
Річ у тому, що масштабування проектів насправді не є простим. Дуже великі, довгоживучі проекти можуть "дозволити" різні процеси розробки тестів, з тестовими наборами якості виробництва, професійними командами тестових розробників та іншим важким складом.
Тестові набори Youtube або комплект із сумісністю Java впевнені, що вони живуть іншим життям, ніж тести у невеликому навчальному проекті, наприклад , масив Демті .