Вы не знаете, есть ли эта инфомрация в сети? Интересно было бы узнать, как в Яндексе это делают. Плохо себе представляю, как можно поддерживать столь сложные патчи.
Опытный разработчик сам знает, где он пойдет на компромисс, но это все-таки исключения, вроде уже подмеченного «упавшего продакшна». К сожалению, слишком много людей с которыми я работал «гибки» на 90%. Отсюда и категоричность.
Мне нравится одна фраза, которая описывает, как разные люди видят definition of done:
Я думаю, что «помыть посуду» — это включить воду и вымыть все, что есть в раковине. Моя жена думает, что «помыть посуду» — это убрать грязные тарелки со стола, протереть стол, помыть посуду, протереть, поставить в сушилку, ложки убрать шкафчик.
В разработке тоже самое. Я за то чтобы ломать меня делать работу полностью.
А можно более подробно, что из вышеописанного займет у вас 40-50 часов в сутки? Может быть вы пользуетесь инструментами, которые вам не подходят и работают слишком долго?
Вы же призываете писать тесты: habrahabr.ru/company/infopulse/blog/177581/ и пишите о том, как отстаивать сроки: habrahabr.ru/company/infopulse/blog/170777/. Я не понимаю, в чем наши позиции расходятся.
Речь идет о зафиксированном объеме работ. Вы правы, что любая задача может иметь «full-banana» и «limited» реализацию. Например, «необходимо отображать на сайте документы для скачивания». Можно начать городить API, забирать эти ссылки через API от источников этих документов, поддерживать авто-обновление и еще много чего, а можно просто собрать необходимый список, положить эти документы на сервер со статикой и дать ссылки. Для конечного пользователя результат одинаков.
Всегда существует объем технического долга. Вопрос в том, на сколько этот технических долг критичен. Недопустимо мириться с костылями в «ядре» системы и core-функционале. Я работал с несколькими проектами, в которых основная бизнес-логика была написана «на костылях». Такой подход приводит к чудовищному перерасходу средств и такому-же чудовищному качеству продукта в среднесрочной и долгосрочной перспективах. Я сталкивался и продолжаю сталкиваться с менеджерами, которые убеждают меня, что поменять какое-то бизнес-правило, лежащее в основе приложения, — дело пяти минут.
Функционал, который делается для ограниченного количества пользователей, не является основным, и, возможно, в будущем, вообще не понадобится — совершенно другая история. Такой функционал я всегда предлагаю реализовывать «limited»-вариантом.
Я оценивал автоматизацию сборки и выкладки «абстрактного проекта в вакууме». Для больших и сложных систем это конечно займет больше времени. Я настраивал CI с нуля на четырех проектах, поэтому у меня уже есть некоторый опыт, чтобы говорить о таких сроках. Если тема настройки CI интересна, я могу написать tutorial на эту тему.
На прошлой YAC был доклад от Google «Тестирование 2.0». Доклад ни о чем, зато слайды смешные.
Докладчик: «В чем корень всех зол и багов?».
Перелистывает слайд: «Fridays».
Перелистывает слайд «Friday 17:00»
Докладчик: «Серьезно, может вообще запретить комиты по пятницам? Как это происходит? Вы уже спишите к друзьям, девушке. Думаете о чем угодно, но не коде»
У нас база бекаптися просто мейнтененс-планом + бекапы инстансов амазона. Необходимости откатывать БД на демо-стенде не было, но в случае чего есть 2 варианта отката. Откат удобен в случае неудачного обновления дев/тест-окружения. На них актуальность данных не так важна, а вероятность накатить фигню существует. Существуют системы, в которых запись производится гораздо реже, чем раз в 10 секунд. Зависит от приложения.
Самодисциплина — да, религия — нет. Воздержание — вообще нет. Я писал не о процессе разработки, а о личной ответственности, мотивации разработчика и об уважении к другим членам команды. Какие чувства вы испытываете, если после апдейта из VCS проект не собирается или даже не стартует? А если коллега говорит, что исправил баг, вы заходите на главную страницу и видите там Exception?
Я не знаю ни одного человека, который сказал бы «наши корпоративные стандарты запрещают поднимать приложение». По крайней мере, я бы не стал работать с таким человеком. А вот примеров «хоп-хоп, ща сделаю» у меня целый вагон.
Поверьте, это у вас в голове. Не надо писать тесты на краткосрочных проектах. Это не рентабельно. Если ваше приложение будет работать достаточно долго, вы просто сами выроете себе могилу «сделай за час-два». Потом все-равно кому-то придется переписывать приложение с нуля, потому что ни один здравомыслящий подрядчик не возьмется разгребать такой код. Современный IT-рынок — рынок соискателя, а не работодателя. Вы в праве и должны организовывать эффективный процесс разработки.
Автоматизация: выкладок, бекапов, всего, что имеет смысл. Сначала кажется, что долго, а потом выясняется, что пара человеко-дней. Если над проектом работает пара десятков разработчиков, это экономит здесь час, там час, набегают дни и недели. Кроме этого, заваленные выкладки задерживают не только разработчика, но и тестировщиков и менеджеров.
Если сложить это время, выясняется, что как раз на хот-пачти и и уходит все время. Обычно, принято считать, что полезна работа — это новые фичи, а не багфиксы и хотпатчи.
Прерывания. Нет ничего хуже, чем когда «дергают». На то, чтобы вернуться обратно «в поток» тоже нужно время.
Вы тратие на один час больше своего времени в краткосрочной перспективе. В долгосрочной экономите человеко-дни другим сотрудникам и себе (вас не дергают).
Пока нет. Вы можете достаточно просто воссоздать этот пример с помощью copy+paste, alt+enter и nuget. Возможно, в будущем фреймворк уйдет в open source.
С параллелизмом есть еще веб-драйвер, который может «зависнуть». Как вариант делать через remote, но там тоже есть свои прелести.
Мы решили разбивать тесты на сборки «по-интересам»: есть одна сборка для смоуков, дальше по компонентам системы. Каждую сборку можно запустить параллельно. На предыдущем проекте не заморачивались с параллелизмом, на этом, возможно будем. Я подумаю об этом, когда тесты будут выполняться 6-8 часов.
С такой оценкой менеджеру будет гораздо проще управлять рисками.
Мне нравится одна фраза, которая описывает, как разные люди видят definition of done:
Я думаю, что «помыть посуду» — это включить воду и вымыть все, что есть в раковине. Моя жена думает, что «помыть посуду» — это убрать грязные тарелки со стола, протереть стол, помыть посуду, протереть, поставить в сушилку, ложки убрать шкафчик.
В разработке тоже самое. Я за то чтобы
ломать меняделать работу полностью.Вы же призываете писать тесты: habrahabr.ru/company/infopulse/blog/177581/ и пишите о том, как отстаивать сроки: habrahabr.ru/company/infopulse/blog/170777/. Я не понимаю, в чем наши позиции расходятся.
Всегда существует объем технического долга. Вопрос в том, на сколько этот технических долг критичен. Недопустимо мириться с костылями в «ядре» системы и core-функционале. Я работал с несколькими проектами, в которых основная бизнес-логика была написана «на костылях». Такой подход приводит к чудовищному перерасходу средств и такому-же чудовищному качеству продукта в среднесрочной и долгосрочной перспективах. Я сталкивался и продолжаю сталкиваться с менеджерами, которые убеждают меня, что поменять какое-то бизнес-правило, лежащее в основе приложения, — дело пяти минут.
Функционал, который делается для ограниченного количества пользователей, не является основным, и, возможно, в будущем, вообще не понадобится — совершенно другая история. Такой функционал я всегда предлагаю реализовывать «limited»-вариантом.
Докладчик: «В чем корень всех зол и багов?».
Перелистывает слайд: «Fridays».
Перелистывает слайд «Friday 17:00»
Докладчик: «Серьезно, может вообще запретить комиты по пятницам? Как это происходит? Вы уже спишите к друзьям, девушке. Думаете о чем угодно, но не коде»
Вы тратие на один час больше своего времени в краткосрочной перспективе. В долгосрочной экономите человеко-дни другим сотрудникам и себе (вас не дергают).
Мы решили разбивать тесты на сборки «по-интересам»: есть одна сборка для смоуков, дальше по компонентам системы. Каждую сборку можно запустить параллельно. На предыдущем проекте не заморачивались с параллелизмом, на этом, возможно будем. Я подумаю об этом, когда тесты будут выполняться 6-8 часов.