1 — Не беспокойтесь о производственных ошибках
Некоторые разработчики внедряют решения, думая только о настоящем моменте, иногда многократно используя один и тот же код. Затем, когда необходимо изменить код, его нужно изменить в нескольких местах системы. Эта ошибка часто ошибочно оправдывается короткими сроками и высоким уровнем стресса.
Мы, разработчики, ДОЛЖНЫ знать, как сказать НЕТ безумным срокам. Мы профессионалы, которые знают, можем ли мы доставить или нет.
Очень вероятно, что производственные ошибки могут возникнуть, если мы не тестируем наши новые функции или не знаем бизнес-правил, как следует.
2 — Не брать на себя ответственность за ошибки, которые видят клиенты
TDD (разработка через тестирование) — отличный метод, позволяющий избежать многих проблем.
При тестировании мы должны использовать маленькие шаги и убедиться, что мы создаем простые тесты, чтобы убедиться, что реализация работает правильно. Лучшее в TDD то, что наш код создается уже протестированным.
Шансы получить ошибку уменьшаются, но важно помнить, что тесты не гарантируют отсутствие ошибок. Мы должны знать систему в целом. Мы должны четко знать бизнес-правила.
3 — Не думать о повторном использовании кода
Парадигму ОО (объектно-ориентированная) трудно освоить. Нужны самоотверженность и трудолюбие.
Некоторые разработчики просто не заботятся об улучшении своих навыков программирования. Они заботятся только о предоставлении работающей функции, потому что считают, что это действительно важно.
В большинстве случаев менеджеры не заботятся о качестве кода. Они заботятся только о том, чтобы программное обеспечение работало, и не думают о возможности внедрения новой функции или изменения программного обеспечения.
Эту проблему можно решить с помощью культуры код-ревью. Таким образом, разработчики могут помогать друг другу, делясь методами программирования, которые помогут им разрабатывать лучший код.
4 — Не думать об изменении функций (программное обеспечение всегда меняется)
Когда менеджеры договариваются о сжатых сроках со своими клиентами, это огромная проблема, потому что работа ложится на плечи разработчиков.
Что происходит с короткими сроками? Большую часть времени нам приходится работать много часов сверхурочно и, к сожалению, очень сложно реализовать код достаточно качественно. Думать только о решении проблемы было бы наиболее распространенным действием разработчика.
Когда проблема находится в корневом процессе компании, наша роль заключается в том, чтобы договориться и убедить наших менеджеров в том, что нам нужно больше времени для разработки проекта, чтобы получить лучшие результаты.
Просто создайте презентацию и покажите менеджерам цифры — количество багов, потерянное время — и насколько сложно изменить фичу в системе, написанной на скорую руку.
5 — Недостаточное знание бизнес-правил
Мы, разработчики, иногда недооцениваем сложность бизнес-правил.
Мы думаем, что они просты, потому что это не код, но у нас могут быть настоящие проблемы, если мы будем так думать.
Если мы не будем четко знать бизнес-правила, мы не будем знать, как эффективно внедрить решение.
Некоторые меры могут быть реализованы для этой проблемы. Очень эффективный способ решить эту проблему — написать основные бизнес-правила в Wiki (центральный сайт компании, в которой вы работаете) и поделиться ею со всеми разработчиками. Бизнес-правила будут централизованы, и их будет очень легко понять.
Проведение еженедельных или периодических совещаний (передача знаний) для обсуждения бизнес-правил — отличный способ свести к минимуму эту проблему.
Пока новые разработчики не поймут, что полное понимание бизнес-правил требует много времени, мы можем использовать эти меры, чтобы облегчить себе задачу!
Продолжайте в том же духе!
Подпишитесь на меня в Твиттере, чтобы узнать больше о отличных методах программирования. Каждую неделю буду присылать новый!
Подпишитесь и на рассылку рассылки NoBugsProject!
Поделись!
