3 неверных предположения, которые делают большинство разработчиков

Вот чего не следует предполагать при создании программного обеспечения

За неправильные убеждения. Они дорого стоят. Много времени, сил и денег.

Предполагая, что у вас хороший процесс ввода адреса. Что делать, если у вас возникли проблемы с вводом адреса?

4 из 10 покупателей бросают корзину из-за проблем с вводом адреса⁵.

Предполагая, что у вас простой процесс оформления заказа. Что делать, если у вас сложная касса?

11% бросивших корзину уходят, потому что процесс оформления заказа был слишком сложным.

Это верхушка айсберга. Существуют и другие неизвестные статистические данные. Все из-за неправильных предположений.

Вот 3 распространенных мифа о программной инженерии. Это поможет вам избежать ошибочных предположений. Я совершил ошибки, поверив этим мифам, поэтому подробно разбираюсь в них.

Каковы распространенные мифы об API?

Я буду ссылаться на этот пост в блоге³, чтобы узнать о большинстве мифов об API.

У каждого API будет хорошая подробная документация. Разработчики могут обратиться к документации для настройки клиентов API.

При работе с Angular этого никогда не было. Бесчисленные часы изучения документации, чтобы обнаружить, что функции не работают.

Я бы пошел в репо Angular, посмотрел исходный код и нашел недокументированные варианты. На них не было документации. Они работали как положено, но в документации о них никто не упоминал.

Документация всегда верна.

Взгляните на следующего разрушителя мифов. Создайте конечную точку REST API. Создайте документы. Измените API. Забудьте изменить документы.

Это вызывает много стресса и разрушения. Никогда не предполагайте, что документация верна или актуальна.

Вы знаете, как работает время?

Мы ошибаемся насчет времени. Вы можете принять это. Вот неправильные предположения о времени, которые делают разработчики.

Мое внимание привлек один миф. «Время идет только вперед».

Как время идет назад?

Да, это возможно. Отметьте этот ответ. Время должно идти вперед. Хотя на практике всякое бывает.

Часовые пояса. Високосные секунды.

Високосные секунды игнорируются по умолчанию. Как системы борются с этим поведением? Время замедляется. Остановка времени. Возвращаясь во времени, уменьшите время на одну секунду.

Все это заставляет время идти назад. Идите в случайном направлении. Идите в более медленном темпе.

Теперь мы подошли к ключевому выводу о времени. Никогда не делайте предположений относительно времени.

Работая с ценами, у нас много проблем со временем. Обработка истечения цен. Испытания с бомбами замедленного действия.

Мы полагаем, что в большинстве случаев нужно время. В одном дне ровно 86400 секунд, и мы основываем расчет на этой предпосылке. Мы делаем смелые расчеты, не задумываясь о времени.

Предполагая время - ломает софт. Не предполагайте. Ставьте под вопрос все.

Вы можете столкнуться с подобной проблемой, подобной этой. Модульный тест с постоянной времени для тестирования. По прошествии времени тест не проходит. Никогда не следует полагаться на постоянную времени в целях тестирования.

«Независимо от того, в какой области вы работаете, ваш код настолько же хорош, насколько хорошо вы понимаете реальный мир, но не лучше. А реальный мир сложен ». ²

Чтобы попасть в кроличью нору мифов о времени, иди сюда. Вы будете поражены тем, чего не знаете о времени.

Вы знаете, как работают адреса?

Что мы думаем об адресах? Вот список.

Мы создали индекс SOLR для адресов. Сейчас в индексе около 3 миллионов записей. Я думал адреса простые.

Большинство ошибок после этого тикета было связано с адресами. Я делал предположения - они вернулись, чтобы преследовать меня после.

У клиентов не будет сохранено более пяти адресов. Я предположил.

Зачем вам искать адресную книгу? Когда у клиентов будет больше адресов?

Электронная коммерция B2B. У организаций несколько десятков адресов.

Допустим, вы организация, заказывающая книги для одного из 10 своих офисов. У вас минимум 10 адресов.

Таким образом, мои предположения оказались ошибочными. Предположения по большинству адресов неверны. Подвергайте сомнению любую реализацию адреса. Не попадайся в мою ситуацию.

Проверка адресов также оказалась сложной. Люди искали адреса, но ничего не получали взамен.

Что искали? «Rd X», «Highway St.».

Значение St слишком широкое. Поиск X еще шире. Мы решили эту проблему с помощью нечеткого соответствия.

Мы можем отправлять нашу продукцию повсюду. Еще одно неверное предположение.

Два слова. Санкции. Эмбарго.

Да, вы можете отправить туда. Но заплатите штраф потом.

Amazon выплатит 134 000 долларов штрафа за нарушение санкционных требований США. - источник

У всех адресов есть имя и номер. Есть?

Я живу в деревне. Ни имени, ни номера улицы.

Есть еще четверо парней по имени Милош Живкович. Однажды этот старый Милош получил мой приз на одном соревновании. Он был хорошим парнем, поэтому отдал его мне.

Мой адрес не уникальный. У всех нас один адрес: деревня X, город Y, ЗИП, Сербия, Милош Живкович.

Это может вызвать множество проблем. Возвращенные посылки, если не верный получатель. Возврат, если заказчик не получил посылку.

Вывод

Не делайте предположений и не верьте в них. Не принимайте все как должное.

Используйте эти ошибочные предположения, чтобы сделать программное обеспечение лучше. Ставьте под вопрос все, что связано со временем. Тесты, код или конфигурация.

Оцените адресные задачи с небольшой долей непредвиденных обстоятельств. Никогда не знаешь, что может случиться с адресами.

Подумайте о неправильных предположениях при кодировании. Подумайте, прежде чем реализовывать. Перед внедрением нового валидатора адреса, ограничения по времени или интеграции нового API.