Каждый программист должен знать об этих неуместных привычках.
Эта история стоит за платным членством Medium, что означает, что автор зарабатывает через партнерскую программу. Нравится читать на Medium? Купите членство для полного доступа.
Хорошие привычки меняют правила игры.
Они могут сделать или сломать чью-то жизнь.
Для программистов привычки играют жизненно важную роль в принятии решения о том, станут ли они посредственными или превосходными в своей области.
Безусловно, есть некоторые привычки, которые каждый программист хочет приобрести в своей жизни. Такие вещи, как правильное комментирование вашего кода, написание осмысленного имени функции и написание правильных тестовых случаев.
Но здесь речь идет не обо всех этих хороших привычках.
Здесь я рассказал о некоторых странных привычках, которые уже есть у программистов, но которые определенно приведут к неприятным последствиям в будущем.
1. Переписать все с нуля
Посредственные программисты хотят переписать все с нуля.
Они думают, что они гении, которые могут добиться большего, чем существующая система. Они не хотят повторно использовать существующий проверенный и проверенный код.
Каждый раз, когда они начинают работать с новой кодовой базой, они хотят избавиться от старого кода. Даже если старый код уже был в продакшене. Они готовы выбросить месяцы напряженной работы.
Выбрасывание проверенного и проверенного кода может иметь катастрофические последствия.
Как программист, вы определенно можете извлечь выгоду из старого кода. Вы можете повторно использовать предыдущий код. Это поможет ускорить процесс написания кода. Это может помочь вам легко уложиться в срок.
Предположим, вы переписали код, не прибегая к помощи предыдущего кода. Код, который вы написали, в конечном итоге показывает те же ошибки, которые уже были устранены в предыдущем коде.
Вы в конечном итоге тратите много времени разработчика.
Вы не только зря потратили свое время, но и не использовали время предыдущего разработчика. Этот разработчик уже исправил ту же ошибку, с которой вы столкнулись сейчас.
Если бы вы использовали старый проверенный и протестированный код. Это определенно сэкономило вам много времени и усилий.
2. Сразу внесите масштабные изменения в кодовую базу
Программисты, привыкшие вносить большие изменения вместо постепенных, сильно страдают.
Есть программисты, которые любят спокойно поработать две-три недели. Как только они закончатся, внесите большие изменения. После этого они приступают к тестированию кода.
Они не верят в постепенные изменения. Все, что их волнует, — это их собственная продуктивность.
Предположим, вы внесли большое изменение в кодовую базу. После этого вы начали тестировать код и получили более сотни неудачных тест-кейсов. Теперь, что ты собираешься делать?
Вы вложили так много времени, чтобы сделать такие большие изменения. Внезапно вам нужно отлаживать большой участок кода. Вы подвергли себя сильному давлению.
Если бы вы только внесли небольшие изменения и продолжали тестировать свой код. Вам придется иметь дело с меньшим количеством неудачных тестов. Вам не нужно иметь дело с сотнями неудачных тестов.
Все, с чем вам придется столкнуться, это четыре или пять неудачных тестов. Это легче обрабатывать.
Постепенные изменения намного лучше, чем одно серьезное изменение.
3. Большой технический долг
Крайне неэффективные программисты имеют привычку задерживать большой технический долг.
Когда есть выбор между «делать это правильно» и «делать это быстро». Они выбирают путь «сделай это быстро».
Они обещают себе, что вернутся позже и исправят все проблемы с кодом. Поскольку они дают это обещание, они серьезно относятся к возвращению. Но когда они продолжают кодировать, возникают новые проблемы.
Со временем они вовлекаются в новые проблемы и не решаются решать старые проблемы. Это называется техническим долгом.
В краткосрочной перспективе вы как программист можете извлечь выгоду из технического долга, но не в долгосрочной. Вы определенно можете использовать ярлыки при написании кода, но когда они остаются без внимания в течение длительного времени.
Последствия могут быть катастрофическими.
Когда вы будете готовы к следующей итерации, чтобы решить свой технический долг. Вы бы сделали так много плохих дизайнерских решений для ваших существующих решений, что рефакторинг вашего кода становится затруднительным.
Со временем вы понимаете, что ваш код стал настолько плохим, что вам нужно сначала исправить более ранние проблемы. Когда вы решите исправить старые проблемы, вы обнаружите, что у вас не так много времени, чтобы решать старые проблемы вместе с новым кодом.
Это становится настолько сложным, что вы начинаете ненавидеть себя.
4. Не проверять предыдущие тестовые случаи
Неэффективные программисты имеют привычку выбрасывать старые тестовые примеры.
Большинство из них считают, что проверка предыдущих тестов — пустая трата времени. У них также есть ложное убеждение, что, поскольку тесты были написаны для более старой версии кода…
Вот почему он не будет применим к реструктурированному коду.
Вместо того, чтобы выбрасывать старые тестовые примеры, программист определенно может использовать их для увеличения скорости разработки.
После каждой итерации они должны убедиться, что существующий тестовый пример пройден. Если предыдущих тестов недостаточно, они должны добавить новый тест.
Некоторые из старых тестовых случаев неприменимы к новому дизайну, но эти тестовые примеры могут вас кое-чему научить. Используйте эти тестовые примеры, чтобы задать вопросы, например, почему они использовались.
Это поможет вам прояснить свой мыслительный процесс.
Краткое содержание
- Избегайте склонности все переписывать.
- Вносите постепенные изменения, а не массовые изменения.
- Большой технический долг обязательно обернется неприятными последствиями.
- Не отбрасывайте существующие тестовые случаи. Они были добавлены не просто так.
Нажмите здесь, чтобы присоединиться к сообществу людей, которые любят программирование и технологии. Нравится читать на Medium? Купить членство для полного доступа.
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.
