Не было и недели, что бы там что-то не правилось, не подпиливалось, не покупалось, не менялось. Потому что, если перестал следить за велосипедом то все, это верный путь к быдлотриалу — когда ты сидишь с пивом на лавке, а твой байк валяется рядом.
И опять же, сейчас, если я достану свой велосипед с балкона, а мне придется это сделать — через 2 недели буду собаку гонять по лесу, для того, что бы в форму привести. То мне придется неплохо так вложиться, потому что, например, в тех же тормозах я не уверен. В вилке — ну, прыгать с ней бы не решился :)
Так же и программы, если его дне подпиливать, не подтачивать, не переделывать — то без этого они погибают, ну или как зомби становятся — вроде они и есть, что-то делают, но лучше не трогать, что бы мозг был в целости и сохранности. Посмотрите сейчас на то, что не правилось в последние несколько лет, но исправно выполняет свои обязанности — сразу поймете о чем я.
Ситуаций когда от кода требуется только что бы он работал — мало. Очень мало. ПО — это, зачастую, живые и развивающиеся системы, которые должны адаптироваться под существующие реалии. Наш мир очень изменчив и если ПО из за своей архитектуры невозможно в приемлемые сроки переделать под текущие реалии, то такое по превращается в зомби.
По поводу велосипедов, тут тоже не все так просто. Когда-то давно, когда я начинал заниматься стритом и очень активно общался с другими велосипедистами, которые триалили или, например, занимались дертом, я понял насколько велосипед для них живой организм. Не было и недели, что бы там что-то не правилось, не подпиливалось, не
Без этого они погибают, ну или как
И правильно говорят, что код пишется не для компилятора, а для человека. По другому никак.
Зачем — сказать не могу. Видимо кто-то когда-то решил, что пригодиться.
jquery это фреймворк, который по своей сложности не уступает голому js. То есть нам теперь не надо знать как именно работает какая-то фишка в каком-то конкретном браузере, но надо знать как она работает в jquery. Собственно поэтому он и не сковывает нам ничего.
Я помню, когда-то давно, когда был еще наивен и глуп, переписывал один код, который мне казался лапшевидным. Я переписал эти 700 строк кода за один день. У меня вышло около 150 строчек, но потом, еще на протяжении месяца допиливал все то, что упустил. В итоге — около 800 строк.
Потому что все абстракции дырявые. Каждый новый слой абстракции сковывает наши движения. После нескольких слоем уже начинаешь ощущать себя словно по горло в песке.
Самый тяжелый случай который я видел фасад с именем Model, который поддерживал все рбд, несколько nosql-бд, три вида кэша и еще несколько приятных мелочей. Собственно методов там было мало — find, load, save, delete. Все.
А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами. Собственно к чему это ведет — да к тому, что за отдельный сервис отвечает уже небольшая команда из 3-10 человек. А не 40-50 девелоперов сидят в одном зале, одной командой и пишут-пишут-пишут код.
Ясное дело, что один разработчик, даже при таком подходе, не будет играть решающую роль. От его прихоти (хочу — не хочу), не будет складываться судьба проекта. Но то, что это будет гораздо гибче и удобнее в плане развития и, если потребуется, смены технологий — это факт.
Проблема может лежать в разной плоскости. И не всегда это связанно с ростом проекта (количества разработчиков), нагрузок. Иногда проблема может лежать в плоскости оптимизаций по затратам — лично видел как один проект, пожирал время 12+ разработчиков. Видел доску этого проекта, где половина (отданная под задачи), была заполнена серыми карточками — техническим долгом.
В итоге была создана команда с гордым названием RT (Refactoring Teem) которая должна была по сути заниматься рефракторным и устранением всех технических долгов. Она как достигла 4 человек, так и осталась со следующей версией продукта. Остальные разработчики стали не нужны, эти люди, после года своей работы (где-то переписали с нуля, где-то зарефакторили три раза до неузнаваемости), делали гораздо больше нежели старая команда со старым кодом.
Как минимум в три раза сократить издержки по разработке — думаю это тоже неплохой результат.
Думаю вся проблема была в том, что это была «главная функция». Я такое тоже встречал и мне говорили о таких местах кода так: делай что хочешь — а вот это не трогай, даже не смотри туда. Один раз посмотрел. Функция которая делает по сути все и ничего одновременно. Когда критическая масса нового функционала стала обрастать костылями для того, что бы «главная функция» не поперхнулась, то решили отказаться от нее. Постепенно она стала не то, что бы второстепенной — а придатком к 2-м стародавним модулям, которые были написаны еще на заре рождения веба, и никому не хотелось туда лезть и что-то править. Работали ведь как часы известной швейцарской марки.
Если изменения кода модуля (компонента, класса и т.п.) затрагивают больше его четверти — то дешевле будет переписать его полностью
От кода все зависит. Если так посчитать то мой последний «перепишем все с нуля» был от того, что необходимо было поправить около 1% кода т.е. чуть более 50 строчек кода. Правда это были основные строчки. В итоге оказалось так, что либо переписываем все и забываем обо всем на свете. Либо эти 20 строчек выделяем в стратегию и используем либо старую (которая работает для всего-всего), либо новую которая работает только для достаточно малой части тех модулей которые имеются в обвесе, но зато так, как необходимо на текущий момент.
Первым шагом был второй вариант, а там в течении той же недели и остальное под новый вариант перепилили. Как водиться — с нуля.
Я вот очень плохо отношусь к тому времени, которое выделяют на рефакторинг. Сейчас попытаюсь объяснить почему.
Потому что многие разработчики считают это время временем для того, что бы все переписать. Так и получалось у нас несколько раз (разные разработчики, разный уровень, разные языки) — два дня в конце спринта на рефакторинг, в начале следующего кричат о том что не хватило времени, нужен еще один день. Смотришь что сделали — половину отрефакторили, половину переписали все с нуля, а так как спешили — то сейчас то, что переписали не менее «кривое» и бажное, так что в первую очередь пойдет на следующий рефакторинг.
Знаю людей которые постоянно выбирают второй вариант. В итоге через какое-то время недоумевают почему даже подправить одну маленькую делать выливается в несколько часов.
Другое дело когда человек начинает допиливать что-либо и понимает, что надо бы немного подправить код, что бы было проще. Тогда и рефакторинг действительно рефакторинг, а не «сейчас мы напряжемся и за день выдадим коду на всю неделю вперед».
Но это не касается тех ситуаций, когда необходим архитектурный рефакторинг — или 2-3 дня только им заниматься, а уже потом новый код (иначе никак) или десяток костылей за те же 2-3 дня но на текущей архитектуре.
Код вообще, сам по себе, очень живуч. В конце прошлого года зашел на один из тех сайтов, которые я поддерживал, в начале своей карьеры. Смотрю — тот же девелоперский бекдор, залез, посмотрел историю в svn — 5 лет без обновления, та система виджетов которую запиливал. Из документации — только комментарий. Количество виджетов за это время выросло с 10 до около 80 (80 разных наследников класса Widget). Зачем так много — кто его знает, посмотрел на несколько, можно было бы удалить вообще, если немного подправить сам базовый класс. Но его почему-то никто не трогает.
Очень хорошее правило, но слабо применимое к активной разработке ПО. Поясню на примере. Сейчас имею дело с одной очень старой системой где очень так хорошо следовали этому правилу. В итоге такого 3.14%$!@#а, я не встречал давно. Тут можно весь день искать то место куда бы влепить костыль и навсегда забыть про это место. Это будет самое лучшее решение, ну или по крайней мере оно не будет выделяться из общей массы кода.
За то недолгое время, которое мне пришлось поработать с этим кодом, я могу сказать следующее: в моих руках находиться история. Я вижу слои программного кода, которые отчетливо показывают как же все таки развивалась java в последние 10 лет, начиная с третьей, и думаю скоро появиться, седьмой версией. Я вижу что поиск и отладка занимают до 90% моего времени.
В сравнении с тем новым кодом, который я пишу, где поиск занимает жалкие 5% времени, а отладка… тут все сложно — тесты пишутся вместе с кодом, поэтому на тыканье этого всего ручками тоже не больше 10% времени, по большей части что бы убедиться, что действительно все так прекрасно.
И да, мой код уже пару раз за последние несколько месяцев хорошо так отрефакторен, что бы не появился еще один пласт истории — уж лучше сейчас потратить 30 минут и допилить до актуальных требований, пусть даже они чисто косметические, нежели потом, через год рвать на себе волосы и громко кричать что приходиться копаться в говне.
Не на всякий лапшекод можно написать тесты, так, что бы быстрее. К примеру, недавно, мне попался один замечательный год-обжект (там где он мне попался, еще с пару десятков таких): 2 публичных метода и 12 (или 13 уже не припомню) тысяч строк кода, около 40 приватных методов и вызов еще трех таких вот год обжектов.
По сути то интеграционный тест накатить можно — вполне понятно что будет после вызова и первого, и второго методов. Собственно так и поступили. Но полноценно растащить все у меня получилось только через полтора дня (рефакторинг от идеи очень облегчил работу). Но и тут для тестирования были проблемы, состояние многих объектов было «нестабильным», в лучшем случае — неполным. Они прокидывались через 10-20-30 методов, перед тем как улететь в очередной внешний объект забивались левыми данными, потом подчищались (благо в комментариях люди поясняли зачем это было сделано). Где-то зачем-то копировались.
В общей сложности там, при каждом последующем рефакторинге, хорошо так и тесты переписывались. Переделывание этого всего заняло уже 8 дней, и это примерно треть от того, что необходимо сделать.
Переписали бы с нуля гораздо быстрее было бы — уже бы закончили, пару таких вот модулей переписали уже. Но, к сожалению, старый код тоже надо активно сопровождать (хотя там сопровождения на 10-20 минут в день — тут поменять, там запилить, тут что бы вместо ААА было ААА + БББ). Поэтому такой вот компромисс — часть времени за задачу, несравнимая часть на рефакторинг.
Потому что, я уже говорил — решения консультантом принимаются на основе некоего среза данных, Не учитывая много скрытых, на первый взгляд, особенностей. Программистам потом с этим жить. И доказать то, что консультант в чем-то был не прав — практически реально.
Цели для которых был приглашен данный эксперт мне, да и всем, кто там был, не совсем ясны — новый продукт, новая группа разработки. Насколько я знаю, от его услуг отказались, потому что по сути люди заплатили кучу денег за рекламу оракла как серебрянную пулю
надо было спросить у консультанта обоснование того что он предлагал. Скорей всего он бы сделал тест и показал конкретные цифры. Про хибернейт бы объяснил.
Обоснование — это оракл, там все быстро
А так можно сюда
Зачем?
Но вообще мне кажется вы даже и не читали то, что я написал. Я вам еще раз повторяю, что одним запросом это быстро не вытащишь. Это нереально. Потому что данные находятся в трех разных местах. Это такой вид бд — реляционная.
У меня за время работы накопилось много минусов в сторону РСУБД, зачастую их используют только потому, что нормальных альтернатив, до недавнего времени не было вообще. Да и любой разработчик знает как работать с рсубд.
При использовании носкуля (в моем случае монги), я весь этот профиль пользователя вообще бы хранил в одном сериализованном массиве со всеми его связями — одна запись сохраняется и загружается, атомарно. Тут надо уже изменять законы физики, что бы такой вариант работал медленнее, нежели рсубд.
А можно пожалуйста чуточку подробнее о тамошник оптимизациях. Суть задачи — достать полностью профиль пользователя который разбит на более чем 20 таблиц (10-20 колонок, в основном инты), в каждой из которых миллионы или десятки силлионов записей. Отношения один ко могим, например юзер имеет несколько объектов на карте к которым привязано еще куча других объектов. Собственно одним запросом то достать можно, но что нам при этом вернется? Около 300 колонок и тысяч десять рядов. При этом большая часть это null-ы. Не припомню во сколько трафика мне это выливалось, но хибернет при маппинге этого ввего отжирал разом более 200 метров мапил в течении нескольких секунд.
На сравние в монге все профили хранились в одной коллекции, средний вес объекта не дотягивал и до полутора мб, сохранялось-доставалось все атомарно (одна запись же вытаскивается) и за несколько миллисекунд.
PM, прочитав в сети про одно «модное» опенсурс решение, предлагает его использовать, для повышения скорости работы программного комплекса в разы.
Обычно в такой ситуации следует сразу хвататься за голову и грубой силой убедить РМ-а в том, что он не совсем прав. Слишком уж далеко от правды. Обычно даже после недолгого ознакомления будет видно за счет чего это «в разы» было получено. А там уже должен включится отдел мозга отвечающий за адекватность. Иногда юз-кейс как раз именно тот что нужен (допустим жертвуем консистентностью в угоду производительности).
К примеру взять тот же гит. У нас как было, фич новых много, одна ветка — все туда, что не успели в комментарии или стабами закрыли и на продакшн. Впринципе оверхед по работе с dvcs минимален, но перед релизом тратили достаточно времени что бы закрыть все недоделанные фичи и все равно в продакшн летети баги связанные с еще недопиленным функционалом.
Потратили немного времени на то, что бы каждую фичу в своей ветке делать, а потом уже собирать билды — оверхед увеличился, но общее количество времени и нервов отнимаемое на релизы и борьбу с мефическими багами в целом по компании снизилось, значительно (лично мое — до 20% т.е. весь следующий день после релиза я не переключался на то, что бы объяснить всем остальным кто где накосячил, что это уже исправлено — фича допилена и работает как надо, но надо потратить еще немного времени для того, что бы исправить в продакшн версии).
При использовании svn-а все то время, что мне удалось сохранить я бы тратил на то, что бы это все нормально смержить (пробовал мержить треть проекта с кучей перемещений файлов).
Эксперта приглашал не я, этот разговор с ним состоялся случайно — он высказал бред (что-то вроде ява — это энерпрайз онли и ничего больше), я зацепился, ну а дальше мы услышали много интересного в адрес всего, что не связано с ораклом.
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
Собственно с этого и надо было начинать. Хорошо, что вы понимаете, что вам разработчик, который привык находится «на волне» технологий не нужен — от него только проблемы, а нужен как раз таки тот, которого я и описал — ему на прошлых месте вдолбили технологии A, B и С — так он и будет их использовать. Может прочитает еще про D, подумает — а круто было бы использовать, придет, пообщается с вами и с другими разработчиками (а они то про D не читали) — разочаруется и вернется опять к своей привычной C.
А по поводу траты денег — категорически не согласен. Сейчас, при использовании новомодных решений можно очень хорошо сэкономить. Если раньше многие вещи делались командами из 5-7 человек по 3-4 месяца, то сейчас они делаются за 1-2 месяца командой из трех человек, а всего то A 1.0 сменили на A 3.0 которая на A 1.0 похожа только названием.
будет экспертная оценка
И кто будет выступать в роли эксперта? Мне, относительно недавно, один приглашенный «эксперт» (видимо люди скупились на его 15+ лет стажа), с умным видом втирал то, я вообще ничего не понимаю в архитектуре, после того, как я ему рассказал как был устроен наш игровой сервер и как я хотел это все адаптировать под достаточно быстро растущие нагрузки (>10к сессий одновременно на 2-3 серверах). В итоге, оказывается, надо было вместо монги начать использовать оракл (постгрес используют только лузеры для домашних сайтов — почти дословно), а все эти носкули это новомодные веяния которые через пару лет сойдут на нет. А после бреда про то, что надо было из 20-30 табличек выбирать данные одним запросом (каким-то магическим способом в оракле решили проблему что при этом у нас будет выборка на пару сотен столбцов и 100500 записей большинство из которых будет в null и скорость этого всего будет в сотню раз меньше), наш разговор решили прервать…
Кстати, час этого эксперта стоит как обычный, восьмичасовой рабочий день обычного программиста. Но тут даже проблема не в этом, проблема в том, что многие экспертные оценки делаются на «текущий момент ясной головой эксперта», а вот разработчикам дальше с этим приходиться жить.
А у меня сразу первые мысли про $
Так это правильно, но к тем двум пунктам, которые вы описали, надо бы добавить третий — сравнение с тем, что есть на данный момент. Иногда бывает что гораздо выгоднее переобучить людей и все перенастроить, нежели и дальше отнимать какой-то процент рабочего времени на борьбу с текущей системой
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
Вот скажите, что вы можете предложить действительно хорошему разработчику что бы он остался в компании, скажем… на 5 лет? Судя по вашим комментариям (может в реальной жизни все по другому) — то мало чего.
Не было и недели, что бы там что-то не правилось, не подпиливалось, не покупалось, не менялось. Потому что, если перестал следить за велосипедом то все, это верный путь к быдлотриалу — когда ты сидишь с пивом на лавке, а твой байк валяется рядом.
И опять же, сейчас, если я достану свой велосипед с балкона, а мне придется это сделать — через 2 недели буду собаку гонять по лесу, для того, что бы в форму привести. То мне придется неплохо так вложиться, потому что, например, в тех же тормозах я не уверен. В вилке — ну, прыгать с ней бы не решился :)
Так же и программы, если его дне подпиливать, не подтачивать, не переделывать — то без этого они погибают, ну или как зомби становятся — вроде они и есть, что-то делают, но лучше не трогать, что бы мозг был в целости и сохранности. Посмотрите сейчас на то, что не правилось в последние несколько лет, но исправно выполняет свои обязанности — сразу поймете о чем я.
По поводу велосипедов, тут тоже не все так просто. Когда-то давно, когда я начинал заниматься стритом и очень активно общался с другими велосипедистами, которые триалили или, например, занимались дертом, я понял насколько велосипед для них живой организм. Не было и недели, что бы там что-то не правилось, не подпиливалось, не
Без этого они погибают, ну или как
И правильно говорят, что код пишется не для компилятора, а для человека. По другому никак.
jquery это фреймворк, который по своей сложности не уступает голому js. То есть нам теперь не надо знать как именно работает какая-то фишка в каком-то конкретном браузере, но надо знать как она работает в jquery. Собственно поэтому он и не сковывает нам ничего.
Самый тяжелый случай который я видел фасад с именем Model, который поддерживал все рбд, несколько nosql-бд, три вида кэша и еще несколько приятных мелочей. Собственно методов там было мало — find, load, save, delete. Все.
А у людей была проблема с ним — медленно работал, да и ни с чем, кроме как с постгресом они работать и не думали.
Ясное дело, что один разработчик, даже при таком подходе, не будет играть решающую роль. От его прихоти (хочу — не хочу), не будет складываться судьба проекта. Но то, что это будет гораздо гибче и удобнее в плане развития и, если потребуется, смены технологий — это факт.
В итоге была создана команда с гордым названием RT (Refactoring Teem) которая должна была по сути заниматься рефракторным и устранением всех технических долгов. Она как достигла 4 человек, так и осталась со следующей версией продукта. Остальные разработчики стали не нужны, эти люди, после года своей работы (где-то переписали с нуля, где-то зарефакторили три раза до неузнаваемости), делали гораздо больше нежели старая команда со старым кодом.
Как минимум в три раза сократить издержки по разработке — думаю это тоже неплохой результат.
От кода все зависит. Если так посчитать то мой последний «перепишем все с нуля» был от того, что необходимо было поправить около 1% кода т.е. чуть более 50 строчек кода. Правда это были основные строчки. В итоге оказалось так, что либо переписываем все и забываем обо всем на свете. Либо эти 20 строчек выделяем в стратегию и используем либо старую (которая работает для всего-всего), либо новую которая работает только для достаточно малой части тех модулей которые имеются в обвесе, но зато так, как необходимо на текущий момент.
Первым шагом был второй вариант, а там в течении той же недели и остальное под новый вариант перепилили. Как водиться — с нуля.
Потому что многие разработчики считают это время временем для того, что бы все переписать. Так и получалось у нас несколько раз (разные разработчики, разный уровень, разные языки) — два дня в конце спринта на рефакторинг, в начале следующего кричат о том что не хватило времени, нужен еще один день. Смотришь что сделали — половину отрефакторили, половину переписали все с нуля, а так как спешили — то сейчас то, что переписали не менее «кривое» и бажное, так что в первую очередь пойдет на следующий рефакторинг.
Знаю людей которые постоянно выбирают второй вариант. В итоге через какое-то время недоумевают почему даже подправить одну маленькую делать выливается в несколько часов.
Другое дело когда человек начинает допиливать что-либо и понимает, что надо бы немного подправить код, что бы было проще. Тогда и рефакторинг действительно рефакторинг, а не «сейчас мы напряжемся и за день выдадим коду на всю неделю вперед».
Но это не касается тех ситуаций, когда необходим архитектурный рефакторинг — или 2-3 дня только им заниматься, а уже потом новый код (иначе никак) или десяток костылей за те же 2-3 дня но на текущей архитектуре.
За то недолгое время, которое мне пришлось поработать с этим кодом, я могу сказать следующее: в моих руках находиться история. Я вижу слои программного кода, которые отчетливо показывают как же все таки развивалась java в последние 10 лет, начиная с третьей, и думаю скоро появиться, седьмой версией. Я вижу что поиск и отладка занимают до 90% моего времени.
В сравнении с тем новым кодом, который я пишу, где поиск занимает жалкие 5% времени, а отладка… тут все сложно — тесты пишутся вместе с кодом, поэтому на тыканье этого всего ручками тоже не больше 10% времени, по большей части что бы убедиться, что действительно все так прекрасно.
И да, мой код уже пару раз за последние несколько месяцев хорошо так отрефакторен, что бы не появился еще один пласт истории — уж лучше сейчас потратить 30 минут и допилить до актуальных требований, пусть даже они чисто косметические, нежели потом, через год рвать на себе волосы и громко кричать что приходиться копаться в говне.
По сути то интеграционный тест накатить можно — вполне понятно что будет после вызова и первого, и второго методов. Собственно так и поступили. Но полноценно растащить все у меня получилось только через полтора дня (рефакторинг от идеи очень облегчил работу). Но и тут для тестирования были проблемы, состояние многих объектов было «нестабильным», в лучшем случае — неполным. Они прокидывались через 10-20-30 методов, перед тем как улететь в очередной внешний объект забивались левыми данными, потом подчищались (благо в комментариях люди поясняли зачем это было сделано). Где-то зачем-то копировались.
В общей сложности там, при каждом последующем рефакторинге, хорошо так и тесты переписывались. Переделывание этого всего заняло уже 8 дней, и это примерно треть от того, что необходимо сделать.
Переписали бы с нуля гораздо быстрее было бы — уже бы закончили, пару таких вот модулей переписали уже. Но, к сожалению, старый код тоже надо активно сопровождать (хотя там сопровождения на 10-20 минут в день — тут поменять, там запилить, тут что бы вместо ААА было ААА + БББ). Поэтому такой вот компромисс — часть времени за задачу, несравнимая часть на рефакторинг.
Цели для которых был приглашен данный эксперт мне, да и всем, кто там был, не совсем ясны — новый продукт, новая группа разработки. Насколько я знаю, от его услуг отказались, потому что по сути люди заплатили кучу денег за рекламу оракла как серебрянную пулю
Обоснование — это оракл, там все быстро
А так можно сюда
Зачем?
Но вообще мне кажется вы даже и не читали то, что я написал. Я вам еще раз повторяю, что одним запросом это быстро не вытащишь. Это нереально. Потому что данные находятся в трех разных местах. Это такой вид бд — реляционная.
У меня за время работы накопилось много минусов в сторону РСУБД, зачастую их используют только потому, что нормальных альтернатив, до недавнего времени не было вообще. Да и любой разработчик знает как работать с рсубд.
При использовании носкуля (в моем случае монги), я весь этот профиль пользователя вообще бы хранил в одном сериализованном массиве со всеми его связями — одна запись сохраняется и загружается, атомарно. Тут надо уже изменять законы физики, что бы такой вариант работал медленнее, нежели рсубд.
На сравние в монге все профили хранились в одной коллекции, средний вес объекта не дотягивал и до полутора мб, сохранялось-доставалось все атомарно (одна запись же вытаскивается) и за несколько миллисекунд.
Обычно в такой ситуации следует сразу хвататься за голову и грубой силой убедить РМ-а в том, что он не совсем прав. Слишком уж далеко от правды. Обычно даже после недолгого ознакомления будет видно за счет чего это «в разы» было получено. А там уже должен включится отдел мозга отвечающий за адекватность. Иногда юз-кейс как раз именно тот что нужен (допустим жертвуем консистентностью в угоду производительности).
К примеру взять тот же гит. У нас как было, фич новых много, одна ветка — все туда, что не успели в комментарии или стабами закрыли и на продакшн. Впринципе оверхед по работе с dvcs минимален, но перед релизом тратили достаточно времени что бы закрыть все недоделанные фичи и все равно в продакшн летети баги связанные с еще недопиленным функционалом.
Потратили немного времени на то, что бы каждую фичу в своей ветке делать, а потом уже собирать билды — оверхед увеличился, но общее количество времени и нервов отнимаемое на релизы и борьбу с мефическими багами в целом по компании снизилось, значительно (лично мое — до 20% т.е. весь следующий день после релиза я не переключался на то, что бы объяснить всем остальным кто где накосячил, что это уже исправлено — фича допилена и работает как надо, но надо потратить еще немного времени для того, что бы исправить в продакшн версии).
При использовании svn-а все то время, что мне удалось сохранить я бы тратил на то, что бы это все нормально смержить (пробовал мержить треть проекта с кучей перемещений файлов).
На часть задач, не нужны амбициозные люди, и пока вы этой не поймёте, вы будет терять $ необоснованно переходя на новые фреймворки, технологии и т.д.!
Собственно с этого и надо было начинать. Хорошо, что вы понимаете, что вам разработчик, который привык находится «на волне» технологий не нужен — от него только проблемы, а нужен как раз таки тот, которого я и описал — ему на прошлых месте вдолбили технологии A, B и С — так он и будет их использовать. Может прочитает еще про D, подумает — а круто было бы использовать, придет, пообщается с вами и с другими разработчиками (а они то про D не читали) — разочаруется и вернется опять к своей привычной C.
А по поводу траты денег — категорически не согласен. Сейчас, при использовании новомодных решений можно очень хорошо сэкономить. Если раньше многие вещи делались командами из 5-7 человек по 3-4 месяца, то сейчас они делаются за 1-2 месяца командой из трех человек, а всего то A 1.0 сменили на A 3.0 которая на A 1.0 похожа только названием.
И кто будет выступать в роли эксперта? Мне, относительно недавно, один приглашенный «эксперт» (видимо люди скупились на его 15+ лет стажа), с умным видом втирал то, я вообще ничего не понимаю в архитектуре, после того, как я ему рассказал как был устроен наш игровой сервер и как я хотел это все адаптировать под достаточно быстро растущие нагрузки (>10к сессий одновременно на 2-3 серверах). В итоге, оказывается, надо было вместо монги начать использовать оракл (постгрес используют только лузеры для домашних сайтов — почти дословно), а все эти носкули это новомодные веяния которые через пару лет сойдут на нет. А после бреда про то, что надо было из 20-30 табличек выбирать данные одним запросом (каким-то магическим способом в оракле решили проблему что при этом у нас будет выборка на пару сотен столбцов и 100500 записей большинство из которых будет в null и скорость этого всего будет в сотню раз меньше), наш разговор решили прервать…
Кстати, час этого эксперта стоит как обычный, восьмичасовой рабочий день обычного программиста. Но тут даже проблема не в этом, проблема в том, что многие экспертные оценки делаются на «текущий момент ясной головой эксперта», а вот разработчикам дальше с этим приходиться жить.
А у меня сразу первые мысли про $
Так это правильно, но к тем двум пунктам, которые вы описали, надо бы добавить третий — сравнение с тем, что есть на данный момент. Иногда бывает что гораздо выгоднее переобучить людей и все перенастроить, нежели и дальше отнимать какой-то процент рабочего времени на борьбу с текущей системой
Ваш детский бред выдают только ваши необоснованный амбиции и непонимание сути дела.
Вот скажите, что вы можете предложить действительно хорошему разработчику что бы он остался в компании, скажем… на 5 лет? Судя по вашим комментариям (может в реальной жизни все по другому) — то мало чего.