Именно проблемы, которых вы не ожидаете, наносят наибольший ущерб, и вы никогда не ожидаете глупости собственных разработчиков.
«Сегодняшнее программирование - это гонка между программистами, стремящимися создавать большие и лучшие программы, защищающие от идиотов, и Вселенной, пытающейся создавать больших и лучших идиотов. Пока что Вселенная побеждает ». - Рик Кук
Я прочитал статью Пять универсальных законов человеческой глупости, и она заставила меня задуматься о глупых вещах, которые я совершал и видел, как поступают другие разработчики.
Глупые действия не являются преднамеренными или злонамеренными, поэтому они могут нанести так много вреда, потому что их никто не ожидает.
Вы не можете защититься от глупости, потому что никто не предсказывает, что члены своей команды сделают что-нибудь, чтобы навредить команде.
Неожиданные проблемы на проектах вызывают наибольшие сбои. Вы можете попытаться смягчить эти проблемы, предугадав, что может пойти не так, используя предсмертный анализ: Определение проблем вашего проекта поможет вам их избежать
Глупый разработчик - самый опасный человек в разработке, потому что никто не ожидает, что разработчик нанесет какой-либо ущерб.
Подобно ошибкам, глупость прячется за предположениями, это создает иллюзию, что ситуация находится под контролем, все расслабляются и полагают, что все в порядке. Вот почему глупость вызывает такие сбои.
Закон 1. Разработчики считают, что разработчики не глупы, а только пользователи и клиенты 🙂
Есть не только глупые разработчики, но и их больше, чем мы себе представляем. Каждый разработчик может сделать что-нибудь глупое, особенно когда он торопится или делает что-то, чего раньше не делал.
Младшие разработчики могут совершать глупые поступки, но ошибки - это цена обучения, и старшие участники обязаны помогать, обучать и выявлять ошибки, прежде чем они обернутся катастрофой.
Легко стать излишне самоуверенным и на полной скорости впасть в глупую ошибку, мы никогда не думаем о себе, как о совершении чего-то глупого, это способствует неожиданности глупого события и усиливает его влияние.
Это удар, которого вы не ожидаете, и он сбивает вас с толку.
Закон 2. Разработчики ориентируются на технологические решения, а не на бизнес-требования
Клиенты и пользователи хотят, чтобы система решала их проблемы и помогала им выполнять свою работу. Разработчики создают техническую систему, отвечающую требованиям. Требования часто неверны, но разработчики не могут определить это, если не понимают, что нужно бизнесу.
Знай, где ты специалист, а где ты идиот, разработчики не являются бизнес-экспертами (вначале). Разработчики должны разбираться в бизнесе, задавать много вопросов и не оставлять никаких предположений невыясненными.
Пользователи не заботятся о технических решениях, они заботятся о системе, которая помогает им выполнять свою работу и добиваться успеха в бизнесе.
Правило 3. Разработчики соглашаются / вынуждают к невозможным срокам
Ничто так не порождает глупость, как недостаток времени. Разработчики склонны к оптимистическим оценкам, а руководство / клиенты любят принимать эти оценки как обязательства.
Когда разработчики спешат с ошибками и появляются баги, среда, в которой все спешат, процветает в глупости.
Закон 4. Разработчики недооценивают ущерб, хаос и разрушения, которые могут быть причинены разработчиками с правами администратора.
Тот факт, что разработчики могут предоставить себе права администратора в среде, не означает, что они должны это делать. Роль системного администратора - это преимущество и проклятие для разработчиков Dynamics. Это приводит к тестированию кода и функциональности с разными привилегиями, которые пользователи будут использовать, что позволяет ошибкам проникать в среду ниже по течению.
Закон 5. Данные разработчика
Разработчики модифицируют данные для тестирования своего кода. Эти сомнительные данные могут вызвать проблемы в других областях, потому что это данные в непредвиденном состоянии, что невозможно при использовании системы.
Разработчики создают данные, которые могут только они, и создают ошибки, которые пользователи никогда не смогут создать.
Закон 6. Не тестировать собственный код
Проверьте код, который вы пишете, или вы не знаете, что он работает? Написание модульных тестов позволяет любому тестировать код после внесения каких-либо изменений. Наиболее распространенные ошибки, которые мы пропускаем, - это ошибки в других связанных или зависимых областях решения. Модульные тесты выявляют эти непредвиденные ошибки.
Многим разработчикам не нравится писать модульные тесты, потому что они чувствуют, что это замедляет их работу, и часто разработчики проводят минимальное тестирование только счастливого пути.
Закон 7. Основание на предположениях
Когда вы создаете настройки / код на основе предположений, он строится на слабой основе, которая может измениться или сдвинуться с места.
Предположения - это то место, где прячутся ошибки, и эта проблема усугубляется, если вы опираетесь на предположения, потому что вы наслоите области, которые нужно будет изменить.
Закон 8. Развертывание вручную
Развертывание вручную утомительно, медленнее и подвержено ошибкам. DevOps и автоматическое развертывание требуют начальных инвестиций для настройки, но дают долгосрочные преимущества
Развертывание вручную увеличивает вероятность ошибок и тратит время и силы разработчиков.
Если вы можете что-то автоматизировать в разумные сроки, то вам следует это сделать.
Стоимость операций ручного развертывания
Закон 9. Не писать документацию
Не писать документ - это ярлык, который через несколько месяцев снова вас укусит. Те же разработчики, которые не пишут документацию, нуждаются в ней больше всего в будущем.
Разработчики уходят из проектов и компаний, их знания исчезают вместе с ними. Новые разработчики должны учиться, читая код, тестируя его и выясняя, как он работает. Это медленный и сложный процесс, которого можно избежать, задокументировав систему.
Когда вы создаете код и настраиваете его, вы понимаете его полностью, по прошествии месяцев вы это забываете.
Документ по развертыванию имеет решающее значение, потому что среди множества шагов легко пропустить. Ошибки развертывания могут привести к рассинхронизации сред и появлению незаметных ошибок, которые проявляются не во всех средах. Эти проблемы сложно диагностировать и разрешить.
Закон 10. Внесение изменений в среду, не связанную с разработкой
Вы хотите, чтобы все среды были синхронизированы, это гарантирует, что любое тестирование, которое вы проводите в любой среде, обнаружит проблемы во всех средах. Поддерживайте синхронизацию сред, изменяя среду разработки и перемещая эти изменения по средам с помощью контрольного выпуска.
Как только вы вносите изменения непосредственно в среду, отличную от среды разработки, среды перестают синхронизироваться.
Почему это проблема и почему это глупо?
Когда среды различны, тестирование в этой среде является уникальным, тестирование, которое вы проводите в изменившейся среде, не поможет вам найти проблемы в производственной среде, потому что среды разные.
например изменение, внесенное в эту среду, не связанную с разработкой, может вызвать или скрыть ошибки. Если вы протестируете функциональность в Dev, это не значит, что она будет работать так же в изменившейся среде.
Когда разработчик исправляет проблему напрямую, применив одно и то же исправление во всей среде, этот процесс подвержен ошибкам. Лучше сменить разработчика, протестировать эти изменения и выпустить изменение в других средах.
Цель состоит в том, чтобы ваш код в dev, production был готов
