Если вы используете настройки по-умолчанию, то IDEA будет использовать технологию Gradle Wrapper. В ней дистрибутив Gradle будет скачан и распакован в домашний каталог (по-умолчанию ~/.gradle/wrapper/dists ) и будет переиспользоваться для проектов с такой же версией.
К сожалению, если версия Gradle в проекте отличается от скачанных ранее хоть чуть-чуть: минорной версией или типом дистрибутива (*-bin или *-all), дистрибутив придётся скачивать заново.
Когда я работаю с кодом, я предпочту читать краткое содержание, влезая в детали только там, где это действительно нужно. Представим статью в википедии. Она должна ясно и сжато излагать предмет по существу, и давать ссылки на детали по мере необходимости.
Допускаю, что «бессистемная раскиданность» не доставляет мне проблем благодаря используемому инструменту (IDE). Читать код с большой степенью косвенности в Vim/Emacs наверное так же сложно, как читать распечатанную википедию (без браузера).
Ни в коем случае не претендую на «серебряную пулю», которой не существует. Просто отметил определённые перекосы и трудности, с которыми сталкиваюсь в повседневной работе.
Все ваши замечания очень даже по существу, и их стоит применять, организуя свой код и проект. Хотя публика может и не оценить предложение использовать копипейст :)
Отличной иллюстрацией проблем с использованием библиотек в индустрии стала истоия «левого отступа» в JavaScript, так что о ней нескоро забудут.
А вот с «обёмной, но линейной функцией» я бы поспорил. Сколь линейной бы она не была, если она не лезет в экран, её пора разделить на «шаги».
главное, чтобы определение вложенной процедуры не встречалось посередине длинного метода (незнаю, допускает ли Delphi такое) :) а так отличный вариант решения, да.
Никогда не слышал о параллельной разработке код + диаграмма, но видел инструменты где блок-схема является собственно кодом. Это обычно нишевые решения, например для телекоммуникаций.
сколько времени сожрёт её вызов чисто на запуливание-выпуливание параметров в/из стека.
Ого! Вот с таким уровнем оптимизации я никогда не сталкивался. Простите уж Java-программисту его наивность :)
Что касается большого количества параметров выделяемой функции, то, если все они действительно нужны, можно задуматься о выделении структуры или класса. Но только если не приходится экономить на виртуальных вызовах и количестве параметров на стеке :)
Самоконтроль нужен всем, это правда. Очень помогает, если на проекте есть инструмент code review (GitHub pull request, Gitter, Upsource etc.) в котором несложно предложить коллегам посмотреть на новый код.
Согласен с вами. Если задача требует 10 000 действий, то от них никуда не денешься. И разбиения только увеличивают количество сущностей.
Но правильно выбраное разбиение на абстракции может разбить эту задачу на (условно) 10 * 10 * 10 * 10 структурных единиц (не только методов, но может быть и классов). В зависимости от того, на сколько глубоко нужно изучить механизм решения задачи, можно будет прочесть (условно) один метод на 10 строк. Или ещё 2-3 метода по 10 строк и так далее. Гораздо легче сфокусироваться, погружаясь в детали.
Я столкнулся с таким, казалось бы излишним, разбиением в open source проекте, к которому готовил pull request, и оно меня спасло. Оно того стоит.
Спасибо, всё правда. Видимо, я плохо описал пример с if. Там речь шла о большом количестве кода внутри «веток». Пока дочитаешь до else, условие успеет уйти с экрана. В таком случае код «веток» следует вынести (функции, объекты и т. д.)
1. Нет, пересказа не было.
2. Была такая мысль. Но проиллюстрировать проблемы с большим объёмом кода можно только большим объёмом кода. Который никто не любит читать :)
Проблема с объёмом появляется тогда, когда логику проследить становится слишком трудно из-за самого объёма. Бороться нужно именно с такой ситуацией.
А преимущества и недостатки «волшебных однострочников» можно обсудить за дружеской кружкой пива :)
Я ничего не имею против коротких лямбд. Для того они и существуют. Но когда внутри callback-а кто-то ставит в очередь Runnable внутри которого ещё и дёргает map по коллекции, становится очень печально. Эдакий callback hell на стероидах.
на универсальность не претендую :)
Напомнить бывалым, что не написанный код содержит заведомо меньше ошибок, чем написанный.
К сожалению, в последнее время встречаю много огромных «простыней» за авторством именно бывалых (5+ лет разработки), уверенных в себе людей
Будет. Backend поддержки сложных проектов может быть запущен локально.
Если вы используете настройки по-умолчанию, то IDEA будет использовать технологию Gradle Wrapper. В ней дистрибутив Gradle будет скачан и распакован в домашний каталог (по-умолчанию ~/.gradle/wrapper/dists ) и будет переиспользоваться для проектов с такой же версией.
К сожалению, если версия Gradle в проекте отличается от скачанных ранее хоть чуть-чуть: минорной версией или типом дистрибутива (*-bin или *-all), дистрибутив придётся скачивать заново.
Допускаю, что «бессистемная раскиданность» не доставляет мне проблем благодаря используемому инструменту (IDE). Читать код с большой степенью косвенности в Vim/Emacs наверное так же сложно, как читать распечатанную википедию (без браузера).
Все ваши замечания очень даже по существу, и их стоит применять, организуя свой код и проект. Хотя публика может и не оценить предложение использовать копипейст :)
Отличной иллюстрацией проблем с использованием библиотек в индустрии стала истоия «левого отступа» в JavaScript, так что о ней нескоро забудут.
А вот с «обёмной, но линейной функцией» я бы поспорил. Сколь линейной бы она не была, если она не лезет в экран, её пора разделить на «шаги».
Ого! Вот с таким уровнем оптимизации я никогда не сталкивался. Простите уж Java-программисту его наивность :)
Что касается большого количества параметров выделяемой функции, то, если все они действительно нужны, можно задуматься о выделении структуры или класса. Но только если не приходится экономить на виртуальных вызовах и количестве параметров на стеке :)
Но правильно выбраное разбиение на абстракции может разбить эту задачу на (условно) 10 * 10 * 10 * 10 структурных единиц (не только методов, но может быть и классов). В зависимости от того, на сколько глубоко нужно изучить механизм решения задачи, можно будет прочесть (условно) один метод на 10 строк. Или ещё 2-3 метода по 10 строк и так далее. Гораздо легче сфокусироваться, погружаясь в детали.
Я столкнулся с таким, казалось бы излишним, разбиением в open source проекте, к которому готовил pull request, и оно меня спасло. Оно того стоит.
2. Была такая мысль. Но проиллюстрировать проблемы с большим объёмом кода можно только большим объёмом кода. Который никто не любит читать :)
А преимущества и недостатки «волшебных однострочников» можно обсудить за дружеской кружкой пива :)
Runnableвнутри которого ещё и дёргаетmapпо коллекции, становится очень печально. Эдакий callback hell на стероидах.на универсальность не претендую :)
К сожалению, в последнее время встречаю много огромных «простыней» за авторством именно бывалых (5+ лет разработки), уверенных в себе людей
PS а можно вас попросить билд лог со стек-трейсом? Посмотрим, что именно случилось.