Ясное дело, что баг нужно исправить и обновить программу или сайт. Но помимо этого желательно еще и сделать для себя какие-то выводы, понять почему произошел косяк и понять, как можно сделать так, чтобы подобный косяк не произошел в будущем. По этому поводу я видел несколько заметок и статей о том, как нужно писать отчет об инциденте. Но главное в таких отчетах сделать вывод именно для себя.
На ошибках учиться и на программных ошибках учиться просто необходимо, особенно на ошибках безопасности. Если игнорировать это, то ошибки будут постоянно повторяться.
У нас на работе при возникновении ошибок постоянно анализируются причины и не для того, чтобы наказать виновного, а для того, чтобы понять причину, осознать и не совершать подобные ошибки в будущем. Хотя иногда бывают случаи, что хотят и наказать, правда пока ни разу наказаний не было, по крайней мере в команде, в которой я работаю.
В других командах и отделах были наказания, например, среди менеджеров проектов я знаю один случай, когда одного менеджера уволили. Среди программистов последнее увольнение кажется было чуть более 3-х лет назад, когда уволили рускоговорящего программиста за постоянные задержки и не выполнения заданий, а не за ошибки в коде. Но это было до меня, и меня, кстати, взяли на его место.
Новые программисты постоянно совершают ошибки, а ошибки во время обучения - вполне нормальная ситуация.
Почему я решил написать этот пост? Просто увидел заметку о том, что в случае ошибки нужно правильно составить отчет об инциденте. Отчет отчетом, но главное понять проблему. Если красиво писать отчеты каждый день о том, как произошла ошибка, которая привела к SQL Injection, то значит отчеты просто не работают. А если без всяких отчетов после первой ошибки осознать, что есть реальная угроза, и больше не давать никаких поводов для уязвимостей, то и отчеты не нужны.
Отчеты же действительно могут помогать в осознании проблем и если вам проще, то их можно писать. Просто когда пишите их, нужно понимать их реальную цель - не отмазаться от совершенной ошибки, а предотвратить подобные случаи в будущем. Мы люди, нам свойственно ошибаться. Если кто-то считает, что не совершал в своей жизни ошибок и пишет только совершенный код, то какого черта вы читаете этот пост?
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
А у нас именно для того что бы наказать виноватого.
Что у вас там за проект такой? Какой-нибудь интернет магазин?
Что делать если найден баг в коде? Исправлять его. Какие еще отчеты об инциденте? Вы о чем вообще? Есть багтрекинговые системы, в которых заводятся эти ошибки. Насчет новых программистов - ошибок они делают не намного больше чем программисты не новые. Это я к тому что ошибки все делают и делают их много и если тратить время на анализ причин возникновения этих ошибок то вы проект никогда не закончите. Вы об agile слышали что-нибудь? Судя по вашим постам вы работаете в какой-то мелкой компании без каких-либо процессов разработки и т.д.
Отлично! Сообщение настоящего программиста)))))
> уволили рускоговорящего программиста за постоянные задержки и не выполнения заданий
плохой прецедент)))
хм, я в Канаде не был, а как-будто про меня))
Кстати, про наказания. Если пропускали в большинстве, Тарасов отправлял всю пятерку в запас. Но это уже хоккей. Кстати, канадцы остались без медалей, мы вырвали у них бронзу в овертайме. Я сказал "Флёнову привет")))
Михаил, сколько время дают программистам для задания?
Ну в основном достаточно времени дают. Бывают иногда задержки и косяки, всякое в жизни бывает.
Михаил, какие методологии разработки вы используете? Если какие-нибудь свои то опишите, если не трудно, как это все происходит.
У нас простая методология - в среду игры, в пятницу пиво. В остальные дни по настроению.
Вы конечно не пропустите этот комментарий, но чего вы хотели с таким подходом?
p.s. Может спрашивал уже. Почему вы не пишите технических комментов?
Никогда нет и я считаю, что не может быть готового сценария решения проблемы для творческой компании, которая работает над творческими проектами. Решение и подход к решению проблемы зависит от самой проблемы. А решать приходиться совершенно разные вещи. Да даже если было бы однообразно, не бывает такого, что взял учебник и только по нему все и делаешь. Так что использовать приходится все, причем не только по очереди, но и в смесях. Поэтому я и написал, что по средам играем, по воскресеньям пьем пиво с намеком на то, что в разные дни бывает по разному. Можно сказать, что у нас Agile.
У нас к ошибкам очень серьёзно относятся. Не в плане наказаний - ошибки действительно случаются, а в плане реакции на ошибки. Если возникла ошибка (тем более если это нашёл заказчик), то это значит, что такой то и такой то сценарий не был тестирован. Для каждой ошибки после исправления создаётся сценарий теста, который служит для того, что бы эта ошибка больше никогда не всплывала. Это может быть JUnit или intergation тест, а может быть selenium тест. Или просто "нажмите туда, введите то, увидите это", потому-что в отделе тестирования сидит куча студентов, которые такие сценарии весь день "прокликивают". Это конечно хорошо, но всё равно все случаи нельзя предусмотреть. И всё тестами не охватиш - уже сейчас полным процесс сборки только одной версии программы (с всеми автоматическими тестами) длится 8 часов.
Но у меня работа непосредственно связана с ошибками - я работаю в maintenance (хз как правильно перевести на русский, потому что "тех поддержка" не совсем подходит) отделе. Когда новая версия разработана другим отделом и используется клиентом, то эта версия переходит к нам и мы устраняем ошибки, вносим изменения, которые заказывает клиент и т.д.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
