Проблемы, возникающие в производственном процессе, постепенно привлекают внимание руководства среднего и высшего звена. Независимо от того, являетесь ли вы разработчиком или архитектором, вам следует уделить достаточно внимания следующим пунктам, чтобы избежать неловких ситуаций в будущем. Вы также можете использовать его как заметку по устранению неполадок.
#1. Не экспортируйте свойства конфигурации в файлы свойств или файлы XML. Например, количество потоков, используемых пакетной обработкой, не подлежит настройке в файле свойств. Ваша пакетная программа может работать без сбоев как в среде DEV, так и в среде UAT (User Acceptance Test), но после развертывания в PROD, когда она используется в качестве многопоточной программы для обработки больших наборов данных, будет выброшено исключение IOException. , либо из-за разных версий драйвера JDBC, либо из-за проблемы, описанной в № 2. Если количество потоков можно настроить в файле свойств, становится очень легко сделать его однопоточным приложением. Нам больше не нужно повторно развертывать и тестировать приложения для решения проблем. Этот метод также подходит для настройки URL-адреса, номера сервера, порта и т. д.
#2. Неподходящий размер набора данных, использованного в тесте. Например, типичный сценарий во время производства — использовать для тестирования только от 1 до 3 учетных записей, тогда как их число должно составлять от 1000 до 2000. При тестировании производительности используемые данные должны быть реальными и необрезанными. Тестирование производительности, не близкое к реальной среде, может привести к непредсказуемым проблемам с производительностью, расширением и многопоточностью. Только протестировав приложение с большим набором данных, вы сможете убедиться, что оно работает правильно и соответствует соглашениям об уровне обслуживания (стандартам уровня обслуживания) для нефункциональных атрибутов.
#3. Наивно полагать, что внешние и внутренние сервисы, вызываемые в приложении, надежны и всегда доступны. Запрет на тайм-ауты и повторные попытки вызовов службы отрицательно повлияет на стабильность и производительность приложения. Требуется надлежащее тестирование сбоев в обслуживании. Это важно, поскольку сегодняшние приложения в основном распределены и ориентированы на службы, требуя большого количества сетевых служб. Бесконечные запросы недоступных служб могут нанести вред вашему приложению. Балансировщик нагрузки также необходимо протестировать, чтобы убедиться, что он работает правильно и поддерживает балансировку каждого узла.
#4. Не соблюдаются минимальные требования безопасности. Как упоминалось выше, сетевые службы распространены повсеместно, что позволяет хакерам легко использовать их для атак типа «отказ в обслуживании». Поэтому при использовании Secure Sockets Layer вам необходимо выполнить базовую проверку и провести тестирование на проникновение с помощью таких инструментов, как Google Skipfish. Небезопасное приложение не только угрожает собственной стабильности, но также может негативно повлиять на репутацию компании из-за проблем с целостностью данных, например ситуации, когда клиент «А» может просматривать данные клиента «Б».
#5. Никакого тестирования кроссбраузерной совместимости. Сегодняшние веб-приложения в основном представляют собой многофункциональные одностраничные приложения, использующие язык программирования JavaScript и такие платформы, как angular js. Чтобы созданный вами веб-сайт работал без проблем на разных устройствах и в браузерах, вам необходимо реализовать соответствующий дизайн. Поэтому, чтобы убедиться, что ваше приложение работает на всех устройствах и в браузерах, его необходимо протестировать на совместимость.
#6. Не воплощать в жизнь бизнес-правила, которые могут часто меняться. Например, налоговое законодательство, государственные или отраслевые требования, таксономии и т. д. Вы можете использовать такой механизм, как Drools, для обработки бизнес-правил, который поможет вам реализовать эти бизнес-правила, сохранив их в базе данных или Excel. Как только предприятия освоят эти бизнес-правила, они смогут быстро реагировать на налоговое законодательство или связанные с ним требования с минимальными изменениями и тестированием.
№7. Следующие документы не предоставляются.
Помимо COS (Conditions of Satisfaction), формы, созданной MindMap, в гибкой разработке существуют две основные формы документов: 1 и 2.
#8. Отсутствие надлежащего плана аварийного восстановления и стратегии мониторинга и архивирования системы. По мере приближения сроков проекта эти вещи часто упускаются из виду в спешке с развертыванием проекта. Отсутствие надлежащего мониторинга системы с помощью Nagios и Splunk не только угрожает стабильности вашего приложения, но также затрудняет текущую диагностику и будущие усилия по улучшению.
#9. Для таблицы базы данных не существует удобного дизайна столбцов , таких как созданный_datetm, update_datetm, созданный_по, обновленный_по и метка времени. Он также не обеспечивает упорядоченное удаление столбцов записей, таких как столбец «удаленный», который может принимать «Y» или «Y». «N» Или вы можете выбрать столбец «record_status» «Активный» или «Неактивный».
# 10. Неспособность разработать правильный план восстановления. В результате в случае сбоя системы невозможно восстановить ее до стабильного состояния перед развертыванием. Этот план должен быть тщательно рассмотрен и подписан соответствующей командой. В планы входит откат к предыдущей версии программного обеспечения, удаление всех данных, вставленных в базу данных, и всех записей в файле свойств.
#11. Неспособность разработать план мощности до начала проекта. Сегодня при описании требований к платформе недостаточно просто сказать: «требуется компьютер Unix, сервер базы данных Oracle и сервер приложений JBoss». Ваш запрос должен быть точным
№ 12 ниже взят из комментария «Дэвида ДеЧезаре» из «java.dzone»,
№ 12. «Не используйте лучший инструмент для работы». Во многих случаях разработчики будут использовать язык или инструмент, который они хотят изучить, в производственной системе. Обычно это не лучший вариант. Например, использование баз данных NoSQL для данных, которые уже являются реляционными. Помните: какой бы инструмент вы ни выбрали, вам придется поддерживать свой продукт в течение следующих 3–5 лет (или даже дольше).
#13. Отсутствие достаточных резервов знаний в 16 ключевых технических областях. Эти области включают выявление и устранение 1) «проблем параллелизма», 2) проблем транзакций и 3) проблем производительности. Во многих интервью я полагался на эти три аспекта знаний, чтобы получить новые контракты.