Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Испытательный срок не только для работодателя, но и для работника.
У вас есть 3 месяца(максимум) понять, что проект г*вно, потом можете получить расчет и уйти в 3х-дневный срок.
А может стоит иногда попробовать разобраться? Построить архитектуру, ввести правила? Просто проектов где идеальный код, все написано красиво и правильно очень мало (я думаю процентов 10). Так что ждать от моря погоды очень долго можно.
L>Испытательный срок не только для работодателя, но и для работника. L>У вас есть 3 месяца(максимум) понять, что проект г*вно, потом можете получить расчет и уйти в 3х-дневный срок.
да, уйти в никуда.. логики нет, так как работодатель и работник не в равном положении тут, деньги на стороне работодателя
Здравствуйте, michael_isu, Вы писали:
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Ну, это идеальный вариант — просить показать примеры кода. Иногда показывают сразу, иногда обещают показать в случае оффера. Мне чаще всего либо показывали, либо обещали показать. Если показывать отказываются — знак очень нехороший. А вообще, наблюдение (как по мне, так и по знакомым) — если в договоре написано про то, что код является суперсекретом, и из посторонних никому никогда ни под каким предлогом нельзя даже бегло на него посмотреть, так как там якобы мегасекреты, стоящие миллиарды — вот там суперговнокод и будет. Обычно все секреты заключается исключительно в том, что внутри все просто ужасно и сам черт голову сломят. Что интересно, полный ужас в коде наблюдается как раз у очень крупных и уважаемых корпораций.
Красивый проект делают как правило люди с хорошим опытом + отличным уровнем знаний + с возможностью отстоять перед начальством необходимость проектирования, тестирования и пр.
Если удастся выяснить, что проект сделал именно такой человек, то вероятнее всего проект "красивый".
R>да, уйти в никуда.. логики нет, так как работодатель и работник не в равном положении тут, деньги на стороне работодателя
Что значит в никуда?
Другой работы нет?
Что значит в неравном?
Если работника что то не устроило на испытательном сроке, то он может уйти и получить расчет.
Если деньги большие и работодатель выкаблучивается, то есть трудовая инспекция, а потом прокуратура.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме _>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Конкретно спрашивать (они сами проговариваются) о проекте. В частности интересоваться, проект с нуля или нет, если нет, то кто над ним работал и почему так получилось. Ибо в данном случае не говнопроект, а говноменеджмент, если над одним проектом работают 10 человек по-очереди.
R>это значит что работник не сможет вернуться к прежнему работодателю если ему не понравится новый, а поиски другого могут занять и несколько месяцев
А что ему делать у прежнего работодателя? Он уже ушел от туда, а если захочет вернуться, не вижу проблем для этого.
Вряд ли работодатель так быстро закрыл вакансию.
А то, что искать несколько месяцев нового, так заранее надо рассматривать несколько вариантов. Один не подошел, пошел к другому
(да-да, компании могут закрывать вакансию по несколько месяцев)
ЗЫ. 2 года назад по приезду в Москву рассматривал 2 варианта, оба были хороши. Выбрал один, только вот через месяц пришлось уходить.
Позвонил по второму варианту, уже работал там через неделю.
ЗЗЫ. Возвращаясь к сабжу, единственный способ хорошо узнать проект, понять как построен процесс — поработать недельку, две.
Если что то не устроило, есть законный способ уйти в кратчайшие сроки.
Здравствуйте, Хэлкар, Вы писали:
Х>А может стоит иногда попробовать разобраться? Построить архитектуру, ввести правила? Просто проектов где идеальный код, все написано красиво и правильно очень мало (я думаю процентов 10). Так что ждать от моря погоды очень долго можно.
Бывают проекты, где нельзя строить архитектуру, нельзя даже исходники отформатировать, нельзя от копи паста избавляться. По мелочи можно конечно, но надо доказывать необходимость каждого изменения и все такое, это должно пройти кучу согласований, это будет затягиваться на месяцы, письма будут игнорироваться, будет черти какая война. А потом когда все сделаешь — в твое творчество вклинится какой нибудь орел, понаколбасит там в спагетти стиле, понавносит багов, и виноват будешь ты, так как тебе больше всех надо. Причем за этот писец могут даже очень и очень неплохо платить. Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. Мистика, но у богатых свои причуды.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими. Известно, что разобраться в чужом коде обычно сложнее чем написать свой, это требует более высокой квалификации. Лет десять назад когда я приходил в чужой проект моя позиция была "переписать все нафик". Сейчас мой похдод радикально изменился. Большой проект редко бывает однородным по качеству, обычно есть удачные части и части написанные плохо. Во вторых, даже плохой код может быть отлажен так, что всех устраивает как он работает. Приходя в "чужой" проект я обычно стараюсь некоторое время вообще ничего не менять, изучить его хорошие стороны и плохие. Потом нахожу наиболее ключевые точки воздействия и начинаю постепенный рефакторинг стараясь нанести минимальный вред существующему коду. У каждого изменения должна быть краткосрочная цель и должна быть общая стратегия развития.
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Во первых, надо перестать думать что другие прораммеры тупей тебя. Keep mind open и даже в плохих проектах можно найти немало удачных идей и кусков кода. Во вторых изменить свое отношение к "говнопроектам", какая разница писать с нуля или рефакторить чужой код? Мне собственно никакой. В третьих надо ставить интересы бизнеса выше своих прихотей. Можно конечно переписать часть кода ради "эстетического удовольствия", но это может ничего не дать вообще.
Основной принцип — не навреди. Прежде чем стать архитектором и вести большие и сложные проекты приходится много разбираться в чужих проектах и доказывать свои способности работать с чужим кодом.
Вы производите впечатление программера junior уровня, не видно профессионального подхода к делу.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
А сам ты случаем не вчерашний студент?
На самом деле идеала нету нигде.
Та или иная порция бардака существует везде.
Практически полное отсутствие хаоса скорей всего означает очень формальные процессы,
при которых может быть еще тоскливее.
"Плюс" же бардака в коде в том, что его можно улучшать.
Главное чтобы начальство это в принципе поддерживало.
Т.е. я бы лично оценивал не текущий бардак в коде,
а общее настроение в фирме, понимание проблем и желание их исправить.
В этом случае будет даже интересно и ты сможешь себя проявить на все 100
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
По ответам на эти вопросы можно судить, что будет ждать тебя в каждодневной работе. Если в проекте бардак, из ответов это будет видно.
Сколько человек в команде?
Какие у них роли?
Есть ли отчётность для разработчиков в каком-либо виде? Нет ли дублирования из-за распределённой команды?
Кто участвует в планировании задач? Как далеко заглядывает план? Возможны уточнения по ходу дела?
Методология управления проектом?
Соотношение исправления багов и написания фич? А конкретно для позиции, на которую претендую я?
Поставлен ли процесс непрерывной интеграции в проекте? Если нет — почему?
Система баг-трекинга? Нет ли дублирования из-за распределённой команды?
Инспекции кода? Сколько этапов из-за распределённой команды? Инспекции дизайна? Сколько этапов из-за распределённой команды?
Юнит-тестирование, приёмочное тестирование, рефакторинг?
Я извиняюсь, система контроля версий?
Дополнительный полезный софт, на который есть лицензии? (Например, Araxis Merge, Resharper и так далее)
Возможно что-то упустил, писал по памяти — примерно такой список вопросов (был составлен когда-то на основе положительного и отрицательного опыта) я задаю на собеседовании, чтобы понять куда я попаду или чего я благополучно избегу.
> Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. Мистика, но у богатых свои причуды.
Извиняюсь, но древний армейский анекдот. Прапорщик отправляет бойца подметать плац ломом.
-Товарищ прапорщик, так ведь метлой чище будет!
-Нахрена мне твоя чистота, мне надо, чтоб ты зае...ся!
_>>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
H>Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими.
Это точно У меня прошло, после того, как я возопил — что за идиот писал — по поводу своего собственного кода, писанного год назад. Но дело-то в том, что на момент писания были веские причины писать так, а не иначе. Были свои соображения, намечалось развитие в одну сторону, а реально проект пошел в другую, да еще под крики "быстрей, быстрей!".
Здравствуйте, Handie, Вы писали:
H>Здравствуйте, michael_isu, Вы писали:
_>>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
H>Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими. Известно, что разобраться в чужом коде обычно сложнее чем написать свой, это требует более высокой квалификации. Лет десять назад когда я приходил в чужой проект моя позиция была "переписать все нафик". Сейчас мой похдод радикально изменился. Большой проект редко бывает однородным по качеству, обычно есть удачные части и части написанные плохо. Во вторых, даже плохой код может быть отлажен так, что всех устраивает как он работает. Приходя в "чужой" проект я обычно стараюсь некоторое время вообще ничего не менять, изучить его хорошие стороны и плохие. Потом нахожу наиболее ключевые точки воздействия и начинаю постепенный рефакторинг стараясь нанести минимальный вред существующему коду. У каждого изменения должна быть краткосрочная цель и должна быть общая стратегия развития.
Я ушел из конторы, где работало 4 человека и все писали очень приличный код, желания переписать не было (разве что редкими местами), даже сидел вечерами на досуге, изучал разные интересные части, очень познавательно было. Проектов там было около десятка, кстати. Как-то не очень совпадает с описанным Вами сценарием.
Но когда системе 10 лет, писало её человек 50, то тут моего энтузиазма не хватает. У всех своя позиция, кто-то гордо и смиренно начинает лопатить мегабайты кода, у меня к сожалению энтузиазма не хватает.
H>Во первых, надо перестать думать что другие прораммеры тупей тебя. Keep mind open и даже в плохих проектах можно найти немало удачных идей и кусков кода. Во вторых изменить свое отношение к "говнопроектам", какая разница писать с нуля или рефакторить чужой код? Мне собственно никакой. В третьих надо ставить интересы бизнеса выше своих прихотей. Можно конечно переписать часть кода ради "эстетического удовольствия", но это может ничего не дать вообще.
H>Основной принцип — не навреди. Прежде чем стать архитектором и вести большие и сложные проекты приходится много разбираться в чужих проектах и доказывать свои способности работать с чужим кодом.
H>Вы производите впечатление программера junior уровня, не видно профессионального подхода к делу.
Некоторые тупее, многие умнее, всяко бывает. Можно сидеть и разглядывать идеи в плохих проектах, но у каждого свой путь. Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов. Если владелец решил быстро студенческими руками налабать продукт и побыстрее срубить бабла, то это его личные проблемы, меня они никак не интересуют. Возьмет в долю — задумаюсь. А так — увольте. Вобщем это уже вопрос отношения к работе и философия. Вопрос тут не в этом.
