Представляю вам список самых распространенных ошибок, которые обычно совершают разработчики-новички (а иногда даже опытные разработчики). Изучите их, и не повторяйте! Итак, вот мой список из 10 ошибок:
10. Доверять данным, которые вводит пользователь
Никогда не доверяйте входным данным, которые предоставляет пользователь. Очень часто в ваши формы будут вводить некорректные данные. Не стоит винить пользователей — в основном, люди, работающие с вашим продуктом, будут делать это непреднамеренно. Люди часто ошибаются и имеют на это право, но у вашей программы нет права на ошибку. Часть некорректных данных может привести к сбою приложения и вызвать серьезные проблемы. Помимо наивных неопытных пользователей, есть люди с определенным уровнем технических знаний, которые они могут использовать, чтобы обойти систему. Это те пользователи, которые представляют угрозу для вашего приложения, а приложение должно быть защищено от любых вредоносных действий.
Единственный способ уберечь себя от неприятностей — проводить качественную валидацию входящих данных с понятными человеку сообщениями об ошибках. Проверка должна выполняться как на UI, так и на уровне базы данных, чтобы вы были уверены, что даже если валидация на клиенте была пройдена, приложение все равно не принимало неправильные данные.
9. Пренебрегать интеграционным тестированием
Изменения кода, которые вы вносите, обязательно должны проходить не только модульное, но и интеграционное тестирование. Вы должны тестировать ваш код, чтобы изменения, внесенные вами в одном модуле, не имели побочных эффектов для других. Это необходимое «зло». Если сможете написать автоматизированные модульные и интеграционные тесты, а не тестировать все вручную, вы сэкономите много времени.
8. Пренебрегать документацией
Самое ужасное, что вы можете сделать, это забить на документацию. Конечно, вы можете прочитать исходный код и попытаться разобраться в том, какую функциональность он реализует, но поверьте, это окажется очень сложной задачей. Без тщательного изучения документации по продукту вы не сможете писать эффективный код.
«Меняются требования, меняется код, но чаще всего меняется состав команды разработчиков».
Знание бизнес-логики приложения не может быть передано другому на все 100%. Иногда люди просто забывают. Поэтому и нужно писать документацию. Вам не нужно создавать десятки документов. Сделайте всего два — «спецификация требований» и «техническая документация». Обязательно обновляйте их. Все это должно быть частью строгого процесса, за которым нужно следить любой ценой и который должен быть учтен на этапе планирования проекта. Это поможет при выявлении ошибок на поздних этапах, когда ваше приложение будет находится в фазе поддержки/обслуживания.
7. Не логгировать ошибки
Никого, кроме разработчика не будут волновать проблемы разработчика. Заказчики будут постоянно просить реализовать новую функциональность или изменить существующую, но вряд ли будут просить логгировать ошибки или поведение пользователей.
Логгирование поведения пользователей, изменения данных систему и ошибок никогда не является частью требований заказчика, но подразумевается, что такая функциональность должна присутствовать и работать как следует. В один прекрасный день пользователь может просто обратится в службу поддержки и попросить предоставить какие-либо данные, относящиеся к доступу, или некоторые критически важные для бизнеса данные. И если у вас нет системы логгирования, вам нечего будет отправить пользователю.
Регистрация ошибок – это очень важно. Вы можете уделять безопасности и стабильности работы приложения много времени, но вы никогда застрахуете себя от всех потенциальных проблем. В таких случаях полезно использовать логгирование. Мониторинг журналов ошибок и отслеживание повторяющихся ошибок помогут вас сделать приложение более стабильным.
6. Неосторожное использование привилегированного доступа
Прежде всего, жестко разграничивайте доступ к вашему приложению. Полный контроль никогда не должны предоставляться рядовым пользователям. Даже самая защищенная система может быть подвергнута вредоносному воздействию, если вы даете пароли суперпользователя или привилегированной учетной записи кому попало. Риски, связанные с безрассудным использованием привилегированного доступа, должны приниматься во внимание разработчиками и специалистами службы технической поддержки.
«С большой властью приходит большая ответственность».
Я помню, как однажды в компании, где я работал, случайно удалили данные из основной таблицы. Словами не передать, как я сильно тогда переживал. Когда я успокоился, то вспомнил, что настроил резервное копирование данных! Предоставляйте ограниченный доступ для изменения данных вашей базы через интерфейс, который делает резервное копирование данных.
5. Конфигурационная угроза
Незащищенные конфигурационные файлы являются угрозой безопасности вашему приложению. Изменение конфигураций, которые затрагивают несколько приложений, должно быть реплицировано во многих файлах и базах данных. Вероятно, это не проблема, если у вас всего несколько приложений, но если у вас сотни приложений в корпоративной среде, то это будет сложно. Храните конфигурации вашего приложения в базе данных — этим вы обеспечите большую защищенность вашему продукту.
4. Хардкодная бомба замедленного действия
Использование хардкода в программе, безусловно, является плохой практикой. При таком подходе вы рискуете получить очень много проблем. К примеру, когда вы используете жестко закодированные значения для определенного максимального числа, предполагая, что максимум не будет достигнут. В сочетании с отсутствием логгирования ошибок вы рискуете оказаться в очень плохом положении. Старайтесь избегать жестко заданных значений. При необходимости переместите их в конфигурационные переменные или постарайтесь полностью избегать ситуаций, для которых они требуются.
3. Моральное и физическое истощение на работе
Постоянная работа без перерывов приведет к истощению сил на работе. Вы должны всегда делать регулярные перерывы. Когда вы перегружены работой, даже решение простых задач будет отнимать у вас много времени.
Установите для себя маленькие достижимые вехи и не забудьте вознаграждать себя за каждое достижение. Шоколадные конфеты, пирожные, быстрые игры — делайте то, что позволяет вам чувствовать себя хорошо. Изучение того, как предотвратить «трудовое истощение», поможет вам стать более продуктивным не только на работе, но и в обычной жизни.
2. Ошибки в выборе стека технологий для проекта
Иметь сильное резюме с перечнем всех новых технологий это здорово, но не нужно делать это для того, чтобы улучшить резюме. Изучите различные новые технологии, но используйте их только в том случае, если вы видите преимущества в каждом конкретном случае.
Если вы предлагаете решение, и это увеличивает время разработки, то, по крайней мере, все должно окупиться последующей простотой поддержки написанного кода. Поэтому я твердо верю в то, что перед тем, как предложить какое-то решение, нужно проверить облегчает ли это жизнь на самом деле. Стоит ли это того.
1. Быть специалистом в одном деле
Быть профи в одной технологии — это здорово. Но не стоит ограничиваться только одной технологией. Попытайтесь расширить свои знания, уверен, что обучение новому это нелегко, но такой вызов самому себе помогает вам стать настоящим профессионалом. Вы сможете выбирать наиболее эффективные технологии для решения различных бизнес-задач.
Времена меняются, технологии устаревают, но ваше обучение никогда не должно останавливаться. Всегда старайтесь исследовать новые технологии и попытайтесь взвесить все «за» и «против», прежде чем использовать новую технологию для решения проблемы.
Я хотел бы услышать ваши мнения о типичных проблемах разработчиков (как начинающих, так и опытных). Если у вас есть опыт, поделитесь им с нами в комментариях.
«Единственная настоящая ошибка – та, из которой мы ничему не научились». ~ Джон Пауэлл