Собственно, сабж?
Работаю уже больше трех лет в компании где разработка ведется на продакшине, ну так исторически сложилось. Десктопное приложение на WPF + Oracle. Мозги уже начинают плавится). Время от времени ОЧЕНЬ хочется уволиться.
Кто то еще так работает? Как самочувствие? Сколько денег платят (если не секрет)?
Как-то лет 15 назад тогдашний мой начальник тихонько мне сказал «за это надо отрывать яйца». Придерживаюсь этого принципа.
Нигде с таким подходом не сталкивался.
А по поводу нервов: человек он такой, что со временем ко всему привыкает. Если первые изменения на базе делаются под аккомпанемент сердечной мышцы и с выступающим пОтом на ладонях, то со временем черствеешь и запускаешь все, особо не задумываясь о чувствах :).
угадай с одного раза, кого сделают крайним в случае чего.
угу. вот именно поэтому и много нервов надо.
это точно. надо почитать чего нибудь что любят спрашивать на собеседованиях и походить, может чего и получится найти .
точно получится.
конец года — лучшее время для поиска работы.
А на вопрос «почему решили поменять работу?»
так прямо как есть и отвечай, но мягко и лояльно, с уважением к текущей работе. Дескать, люблю её, но жить вместе мОчи нет уж.
А что это значит «сделают крайним» и как это в случае чего поможет компенсировать потерю клиента?
а что значит
компенсировать потерю клиента?
То есть никаких рисков в случае отказа нет? Тогда продукт лучше выбросить, а разработчиков отпустить, раз уж и сами хотят уволиться. :)
ответ зависит от того что вы подразумеваете под «случаем отказа». можете уточнить?
если имеется ввиду что какая та часть функционала будет недоступна несколько минут, или даже час, то в принципе ничего страшного не случится, люди позвонят, пообрывают провода, понервничают, и пойдут пить кофе.
но всегда есть риск угробить все более серьезно, и вот чтобы этого не случилось приходится нервничать.
и такой продукт выбросить не получится, потому как на него завязана вся работа компании начиная от закупки заканчивая продажей и включая так называемые «социальные сервисы» : буфет, столовую, стоматолога, курсы и общежитие.
и разработчиков то можно отпустить (меня в том числе), но мы ничего насчет такой схемы не решаем. а если «отпустить» того человека который решает насчет работы на продакшине , то все умрет . bus factor=1.
мы ничего насчет такой схемы не решаем. а если «отпустить» того человека который решает насчет работы на продакшине , то все умрет .Как правило, кто ничего не решает, тот не особо и отвечает, а здоровая доля пофигизма еще никому не вредила.
как это не странно звучит, я отвечаю за то что делаю.
в смысле чем ? у вас принято накосячить и не исправлять ? пусть делает кто-то другой?
Так исправлять это наша работа, даже если накосячил кто-то другой. При чем тут ответственность? У врачей есть страхование на случай медицинской ошибки. Но вот, например, список знаменитых багов: List of software bugs. При этом отсутствует список ответивших за них программистов, потому что так это не работает.
просто изначально неправльно поставлен вопрос. отвечают в данном случае не чем (деньгами, здоровьем, квартирой итд) , а за что. я отвечаю за свою работу. и если я где то накосячил, то постараюсь исправить это . а не буду ждать кого то кто это сделает. тем более если я это делал, я скорее всего немного более в курсе что там и как , и мне на исправление понадобится намного меньше времени чем человеку которому во все это надо вникнуть.
Может конкретно в этом случае неактуально, но для защиты задницы разработчиков существует лицензионное соглашение для пользователей. В котором обязательно нужно указать, что разработчик не несёт ответственности за прямые или косвенные убытки, понесённые использованием или неиспользованием продукта. Если заводят речь об возможных потерях клиента, то соответственно нужно обращаться или допиливать лицензионное соглашение.
Работаю в украинской компании, четкое разграничение тест-продакшн. Даже, если при инсталляции на продакшене, что-то не завелось и нужно чуть-чуть подправить. Все равно полный откат, снова тестирование и т.п.
если продукт для своей компании то какое приблизительно соотношение пользователей-разработчиков-тестировщиков?
У нас корпоративный продукт, поэтому тестирование функционала и интегрейшн тесты проходят на стороне заказчика. А так тестирует продукт соседний разработчик. Поэтому обычная схема 10-2-0.
А где и как вы тестируете фичи?
А цепочка dev->review->stage->uat->prod ни о чем не говорит ?
Вопрос к автору темы, а то что ты написал это скорее надо сделать отдельным комментом и предложением для автора а не подкомментов к моему вопросу. Ты разницу понимаешь?
Пардон, действительно не заметил.
круто так работать )
все на продакшине. делаем на продакшине. то что сделали сами проверяем на нем же. выкладывается новая версия, и радостные пользователи набрасываются на новый функционал.
Так работать нельзя, вам необходимо переходить на работу с демо серверами и прочими процедурами. Нельзя выкатывать на прод фичу которая толком не протестирована, да и вообще при такой работе у вас продукт будет не качественный, что в конечном итоги повлияет на решения пользователя оставаться на вашем ресурсе или выбрать, что то поинтереснее.
у нас продукт для себя, боле того не веб . как это ни дико звучит в наш век , но это десктопное приложение. гы.
А можно продакшн прямо из IDE запускать с подключенным отладчиком. Если возникает проблема, ставишь брейкпоинт, фиксишь код, edit-and-continue его подхватывает и дальше пошли.
У меня кстати была такая идея: на удалённом сервере развернуть IDE из-под него запускать программный сервер. Но это не поможет, поскольку ошибка может возникнуть в любое неподходящее время, например когда в баре сидишь. Кроме того, если много подключений, это не вариант сидеть трассировать в это время. Лучше запускать код из-под sandbox, и если что-то вылетает, писать в лог сообщение об ошибке, место вылета, и состояние стека вызовов, обычно этого достаточно.
один вопрос: зачем?
не хватает острых ощущений в жизни? )
крутая идея, если нет жестких требований по privacy реальных данных.
По сравнению с разработкой и тестированием прямо на боевой системе — это будет в любом случае шаг вперед.
Следующим шагом можно обезличивание как часть процедуры восстановления на test/dev ввести. Несколько замедлит перезаливку, но не критично.
Обычно менедмент жлобится именно на подходящее железо (как минимум сторадж) под эти системы, пока конкретно боком не вылезет.
Та не, неужели такое бывает?
ну это первая работа где у меня так. на большинстве предыдущих был доступ к боевой базе, но лезли тута в крайнем случае быстро чего то пофиксить.
Работал как-то на проекте, где делали «правки на продакшене для клиентов». Т.к. проект был большой, то потом были траблы, так как UAT/CI отличался от лайва постоянно, не говоря уже про локальные версии разработчиков и часто такие фиксы терялись при деплойментах, а они были каждую неделю)
А потом наступает неловкий момент, когда баг, который был пофикшен пол года назад — возвращается)
В своё время, когда работал в банках я любил писать отчёты сразу на проде. На живых данных сразу видно косяки, а положить БД селектами — это тоже надо уметь :) Так что ни каких проблем девелопить сразу на проде у меня не было :)
ps: большие функциональные ченжи я не делал
на больших базах — положить базу селектами — не фиг делать)
Особенно если они с блокировкой
Ну тут как бы подразумевается оракл, а там неблокирующий селект, я не думаю, что кто-то в здравом уме делает select for update для выборки данных больше одной-двух строк на больших таблицах.
так ось чому смс про оплату від ПриватБанку інколи тільки через годину приходить :)
на большой базе селектами устроить проблемы — это как два пальца обосцать
Только сейчас заметил, что это написал «Senior Database Developer». Ой все!
понятное дело, что в prime time никто ничего тяжелого не запускал.
А в случае, когда от тебя требуют отчет на позавчера, а у тебя еще толком к нему нет требований — то девелопмент экономит кучу времени :)
PS: дай дураку хер стеклянный — так он и руки порежет и хер разобьет ;)
Давай доступ только с селектами — положим)
Кто то еще так работает? Как самочувствие? Сколько денег платят (если не секрет)?1) уяк-уяк в продашкшен.
1 — да
2- нет. стабильно
3 — нет . отдают все и всегда.
4 — привязка к твердой валюте
5 — нет. иногда возникает сильное желание уволится. но пока плюсы перевешивают )
ну у меня уже было, все предыдущие ответы наоборот. в продакшин через несколько баз с тестировщиками (комапания обслуживала один бооольшой банк), а все остальное было не очень , скажем так. забрал первую зп и сказал им прощайте.
У меня аналогично по всем пунктам было до недавнего времени. Желание уволиться, по собственным наблюдениям, лечится отдыхом на природе и в ночных клубах.
в ночной клуб меня жена не пустит )
для веб разработок фиксить баги лучше на боевом, потом переносим на дев и комитим
разрабатывать только на деве, за разработку на продакшене надо бить канделябром
для веб разработок фиксить баги лучше на боевомв смысле, «дебажить», надеюсь?
да, я имел ввиду что на деве нет тех и того кол-ва данных что на боевом, и что на деве баг можно и не увидеть
Дебажить на продакшене?
Клиент усирается, если продакшен 20 секунд лежит, а Вы тут такое говорите
ну бывают ситуации когда на деве работает а на продакеше нет
ні
Это, конечно, экстремальный случай, но если у вас получится в таком режиме работать достаточно стабильно — вы сможете пережить что угодно.
в таком режиме компания работает со дня основания, уже лет десять наверное, )
А кто-то у вас уже херил базу или какую-то важную схему по ошибке или там по злому умыслу? И вот интересно, если база падает с копыт по вине разработчика, то как вы ее поднимаете и кто?)
при мне нет. когда говорят было. бэкап наше все.
Так для восстановления тоже время нужно. А если какой-то нехороший человек сделал ошибку, которая обнаруживается спустя неделю, скажем? И надо откатиться на то время, когда еще не было этой ошибки?
тогда пишутся по ходу дела скрипты которые исправляют данные. есть много разных журанлов с историей откуда можно почти все вытащить.
Крутая у вас стратегия восстановления, прямо скажем)
ну это не востановление. а поправить данные после багов. но такое бывет редко.
Похоже, Вы не совсем понимаете, о чем я говорил. Но это и к лучшему. Зачем думать о самых худших сценариях, правда? Трава зеленая небо голубое, зарплата платится более-менее вовремя и в полном объеме, что еще надо, чтобы чувствовать удовлетворение от работы?)
небо серое, травы почти нет , листья мало и желтое все. если бы зп не платилось вовремя и в полном объеме меня бы тут не было через две недели. а парадом здесь командую не я, пока в силу разных причин менять работу не выгодно, но стало интересно сколько еще компаний так работают.
Как-то лет 15 назад тогдашний мой начальник тихонько мне сказал «за это надо отрывать яйца». Придерживаюсь этого принципа.
да, но тестовую базу сделать не реально, точнее все реально, но надо много времени и людей. я уже смирился, взяли еще одного нового человека, у него такие же мысли появились сразу, но тоже принял действительность такой как есть.
тестовую базу сделать не реально, точнее все реально, но надо много времени и людей
Чисто технический вопрос: это из-за Оракла или по другим причинам?
Тестовую базу обычно можно сделать, подняв бэкап на левом (резервном) сервере. Заодно проверяется сам бэкап и процедура восстановления. Если на это надо много времени и людей, то вас ждут сюрпризы когда основной сервер решит навернуться.
база несколько терабайт просто. и чтобы вытянуть какой то связный кусок данных в тестовую очень много мороки .
Именно всю базу, не связный кусок. Это обычно проще, плюс это отработка процедуры.
Ситуация с размером понятная, но ничего принципиально не меняет.
Т.е. скажем если нет сервера, на который эти ТБ можно развернуть, его точно так же не будет в случае реальной аварии. Или если это долго и сложно, восстановление после аварии будет долгим и сложным.
Можно с этой позиции с руководством поговорить.
Слова про бэкапы и резервирование обычно доходят хорошо.
в случае реально аварии мы один раз три дня гуляли. сервер по сравнению с остальным стоит копейки , но никто так и не чешется. точнее приняли меры чтобы больше такого не повторилось и все дела.
я думаю вам будет интересно почитать про репликации
я думаю не интересно. кроме этого сервера в другом офисе есть еще один. данные между ними хотят по репликации, но он не большой , там часть данных только.
лол не все ок- вы похоже норм вписываетесь в этот дурдом, продолжайте :)
что вызвало лол в предыдущем сообщении не соизволите поделится?
а что вы делаете если на основной машине вылетает дисковый массив? курите пока вчерашние бекапы на новом массиве восстановятся? Когда последний раз проверяли что после этого все будет работать?
лично я буду смотреть в окно , и на картинки в интернете если такое случится. моя работа писать буквы на sql и c# . тот кто отвечает за базу и будет с эти разбираться. но там рейд и чтобы так повезло надо много времени.
ps/ так что вызвало лол в предыдущем сообщении не соизволите поделится?
???
бгггг молодцы че
нет
у меня к продакшенам доступа сейчас нет и слава богу
боюсь если мы так будем разрабатывать кризис 2008 года будет повторяться по три раза в день
на самом деле плюсы для бизнеса в этом есть. пользователи получают свои хотелки очень быстро. и если делать все аккуратно, и конечно думать что делаешь, то не так и страшно.
Спаси нас от лукавого.
кто платит то и заказывает музыку.
Ну вот придете вы к врачу. Он вам скажет там пить вот такие вот таблетки и побыть там на определеной диете. Но вы ему такой — а фиг там, клиника частная, я плачу деньги и за свои деньги хочу не таблетки с диетой а просто молитву мне прочтите! Я же деньги плачу! Я и музыку заказываю. Если врач за это возьмет деньги то он врач или шарлатан?
так то оно так, но не совсем. есть правила игры. и либо вы в эту игру играете (работаете в этой компании) или не играете (работаете в другом месте). можете попробовать договариваться играть по другим правилам, но это другая история. уже где в комментариях писал об этом.
Ну я бы лично играл бы в другом месте т.к. очевидно что в этом я как профессионал не нужен.
Лучше с умным потерять, чем с дураком найти
как писали одни товарищи, которые нам совсем не товарищи — каждому свое.
Вообще это настолько bad practice, что и обсуждать нечего. Хотя в условиях Украины и не такое бывает. Видел как у аутсорсеров был доступ к продакшн базам банков(украинских). Вот то уже чад кутежа и дичайший угар во мгле ада.
эти плюсы забудутся в первые 5 минут аварии обсуловленной тем что у кого то дрогнула рука и дропнулась БД. Или просто важная табличка. Ага.
а я и не говорю что это хорошо. меня больше интересует много ли компаний так работают, как себя чувствуют разработчики? и дают ли им молоко за вредность?
но дропнуть базу или табличку это постараться надо.
Та запросто. Соединился с БД, заморочили голову, забыл что присоединён к БД на боевом сервере, дропнул.
у нас одна бд. поэтому забыть об этом как то странно )
Фигня вопрос! Махнулся в скрипте. Или во времени запуска скрипта. Или еще чего.
Best Practices (кот-е правильно переводятся как «стандарты») они ж не на пустом месте возникли. А на останках уволенных программеров/админов/ПМов и прочая и прочая.
Даже если у вас внутренний проект для одной конторы, любой аудит этой конторы на предмет ее надежности при виде таких вот ковбойских методов придет в ужас.
насчет ужаса что есть то есть.
я даже не знаю до какой степени нужно чем то долбиться что бы предложить такое... ну или на сколько дешево стоит простой бизнеса если такие практики используються
за 15 лет не видел не разу
если кто такое предложит в финансовом секторе его наверно скрутят и вызовут дурку
я за свою жизнь тоже не видел ни разу. это первое место. правда встречал людей которое работали в большой банке которая в 2008 стараниями вкладчиков было быстро похоронена, что там тоже на продакшине делали. сам работал чуть больше года в небольшом банке, был доступ до продакшина, но делали все на своем сервере. а так первые дни были незабываемые ощущения когда пишешь commit )
для меня как разработчика такая работа — плохо,
для компании наверное нет. очень много хотелок появляется в течении дня. я думаю что компании за 10 лет удалось подняться из подвальной конторы с 10 человечками до больше тысячи сотрудников, не в последнюю очередь и из-за такой системы.
ну как бы есть шанс из конторы с тыщей человек вообще в ноль скукожиться с таким то подходом
ну я могу сказать что о таком подходе я тут впервые услышал если честно....
шанс всегда есть,значит быстрее найду другую более адекватную работу) а про такой подход впервые услышал лет 5 назад (там чуть выше писал про банк). сам был тогда в шоке. а потом здесь. вот тебе комп, вот студия и pl sql developer , только тута это... мы пишем на продакшине .... мда ... вот так вот
Ну а у вас, конечно, разработчики того недостижимого уровня, когда код пишется без ошибок, на тесты время тратить не стоит и т.д.
А пробовали составить статистику, сколько времени потратили на факапы и их починку, просто посмотреть и перевести время в деньги ?
ну когда я только пришел , то на мой первый вопрос как же так можно то . сказали что это управляемый риск, и время потраченное на оперативное исправление ошибок ничто в сравнении с временем разработки на тестовой базе и переносе изменений на продакшин. как то так.
у Джоела Спольски есть такая статья «Пять миров разработки ПО».
на самом деле, как мне кажется, их чуть больше, но в качестве модели — вполне подойдет.
1) «коробочное». оно же — продуктовая разработка. здесь разработка сразу в продакшн, во-первых, — не получится ибо есть цикл разработки с прохождением QA, во-вторых, — самоубийство. если версия 1.0 будет глюкаловом, то на версию 1.1 бабла никто не даст.
2) «гейм-дев». тоже не получится, ибо оно хоть и похоже на «коробочное», но является одноразовой разработкой, версии 1.1 с багофиксом никогда не будет.
3) «корпоративное ПО» или, если угодно, внутренняя 1С. здесь сразу всё идет в продакшн, тестируем прямо на юзерах. и вообще в данном виде разработки экономически выгоднее — костыльный метод. повторяю, он не лучше, он ВЫГОДНЕЕ.
4) «ERP». то же самое, что и «корпоративное», с той лишь разницей, что копий ПО — несколько по количеству клиентов. на первом клиенте, кому понадобился такой функционал, мы тестируем (точнее на его юзерах), потом — рефакторим, а потом уже чистенькую и красивую по коду версию с настройками и опциями отправляем остальным.
5) «вэб-дев». у вэба есть самый главное отличие от других видов разработки: копий п.о. и версия — одна, та что на сервере. и тут уже всё на совести разработчика. некоторые держат тестовый сервер с копией сайта, некоторые — нет.
и вообще: пусть лучше присутствующие вэб-девы расскажут, как они делают и как надо делать. я не буду судить, я не отсюда.
судя по описанным топик стартером технологиям, он работает в разработке ПО вида или «корпоративное», или «ERP». для этих видов разработки тестирование прямо в продакшене — это нормально.
«гейм-дев». тоже не получится, ибо оно хоть и похоже на «коробочное», но является одноразовой разработкой, версии 1.1 с багофиксом никогда не будетОчень часто работают по другой схеме: клиент при запуске сначала проверяет и качает обновления с сервера, потом запускается. Реализации могут отличаться, но суть такая. Разработчики пишут какой-то функионал, что-то фиксят, заливают билд на сервер, приступают к новым задачам. Если деньги получают не с продажи копии, а постепенно взымаются за счёт внутриигровых покупок или пополнений, то скорее всего именно по такой схеме и разрабатывается. Бывает иногда, что выносят мозг если в новом билде внезапно возникают баги, которых раньше не было.
Вобщем, как лечатся проблемы: нужно хранить на сервере 3 версии последних рабочих билдов. Если вдруг в свежем находят пропущенный критический косяк, то просто откатывается на предыдущий рабочий билд, дальше в спокойной обстанвке решается суть проблемы.
так то оно так .... но это клиент-серверное приложение. и откат клиента на версию назад может ничего не дать , поскольку ошибка на сервере. или же что-то перестанет работать вообще.
Сервер ещё проще откатывать назад. Делаются папки Server1, Server2, Server3 с последними рабочими билдами, которые циклически заливаются по очереди. Если в последнем, допустим в папке Server2 — баг в логике, сервер вырубается, и тут же запускается из Server1. Если меняется структура БД, то старая сначала копируется под другим именем. Чтобы сервер не падал из-за багов в логике, эту логику лучше всего писать на каком-нибудь скрипте под виртуальную машину, и исполнять в коротинах в sandbox. Ещё не помешает сделать такой костыль, который запускается в отдельном процессе, периодически пингует сервер, раз в 15 сек, и если ответ не приходит, то снимает старый процесс сервера, запускает новый.
кроме скриптов зачастую меняется и то как и где хранятся данные. и время затраченое на испраление ошибки будет намного меньше чем скрипт которых будет тасовать данные по таблицам
да, у нас третий вариант. все надо прям здесь и сейчас. но время от времени выматывает. надо следить чтобы при изменениях на сервере текущие версии клиента работали корректно, ничего не угробить, так как тестовых данных на которых можно безболезненно тренироваться в 90% процентах нет.
Я работал с подобной темой. Вобщем, клиент лучше всего писать нормально, без проверок на версию протокола. При этом клиент передаёт в начале на сервер свою версию. На стороне сервера реализуются разные ветки логики, в зависимости от версии клиента. Когда старые версии клиента обновляются, на сервере удаляются соответствующие ветки логики.
он че про UAT не слышал?
и?.... можете развить свою мысль дальше ? мне не понятно совершенно при чем здесь UAT ?
потому что между дев и продакшн обычно есть uat, и у некоторых даже не один а два
потому что у нас нет dev и нет test . потому что топик называется "
А вы разрабатываете на продакшине?". так при чем здесь UAT ?
я про Спольски и его классификацию. в ентерпрайзе и веб UAT обычно всегда есть
про гейм дев не уверен :-))) там нередко продукты с такими багами выпускают, с которыми в ентерпрайзе сразу бы всех уволили
аааа, ну тогда мысли понятна )
Десктопное приложение на WPЧто такое продакшин в вашем случае?
продакшин — это база данных оракла с которой работают пользователи и где хранятся реальные данные, утеря или повреждение которых чреваты последствиями )
Спасибо, как говорится, порвало)
Кстати, хуяк хуяк и в продакшн — выражение, запрещенное доукомнадзором, через пару часов мое сообщение запиликают звездочками, будьте острожны.
в маленьких фирмах часто бывает доступ к проду и можно колупать там, прямо чтобы постоянно это печалька
«самочуствие, очень ххочется уволиться, мозги плавятся» — это все полная фигня, не нравится работать в той фирме — поменяй, надоел проект — поменяй, все остальное ты додумал сам — страдай, если так хочется;
раз можно косячить прямо в прод, то значит так и задумано, переживать не стоит, вообще переживать никогда не стоит, если ты в свой психике порядок навести не можешь, то куда тебе работать? только холодный расчет, эмоции в работе программиста неуместны
как там у классика?.... — не говорите мне что мне делать, и я не скажу куда вам надо идти )
только это изречение не от классика, а от гопничка какого-то
из песни слов не выкинешь.
Я заметил что у нас любят цитировать людей, которых не знают. К примеру на хабре в качестве аргумента вести грязно бизнес, цитировали такое: «Это просто бизнес, ничего личного». При том еще и подчеркивали, что вон, это западная поговорка. А по факту это фраза американского бандита Аль Капоне. Ну это я уже так, отошел от темы.
не надо мне приписывать чужих заслуг.
Вадим вроде дельный совет дал: не нравится — меняйте, слабо менять — терпите. Никто за вас решение не сделает.
за свою недолгую жись, я уже поменял с десяток работ. и могу сказать что здесь не самое плохое место, и когда менять я могу решить сам. топик был о совсем другом. о том много ли работает так же, как самочувствие в плане нервов, и дают ли молоко за вредность. (если судить по статисте джина , то мне не дают).
а чего ты нервничаешь? тебе придется оплатить потери, если что-то пойдет не так?
плохо себя чувствую когда из -за моих ошибок другие люди не могут делать свою работу. а писать без ошибок еще не научился ) . и когда меняешь что то в процедуре с которой в этот момент работают люди, то ситуации бывают разные.
Иди к психологу, он научит)
Твои нервы — это твои нервы. Твой выбор- только твой выбор... и т.д. А у других по всякому. Можно, конеш, сесть в кружок и устроить групповую терапию... но вне методики оно не работает, вырождается в «нытье на дружеские уши» от которого облегчение лишь временное, а далее — бег по кругу.
Ну и, в догонку, написал напублику — терпи внимание публики, «другой публики для тебя у нас нет» )) Или расставайся с иллюзиями.
иллюзиями чего ? )
это у себя сами смотрите. А у меня «свой бой».)
а ты не научишься без ошибок, такого не бывает, людям этим на самом деле пофигу и тебе должно быть пофигу и только тогда ты сможешь и лучше работать, и лучше себя чувствовать
людям не пофиг, у них зп от выработки.
мда... действительно неприятно
мда, похоже на правду.
Работал в такой компании, очень медленно и мучительно от этой практики уходили. Похоже, наладка стейджинга + контроль версий + ревью кода обходятся всё-таки дешевле, чем замена и/или факапы выгоревшего персонала.
Разработка десктопного приложения на продакшене? Это как, прямо у клиента на компе?
продуктовая компания, все для себя.
Разрабатываю, на продакшине больше тестировщиков.
ага, особенно весело когда что то ломаешь в базе и все начинают сразу звонить и писать.
Один из выходов из этой ситуации — делать проекты без баз.
только ..... у нассамописная система управления предприятием, без базы данных сложно себе представить такое. если имеется ввиду поменять место работы и там писать без базы данных, то надо именно искать проект без базы, но зачем если на новом месте например есть пара тройка баз для разработки и тестирования.
не понимаю, в чем смысл совета ?
Андрей Петруша
Pavel Katiushyn
Gremlin
Anatoli Koutsevol
Yevhen Stolietnii
Samko Stanislav
Конь в Пальто
Artyom Krivokrisenko
Max Kalagur
anonymous
Євген Козлов
Gennady Dogaev
Олесь Мальков
Volodymyr Antoniuk
Olegek Bondar
Alex Batler
Valery Shestakov
Нестор Иванович
Valiantt Jeff
Серега Коваленко
flyman
Anatoliy Rentgenovich
Andrii Podanenko
Dmitry Borshchanenko
Alex Batler
Нестор Иванович
Vladimir Pauchev
Sergyeyev Vladimir
Victor Mikhaylov
Mikhail Boiko
Vladimir Pauchev
Artyom Krivokrisenko
Vadim Kopanev
Konstantin Uvarin
Олексій Пєніє
Борис Махно
Sergii Voloshyn
Найкращі коментарі пропустити