а он тебе и напишет портянку. И сможет аргументировать. И фиг ты поспоришь. Потому ты и нанял этого чувака, что он намного умней тебя в данной профильной теме, не? Из спора со специалистом на тему специальности никак не выйдешь победителем :)

Если этот вопрос ты задаёшь как работодатель - то нанимать людей тебе не просто рано, а чревато.

я регулярно имею дело с последоствиями такого найма. В частности, занимаюсь полным переписыванием проектов с Node и Ruby на Java. Или с Java на Java, когда предыдущий разраб написал умопомрачительное говно. Можешь посчитать хотя бы бабки, сколько это стоит, переписать то, что недожс-ники фигачили год. А усилий, баттхерта..

У нас говорят так : если вам надо тех. задание на каждый чих, то нахрена вы нам вообще нужны ? Не лучше ли нам самим взять и написать софт вместо кропения над нудным тех. заданием, и последующем выяснением отношений ?

Тех задание, когда хорошо знаешь ЧТО требуется пишется все же быстрее, чем покрытая юнит-тестами и проходящая все проверки реализация.

Золотая середина

У нас говорят так : если вам надо тех. задание на каждый чих, то нахрена вы нам вообще нужны ? Не лучше ли нам самим взять и написать софт вместо кропения над нудным тех. заданием, и последующем выяснением отношений ?

А истина, как обычно, где-то посередине между чрезмерным доверием разработчику и чрезмерной задокументированностью.

А после тебя переписывают?

а он тебе и напишет портянку. И сможет аргументировать. И фиг ты поспоришь. Потому ты и нанял этого чувака, что он намного умней тебя в данной профильной теме, не?

Не, если ты не можешь отличить объективные аргументы от аргументов фанатика то ты хреновый начальник.

Не так, надо «покажи код».

Обычная проблема, когда в организации в чём-то разбирается один единственный человек.

Если кроме него в ноду никто не умеет, то вы идиоты, раз разрешили ноду.

Всегда надо рассчитывать на то, что уволится самый незаменимый. Иначе так и будете переписывать. В идеале, на каждый проект не меньше двух человек, т.к. второй будет всегда в курсе, плюс, понимая, что ему нужно будет это всё поддерживать, будет не давать люто говнокодить первому. А если они ещё и на разных платформах разрабатывают, то и тестироваться шире будет.

nodejs (читается как «недожс») или руби

а на линуксе оно потом не собирается.

Тебя обманули.

потом не собпотомирается.

потом

Т.е. вы вообще не проверяете что вам накодили? :)

Вообще, топик толстый вброс.

https://en.wikipedia.org/wiki/Bus_factor

не надо так много слов

Хотелки же со временем меняются.

Грубо говоря, было приложение, которое держало 1000 человек на один сервер. Завтра хотелка поменялось, и захотелось держать 30000. Лид PHP скоренько увольняется, оставшаяся команда и эксперты говорят «на PHP технически невозможно». Спрашивают джавистов и сишников, а они согласны на такие требования. Сишники слишком дорогие, поэтому Java. Мыло-мочало перепиши всё сначала.

Получается, само решение выбрать PHP или Ноду было изначально неверное, но твое решение (написать ТЗ) не решает эту проблему.

Получается, само решение выбрать PHP или Ноду было изначально неверное

Не получается, если цена и время разработки на php или ноде ниже, чем на java.

Получается, что при закладке проекта неверно оценили его будущие масштабы.

А можно ли программистов в рабство как-нибудь?
stevejobs ★★★★★  я очень всем рекомендую рыться на помойке

Что сказать-то хотел?

Через 2года+1месяц проект разваливается, потому что платформа больше не держит нагрузки

ичо? вы когда на ноде переписывали - требования по производительности ставили? ставили же? проверяли же результат? проверяли. если вы сразу не смогли написать нормальные требования и по мере роста платформа не держит - кто тут ССЗБ?

или без ушедшего гения ничего нельзя сделать

ушедший гений вам же писал документацию, да? вы же её ревьюили, да?

или еще что-то такое очень плохое

например?

Я по теме заметил, что о языках ты говоришь как о точном указании на скилл человека, который его использует. Это не должно быть так, прекращай, а то выглядит глупо, и выставляет тебя не в лучшем свете.

Плюс я не совсем понимаю профит миграции проекта с инструмента на инструмент. На самом деле такое выгодно предпринимать в только ~ 2 схучаях из 20. Или, как вариант, у тебя не правильно представление о слове «проект», как о аппаратно-программном или просто программном комплексе. И тогда действительно тысячу строк с ноды можно хоть каждый день переписывать на ${самый трушный, по твоему мнению, язык, который, ко всему же, ты позиционируешь как золотую пулю}.

У меня есть в сопровождении пара проектов на рубях (в одном из них хоть номинально и 100% написано с использованием рубинов, но писали явно на php), адовщины на перле, и кучи башемонстров: всё живо, всё получает необходимые патчи. И гораздо дешевле идти по пути Аудит->Патч, чем по Аудит->Рефакторинг архитектуры под новый инструмент (ведь ты не из тех, кто просто делает рерайт синтаксиса, а используешь всю силу ${твой любимый язык})->Написание кода и тестов->Ревью и обкат->Анализ->Возможно результат.

В общем судя по всему, на моё скромное мнение, ты занимаешься не тем. Нужна организация конвейера, прежде производства продукта.

Ну описаный тобой чувак в ваакуме вполне норм. Отработал у вас 4 года. Это между прочим немало в этой сфере. В том что он выбрал некую технологию которая в его руках выстрелила и работала все это время - тоже норм. Пока что фейлов нет. Идем дальше. Фейл будет дальше, причем фейл не чувака а ваш. Чувак увольняется. Он единственный среди вас кто владеет технологией на достаточном уровне. В этой ситуации выходов для вас немного: нанять чувака с соответсвующим уровнем владения технологией, договориться с увольняющимся о постсаппорте или в конце концов самим овладеть технологией на достаточном уровне.

Если

он уволился как раз в тот момент, когда понял, что сейчас всё бахнет, и бахнет исключительно по его вине.

то тут два пути:

- он такой тип человека, который не способен нести ответсвенности за свои действия. (На самом деле таких мало).

- в текущей ситуации он не может вам рассказать о надвигающемся БП. (Самый распространенный вариант).

В этой ситуации грядущий БП не его(чувака) проблема и не его вина. Это ВАША ОБЩАЯ вина и проблема. В идеальном варианте чувак должен прийти в руководству и рассказать какие траблы приключатся в ближайшем будущем. И да, по лицу он за это получить не должен(в прямом и переносном смысле). Руководство компании/тимы должно разгребать это вместе, т.е. не следует говорить: «Ты налажал - бери и исправляй» если он физически не сможет этого сделать. Вы должны разработать план решения проблемы: по возможности закрыть проблему силами чувака, впрячься всей тимой, нанять еще спецов по этой технологии, плюнуть и перепесать все потеряв кучу бабла. Суть в том что shit happens, но этот shit нужно кому-то разгребать. Если чувак к вам не идет рассказывать о грядущей БП - проблема во взаимоотношениях в вашей среде, он не чувсвует себя «в семье».

Ну а изменение такого параметра как нагрузка в 30 (ТРИДЦАТЬ!) раз вполне реально выливается в кругленькую сумму. Вот спроектировал ты экскаватор, наладил линюю его выпуска, а потом к тебе приходит клиент и говорит: «Вот тебе штука баксов, приделай что-нибудь чтоб экскаватор за раз поднимал не 3 куб.м., а 90 куб м.». Очевидно что такие проблемы не решаются малой кровью. Типичная «Добавь вот тут такую-то кнопочку! Это ж несложно, правда?» Такие вещи надо обсуждать с клиентом, и либо оплата соответсвует либо вы рвете жопы забесплатно, но и не ноете(мыши плакали, кололись ...).

Я о том что фейловые не чуваки пишушие код, а в вашей организации трудового процесса существует систематический фейл. Его и надо решать. Проблема вовсем не в хипстерах.

Но я-то в Интернете Лев Толстой, а на деле - сам знаешь ...

Через 2года+1месяц проект разваливается, потому что платформа больше не держит нагрузки

то есть, масштабирование это что то такое, нереальное, все должно работать всегда на одном сервере?

1. Проблема с производительностью/масштабируемостью - это не проблема PHP, а проблема того, что на нем написали и как. Даже на PHP можно сделать балансировку нагрузки и еще очень много трюков, и даже есть люди которые это могут сделать.

2. Древняя военная мудрость, что про ТЗ, что про остальное - «просите много, чтобы дали сколько надо». Как по мне - прописывать надо «на вырост».

Но от ошибок в долгосрочном планировании никто не застрахован, так что если выход только переписывать - тогда уж переписывать.

Да, можно. Отдать долю в бизнесе и возможность влиять на его развитие. Такой раб никуда не уйдет.

А вообще, страсть к велосипедостроительству у программистов повальная. Понаделают велосипедов, наиграются и уйдут писать другие. А вы тут поддерживайте этот говнокод. Так Google::code помер. Фреймворк там был древний, неподдерживаемый и они решили что проект дешевле закрыть, чем чинить.

Говнокодерство здесь и заканчивается.

И возникает ясное понимание, что если хочешь нормальный результат - ищи подходящего специалиста и плати соответственно.

программист должен отвечать только в той мере, в какой ему поставили тз

У них программист вообще уволился. В какой мере он должен отвечать?

Тебе на кавказ с таким вопросом).

Для таких дел придумали контракты

1. Они подразумевают ответственность обеих сторон.

2. Если это трудовой договор, то сотрудник в случае чрезмерных требований и низкой оплаты просто уволится.

3. Если работа по контракту, то после работы на условиях «мы хотим подешевле и качественно», следующий будет уже на других условиях.

Для этого нужно иметь «под ружьём» несколько ранее судимых граждан.

Зависеть от уголовников? Ты серьезно. Подумай, какие у них цели и какова твоя роль в их достижении. Если у тебя есть бабки, а они хотят их получить самым простым способом, то есть серьезный шанс, что ты сам станешь целью. Причем один раз испачкаешься и всю жизнь будешь должен.

Для того чтобы починить то что наделали Эффективные Тимлимды с Эффективными Джуниорами для Эффективных Мэнеджеров есть специально обученные люди.

Это потому, что он уволился как раз в тот момент, когда понял, что сейчас всё бахнет, и бахнет исключительно по его вине.

Ситуация, конечно, вполне реальная и неприятная. Только как за 4 года совместной работы вы не поняли, что человек - мудак. Потому что был бы не мудак, занялся бы переработкой проекта под растущие нагрузки. Или, может, это вы его сами так достали, что ему было проще уволиться?

чудик, любой начальник спросит «а почему» и потребует портянку сравнения с альтернативными платформами, с привлечением сторонних экспертов

Ну, при таком раскладе, когда нужно кому-то постоянно что-то доказывать, человек либо перестанет проявлять инициативу и начнет работать тяп-ляп, либо начнет изменения втихаря, либо свалит к более разумному работодателю.

ты как любой новичек путаешь выбор платформы для нового проекта на годы (исходя из постов стиви) и какието инициативы.

у нас так и было - выбор платформы надо было обосновать, а как устроен rpc - всем пофиг, лишь бы решал задачи.

и что характерно rpc я переделывал несколько раз ибо кусок не большой и архитектура позволяла - а платформу не менял ибо там несколько десятков человеколет.

Да, можно. Отдать долю в бизнесе и возможность влиять на его развитие. Такой раб никуда не уйдет.

Лол. Либо придется делиться с ним прибылью, либо, если всё плохо, он просто свалит и отдуваться всё равно будет генеральный %)

Зависеть от уголовников? Ты серьезно. Подумай, какие у них цели и какова твоя роль в их достижении. Если у тебя есть бабки, а они хотят их получить самым простым способом, то есть серьезный шанс, что ты сам станешь целью. Причем один раз испачкаешься и всю жизнь будешь должен.

Правильно. Платить нужно ментам.

Подумай, какие у них цели и какова твоя роль в их достижении.

А у тебя?

Если у тебя есть бабки,

Это сколько?

а они хотят их получить самым простым способом, то есть серьезный шанс, что ты сам станешь целью.

Это значит что денег нет.

Причем один раз испачкаешься и всю жизнь будешь должен.

Не давай в долг.

А чем он до увольнения занимался? ИБД в углу, до которой никому не было дела? И не тестировали его код, и документацию на написанные части не требовали?

Лол. Либо придется делиться с ним прибылью

Правильно, нельзя делиться прибылью. Ты же придумал офигенную бизнес-идею и нанял идиотов за копейки для её реализации. Как ты представляешь с ними делиться вообще?!

либо, если всё плохо, он просто свалит и отдуваться всё равно будет генеральный

Экономисты уровня /lor/

Экономисты уровня /lor/

Чем рискует ООО кроме уставного капитала?

а каким образом доля в ООО связана с долей бизнеса? доля в ООО - это доля в уставном капитале, доля в бизнесе - это доля в экономической деятельности

А потом «саппортите как-нибудь сами, я через две недели увольняюсь».

Косяк менеджера, не должно быть незаменимых программистов.

И еще на маке всё пишут, деплоют собранное, а на линуксе оно потом не собирается.

Косяк лида, где ci и cd?

Оговаривается в рамках ТЗ и договора

Начали за здравие, закончили за упокойтем, что ТС хочет перекладывать свои бизнес-риски на наёмных работников. Арни в тему: http://www.youtube.com/watch?v=5aBJgqgANHY

Не, если ты не можешь отличить объективные аргументы от аргументов фанатика то ты хреновый начальник.

Ну вот он приносит результаты бенчмарка и грит, мол что вот так будет быстрее, как «хороший начальник» должен определить, что бенчмарк затачивали под конкретный кейс, который не соотносится с поставленной задачей и быстрее/лучше результат не будет?

Панацеи нет, но ключи есть. Можно минимизировать. Нужны несколько вещей, над которыми нужно постоянно работать.

Подробное описание рабочего процесса, нужно закрепить шаги, внутренние процедуры (например, описание процесса локализации или описание процесса коммита в репозиторий). Это очень сильно облегчит введение в курс дела новых сотрудников. Да и когда все работают по одной и той же схеме, самим же легче становится.

Ревью кода. Не важно изменил ли ты в коде запятую в комментарии или разработал новый класс, каждое изменение должно быть выложено на ревью.

Вики. База знаний по проекту. Программисты пишут не только классы, но и описывают как работает та или иная штуковина. Например, диаграммы переходов используемых в проекте стэйт-машин. Как собрать проект, как настроить окружение и прочее.

В некоторых странах можно заключать контракт на определённый срок со штрафом за преждевременный разрыв оного.

Ну вот он приносит результаты бенчмарка

Какбы ориентироваться на результаты бенчмарка при выборе платформы это хороший годный способ закопать всю контору.

Как бы гипотетический пример он гипотетический.