Обновить

Полезные советы от разработчика OpenSearch Даниила Дубровкина из AWS.

Вы смотрели The IT Crowd? Это уморительный британский телевизионный ситком примерно 2006 года, в котором группа ИТ‑гениев работала в отделе технической поддержки Reynholm Industries в Лондоне. Один из характерных смешных моментов заключается в том, что каждый раз, когда звонил телефон, Рой брал трубку и, не дожидаясь ответа, спрашивал: «Вы его выключили и снова включили?», а затем вешал трубку. Я часто чувствую себя Роем, когда общаюсь с пользователями, сообщающими об ошибках в проектах с открытым исходным кодом, которые я поддерживаю.

Вот мой структурированный подход к любым ошибкам (багам, проблемам), о которых сообщают в моих проектах с открытым исходным кодом:

  1. Не исправляйте ошибку. Поскольку это проект с открытым исходным кодом, и мы не продаём программное обеспечение, у сопровождающих может быть некоторая социальная ответственность, но они не обязаны что‑либо делать.

  2. Не пытайтесь воспроизвести ошибку. Не уверены, что это ошибка? Не можете воспроизвести проблему? Вежливо запросите дополнительную информацию или разъяснения.

  3. Не пытайтесь написать тест, который докажет, что это ошибка. Попросите человека, сообщившего о проблеме, попытаться написать автоматизированный и провальный тест. Это поможет сузить круг проблем и гарантировать, что ошибка останется исправленной в будущем.

  4. Не исправляйте ошибку. Теперь, когда человек, сообщивший об ошибке, написал для неё автоматизированный тест, он так близок к её исправлению. Попросите его сделать это. Это дает человеку, сообщившему об ошибке, чувство причастности и вклада в проект.

  5. Не делайте ничего другого. Не можете получить никакого участия в устранении ошибки от человека, сообщившего о ней? Оставьте ошибку открытой. Кто‑то другой её подхватит.

tl;dr Не исправляйте ошибку! У здорового проекта с открытым исходным кодом будет много вовлечённых участников, особенно когда дело касается ошибок. Это один из самых простых плодов, которые вы можете собрать как сопровождающий. Тем не менее, иногда я просто хочу исправить ошибку сам, потому что это так интересно.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Скорость разработки кода перестала быть дефицитом. Дефицитом стали денежные идеи

Тридцать-сорок лет IT-менеджмент оптимизировал утилизацию дорогих человеко-часов, где чем больше кода писал разработчик, тем лучше компания оценивала свою эффективность. ИИ сделал написание кода дешевым — и выяснилось, что узкое место давно не в разработке, а в идеях, которые стоит реализовывать.

С появлением ИИ у бизнеса появилась возможность собирать MVP, фичи и рефакторинги за недели, а не за кварталы. И оказалось, что подавляющая часть этих MVP - никому не нужна. И это вызвало вопрос: "А действительно ли бутылочное горлышко было в разработке?". Ведь очевидно, если мы генерим MVP достаточно быстро, но эти MVP не находят востребованность, то проблема в нем, а не скорости разработки.

Скорость разработки кода перестала быть дефицитом. Дефицитом стали денежные идеи

Публикации