Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Здравствуйте, michael_isu, Вы писали:
_>> не просить же примеры кода проекта, на который тебя берут...
U_E>а почему бы и нет. если пройдешь собеседование, и будут готовы брать — то почему бы и не показать пример кода соискателю.
угу, и что потенциальные работодатели будут об этом думать? Это все фантастика.
Шаги, которые (на мой взгляд) позволят избежать заведомо провального проекта
1. Присутствует ли баг-трекинг? (А формы его разные бывают, мне встречались даже листочки с замечаниями пользователей, но аккуратно подшитые).
2. Присутствует ли какая-нибудь CVS в проекте?
3. Сколько человек ДО вас делали проект? "Кто все эти люди? " В смысле, не были ли они студентами, не то чтобы я заранее и огульно пытаюсь кого-то обвинить, просто иногда ТАКИЕ чудеса пишут именно подобные ребята, что вам волей-неволей придется писать "костыли", что выглядит архитектурно чудовищно, но тем не менее позволяет проекту как-то работать. Ну или попытайтесь убедить остальных, что определенные части проекта нуждаются в переделке (с 95% вероятностью — откажут). Да, эмпирическое правило: Если над проектом ДО вас работало больше 2-х человек — забудьте про ООД, ООП. Но сами старайтесь так не делать.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, michael_isu, Вы писали:
_>>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
B>А сам ты случаем не вчерашний студент?
B>На самом деле идеала нету нигде. B>Та или иная порция бардака существует везде. B>Практически полное отсутствие хаоса скорей всего означает очень формальные процессы, B>при которых может быть еще тоскливее.
B>"Плюс" же бардака в коде в том, что его можно улучшать. B>Главное чтобы начальство это в принципе поддерживало. B>Т.е. я бы лично оценивал не текущий бардак в коде, B>а общее настроение в фирме, понимание проблем и желание их исправить. B>В этом случае будет даже интересно и ты сможешь себя проявить на все 100
Здравствуйте, sourcerer, Вы писали:
U_E>>а почему бы и нет. если пройдешь собеседование, и будут готовы брать — то почему бы и не показать пример кода соискателю. S>угу, и что потенциальные работодатели будут об этом думать? Это все фантастика.
о чем, об этом? об вопросе-то?
ну вот я работодатель, если бы соискатель попросил показать кусок кода, с которым ему, может быть, придется работать -- меня бы это не смутило. показал бы.
S>Шаги, которые (на мой взгляд) позволят избежать заведомо провального проекта S>1. [...]
Здравствуйте, michael_isu, Вы писали:
H>>Здравствуйте, michael_isu, Вы писали:
_>Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов.
Здравствуйте, kosmik, Вы писали:
K>А если это не фриварный проект, написанный одним человеком за пол-года?
уверен, что тогда есть шанс найти такой кусок кода, который, с одной стороны, продемонстрировал бы соблюдение (или не соблюдение) разработчиками определенной культуры кодирования, а с другой не содержал бы в себе know how.
не обязательно посылать кусок кода по e-mail. можно показать распечатку. а потом забрать, сжечь и растворить в кислоте.
далее: мы все знаем, что продукт редко ценен одним кодом. более того: беда, если компания устроена таким образом, что может разориться в случае кражи исходных кодов.
всегда можно попросить подписать соискателя NDA.
наконец, если компания не доверяет соискателю на этапе готовности взять его в команду, то будет ли она доверять ему в дальнейшем.
Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
Здравствуйте, kosmik, Вы писали:
K>Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
Всегда можно продемонстировать соглашения о кодировании, если они претенденту достаточно близки, то и проблем с чтением у него не возникнет.
K>>Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
U_E>примерно такой же объем информации, что и от примера кода, который принесет соискатель. U_E>мысль я понял, панацеи нет, никто не спорит
Код все-таки будет кандидата (неадекватных я не рассматриваю), хотя лучше дать ему задание и посмотреть.
K>>Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка? D>Всегда можно продемонстировать соглашения о кодировании, если они претенденту достаточно близки, то и проблем с чтением у него не возникнет.
Не всегда они оформлены в виде формального документа.
Вас нанимают копать могилы. Вы приходите и видите недокопанные ямы и жалуетесь, что ну до меня тут одни ламеры копали , да я докапывать за ними не хочу , мне или с чистого места под тенью кипариса могилку копать правильной лопаткой или я могу постоять в хорошо вырытой могилке для сурьезности момента.
Здравствуйте, michael_isu, Вы писали: _>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
просите встретиться с теми, с кем работать будете. мне правда, обычно удивленно в этой просьбе отказывали. программирование имеет больше отношения к книгописанию, чем к обычному производству. у всех свой стиль и отношение к делу. надо смотреть на людей, которые пишут код. архитектор студент — значит архитектуру будут постоянно менять по мере изучения им все новых приемов и код не будут успевать тестировать. программисты выглядят как нарки-раздолбаи — значит всем плевать на качество кода и на баг репорты, продукт никогда не станет популярным. пузатые и ленивые — значит будут полгода новую фичу делать, со скуки помрете, будете только ходить и чаи гонять с остальными.
еще есть ньюнс, если ваш коллега или, хуже, начальник, заметно моложе вас. они бывают хоть и умные, но очень ранимые. работал я в одной конторе лет 5 назад, пишу С++ код, смотрю — у фикседпойнтного вектора нет оператора минус. я подхожу к чуваку, который сидит спцеиально над этой библиотекой только и работает и говорю — а че у тебя оператора минус у вектора нет? добавь.
тот нет, чтобы сказать "угу", записать и продолжить работу тааак на меня обиделся и минут 15 рассказывал мне возмущенно, что оператор минус вектору не нужен, что можно и без него и смысла в нем нет. мне аж даже неудобно стало, что человека ни за что обидел. стоял, слушал из вежливости, успокаивал его, что все нормально, можно и не писать, ничего страшного, ты, главное, не плачь.
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, michael_isu, Вы писали:
H>>>Здравствуйте, michael_isu, Вы писали:
_>>Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов.
A>Вон из профессии.
Как только за мой труд перестанут платить адекватные деньги, так сразу
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Хэлкар, Вы писали:
>Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. >Мистика, но у богатых свои причуды.
Не верю. Это только кажется по наивности что с нуля быстрее, а на самом деле основная часть работы уходит не на кодинг, а на тестирование и дебаг, а это соответственно придется делать по всему комплексу. В итоге времени потрачено много, а в результате пользователь получает тот же самый продукт, что и в начале. При этом понятно, что пользователю плевать, что там внутри, ему надо чтобы работало.
Да, совокупные затраты на поддержку говнопроекта могут быть выше, а могут и не быть. Вот только очень сложно аргументированно доказать, что таковые затраты превысят затраты на разработку нового продукта. И в первую очередь потому что скорее всего это не так.
Здравствуйте, ax_prof, Вы писали:
_>Не верю. Это только кажется по наивности что с нуля быстрее, а на самом деле основная часть работы уходит не на кодинг, а на тестирование и дебаг, а это соответственно придется делать по всему комплексу.
Угу. Именно по этому с нуля и может оказаться быстрее. Если строили изначально дачный домик, а потом потребовалось превратить это в небоскреб. А фундаметнта нет. В результате один этаж, второй добавляешь и чем выше, тем больше подпорок приходится ставить, с на багфиксинге потери времени просто чудовищные. То, что можно сделать двумя человеками за 2 месяца, не спеша (проверенные данные, на подобных проектах это занимало именно 2 месяца), делается пятью за год, и плюс полгода на исправление багов. Скупой платит дважды. Я не про комплекс говорю, а про отдельный модуль. По хорошему, надо модули один за одним переписывать с нуля. Уже был у меня неоднократный крайне позитивный опыт переписывания модулей с нуля при изменении требований — в сроки всегда укладывались и багов потом не было. А когда решается ничего не трогать, и навесить на дачный домик еще десяток этажей, вот тогда просирают сроки в среднем в 10 раз (на моей практике такое было 2 раза, и каждый раз вместо месяца возились больше года, именно по тому, что не хватало кое кому из руководства смелости признать свои ошибки.).
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Обычно в конце технического собеседования спрашивают "есть ли у вас вопросы к нам".
Вот тут надо не стесняться и спрашивать все что интересует
какие технологии и фреймворки
какие методологии
какая команда
как планируете
какая длинна итерации
как принимаются техническии решения и кто принимает
какую систему контроля версий используете
какая архитектура проекта
сколько человек в команде
сколько синиоров и сколько джуниоров
какая база данных
почему выбрали такую базу данных а не другую
да элементарно распознать
собеседование же проходит не в одну калитку
тебе задают вопросы
ты задаешь вопросы
если контора готова тебя взять, она охотно отвечает на твои расспросы
вот тут и надо их на гавне ловить
" В смысле, не были ли они студентами, не то чтобы я заранее и огульно пытаюсь кого-то обвинить, просто иногда ТАКИЕ чудеса пишут именно подобные ребята, что вам волей-неволей придется писать "костыли", что выглядит архитектурно чудовищно, но тем не менее позволяет проекту как-то работать. Ну или попытайтесь убедить остальных, что определенные части проекта нуждаются в переделке (с 95% вероятностью — откажут). Да, эмпирическое правило: Если над проектом ДО вас работало больше 2-х человек — забудьте про ООД, ООП. Но сами старайтесь так не делать. 
