Все отлично в новой версии, но:
1. Памяти ест все больше, при чем рост почти в два раза в новой версии;
2. В майвен pom.xml хорошо бы обрабатывать имеющиеся property, если pom.xml открыт не из текущего проекта, а как обычный файл;
3. Очень хочется плюшек «инкрементальной компиляции» в майвен проектах;
4. Даешь фид-бек прямо из ide, как при возникновении ошибок. А то забываются некоторые ошибки и до отправки баг-репорта так и не доходит;
5. Импорт исходников для SNAPSHOT зависимостей почти никогда не отрабатывает автоматически, приходится указывать руками;
6. Будет ли прозрачное транслирование кириллицы Native2ASCII в property-файлах?
7. При поиске файлов для коммита (ctrl-K) иногда идея уходит в долгие раздумья минут на 10 — ходим пить кофе :)
8. Идея очень классно подменяет jsp и простые изменения в классах при обычном проекте, а вот при использовании maven иногда возникают проблемы. При этом используем remote Tomcat на той же машине, где и сборка — удобно запускать томкат отдельно :)
9. Редактор UI под Android в последней версии что-то не завелся, хотя раньше все было ок. Кидаешь любой элемент на форму, а получаешь некий один и тот же — может уже поправили :)
10. Очень нравится IDE и за бесплатную версию готов писать баг-репорты прямо из среды (goto 4)
В моем случае разбиение на модули хорошее, но сильно тормозит сборку maven-war-plugin со своими оверлеями. Собираем каждый модуль в отдельности. Для деплоя используем war, а во время разработки его распакованную версию в target, достаточно было бы, чтобы эта папка обновлялась только инкрементно, war даже перепаковывать не надо. Задумываюсь о доработке плагина :) Есть мысли?
Вам очень повезло, если вы не сталкиваетесь с этими «избитыми банальностями» каждый день. В большинстве же случаев очень трудно объяснить, почему описанные в статье проблемы съедают время.
Хлопальщиков я привел в пример, как последнюю запомнившуюся попытку повысить производительность. Никто и не предлагает работать на износ. Есть конкретное предложение для повышения эффективности своего труда. Если работать эффективно, то и времени свободного появится больше. Освобожденное время можно потратить на семью, саморазвитие, отдых, хобби и общение с друзьями.
Согласен с вами. Но стоит учитывать, что один прототип — одна концепция решения проблемы. Если появилась новая концепция, то для нее должен создаваться отдельный прототип.
Да, согласен. Если включать создание прототипов в стадию разработки, то оно занимает большую ее часть. В полном жизненном цикле ПО, на прототип тратится не очень много времени. На разработку же меньше всего. Документирование, прототипирование, документирование, исследование пользователей, тестирование, разработка, снова тестирование, документирование, сопровождение. Этап разработки совсем затерялся.
Прототипы бывают разные. Кнопка с некой простой логикой, позволяет получить данные от реальных пользователей системы. В вашем случае, эти три варианта и есть прототипы. Вы же не создаете для каждого продуманную монтажную плату, не пишете талмуд документации, опускаете некоторые ньюансы. Каждый вариант может быть похож на это:
Быстрый монтаж
А вот если прототип заведется, то будут разведены платы, написаны инструкции, стандартизированы элементы.
На самом деле на прототип тратиться совсем мало времени.
Его не надо тестировать, не надо оттачивать архитектуру, дизайн, механику и графику. Все схематично и максимально утрировано. Есть в приложении кнопка, при ее нажатии отправляются данные по сети. Так в прототипе просто при нажатии появляется ProgressBar и больше ничего.
По какому критерию у вас на прототип уходит столько же времени, сколько и на разработку основного продукта?
Да, ни один комплект тестов не гарантирует 100% безошибочности кода. Но, с другой стороны, тесты выявляют ошибки архитектуры, дизайна API. Исключают регрессию кода и повторное возникновение проявившейся ошибки в будущем. Тесты упрощают модернизацию системы, а также дают больше свободы действий при рефакторинге — всегда можно проверить, не сломалось ли что.
Можно сказать и иначе. Большую часть времени работы с кодом, его приходится читать, поэтому грамотное его оформление, прозрачная архитектура, актуальные комментарии, позволяют экономить уйму времени. Та же ситуация с тестами. Большую часть времени работы с кодом, разработчик тратит не на написание функционала, а на его сопровождение. В этом случае любое тестирование экономит уйму времени.
В этот критерий, конечно же, не входят сайты визитки и проекты «разработал за вечер и забыл».
Да, бытует мнение, что создание прототипа — это двойная работа. Поэтому из прототипа рождаются полуживые продукты. Прототип, это способ исследования проблемы, позволяющий получить критику заказчика и необходимый багаж знаний в предметной области.
1. Памяти ест все больше, при чем рост почти в два раза в новой версии;
2. В майвен pom.xml хорошо бы обрабатывать имеющиеся property, если pom.xml открыт не из текущего проекта, а как обычный файл;
3. Очень хочется плюшек «инкрементальной компиляции» в майвен проектах;
4. Даешь фид-бек прямо из ide, как при возникновении ошибок. А то забываются некоторые ошибки и до отправки баг-репорта так и не доходит;
5. Импорт исходников для SNAPSHOT зависимостей почти никогда не отрабатывает автоматически, приходится указывать руками;
6. Будет ли прозрачное транслирование кириллицы Native2ASCII в property-файлах?
7. При поиске файлов для коммита (ctrl-K) иногда идея уходит в долгие раздумья минут на 10 — ходим пить кофе :)
8. Идея очень классно подменяет jsp и простые изменения в классах при обычном проекте, а вот при использовании maven иногда возникают проблемы. При этом используем remote Tomcat на той же машине, где и сборка — удобно запускать томкат отдельно :)
9. Редактор UI под Android в последней версии что-то не завелся, хотя раньше все было ок. Кидаешь любой элемент на форму, а получаешь некий один и тот же — может уже поправили :)
10. Очень нравится IDE и за бесплатную версию готов писать баг-репорты прямо из среды (goto 4)
Кстати, в статье всего два упоминания, а в комментарии выше целых три. В процентном соотношении вы меня обогнали.
А вот если прототип заведется, то будут разведены платы, написаны инструкции, стандартизированы элементы.
Его не надо тестировать, не надо оттачивать архитектуру, дизайн, механику и графику. Все схематично и максимально утрировано. Есть в приложении кнопка, при ее нажатии отправляются данные по сети. Так в прототипе просто при нажатии появляется ProgressBar и больше ничего.
По какому критерию у вас на прототип уходит столько же времени, сколько и на разработку основного продукта?
В этот критерий, конечно же, не входят сайты визитки и проекты «разработал за вечер и забыл».