alt-text ci git mvp Мысли вслух тестирование alt-text

Дайджест лофта #11

Mykola Sarry

• 2 min read

В этом выпуске дайджеста:

Статья о том как программисты иногда помогают создавать суррогатные продукты и как программисту избежать создания суррогата.

У программистов разного уровня часто возникают вопросы о том, как работать с ветками в Git, когда их заводить и как мержить между собой. Порой мне попадались очень «оригинальные» и неоправданно усложненные схемы работы с гитом. В то время как в сообществе программистов уже сформировалась схема работы с гитом и ветками в нем. В этой статье  краткий обзор основных моментов при работе с Git, и описать «классическую» схему работы с ветками.

Перевод статьи программиста из Чикаго, который решил сменить работу.

Тестирование — это проверка работоспособности программы, предмета или любой промышленной разработки. Как и в любом деле, здесь есть свои тонкости и своя философия. Она, наверное, ближе тестировщикам, которые на произведенные нами вещи смотрят деструктивно — они с самого начала думают о том, как сломать предложенный разработчиками продукт. Это не очень типично для пользователей, которые более предсказуемы и обычно находят ошибки, случайно пытаясь сделать с нашей программой что-то нетипичное. У разработчиков подход к программам в принципе другой, но мы должны помнить: тестировщики должны ломать то, что мы создали — это их хлеб.

MVP (minimum viable product — минимально жизнеспособный продукт) – это продукт, который разрабатывается с максимальной экономией денег и ресурсов, как правило, с единственной целью – проверки гипотезы. Гипотеза, как правило, заключается в необходимости и/или полезности этого продукта. MVP ни в коем случае не означает “черновой вариант”, сделанный в спешке, который после завершения выбросят и будут писать с нуля. Если вы убеждены в обратном, то вам точно стоит остановиться, пересмотреть приоритеты разработки и прочитать эту статью. Стоит уменьшать функционал продукта, но ни в коем случае не пытаться сделать все и сразу, в безумной спешке, упуская важные части функционала и оставляя за собой вереницу багов. Нужно точно определить, какой функционал является основным, а какой не используется в большей части случаев.