Ваш комментарий не похож на начало конструктивного диалога, но тем не менее, я попытаюсь ответить, поскольку максимально серьезно отношусь к этой проблеме.
Первое, что хотелось бы сказать, что это не специфика работы компании CDEK. Например в 2022–2023 годах в России зафиксировано более 400 случаев yтечек из многих компаний, в том числе и банковского сектора, который, казалось бы, не должен вообще допускать такого. Во‑вторых, я считаю, что систему характеризует не факт ошибки, а реакция на неё. Мы проанализировали и свой кейс и проблемы наших коллег по индустрии, сделали соответствующие выводы и приняли соответствующие решения. Сейчас мы ежедневно работаем, в том числе над тем, чтобы максимально снизить вероятность таких событий в будущем.
Абсолютно согласен, что идеальный вариант, когда стандарты приняты до реализации бизнес‑процесса или хотя бы начала разработки. Но такое редко случается. Обычно выработка единого подхода происходит, когда уже накоплено определенное количество ошибок и явных проблем с текущими решениями (ну то есть когда уже всем очевидно, что что‑то идёт не так). И поэтому стандарты приходится внедрять в уже существующие процессы. А это всегда больно.
Понятно, что к формулировке стандарта нужно подходить очень аккуратно, чтобы не навредить. Не нужно подходить к стандартизации с точки зрения «у вас тут не красиво/не правильно», обязательно нужно взвешивать плюсы и минусы принимаемых решений и четко понимать их необходимость, решаемые задачи и отрицательный эффект (который нужно постараться минимизировать). Стандарты должны быть спроектированы так, чтобы быть удобными тем, кто их использует (включая клиентов, пользователей системы, менеджеров и технических специалистов). Это сделать не просто, но, в принципе, возможно. Для этого важно собрать качественную обратную связь от всех заинтересованных.
Я придерживаюсь такого подхода: выявление проблемы, поиск вариантов её решения (такого, чтобы постараться учесть все накопленные ошибки), обсуждение с заинтересованными лицами (с теми, на кого стандарт повлияет), а затем внедрение (вот это самое сложное и я полностью понимаю боли, которые вы озвучили во втором абзаце, про интернационализацию телефонии). Причем, если нет общего стандарта для индустрии (например ISO), то я стараюсь выбрать лучший вариант из существующих в компании решений (желательно, наиболее эффективный, но в крайнем случае подойдет и общеиспользуемый) и разрабатывать требования на его основе.
Ну а что касается нелюбви к стандартам, то здесь, на мой взгляд, корень проблемы только в том, что неудобно это обычно тем, на кого неожиданно сваливается дополнительная работа. И это, по моему опыту, хорошо решается озвучиванием проблем, которые имеются, задач, которые решаются с помощью стандарта и перечисление плюсов, которые мы получим в итоге. А нелюбовь уходит, как только начинают использоваться очевидные, однозначные подходы, основанные на выверенных и понятных стандартах.
Опубликовать эту статью в открытом доступе вряд ли возможно.
Однако я сейчас, в том числе, работаю над тем, чтобы унифицировать подходы к работе с датой и временем в приложениях на Java, PHP и Python в компании (т.е. именно в контексте использования в логике сервисов, а не только обмена данными).
Уже сейчас понятно, что задача не тривиальная. Например, в PHP, кроме типа DateTimeImmutable, представляющего собой аналог ZonedDateTime в Java, отсутствуют типы локальных даты и времени, что усложняет расчеты. В Python, хотя и существуют типы date, time и datetime, но из-за необязательности указания таймзоны, работа с ними также иногда приводит к ошибкам.
Вообще, я заметил, что любая неоднозначность в трактовке, почти гарантированно приводит к ошибкам. Вот один из примеров, когда стандартное представление даты и времени со смещением все равно ведет к двусмысленности: 2024-03-21T19:56:30+05:00. Казалось бы, что может пойти не так? Но один из разработчиков воспринял дату и время слева от плюса как будто они указаны в нулевом смещении UTC (т.е. что смещение +5 часов нужно прибавить дополнительно), а другой, что дата и время уже указаны в смещении +5 часов (а это верный вариант).
Поэтому я мог бы написать статью на Хабре, о том, как вести расчеты с датой и временем (на всех трёх языках программирования), как хранить такие данные в БД PostgreSQL и MySQL и некоторых NoSQL базах данных: ElasticSearch, MongoDB. Ну и, конечно, привести примеры распространенных ошибок, которые совершают разработчики.
Деловые линии требуют документ удостоверяющий личность.
Во всех случаях необходим – документ, удостоверяющий личность непосредственно получающего груз лица.
Ваш комментарий не похож на начало конструктивного диалога, но тем не менее, я попытаюсь ответить, поскольку максимально серьезно отношусь к этой проблеме.
Первое, что хотелось бы сказать, что это не специфика работы компании CDEK. Например в 2022–2023 годах в России зафиксировано более 400 случаев yтечек из многих компаний, в том числе и банковского сектора, который, казалось бы, не должен вообще допускать такого. Во‑вторых, я считаю, что систему характеризует не факт ошибки, а реакция на неё. Мы проанализировали и свой кейс и проблемы наших коллег по индустрии, сделали соответствующие выводы и приняли соответствующие решения. Сейчас мы ежедневно работаем, в том числе над тем, чтобы максимально снизить вероятность таких событий в будущем.
Абсолютно согласен, что идеальный вариант, когда стандарты приняты до реализации бизнес‑процесса или хотя бы начала разработки. Но такое редко случается. Обычно выработка единого подхода происходит, когда уже накоплено определенное количество ошибок и явных проблем с текущими решениями (ну то есть когда уже всем очевидно, что что‑то идёт не так). И поэтому стандарты приходится внедрять в уже существующие процессы. А это всегда больно.
Понятно, что к формулировке стандарта нужно подходить очень аккуратно, чтобы не навредить. Не нужно подходить к стандартизации с точки зрения «у вас тут не красиво/не правильно», обязательно нужно взвешивать плюсы и минусы принимаемых решений и четко понимать их необходимость, решаемые задачи и отрицательный эффект (который нужно постараться минимизировать). Стандарты должны быть спроектированы так, чтобы быть удобными тем, кто их использует (включая клиентов, пользователей системы, менеджеров и технических специалистов). Это сделать не просто, но, в принципе, возможно. Для этого важно собрать качественную обратную связь от всех заинтересованных.
Я придерживаюсь такого подхода: выявление проблемы, поиск вариантов её решения (такого, чтобы постараться учесть все накопленные ошибки), обсуждение с заинтересованными лицами (с теми, на кого стандарт повлияет), а затем внедрение (вот это самое сложное и я полностью понимаю боли, которые вы озвучили во втором абзаце, про интернационализацию телефонии). Причем, если нет общего стандарта для индустрии (например ISO), то я стараюсь выбрать лучший вариант из существующих в компании решений (желательно, наиболее эффективный, но в крайнем случае подойдет и общеиспользуемый) и разрабатывать требования на его основе.
Ну а что касается нелюбви к стандартам, то здесь, на мой взгляд, корень проблемы только в том, что неудобно это обычно тем, на кого неожиданно сваливается дополнительная работа. И это, по моему опыту, хорошо решается озвучиванием проблем, которые имеются, задач, которые решаются с помощью стандарта и перечисление плюсов, которые мы получим в итоге. А нелюбовь уходит, как только начинают использоваться очевидные, однозначные подходы, основанные на выверенных и понятных стандартах.
Опубликовать эту статью в открытом доступе вряд ли возможно.
Однако я сейчас, в том числе, работаю над тем, чтобы унифицировать подходы к работе с датой и временем в приложениях на Java, PHP и Python в компании (т.е. именно в контексте использования в логике сервисов, а не только обмена данными).
Уже сейчас понятно, что задача не тривиальная. Например, в PHP, кроме типа DateTimeImmutable, представляющего собой аналог ZonedDateTime в Java, отсутствуют типы локальных даты и времени, что усложняет расчеты. В Python, хотя и существуют типы date, time и datetime, но из-за необязательности указания таймзоны, работа с ними также иногда приводит к ошибкам.
Вообще, я заметил, что любая неоднозначность в трактовке, почти гарантированно приводит к ошибкам. Вот один из примеров, когда стандартное представление даты и времени со смещением все равно ведет к двусмысленности:
2024-03-21T19:56:30+05:00. Казалось бы, что может пойти не так? Но один из разработчиков воспринял дату и время слева от плюса как будто они указаны в нулевом смещении UTC (т.е. что смещение +5 часов нужно прибавить дополнительно), а другой, что дата и время уже указаны в смещении +5 часов (а это верный вариант).Поэтому я мог бы написать статью на Хабре, о том, как вести расчеты с датой и временем (на всех трёх языках программирования), как хранить такие данные в БД PostgreSQL и MySQL и некоторых NoSQL базах данных: ElasticSearch, MongoDB. Ну и, конечно, привести примеры распространенных ошибок, которые совершают разработчики.
Как вам идея?