Почти 3 года работаю в сфере и постоянно преследует ощущение, что я жутко невнимательный. Понимая, насколько это важная черта для разработчика, становится в разы неприятнее. Доходит до того, что я думаю заняться другим родом деятельности дабы не портить клиентам жизнь своими косяками. По иронии, работаю в большой финансовой компании и уже несколько релизов (чуть ли не подряд) на продакшн сервере всплывают какие-то косяки. Уже год я - единственный бэкенд разработчик в команде с тех пор как ушел тимлид и ему до сих пор не сумели найти замену. Таким образом, ревью проводят коллеги из других команд, но в силу специфики работы, они не могут проверить задачи досконально, соответственно, какие-то косяки проходят ревью и, более того, обнаруживаются слишком поздно. Не знаю сталкивался ли кто-то еще с такой ситуацией, но очень хотелось бы услышать мнение коллег по цеху, желательно старших разработчиков, которые могут дать оценку происходящему. Что касается тестирования, могу сказать, что не всегда можно все протестировать, да и без тестирования мне постоянно кажется, что этих ошибок я мог бы избежать, если бы был более внимательным/больше думал о задачах.
Edit: отвечая на вопрос по стеку технологий: Spring + Kafka + Oracle
Я не эксперт в этом вопросе, но советую почитать или прослушать аудио книгу "Почему я отвлекаюсь. Как распознать синдром дефицита внимания у взрослых и детей и что с ним делать"
vanilla_thunder, не верим, это полный бред. Один бек не может поддерживать сервис крупной компании, даже если это супер-сеньер. Там беков десятки-сотни.
Я проверяю свои решения, просто забываю о каком-то случае или просто его не учитываю, он не всплывает в моей голове.
Конкретно чек-листами я не пользуюсь (возможно, стоит попробовать), но мне кажется, что какой-то случай в этом чек-листе может просто не оказаться.
vanilla_thunder,
1. Обязательно попробуйте, и честно проверяйте каждый пункт.
2. Если какого-то пункта не хватило при релизе - добавляйте его в чеклист и в следующий раз проверяйте.
Так ревью это же не тестирование. Нужен тестировщик, в идеале сумеющий все покрыть автоматизационными тестами.
Также нужна информация о том, что за стек используется на бэке. Допустим, если это JS, то не помешало бы постепенно внедрять туда TypeScript. Также независимо от языка можно внедрить практики из контрактного программирования
ну так разработчик же тоже должен тестами покрывать)
Почитайте какие-нибудь основы по тест-дизайну, и применяйте их, чтобы тестировщик не занимался обезьяньей работой
Василий Банников, вот когда разработчик и жнец, и швет, вероятность появления багов повышается. Лучше конечно иметь отдельного человека, который будет сконцентрирован только на том, что ожидается в результате, а не как это работает внутри
Виталий Столяров, не факт.
1. Если разработчик никак не тестирует код, то при переводе в тестирование возникает перекидывание задачи с тестировщика на разработчика и обратно - это тратит много времени обоих.
При этом могут не работать даже самые основные сценарии
2. Только разработчик знает, какие есть подводные камни в его коде, так что он может гораздо быстрее сделать полное покрытие.
3. Хорошее покрытие автотестами = минимальная регрессия.
Тестировщик, в идеале, должен тестировать только бизнес-логику - то, как требования превратились в код.
Тестировщик не должен проверять какие-то примитивные кейсы типа "а что если я передам в эту функцию точно невалидное значение?"
Говорю я это на своём опыте, когда в проекте не было тестировщиков вообще, но благодаря большому количеству автотестов (на самом деле не очень большому - тестов было наверно только около половины от всего кода) - мы смогли спокойно провести несколько глобальных рефакторингов без регресса.
Василий Банников, речь идет о СВОЕМ коде, а не всей система, поэтому есть вероятность, что при изменениях в одной части системы может вылезть проблема в другой ее части
Только разработчик знает, какие есть подводные камни в его коде
При чем здесь подводные камни, если с точки зрения бизнеса важны определенные тест кейсы, а не покрытие кода?
Верно то, что в идеале нужно тестировать бизнес логику, а не писать тесты ради тестов, из-за чего сами тесты в какой-то мере будут повторять функционал
Если бы все люди были бы такими мнительными перфикционистами - мир бы давно бы развалился от отсутствия людей с инструментом в руке.
У вас профессия не связанная с большим риском, так как программирование и баги, это взаимосвязанные вещи. Вы же не нейрохирург который забывает инструменты в черепной коробке пациента.
PS: когда вы один бэкэнд разработчик в компании, самый актуальный способ работы - сделать плохо и что бы работало, а потом уже рефакторить и улучшать.
У меня цена бага может исчисляться миллионами. Многие разрабатывает софт для больниц, и там речь уже не об одной смерти, а о десятках за раз - нейрохирургам и не снилось.
mkone112, Аналогичная ситуация, но вы не берете в счет то - что в компаниях, где цена бага исчисляется миллионами, и нет отдельного тестировщика или команды = это не компания, а рассадник стресса. И я такую компанию даже бы не выбирал.
Так что тут с автором всё хорошо, просто ему с рабочим местом не повезло. Попал в то место, где на из пони сделали мустанга.
approximate solution, тестировщик есть. Я разве как-то дал понять, что его нет? Тестирование проходит, но не все кейсы можно проверить. К примеру, вряд ли тестировщик проверит все максимальные и минимальные длины полей, которые полезут в базу.
vanilla_thunder, Вы слишком суровы к себе, не знаю какой у вас стаж разработки, но советую послушать https://www.youtube.com/watch?v=TLn1aXXnyKo
А именно 11:20 - где рассказывают почему нельзя считать баги, и как правильно к ним относится.
Покрытие кода тестами. Да, трудозатратно, зато дает массу плюсов, в том числе, избавляет от неожиданных касяков. Тем более, что сфера деятельности достаточно серьезна.
Я пишу тесты, но опять же, его можно написать не на каждый кейс и тесты пишутся обычно на хэппи-кейсы, если проверять каждый кейс, то на разработку времени не останется
С первого раза и без багов только "hello world" получается))) Все, что сложнее, приходится тестировать и отлаживать. Это нормально, все так делают. Только делать это нужно до выката на прод))
А если на прод пролазят критичные баги, то явно имеется пробел в тестировании кода. Тут надо разбираться в конкретной ситуации, что с этим делать. Но, в любом случае, покрыть код тестами никогда не повредит.
vanilla_thunder, учитывая, что ты один и уже проскакивали серьёзные баги на прод, то очевидно надо сказать руководству, что необходимо заняться покрытием хотя бы 100% кода юнит тестами, что уже крайне сильно снизит шанс возникновения даже небольших проблем.
Иметь абсолютную внимательность, чтобы за всем уследить, невозможно, для этого тесты и придумали. Если все тесты пройдены, значит код не содержит известных более-менее серьёзных ошибок, а если ты не делаешь тесты на уже случившиеся ошибки, то это уже твои проблемы.
Если невнимательность - (мягко скажем)особенность работы мозга, то тут уж ничего не попишешь. Нейроны не восстанавливаются (по крайней мере, так считает официальная наука). Следует ИМХО перейти на должность, где ответственность за косяки меньше
Когнитивный ресурс мозга конечен. Оперативная память ограничена и способна удерживать одновременно 7+-2 объекта. Если задач много и приходится постоянно переключаться, то все нормально, так и должно быть.
Отдельный вопрос - что со всем этим делать?
Если сроки всегда жмут, да и QA, насколько я понял из описания, то ли недорабатывают, то ли их вообще нет, соответственно процессы не поставили - это очень большая проблема, но не разработчиков, а менеджмента. Скорее всего они не в теме.
Как выше подсказывают коллеги, в нормальных командах процесс QA поставлен как следует и вылавливает львиную долю косяков на этапе тестирования. Ну и да, покрывай код тестами, это, хоть как-то, поможет облегчить ситуацию.
Возвращаясь к когнитивному ресурсу - надо нормально спать и убрать лищние углеводы из рациона, добавить
физнагрузки и вечерний моцион перед сном. Так же надо перестать стрессировать из-за проблем, которые не в твоей компетенции и власти. Толку все равно нет, а ценный и весьма ограниченный ресурс расходуется. На адреналине и кортизоле много годного кода не напишешь.
Возможно у тебя вообще вальяжный темперамент, а тебя все время пытаются ускорять и подгонять. Вообще я бы задумался о смене места работы.
Я не эксперт в этом вопросе, но советую почитать или прослушать аудио книгу "Почему я отвлекаюсь. Как распознать синдром дефицита внимания у взрослых и детей и что с ним делать" 2019 года.
Авторы: Эдвард Хэлловэлл, Джон Рэйти
Во-первых - с вопросом автора он не связан никак, во-вторых - нужно начать с книги где приводились бы доказательства существания или опровержение существования сдвг.
Это слово применимо только в случаях общепризнанного мнения, а вот сдвг - самый спорный неврологический диагноз, и какого-то единого мнения нет. Будут доказательства существования - тогда и поговорим.
kolossradosskiy, воз не единственная крупная организаци, воз неоднократно признает, а потом снова не признает различные заболевания. Сдвг никак не подтверждается лабораторно, критерии оценки каждый выдумывает как хочет.
Это вам не гомеопатия с арбидолом.
В отличии от сдвг - имеют доказанную неэффективность.
Ps. топик-стартеру лень составить чек-лист - вы считаете что это из-за сдвг?
Любой навык развивается регулярной практикой. Кроме того, с вашей стороны стоит рефакторить код в направлении стабильности и писать больше модульных тестов, со стороны QA стоит увеличивать количество автотестов и тоже разрабатывать внимательность во время регресса, а руководству стоит понять, что у них в проекте 100% басфактор. Не знаю какой подход к управлению проектом используется в вашей команде, но вероятно стоит добавить периодическую активность с разбором - почему ошибка возникла, почему её не выявили, что можно сделать, чтобы такого не происходило больше и т.п. Наконец, совсем без багов ни у кого не бывает. Вопрос только в том, насколько они частые и серьёзные.
Почему бы не писать юнит тесты? (да, уйдет чуть больше времени, однако и качество кода улучшится)
Также, попробуйте открыть ваш код и прочитать его (как книгу) - если не получается, то качество кода нужно улучшать (задел на саморазвитие).
А так, лучше запросите у руководства компании тестировщика, чтобы он перед релизами мог баги почекать. Вы человек, а не робот. Всё люди могут ошибаться.
Простой
Простой
Простой
