Если это хотя бы средний по размеру продукт, то в штате уже как минимум 20-30 человек.
ну допустим 150. в штате разработки.
Если это продукт чуть больший, чем средний, у него куча зависимостей, то уже не существует одного человека, который бы знал всю систему, даже если он в проекте уже давно.
значит в каждой команде должен быть такой человек.
Если это statefull продукт, то у него может быть база, и ошибка, которые вызывает изменения прямо на проде, может привести крупным проблемам, которые не так легко откатить назад.
Особенно если база большая, а операций много. Там даже банальное восстановление из бэкапа может занять часы, при этом надо еще разобраться можно ли откатываться с потерей текущих операций и как это правильно все сделать и вообще сразу снежный ком.
Да, конечно. При исправлении проблемы такое странно будет не учитывать.
По моему опыту — бизнес не должен доверять разрабам на слово.
Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.
И если риск проблем на продакшене стоит денег/репутацию, все изменения должны проходить через тестовый енвайрнмент и как минимум «четыре глаза».
Ну, с этим никто и не спорит.
Вопрос в хотфиксах и исправлении критических ошибок. И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)
На самом деле это не нужно, если все изменения на прод выкатываются после тестирования. Риск, что выйдет что-то с ошибкой — в таких случаях стремится к нулю, а значит что на выходных релиз выкатывает релиз инженер, а все остальные — максимум on-call, на случай нестандартной ситуации.
Так разговор как раз о нештатных ситуациях и падениях в бою и необходимости срочного исправления.
Это как раз в случае прямого исправления чего-либо на продакшене, нужен целый штат на всякий случай, чтобы оперативно понять что и как чинить и восстанавливать.
т.е. что бы исправить что то на проде этот штат не нужен, а что бы исправить то что кто то исправил на проде — нужен?
Судя по постам — нет, не можем. *в прочем, как и по многим конференциям, где люди честно верят, что будущее за опенсорсом, пет-проектами и сменой стека каждые пол года.
Это вполне нормально, учитывая какие слои программистского сообщества склонны к социализации, нуждаются в сообществе и участвуют в сообществе. В частности, разработчики баз данных в этом участвуют очень слабо, у них намного меньше «пэт-проектов» и опенсорса и многим другим причинам. =)
Более того, даже такие сервисы как стаковерфлоу будут давать искажённые данные, просто потому что есть области, где вопросов или полезных хаков меньше и они вполне стабильны и не требуют регулярных правок.
Но для пользователей хабра, безусловно, статистика по пользователям хабра более релевантна… но, к сожалению, это заставляет пользователей хабра верить, что это и есть все программисты.
Если вы понимаете о чём я.
ЗЫ: вечером загляну в калькулятор ) мне кажется я в него уже заглядывал, но пару лет назад.
Разработчик баз данных.
В общем то, помониторив мой круг на предмет вакансий могу сказать, что у вас, по ощущениям, есть заметная деформация в плане того, какая часть разработки к вам попадает в вакансии и соискателей, так что ничего удивительного. =)
Правда, это моё личное наблюдение и я не знаю, как бы вы могли это проверить, кроме как сравнив свою статистику с другими похожими проектами. Ничем таким не занимались? )
Спрос. В среднем, нужнее тысячи клепателей сайтиков и приложушек чем нормальный разработчик каких то менее массовых решений. =)
Тут нет ничего несправедливого.
Моей специализации тут вообще нет ))
Мне кажется он спрашивал о немного другом (не о списке столбцов, а о поиске ближайшего/всех значений в подзапросе в EXISTS).
Для MS SQL Server разницы не будет, потому что он для EXISTS и так ищет только первую строку, после чего прекращает поиск.
Это легко проверить посмотрев планы запроса для вариантов
… WHERE EXISTS (SELECT TOP 1 1 FROM ...)
… WHERE EXISTS (SELECT 1 FROM ...)
… WHERE EXISTS (SELECT * FROM ...)
Ну, тут зависит от компетентности того, кто исправляет. =)
Если бизнес верит, что перед внесением неисправимых изменений разработчик не озаботится бэкапом или возможностью отката, не отложит проблему как невозможную в разрезе его ответственности или не призовёт кого то для дублирования своих выкладок и вообще — не очень ответственный и адекватный человек… Ну что ж, тогда стоит пересмотреть кандидата на дежурство или риски и процесс внесения хотфиксов на бой )
Только в случае если ошибка того же класса, что и была (которая прошла все тесты и задеплоилась) можно потерять и две недели в случае повтора.
А так — тоже мгновение на вмешательство в прод.
Тут не вопрос «может или не может», «ошибётся / не ошибётся», а вопрос издержек.
На одной чаше весов:
— Риск что человек, который хорошо понимает систему и сам же её разрабатывал сделает что то непоправимое и сломает вообще всё.
На другой:
— Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
— Простой системы (чем она больше — тем она больше стоит) в течении прохождения задачи полного цикла выпуска или вообще — пока на работу не выйдут ответственные работники.
Вопрос лишь в величине рисков и издержек. По моему опыту — бизнес достаточно доверяет компетентности своих разрабов (или конкретных людей, к примеру тимлидам), что бы считать риск первого достаточно небольшим что бы избежать реальных и постоянных издержек второго варианта.
Если издержки на второй вариант не велики, а доверие к профессионализму сотрудников не очень велико — то решение будет иным и это будет тоже правильно. =)
Может. А может и не привести.
Риски и издержки каждый оценивает по-своему.
Для кого то риски повторной ошибки при фиксе (и так же оперативно исправленной) куда ниже чем издержки от недельного выкатывания фикса в бой и простоя всей системы в течении этого времени. (который может пройти все тесты, как и предыдущая версия).
значит в каждой команде должен быть такой человек.
Да, конечно. При исправлении проблемы такое странно будет не учитывать.
Если бизнес не доверяет разработчикам, то я даже не знаю… отдавать сторонним специалистам проверять и ревьюить код? =)
Конечно бизнес должен доверять программистам. Но это не значит, что программисты не должны прикрывать свои пятые точки и защищать бизнес.
Ну, с этим никто и не спорит.
Вопрос в хотфиксах и исправлении критических ошибок. И тут стоит уже выбор: тратить время и средства на содержание итп-итп-итп я это уже писал. =)
Так разговор как раз о нештатных ситуациях и падениях в бою и необходимости срочного исправления.
т.е. что бы исправить что то на проде этот штат не нужен, а что бы исправить то что кто то исправил на проде — нужен?
Через него — государству.
Через него — людям.
Фактически, деньги дают за нарушение закона или процедур, которые не просто так были придуманы. =)
Ну это если вкратце.
Это вполне нормально, учитывая какие слои программистского сообщества склонны к социализации, нуждаются в сообществе и участвуют в сообществе. В частности, разработчики баз данных в этом участвуют очень слабо, у них намного меньше «пэт-проектов» и опенсорса и многим другим причинам. =)
Более того, даже такие сервисы как стаковерфлоу будут давать искажённые данные, просто потому что есть области, где вопросов или полезных хаков меньше и они вполне стабильны и не требуют регулярных правок.
Но для пользователей хабра, безусловно, статистика по пользователям хабра более релевантна… но, к сожалению, это заставляет пользователей хабра верить, что это и есть все программисты.
Если вы понимаете о чём я.
ЗЫ: вечером загляну в калькулятор ) мне кажется я в него уже заглядывал, но пару лет назад.
В общем то, помониторив мой круг на предмет вакансий могу сказать, что у вас, по ощущениям, есть заметная деформация в плане того, какая часть разработки к вам попадает в вакансии и соискателей, так что ничего удивительного. =)
Правда, это моё личное наблюдение и я не знаю, как бы вы могли это проверить, кроме как сравнив свою статистику с другими похожими проектами. Ничем таким не занимались? )
Я про первую часть комментария )
Тут нет ничего несправедливого.
Моей специализации тут вообще нет ))
Для MS SQL Server разницы не будет, потому что он для EXISTS и так ищет только первую строку, после чего прекращает поиск.
Это легко проверить посмотрев планы запроса для вариантов
… WHERE EXISTS (SELECT TOP 1 1 FROM ...)
… WHERE EXISTS (SELECT 1 FROM ...)
… WHERE EXISTS (SELECT * FROM ...)
Если бизнес верит, что перед внесением неисправимых изменений разработчик не озаботится бэкапом или возможностью отката, не отложит проблему как невозможную в разрезе его ответственности или не призовёт кого то для дублирования своих выкладок и вообще — не очень ответственный и адекватный человек… Ну что ж, тогда стоит пересмотреть кандидата на дежурство или риски и процесс внесения хотфиксов на бой )
А так — тоже мгновение на вмешательство в прод.
Тут не вопрос «может или не может», «ошибётся / не ошибётся», а вопрос издержек.
На одной чаше весов:
— Риск что человек, который хорошо понимает систему и сам же её разрабатывал сделает что то непоправимое и сломает вообще всё.
На другой:
— Содержание целого штата дежурных (разраб, техлид, тестировщик, QA, девопс, сисадмин, кто там ещё), причём по ставке выходного дня.
— Простой системы (чем она больше — тем она больше стоит) в течении прохождения задачи полного цикла выпуска или вообще — пока на работу не выйдут ответственные работники.
Вопрос лишь в величине рисков и издержек. По моему опыту — бизнес достаточно доверяет компетентности своих разрабов (или конкретных людей, к примеру тимлидам), что бы считать риск первого достаточно небольшим что бы избежать реальных и постоянных издержек второго варианта.
Если издержки на второй вариант не велики, а доверие к профессионализму сотрудников не очень велико — то решение будет иным и это будет тоже правильно. =)
Риски и издержки каждый оценивает по-своему.
Для кого то риски повторной ошибки при фиксе (и так же оперативно исправленной) куда ниже чем издержки от недельного выкатывания фикса в бой и простоя всей системы в течении этого времени. (который может пройти все тесты, как и предыдущая версия).