Разработчики всегда стремятся начать писать код с первого дня. Вот несколько причин, по которым нам нужно проявлять осторожность.
Каждый разработчик, независимо от его опыта, время от времени оказывается внутри временного цикла цикла разработки. Требования постоянно меняются, а разработчик постоянно обновляет код. Это все равно что застрять между Доктором Стрэнджем и Дормамму внутри временной петли. Как и в большинстве случаев, разработчикам приходится уступать требованиям.
Практика разработки программного обеспечения развивалась с годами, но может возникнуть ситуация, когда временная петля станет неизбежной. Столкнувшись с непростой задачей, некоторые из нас иногда склонны подталкивать чертежную доску ко второму шагу. Мы начинаем настраивать базовый код в первый день, как только получаем требование. Спустя годы, с опытом, наш разум начинает разрабатывать код (классы, сторонние библиотеки, плагины для использования и т. Д.), Как только мы видим требования на бумаге.
Почему мы пишем код в первый день?
Небольшие изменения или обновления
Всегда будут небольшие изменения, такие как перефразирование текста или добавление нового элемента в существующий раскрывающийся список, или переименование файла, или изменение текста пути URL. Эти изменения являются прямыми и требуют минимальных усилий, даже если они предусмотрены. да. Это изменения первого дня. Мы все можем согласиться с этим.
Опережая время
Время всегда побеждает. Мы когда-либо знали этот факт, особенно в мире разработки программного обеспечения. Какими бы быстрыми и блестящими мы ни были, разработка и развертывание кода требуют времени. Рефакторинг и выполнение регрессионных тестов нашего кода требует времени. Оценка трудозатрат в 10 часов всегда занимает 10 часов, если вы не хотите иметь какое-то время простоя для себя.
Мне нужно сообщить обновленную информацию о моей задаче.
Каждое требование требует времени на анализ, проектирование и разработку. Один мудрый менеджер однажды сказал мне: «Тебе нужно подумать, прежде чем твоя команда сможет начать писать код». Акцент был сделан на выполнении анализа и предоставлении команде простого дизайна кода. «Браво», которое вы получаете от своих коллег за кодирование в первый день, ничего не значит, если мы продолжаем изменять наш код и не успеваем в срок. В некоторых случаях бравада может дорого обойтись.
Вещи, которые мы теряем при кодировании в первый день.
Время на анализ и дизайн
да. Анализ и дизайн кода - это вещь. Это не клише. Во внутренней борьбе со временем мы часто забываем делать очевидные вещи. Мы не тратим достаточно времени на анализ и проектирование, когда уходим от начальной точки.
По мере накопления опыта анализ становится более управляемым. Это не значит, что мы имеем право пропустить этот шаг. Дизайн - еще один аспект, который всегда должен сопровождать ваши исследования. Как будет структурирован код для реализации функциональности?
Перед взлетом мы должны убедиться, что мы, как разработчики, задаем следующие вопросы.
- Есть ли у меня все необходимое для программирования?
- Есть ли недостающие звенья в данных требованиях?
- Требуются ли какие-либо обновления в будущем?
Эти вопросы не только помогут вам в разработке, но и помогут избежать недоразумений в будущем.
Я занимаюсь рефакторингом кода. Правда?
Допустим, вы начинаете писать код в первый же день и начинаете работать с большой скоростью. Что происходит, когда функциональность не работает должным образом или обнаруживается ошибка во время тестирования продукта. По своему опыту я обнаружил, что чаще всего это происходит из-за того, что я не уделял достаточно времени анализу / дизайну. Классы больше не нужны, компоненты должны были быть в другом пакете и так далее. Вы уловили суть. Удачи с дополнительным Техническим долгом в будущем :). Люди часто называют это рефакторингом, потому что они пропустили анализ и проектирование.
Из Википедии: В« компьютерном программировании и дизайне программного обеспечения рефакторинг кода - это процесс реструктуризации существующего компьютерного кода - изменение факторинга - без изменения его внешнее поведение. Рефакторинг предназначен для улучшения дизайна, структуры и / или реализации программного обеспечения (его нефункциональных атрибутов) при сохранении его функциональности ».
Надежность
Написание кода без готового дизайна похоже на навигацию по морю без карты и компаса. Вместо того, чтобы создавать надежный код, есть большая вероятность, что мы получим что-то, что соответствует письменным требованиям - слышали когда-нибудь о неявных требованиях? Код, поддерживающий предполагаемую функциональность, не сообщает вам автоматически, что код соответствует стандартам. Способность понимать код после месяцев (и нескольких лет) разработки - ключ к хорошей разработке программного обеспечения. Хорошо работающее программное обеспечение прямо или косвенно увеличивает доход почти в 100% случаев.
Вывод
Каждый хороший разработчик потратит значительное количество времени на обдумывание кода перед его написанием. Мы можем сэкономить много времени, усилий и много мирного времени, если у нас есть отличный дизайн для кодирования. Владельцы продуктов достаточно умны, чтобы понимать, что мы не всегда можем начать с первого дня. В следующий раз, давая оценки, пожалуйста, рассмотрите «время подумать, прежде чем начинать кодировать» как один элемент, прежде чем сообщать окончательные числа. Давайте начнем думать о коде, который мы пишем.
С Новым годом и счастливым кодированием!
