Как правильно писать на Java/Scala/C#/etc?

Question

[max_mara]

Хабрахабр, помоги!

Загрузил недавно (пол года назад) пару мануалов по Spring Framework, долго-нудно в общем мучался с Привет Миром, через пару дней в итоге получилось увидеть долгожданные заветные слова на мониторе. За это время я столкнулся с мавеном, томкатом, деплойментом, компиляциями, сборками проектов.

На PHP-же или Node.js писал я так

• Написал код
• Перегрузил страницу
• Обрадовался
• PROFIT...?

Так, вот. Данная методика в данном случае не подходит, ибо Привет Мир компилируется и деплоится секунд тридцать. А если это не привет мир? Мне почему-то кажется, что люди работающие в банках не обновляют страничку по тысяче раз, пока что-то там меняют

Сейчас активно пользуюсь скалой и Play Framework, очень их люблю. Но чувство того, что пишу я не правильно не покидает. Что делать? Как правильно писать? Как дальше жить?

Спасибо

Answer 1

[Snowindy]

На Java, особенно с использованием Spring Framework, нормальная разработка примерно такова
1) делим систему на слои: слой хранения данных с интерфейсом, слой бизнес-логики с интерфейсом, слой веб-приложения или веб-сервиса (к примеру).
2) Каждый из слоев обкладывается Unit-тестами (автоматизированное тестирование), при этом остальные части системы, на которые есть зависимости, выглядят просто как интерфейсы, которые можно «эмулировать» на время тестов (техника test mocking).
3) Интеграционное тестирование (автоматизированное/полуавтоматизированное тестирование) — несколько слоев запускаются почти в реальном окружении, и тестируются вместе наподобие черного ящика. Смотрим на то, как работает система в сборе.
4) Ручное тестирование всей системы перед релизом — к этому вы как раз привыкли.

Основная работа происходит на этапах 1 и 2. Цикл тест-изменение кода-тест — происходит обычно в течение нескольких секунд, так как Unit-тесты легковесные.

Цикл разработки, описанные вами, обладает одним серьезным ограничением — никакой автоматической защиты от регрессий функциональности. Для этого и пишут тесты.

Comments

[max_mara]

А как правильно писать тесты для каждого из слоев? Где можно подробней почитать о том, что Вы описали? Спасибо

[Snowindy]

Это интересный вопрос, который я задаю себе до сих пор.

Вначале про подход. Надо понимать, что писать тесты это непросто, и с первого раза не получится даже на тройку. Быть готовым к тому, что мало что будет получаться хорошо протестить сначала, из-за недостатка опыта. В голове держать мысль «а как я покрыл эту часть тестами? где она слаба?». Это будет мотивировать что-то делать постоянно, и стесняться выкатывать не покрытый автотестами код.
Я иду к тестам уже два года и к TDD все еще не пришел по уровню понимания. Тем не менее, я делаю гораздо более серьезный код, чем раньше и качество растет не просто в моем самомнении, а я вижу, что багов выплывает меньше, код разделен четче, нового человека в проект запускать проще и т.п.
Еще про время — написание и поддержка тестов добавляет около 60% к времени разработки. Но при этом снимает головняки с команды поддержки наполовину, а с команды тестирования на 80%. Вот и считайте командные трудозатраты. С тестами дешевле. Если их правильно писать.

Как начинать тестировать? Ну вот вам пример частей, которые подлежат тестированию в первую очередь:
1. Утилиты манипуляции строками, датами, числами. Все, что у вас в проекте называется *Utils.java обычно. Есть метод манипуляции — на вход ему даем данные, ждем на выходе результат (assertEquals и подобное из JUnit).

2. Парсеры. Надо разобрать HTML и забрать из него данные — это можно хорошо потестить. Берем пример HTML, сохраняем в файл, начитываем в строку, кормим парсеру, ждем результат.

3. Слой БД. Уже сложнее, но тоже можно. Выделяем сущности через паттерн DTO (на примере блога: User, BlogPost, Comment). Выделяем интерфейс БД с ее операциями. Там будут методы типа findLastNComments(), findUserById(), addCommentToPost() и т.п.
Делаем так, чтобы Unit-тесты поднимали как-то реальную БД на время тестов. Пишем тесты про логику работы БД слоя. К примеру, слой БД всегда обновляет поле lastUpdated при сохранении сущности. Вот и напишите для этого тест — ожидаем обновления lastUpdated после сохранения. Еще пример: ожидаем, что после обновления имени пользователя его можно найти по новому имени, а по старому уже нельзя.

Сколько тестов готовить?
Несколько разнородных валидных примеров, несколько corner-case примеров (null, пустая строка и т.п.), несколько невалидных примеров. В каждом из них код под тестом должен давать верный результат. Это мы по сути документация контракта кода, через тесты.

Постепенно вы заметите, что архитектура ваших систем стала не такая горбатая и путаная как раньше. Все потому, что вы начали делать на слои, выделять отдельные компоненты, интерфейсы и т.п. И все из-за тестов — они мешают делать макаронный код.

[max_mara]

Snowindy, вы просто бетмен. Уже который месяц и который раз перечитываю ваш комментарий, википедию и до сих пор ничего не получается, но код стал немного лучше. Спасибо Вам.

[Snowindy]

max_mara: хахаха, спасибо.
// Вначале перечитал свой комментарий, подумал, "какой разумный чувак написал диву даюсь!"

[Snowindy]

max_mara: Советую послушать лекции яндекса, там все по полочкам разложено намного лучше. habrahabr.ru/company/yandex/blog/245869

Answer 2

[deadkrolik]

Вот поэтому они и изобрели тесты.

Comments

[max_mara]

Но как?

Answer 3

[sergei-grigorev]

А еще можно воспользоваться JRebel, чтобы на ходу обновлять код, включая EJB-компоненты. Это позволит экономить время на деплойменте (за день я запускаю деплой обычно не чаще 3х раз). И соглашусь с deadkrolik, что неплохо писать юнит-тесты, так можно быстро найти и исправить ошибку в отдельном участке кода.

Answer 4

[javax]

Запускаете из IDE, он компилит лишь классы которые изменились, после этого поднимается сервер — ну секунд 10 15 надо подождать и всё.

Answer 5

[stemm]

В вашем случае подойдёт связка Spring + embedded Jetty + Maven + IDE Eclipse.

Встраиваемый Jetty очень ускоряет разработку, т.к. можно вносить изменения в код и очень быстро перезапускать приложение — у меня это занимает 2-3 секунды. Если нужно править JSP, JS или CSS — приложение можно вообще не останавливать.

Структура приложения более подробно описана здесь: steveliles.github.io/setting_up_embedded_jetty_8_and_spring_mvc_with_maven_and_no_xml.html

Answer 6

[Владимир Голованов]

Все дело в целях и объемах приложения.
Если вам нужен маленький Application — можете хоть JSP + Servlet использовать.
Если же большое приложение со множеством модулей, интеграцией с различными системами и гибкой системой динамически подключаемых модулей — это уже совсем другие подходы а-ля Spring + Hibernate + Maven + JBoss, разделение на слои, отделение модели данных от модели предметной области и т.д.
У Вас слишком общий вопрос для конкретных рекомендаций. Хороший архитектор выбирает средства по задаче.

Comments

[Владимир Голованов]

И еще разделите для себя технологии (Spring, Hibernate, Maven, JBoss и т.д.) и подходы (разбиение на модули, разделение на слои, отделение модели данных от модели предметной области, ORM, MVC и т.д.).
Технологии навязывают подходы, но не наоборот.