Вот прям апокалипсис какой-то 😁 Не осталось ни одного человека, который что-то понимает в этом коде, трэкер задач снесли, посмотреть некуда... репо хоть оставили? Или его изначально не было, код меняли руками прямо на продакшн сервере? И всю эту радость нужно теперь раскапывать в одно лицо? Но при этом есть подробное ТЗ, на которое комменты могли бы ссылаться, и штат аналитиков, которым можно задавать вопросы? Честно говоря, ситуация выглядит высосанной из пальца. А если такое и возможно, я бы просто не подписался на такую работу - можно и получше места найти.
Если вся разработка нарезана на задачи-кусочки по нескольку параграфов
Она и должна быть так нарезана - независимо от наличия или отсутствия глобального ТЗ.
Вот только через достаточное количество лет группа поддержки этого продукта будет необычайно тормозить и ругаться, собирая по крупицам знание 'а чего делать-то хотели и почему?'.
Если тикеты пишутся в стиле "сделай мне хорошо" - то несомненно. А если включают в себя описание проблемы и её контекста (как и должно быть) - то все всё поймут.
Ссылаемся тот кусок того документа(учитываем, что документ -- понятие растяжимое), на основании данный кусок кода написан.
Так это как раз тикет и есть. Я о том, что ссылка на тикет фактически абсолютно универсальна - ибо при правильной организации работы изменения кода должны делаться только на основании тикета. Который уже, в свою очередь, может ссылаться и на пункты ТЗ - буде таковое в принципе существует.
Так и проверяется - читается комментарий "Поиск подходящей заявки в соответствии с ТЗ номер, правила параграфа..."
А что, если ТЗ отсутствует, как класс - что сплошь и рядом встречается в эджайл разработке? У меня, например, так и есть, ТЗ - это тикет на реализацию конкретной фичи и ссылаться больше не на что.
Кроме того, код может попросту фиксить некий баг, влияющий на сразу на множество описанного в ТЗ функционала. Например, критические данные читаются со слэйва, который может время от времени лагать, искажая самые разные результаты. На какой пункт ТЗ ссылаться?
Неплохой обзор для начинающих. Довольно много опечаток (null-awear, etc.), но сильно придираться не буду. Только вот это реально смешно:
я являюсь Cross-Platform Developer и использую фреймворк Flutter уже больше 20 лет
Orly? 😁
Ну и много лишнего понамешано, честно говоря - если статья про дарт/флаттер, то при чём тут http, git, SOLID, design patterns... Такое ощущение, что автор решил вывалить вообще всё, чему успел научиться за свои 4 года в программировании (из коих 20 на флаттере, ага 😁) - тем самым проигнорировав буковку S из SOLID.
Самая важная фича языка - отсутствие типизации, толерантность к ошибкам в данных (сделать из числа строку или массив и работать с этим дальше - легко!) и простота языка позволяют писать то, что на других языках превращается в огромную портянку кода.
Мой самый крупный проект (за миллион строк кода, юзерская база 30М+) таки РНР - лютое легаси, писать начинали 15 лет назад, когда о строгой типизации в РНР никто и не слышал ещё. Если (когда) будем переписывать - несомненно, со строгой типизацией, ибо это автоматически предъявляет к программисту требование понимания, что у него на входе, что на выходе и как это правильно обрабатывать. А то иногда получается вот такая вот красота:
Да, написание занимает больше времени. Но вероятность ошибки и стоимость поддержки уменьшаются значительно - оно того стоит.
После перехода на Flutter RN вспоминается, как страшный сон. Должен признать, тому были и субъективные причины: RN аппу получили в наследство, с очень низким качеством кода - ни одного теста, простыни по 1500 строк кода в файле, куча ошибок в логах, процент крэша сессий до 30 (!!!). Около года боролись, пытаясь привести в чувство, но не слишком преуспели. То есть стало сильно лучше, но даже 5% крэшей - слишком много, ну и постоянные проблемы со сборкой утомили. Может, конечно, мы так и не научились его готовить, но каждый билд превращался в квест с неясным исходом - особенно, если сопровождался апдейтом библиотек или, не к ночи будь помянут, самого RN.
Плюнули, переписали на Flutter. Тоже около года заняло, но это просто другой мир - особенно после добавления null safety. Сейчас у нас 16 приложений на одной кодовой базе, никаких проблем со сборкой (CI/CD в полный рост), ноль крэшей, три платформы (Android, iOS, web) с минимумом платформ-специфик кода. Отсутствие OTA updates тоже сильно не напрягает: благодаря CI/CD и правильно организованномому процессу деплоя релизы, как правило, раз в неделю. Если надо, можем и чаще, но грубые ошибки обычно вылавливаются при тестировании, а для исправления мелких недельного цикла достаточно. Программисты счастливы, юзеры тоже 😁
Наше тестирование проставляет приоритеты. А бот проставляет важность :) Плюс не всегда тестировщик, или какой-либо другой участник команды, может знать все о значимости для бизнеса или пользователя
Простите, а как такое может быть? Приоритет зависит от важности для бизнеса и более ни от чего. Если тестировщик её оценить не в состоянии, как он(а) может проставить приоритет? Да и вообще: если не может, то это плохой тестировщик. То, что проверяемо независимо от важности для бизнеса, должно покрываться автотестами, а QA нужны именно для проверок соответствия бизнес требованиям и экспертной оценки юзабилити.
Конечно, люди ошибаются - но в норме любой тикет, прежде чем уйти в работу, проходит через тимлида, и мониторится ПМ - кто-то да поправит приоритет.
Вот прям апокалипсис какой-то 😁 Не осталось ни одного человека, который что-то понимает в этом коде, трэкер задач снесли, посмотреть некуда... репо хоть оставили? Или его изначально не было, код меняли руками прямо на продакшн сервере? И всю эту радость нужно теперь раскапывать в одно лицо? Но при этом есть подробное ТЗ, на которое комменты могли бы ссылаться, и штат аналитиков, которым можно задавать вопросы? Честно говоря, ситуация выглядит высосанной из пальца. А если такое и возможно, я бы просто не подписался на такую работу - можно и получше места найти.
Она и должна быть так нарезана - независимо от наличия или отсутствия глобального ТЗ.
Если тикеты пишутся в стиле "сделай мне хорошо" - то несомненно. А если включают в себя описание проблемы и её контекста (как и должно быть) - то все всё поймут.
Так это как раз тикет и есть. Я о том, что ссылка на тикет фактически абсолютно универсальна - ибо при правильной организации работы изменения кода должны делаться только на основании тикета. Который уже, в свою очередь, может ссылаться и на пункты ТЗ - буде таковое в принципе существует.
А что, если ТЗ отсутствует, как класс - что сплошь и рядом встречается в эджайл разработке? У меня, например, так и есть, ТЗ - это тикет на реализацию конкретной фичи и ссылаться больше не на что.
Кроме того, код может попросту фиксить некий баг, влияющий на сразу на множество описанного в ТЗ функционала. Например, критические данные читаются со слэйва, который может время от времени лагать, искажая самые разные результаты. На какой пункт ТЗ ссылаться?
Неплохой обзор для начинающих. Довольно много опечаток (null-awear, etc.), но сильно придираться не буду. Только вот это реально смешно:
Orly? 😁
Ну и много лишнего понамешано, честно говоря - если статья про дарт/флаттер, то при чём тут http, git, SOLID, design patterns... Такое ощущение, что автор решил вывалить вообще всё, чему успел научиться за свои 4 года в программировании (из коих 20 на флаттере, ага 😁) - тем самым проигнорировав буковку S из SOLID.
Хабр
Мой самый крупный проект (за миллион строк кода, юзерская база 30М+) таки РНР - лютое легаси, писать начинали 15 лет назад, когда о строгой типизации в РНР никто и не слышал ещё. Если (когда) будем переписывать - несомненно, со строгой типизацией, ибо это автоматически предъявляет к программисту требование понимания, что у него на входе, что на выходе и как это правильно обрабатывать. А то иногда получается вот такая вот красота:
Да, написание занимает больше времени. Но вероятность ошибки и стоимость поддержки уменьшаются значительно - оно того стоит.
После перехода на Flutter RN вспоминается, как страшный сон. Должен признать, тому были и субъективные причины: RN аппу получили в наследство, с очень низким качеством кода - ни одного теста, простыни по 1500 строк кода в файле, куча ошибок в логах, процент крэша сессий до 30 (!!!). Около года боролись, пытаясь привести в чувство, но не слишком преуспели. То есть стало сильно лучше, но даже 5% крэшей - слишком много, ну и постоянные проблемы со сборкой утомили. Может, конечно, мы так и не научились его готовить, но каждый билд превращался в квест с неясным исходом - особенно, если сопровождался апдейтом библиотек или, не к ночи будь помянут, самого RN.
Плюнули, переписали на Flutter. Тоже около года заняло, но это просто другой мир - особенно после добавления null safety. Сейчас у нас 16 приложений на одной кодовой базе, никаких проблем со сборкой (CI/CD в полный рост), ноль крэшей, три платформы (Android, iOS, web) с минимумом платформ-специфик кода. Отсутствие OTA updates тоже сильно не напрягает: благодаря CI/CD и правильно организованномому процессу деплоя релизы, как правило, раз в неделю. Если надо, можем и чаще, но грубые ошибки обычно вылавливаются при тестировании, а для исправления мелких недельного цикла достаточно. Программисты счастливы, юзеры тоже 😁
Простите, а как такое может быть? Приоритет зависит от важности для бизнеса и более ни от чего. Если тестировщик её оценить не в состоянии, как он(а) может проставить приоритет? Да и вообще: если не может, то это плохой тестировщик. То, что проверяемо независимо от важности для бизнеса, должно покрываться автотестами, а QA нужны именно для проверок соответствия бизнес требованиям и экспертной оценки юзабилити.
Конечно, люди ошибаются - но в норме любой тикет, прежде чем уйти в работу, проходит через тимлида, и мониторится ПМ - кто-то да поправит приоритет.