Длинная сборка калечит весь процесс разработки программного обеспечения. Вы не должны принимать это как факт жизни, не предприняв предварительно шагов по сокращению времени сборки. Вот несколько способов сделать это:

1. Купите SSD .
2. Добавьте больше оперативной памяти.
3. Если вы разрабатываете веб-приложение: используйте браузер для горячей перезагрузки кода на стороне клиента.
4. При разработке создавайте только те части кодовой базы, которые изменяются.
5. Изучите код сборки и на локальном компьютере замкните сборку, чтобы она строила только изменяемые части кодовой базы.
6. Рассмотрите возможность запуска автоматических модульных тестов только перед регистрацией.
7. Сотрудничайте с членами команды и менеджерами, чтобы навсегда сократить время сборки.

Подробнее о № 1 и № 2: они особенно эффективны. Вы должны делать это, даже если вам нужно тратить деньги из собственного кармана, потому что это повысит вашу общую удовлетворенность работой. Хороший плотник не потерпит тупой пилы, а вы не должны мириться с медленным жестким диском или рабочей станцией с недостаточным объемом оперативной памяти. Вы хотите быть дома ночью, ужинать с семьей или смотреть Netflix. Вы не хотите страдать от жалкой «смерти от тысячи порезов», ожидая медленных сборок.

РЕДАКТИРОВАТЬ:

1. Тем людям, которые сказали, что я не ответил на вопрос ОП: рассмотрите этот мета-ответ .
2. Медленная сборка может повредить рабочему месту. Очень важно изучить все варианты, прежде чем смириться с тем, что сборка выполняется медленно.

Бой на мечах — отличное упражнение. Используй это.

Честно говоря, мало что можно сделать с кодом во время его компиляции. Вы можете попытаться сократить время компиляции, но иногда это просто невозможно. Вы можете попытаться уменьшить количество компиляций, но опять же, иногда это просто отстой.

Итак.., чтобы повысить производительность, вам просто нужно поправиться, затем стул, бой на мечах. Я бы предложил:

• Отвечать на электронные письма
• Документ Билеты
• Заявка на документ
• Примите участие в SCM, если можете
• Сделайте законный перерыв.
• Обработка других несвязанных задач кода
• проводить встречи с членами команды
• Вздремнуть

Честно говоря, это одна из причин, по которой мне нравятся те языки, которые мне нравятся. Нет времени компиляции. Если у вас долгое время компиляции, вам просто придется иметь дело с этим, предполагая, что вы не можете его решить.

Например, в .NET вы можете разделить большие фрагменты логики на библиотеки DLL. Тогда вам нужно только часто компилировать участки кода.

Вы также можете посмотреть параметры компилятора и выбрать параметры, которые «прерывают работу после первой ошибки».

Примечание Только что заметил, что время сборки составляет 30 секунд. Это не долгий срок сборки. Если вы хотите чем-то заняться в это время, то сделайте упражнения для пальцев или встаньте и сделайте глубокий вдох. Длительное время сборки 10 минут. или больше.

Кое-что из собственного опыта:

Попробуйте исправить сразу несколько ошибок.

Конечно, поменять местами два столбца очень быстро, если вы заметите, что они поменялись местами. Но убедитесь, что вы не прекращаете проверку после того, как найдете 1 неисправность.

Например, вы можете уменьшить количество циклов, проверив другие вещи:

• По крайней мере, столбцы отформатированы правильно?
• Содержат ли все остальные столбцы то, что должны?
• ...

Это особенно важно в первых 1 или 2 циклах и может помочь вам вернуться с 15 к 5 задержкам по 30 секунд (и, возможно, к лучшему результату).

Попробуйте создать скрипт, который делает то, что вам нужно, а затем издает слышимый звук и/или создает всплывающее окно. Таким образом, если вы хотите отвлечь внимание, вам не нужно беспокоиться о том, чтобы полностью отключиться и забыть проверить, все ли вы сделали. Для меня нормально «отвлекаться», глядя на другие вещи, такие как другой код, но проблема в том, что вы «заходите слишком далеко в кроличью нору» и забываете проверить, завершен ли процесс.

Я не буду давать советов, как это сделать, так как это зависит от операционной системы, метода компиляции и других факторов. Я бы просто погуглил что-то вроде «сделать звук и всплывающее окно (вставьте здесь операционную систему), когда команда выполнена» или что-то в этом роде.

Обновление: как указывалось в некоторых комментариях, могут быть способы сделать это в определенных программах с графическим интерфейсом, а не только из командной строки. Как и раньше, я не буду давать здесь предложений, потому что они будут сильно различаться в зависимости от того, какая это программа и что требует времени.

Мой ответ зависит от компилятора, но попробуйте следующее:

Если компилятор позволяет вам просматривать код, и он компилируется в фоновом режиме, вы можете выполнить свою собственную версию RDD . Пока компилятор делает свое дело, просто просмотрите только что написанный код, скомпилируйте его в уме, просмотрите и попытайтесь найти ошибки.

Ты сможешь:

1. Не отвлекаться и не терять фокус.
2. Если есть ошибка, вам не потребуется двух минут, чтобы исправить и снова скомпилировать, но гораздо меньше.

Например, замена двух (плохо задокументированных) идентификаторов.

Я видел эту проблему во многих программах, которые используют Intили Stringдля каждого отдельного идентификатора; в этом случае легко случайно передать один ID вместо другого и не заметить этого... долгое время.

Если вы можете передать идентификатор цыпленка в автомат для напитков, ваш код имеет проблему (*).

Хитрость заключается в том, чтобы пометить идентификаторы. Поскольку вы говорите о длительном времени компиляции, я предполагаю, что в вашем распоряжении есть статически типизированный язык, и в этом случае вы должны использовать указанные типы. А ChickenIdне то же самое, что а DrinkId. А DrinkIdне то же самое, что а FuelId.

Сделайте их разными типами, и компилятор с радостью укажет вам на ваши ошибки, что ускорит цикл Fix-Compile-Test (путем вырезания шага Test и прерывания шага Compile).

Это статически типизированная версия принципа Fail Fast : вряд ли есть что-то быстрее, чем когда компилятор (или даже IDE, если он компилируется в фоновом режиме) указывает вам на ошибки.

В качестве бонуса вы даже можете ввести некоторую проверку в той же системе. В моей части мира несколько идентификаторов когда-либо были отрицательными для примеров ... или, если вы String, идентификатор 2 КБ, мягко говоря, удивителен.

(*) Если питье куриной крови не является стандартной практикой у вас дома, откуда мне знать...

Очевидный способ смягчить это — в первую очередь перестать совершать множество мелких ошибок. Вот с этого я бы начал в любом случае.

Если компилятору требуется 30 секунд, то компилятору требуется 30 секунд. Мы все делаем ошибки, но 15 раз в час было бы для меня сигналом к ​​тому, чтобы иметь более надежную методологию проверки ошибок.

Вероятно, существует столько же способов сделать это, сколько и программирование людей. Все, что работает для вас. Устраните проблему в ее источнике.

Я не программист, поэтому мне нужно немного повозиться, чтобы иногда что-то работало. Я остаюсь продуктивным благодаря многозадачности: когда я не могу работать над чем-то одним, я работаю над чем-то другим.

Я часто ловлю себя на том, что нажимаю кнопку компиляции и либо жду около 30 секунд, либо отвлекаюсь. По прошествии этих 30 секунд я возвращаюсь к работе, но обнаруживаю, что допустил небольшую ошибку, и в течение двух минут мне снова нужно выполнить компиляцию.

Ждать 30 секунд один раз не так уж и страшно, но делать это примерно 15 раз в час утомительно.

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

И если вы делаете небольшие ошибки, которые улавливает компилятор, это, вероятно, признак того, что вы также делаете логические ошибки, которые не улавливаются.

Постарайтесь быть более внимательным к своему коду перед его компиляцией.

Просмотрите его, напишите несколько комментариев, просмотрите его еще раз. Затем скомпилируйте.

Если вы обнаружите, что неоднократно совершаете одну и ту же небольшую ошибку, возможно, вам нужно потратить больше времени на изучение вашего языка программирования. Небольшие инвестиции в обучение могут окупиться в долгосрочной перспективе.

Инвестируйте время в себя.

10 секунд бесплатно: отжимайтесь.
60 секунд бесплатно: просмотрите вопросы о горячей сети Stack Exchange.
120 секунд бесплатно: встаньте и выпейте воды.

Я только что встал после 20 отжиманий, пока ждал, пока коллега ответит мне в Slack. Каждый раз, когда я вижу, что мне нужно 10 < seconds < 120чего-то ждать, я использую это время, чтобы стать лучше . С тех пор, как я начал делать это несколько недель назад, я чувствую себя более здоровым, более энергичным и менее уставшим. Я вижу, что моя продуктивность резко возросла. И я чувствую себя прекрасно.

Будьте внимательнее / Получите лучшее программное обеспечение

Настоящая проблема заключается в том, что вам нужно дождаться завершения сборки, чтобы узнать, допустили ли вы ошибку, или в том, что вы допускаете достаточно мелких ошибок, из-за чего очень короткое время сборки (30 секунд!) стало проблемой?

Не все проблемы сразу становятся очевидными; Вот почему случайное программирование — ужасная идея, и похоже на то, чем вы занимаетесь.

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

Используйте время для небольших разовых задач

30 секунд кажутся идеальным временем для выполнения нескольких небольших задач, которые вряд ли отвлекут вас от дел. Лучшие примеры, которые я могу придумать, это воспроизведение/изменение музыкальной дорожки и проверка вашей официальной электронной почты. Хотя второе может отвлекать вас, это может быть не так уж и плохо по своей сути.

Многозадачность

Как сказано в моем комментарии к вопросу, я привык к сборкам, которые занимают намного больше 30 секунд. Если ваши сборки начинают занимать больше времени, вы можете убедиться, что у вас всегда есть вторая задача, на которую можно переключиться во время них.

Я пытаюсь иметь задачу A и задачу B - задача B не имеет ничего общего с скомпилированными программами, над которыми я могу работать, пока задача A строит и поглощает почти все мои дисковые операции ввода-вывода.

Внедрите сервер непрерывной интеграции/сборки и автоматизированные тесты.

Как только вы сделаете фиксацию, ваш сервер сборки должен заметить и запустить автоматическую сборку. Это немедленно освобождает вас для продолжения работы.

Когда сборка завершится, ваш сервер должен запустить несколько автоматических тестов, чтобы выявить распространенные проблемы, подобные описанным вами (смешанные столбцы и т. д.). Сервер должен отправить вам электронное письмо, если обнаружит какие-либо ошибки компиляции и/или тестирования.

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

(Это ответ на редактирование исходного вопроса, в котором говорится, что рассматриваемые ошибки являются не ошибками компиляции, а теми, которые вы замечаете только после запуска программы.)

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

Учитывая, что ошибки здесь связаны не с плохим кодированием, а с плохой документацией, возможно ли (1) поймать много идентификаторов за один запуск компиляции, а не исправлять их по отдельности, тогда вы сможете работать более продуктивно, учитывая вашу систему сборки или (2 ) переместите идентификаторы, с которыми у вас возникла проблема, в текстовый файл, который можно прочитать во время выполнения. Затем вы хорошо скомпилируете, а затем проведете время в цикле «выполнение-редактирование-выполнение», что может быть быстрее в вашем случае.

Лучшее оборудование

Перед тем, как что-либо менять , пробовали ли вы использовать больше/лучшее оборудование для решения проблемы? Наличие обновленной рабочей станции — это не только приятно иметь, но и экономить деньги компании. Каждый раз, когда вы отвлекаетесь, компания теряет деньги (за то время, которое вы тратите на то, чтобы снова сосредоточиться).

Лучший процесс сборки

Если дополнительное/лучшее оборудование не решило проблему, рассмотрите возможность оптимизации процесса сборки, чтобы ускорить его, или даже изменить цепочку инструментов на более быструю.

Лучше себя

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

Когда я работаю над проблемой, я планирую, как ее решить в несколько этапов. Примером может быть реализация кнопки входа. Это многоэтапный процесс.

- Find the appropriate button icon and place it in the index.html file.
- Make the button call something on the backend, usually an API
- Make the API call the appropriate service.
- Let the service call the appropriate DataAccess methods
- Create tests for valid and invalid logins (backend)
- Create tests for valid and invalid logins (integration)
- Add these tests to automated test repo
- Commit code
- proceed to next task

Обратите внимание, что все задачи расположены в логическом порядке (по крайней мере, для меня), но они не являются зависимыми в том смысле, что изменения в коде происходят в разных местах. Это позволяет мне планировать следующую задачу, пока моя текущая задача компилирует и/или запускает тесты.

Однако этот подход требует, чтобы ваша способность переключаться между двумя задачами была на должном уровне. Если это не так, то этот подход вам не подходит. Другие подходы (упомянутые выше), такие как растяжка, упражнения для пальцев, также могут работать.