Тут могу сказать, что при работе не с продуктом, а в web-студии, часто для выполнения задач на проект привлекаются разработчики малознакомые с проектом. Когда проект отягощен большим количеством недокументированного легаси, то подробная документация позволяет быстро провести онбординг на проект и подсказать разработчику, ПОЧЕМУ на этом проекте принято именно такое решение.
Ну а в целом, разработка движется к агентно-ориентированному подходу. И агентам, а не разработчикам, нужна подробная документация как раз для уменьшения контекста, чтобы на стадии постановки задачи ограничить контекст.
И я полностью с вами согласен, что для разработчика код является документацией, но только если этот код можно читать и легко в нем разбираться. Однако реальность нам говорит, что когда проект проходит за несколько лет через несколько команд, там ничего не остается от того замечательного SOLID GRASP KISS DRY и всех остальных аббревиатур которыми нас учат ГУРУ разработки
Поживем-увидим, надеюсь, наша все-таки продолжит процветать) Назначить ответственного хранителя иногда действительно кажется здравой мыслью, но пока обходимся...
Всем спасибо за уточнения про неточности в коде и нюансы тестирования. Пример в статье действительно несколько надуманный и приводился в исследовательских целях. Но тем не менее, основан на реальных событиях. Был опыт работы с проектом, где предыдущие разрабы настроили выгрузку по крону таким образом, что сервер падал как раз по упомянутым причинам.
Ну а задача статьи была больше в том, чтобы показать неопытным программистам полезность yield для использования в конкретной ситуации, а не рассмотреть тему генераторов целиком и полностью. Опять же исходя из опыта, не все начинающие разработчики битрикс в курсе возможного решения проблемы с памятью на большой выгрузке.
Тут могу сказать, что при работе не с продуктом, а в web-студии, часто для выполнения задач на проект привлекаются разработчики малознакомые с проектом. Когда проект отягощен большим количеством недокументированного легаси, то подробная документация позволяет быстро провести онбординг на проект и подсказать разработчику, ПОЧЕМУ на этом проекте принято именно такое решение.
Ну а в целом, разработка движется к агентно-ориентированному подходу. И агентам, а не разработчикам, нужна подробная документация как раз для уменьшения контекста, чтобы на стадии постановки задачи ограничить контекст.
И я полностью с вами согласен, что для разработчика код является документацией, но только если этот код можно читать и легко в нем разбираться. Однако реальность нам говорит, что когда проект проходит за несколько лет через несколько команд, там ничего не остается от того замечательного SOLID GRASP KISS DRY и всех остальных аббревиатур которыми нас учат ГУРУ разработки
Поживем-увидим, надеюсь, наша все-таки продолжит процветать) Назначить ответственного хранителя иногда действительно кажется здравой мыслью, но пока обходимся...
Всем спасибо за уточнения про неточности в коде и нюансы тестирования. Пример в статье действительно несколько надуманный и приводился в исследовательских целях. Но тем не менее, основан на реальных событиях. Был опыт работы с проектом, где предыдущие разрабы настроили выгрузку по крону таким образом, что сервер падал как раз по упомянутым причинам.
Ну а задача статьи была больше в том, чтобы показать неопытным программистам полезность yield для использования в конкретной ситуации, а не рассмотреть тему генераторов целиком и полностью. Опять же исходя из опыта, не все начинающие разработчики битрикс в курсе возможного решения проблемы с памятью на большой выгрузке.