Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими. Известно, что разобраться в чужом коде обычно сложнее чем написать свой, это требует более высокой квалификации. Лет десять назад когда я приходил в чужой проект моя позиция была "переписать все нафик". Сейчас мой похдод радикально изменился. Большой проект редко бывает однородным по качеству, обычно есть удачные части и части написанные плохо. Во вторых, даже плохой код может быть отлажен так, что всех устраивает как он работает. Приходя в "чужой" проект я обычно стараюсь некоторое время вообще ничего не менять, изучить его хорошие стороны и плохие. Потом нахожу наиболее ключевые точки воздействия и начинаю постепенный рефакторинг стараясь нанести минимальный вред существующему коду. У каждого изменения должна быть краткосрочная цель и должна быть общая стратегия развития.
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Во первых, надо перестать думать что другие прораммеры тупей тебя. Keep mind open и даже в плохих проектах можно найти немало удачных идей и кусков кода. Во вторых изменить свое отношение к "говнопроектам", какая разница писать с нуля или рефакторить чужой код? Мне собственно никакой. В третьих надо ставить интересы бизнеса выше своих прихотей. Можно конечно переписать часть кода ради "эстетического удовольствия", но это может ничего не дать вообще.
Основной принцип — не навреди. Прежде чем стать архитектором и вести большие и сложные проекты приходится много разбираться в чужих проектах и доказывать свои способности работать с чужим кодом.
Вы производите впечатление программера junior уровня, не видно профессионального подхода к делу.
Здравствуйте, michael_isu, Вы писали:
H>>Здравствуйте, michael_isu, Вы писали:
_>Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов.
_>>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
H>Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими.
Это точно У меня прошло, после того, как я возопил — что за идиот писал — по поводу своего собственного кода, писанного год назад. Но дело-то в том, что на момент писания были веские причины писать так, а не иначе. Были свои соображения, намечалось развитие в одну сторону, а реально проект пошел в другую, да еще под крики "быстрей, быстрей!".
еще есть ньюнс, если ваш коллега или, хуже, начальник, заметно моложе вас. они бывают хоть и умные, но очень ранимые. работал я в одной конторе лет 5 назад, пишу С++ код, смотрю — у фикседпойнтного вектора нет оператора минус. я подхожу к чуваку, который сидит спцеиально над этой библиотекой только и работает и говорю — а че у тебя оператора минус у вектора нет? добавь.
тот нет, чтобы сказать "угу", записать и продолжить работу тааак на меня обиделся и минут 15 рассказывал мне возмущенно, что оператор минус вектору не нужен, что можно и без него и смысла в нем нет. мне аж даже неудобно стало, что человека ни за что обидел. стоял, слушал из вежливости, успокаивал его, что все нормально, можно и не писать, ничего страшного, ты, главное, не плачь.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
По ответам на эти вопросы можно судить, что будет ждать тебя в каждодневной работе. Если в проекте бардак, из ответов это будет видно.
Сколько человек в команде?
Какие у них роли?
Есть ли отчётность для разработчиков в каком-либо виде? Нет ли дублирования из-за распределённой команды?
Кто участвует в планировании задач? Как далеко заглядывает план? Возможны уточнения по ходу дела?
Методология управления проектом?
Соотношение исправления багов и написания фич? А конкретно для позиции, на которую претендую я?
Поставлен ли процесс непрерывной интеграции в проекте? Если нет — почему?
Система баг-трекинга? Нет ли дублирования из-за распределённой команды?
Инспекции кода? Сколько этапов из-за распределённой команды? Инспекции дизайна? Сколько этапов из-за распределённой команды?
Юнит-тестирование, приёмочное тестирование, рефакторинг?
Я извиняюсь, система контроля версий?
Дополнительный полезный софт, на который есть лицензии? (Например, Araxis Merge, Resharper и так далее)
Возможно что-то упустил, писал по памяти — примерно такой список вопросов (был составлен когда-то на основе положительного и отрицательного опыта) я задаю на собеседовании, чтобы понять куда я попаду или чего я благополучно избегу.
Красивый проект делают как правило люди с хорошим опытом + отличным уровнем знаний + с возможностью отстоять перед начальством необходимость проектирования, тестирования и пр.
Если удастся выяснить, что проект сделал именно такой человек, то вероятнее всего проект "красивый".
А может стоит иногда попробовать разобраться? Построить архитектуру, ввести правила? Просто проектов где идеальный код, все написано красиво и правильно очень мало (я думаю процентов 10). Так что ждать от моря погоды очень долго можно.
Здравствуйте, michael_isu, Вы писали: _>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
просите встретиться с теми, с кем работать будете. мне правда, обычно удивленно в этой просьбе отказывали. программирование имеет больше отношения к книгописанию, чем к обычному производству. у всех свой стиль и отношение к делу. надо смотреть на людей, которые пишут код. архитектор студент — значит архитектуру будут постоянно менять по мере изучения им все новых приемов и код не будут успевать тестировать. программисты выглядят как нарки-раздолбаи — значит всем плевать на качество кода и на баг репорты, продукт никогда не станет популярным. пузатые и ленивые — значит будут полгода новую фичу делать, со скуки помрете, будете только ходить и чаи гонять с остальными.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Хэлкар, Вы писали:
>Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. >Мистика, но у богатых свои причуды.
Не верю. Это только кажется по наивности что с нуля быстрее, а на самом деле основная часть работы уходит не на кодинг, а на тестирование и дебаг, а это соответственно придется делать по всему комплексу. В итоге времени потрачено много, а в результате пользователь получает тот же самый продукт, что и в начале. При этом понятно, что пользователю плевать, что там внутри, ему надо чтобы работало.
Да, совокупные затраты на поддержку говнопроекта могут быть выше, а могут и не быть. Вот только очень сложно аргументированно доказать, что таковые затраты превысят затраты на разработку нового продукта. И в первую очередь потому что скорее всего это не так.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Обычно в конце технического собеседования спрашивают "есть ли у вас вопросы к нам".
Вот тут надо не стесняться и спрашивать все что интересует
какие технологии и фреймворки
какие методологии
какая команда
как планируете
какая длинна итерации
как принимаются техническии решения и кто принимает
какую систему контроля версий используете
какая архитектура проекта
сколько человек в команде
сколько синиоров и сколько джуниоров
какая база данных
почему выбрали такую базу данных а не другую
Здравствуйте, michael_isu, Вы писали:
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Ну, это идеальный вариант — просить показать примеры кода. Иногда показывают сразу, иногда обещают показать в случае оффера. Мне чаще всего либо показывали, либо обещали показать. Если показывать отказываются — знак очень нехороший. А вообще, наблюдение (как по мне, так и по знакомым) — если в договоре написано про то, что код является суперсекретом, и из посторонних никому никогда ни под каким предлогом нельзя даже бегло на него посмотреть, так как там якобы мегасекреты, стоящие миллиарды — вот там суперговнокод и будет. Обычно все секреты заключается исключительно в том, что внутри все просто ужасно и сам черт голову сломят. Что интересно, полный ужас в коде наблюдается как раз у очень крупных и уважаемых корпораций.
R>да, уйти в никуда.. логики нет, так как работодатель и работник не в равном положении тут, деньги на стороне работодателя
Что значит в никуда?
Другой работы нет?
Что значит в неравном?
Если работника что то не устроило на испытательном сроке, то он может уйти и получить расчет.
Если деньги большие и работодатель выкаблучивается, то есть трудовая инспекция, а потом прокуратура.
Здравствуйте, Хэлкар, Вы писали:
Х>А может стоит иногда попробовать разобраться? Построить архитектуру, ввести правила? Просто проектов где идеальный код, все написано красиво и правильно очень мало (я думаю процентов 10). Так что ждать от моря погоды очень долго можно.
Бывают проекты, где нельзя строить архитектуру, нельзя даже исходники отформатировать, нельзя от копи паста избавляться. По мелочи можно конечно, но надо доказывать необходимость каждого изменения и все такое, это должно пройти кучу согласований, это будет затягиваться на месяцы, письма будут игнорироваться, будет черти какая война. А потом когда все сделаешь — в твое творчество вклинится какой нибудь орел, понаколбасит там в спагетти стиле, понавносит багов, и виноват будешь ты, так как тебе больше всех надо. Причем за этот писец могут даже очень и очень неплохо платить. Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. Мистика, но у богатых свои причуды.
Здравствуйте, ax_prof, Вы писали:
_>Не верю. Это только кажется по наивности что с нуля быстрее, а на самом деле основная часть работы уходит не на кодинг, а на тестирование и дебаг, а это соответственно придется делать по всему комплексу.
Угу. Именно по этому с нуля и может оказаться быстрее. Если строили изначально дачный домик, а потом потребовалось превратить это в небоскреб. А фундаметнта нет. В результате один этаж, второй добавляешь и чем выше, тем больше подпорок приходится ставить, с на багфиксинге потери времени просто чудовищные. То, что можно сделать двумя человеками за 2 месяца, не спеша (проверенные данные, на подобных проектах это занимало именно 2 месяца), делается пятью за год, и плюс полгода на исправление багов. Скупой платит дважды. Я не про комплекс говорю, а про отдельный модуль. По хорошему, надо модули один за одним переписывать с нуля. Уже был у меня неоднократный крайне позитивный опыт переписывания модулей с нуля при изменении требований — в сроки всегда укладывались и багов потом не было. А когда решается ничего не трогать, и навесить на дачный домик еще десяток этажей, вот тогда просирают сроки в среднем в 10 раз (на моей практике такое было 2 раза, и каждый раз вместо месяца возились больше года, именно по тому, что не хватало кое кому из руководства смелости признать свои ошибки.).
Здравствуйте, michael_isu, Вы писали:
_>В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать _>Как можно избежать таких осечек?
Научится рефакторить чужой код сроком больше недели.
... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>
Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме хватает на неделю и хочется сбежать
Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
_>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Испытательный срок не только для работодателя, но и для работника.
У вас есть 3 месяца(максимум) понять, что проект г*вно, потом можете получить расчет и уйти в 3х-дневный срок.
L>Испытательный срок не только для работодателя, но и для работника. L>У вас есть 3 месяца(максимум) понять, что проект г*вно, потом можете получить расчет и уйти в 3х-дневный срок.
да, уйти в никуда.. логики нет, так как работодатель и работник не в равном положении тут, деньги на стороне работодателя
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами. Хотя конторы большие, проекты серьезные, заказчики крупные и на собеседовании все красиво преподносится. В итоге запала разбираться во всем этом де*ьме _>Как можно избежать таких осечек? не просить же примеры кода проекта, на который тебя берут...
Конкретно спрашивать (они сами проговариваются) о проекте. В частности интересоваться, проект с нуля или нет, если нет, то кто над ним работал и почему так получилось. Ибо в данном случае не говнопроект, а говноменеджмент, если над одним проектом работают 10 человек по-очереди.
R>это значит что работник не сможет вернуться к прежнему работодателю если ему не понравится новый, а поиски другого могут занять и несколько месяцев
А что ему делать у прежнего работодателя? Он уже ушел от туда, а если захочет вернуться, не вижу проблем для этого.
Вряд ли работодатель так быстро закрыл вакансию.
А то, что искать несколько месяцев нового, так заранее надо рассматривать несколько вариантов. Один не подошел, пошел к другому
(да-да, компании могут закрывать вакансию по несколько месяцев)
ЗЫ. 2 года назад по приезду в Москву рассматривал 2 варианта, оба были хороши. Выбрал один, только вот через месяц пришлось уходить.
Позвонил по второму варианту, уже работал там через неделю.
ЗЗЫ. Возвращаясь к сабжу, единственный способ хорошо узнать проект, понять как построен процесс — поработать недельку, две.
Если что то не устроило, есть законный способ уйти в кратчайшие сроки.
Здравствуйте, michael_isu, Вы писали:
_>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
А сам ты случаем не вчерашний студент?
На самом деле идеала нету нигде.
Та или иная порция бардака существует везде.
Практически полное отсутствие хаоса скорей всего означает очень формальные процессы,
при которых может быть еще тоскливее.
"Плюс" же бардака в коде в том, что его можно улучшать.
Главное чтобы начальство это в принципе поддерживало.
Т.е. я бы лично оценивал не текущий бардак в коде,
а общее настроение в фирме, понимание проблем и желание их исправить.
В этом случае будет даже интересно и ты сможешь себя проявить на все 100
> Переписать с нуля в 10 раз быстрее, безопаснее, и дешевле, но отчего то хотят сделать так, чтоб как можно труднее было сделать так, как они хотят. Мистика, но у богатых свои причуды.
Извиняюсь, но древний армейский анекдот. Прапорщик отправляет бойца подметать плац ломом.
-Товарищ прапорщик, так ведь метлой чище будет!
-Нахрена мне твоя чистота, мне надо, чтоб ты зае...ся!
Здравствуйте, Handie, Вы писали:
H>Здравствуйте, michael_isu, Вы писали:
_>>Уже второй раз возникает проблема: приходишь на новую работу, садят на проект, а он из себя представляет говнопроект, по стилю спроектированный и написанный вчерашними студентами.
H>Большинство молодых и самонадеянных программеров считаю "дерьмом" любой код написанный не ими самими. Известно, что разобраться в чужом коде обычно сложнее чем написать свой, это требует более высокой квалификации. Лет десять назад когда я приходил в чужой проект моя позиция была "переписать все нафик". Сейчас мой похдод радикально изменился. Большой проект редко бывает однородным по качеству, обычно есть удачные части и части написанные плохо. Во вторых, даже плохой код может быть отлажен так, что всех устраивает как он работает. Приходя в "чужой" проект я обычно стараюсь некоторое время вообще ничего не менять, изучить его хорошие стороны и плохие. Потом нахожу наиболее ключевые точки воздействия и начинаю постепенный рефакторинг стараясь нанести минимальный вред существующему коду. У каждого изменения должна быть краткосрочная цель и должна быть общая стратегия развития.
Я ушел из конторы, где работало 4 человека и все писали очень приличный код, желания переписать не было (разве что редкими местами), даже сидел вечерами на досуге, изучал разные интересные части, очень познавательно было. Проектов там было около десятка, кстати. Как-то не очень совпадает с описанным Вами сценарием.
Но когда системе 10 лет, писало её человек 50, то тут моего энтузиазма не хватает. У всех своя позиция, кто-то гордо и смиренно начинает лопатить мегабайты кода, у меня к сожалению энтузиазма не хватает.
H>Во первых, надо перестать думать что другие прораммеры тупей тебя. Keep mind open и даже в плохих проектах можно найти немало удачных идей и кусков кода. Во вторых изменить свое отношение к "говнопроектам", какая разница писать с нуля или рефакторить чужой код? Мне собственно никакой. В третьих надо ставить интересы бизнеса выше своих прихотей. Можно конечно переписать часть кода ради "эстетического удовольствия", но это может ничего не дать вообще.
H>Основной принцип — не навреди. Прежде чем стать архитектором и вести большие и сложные проекты приходится много разбираться в чужих проектах и доказывать свои способности работать с чужим кодом.
H>Вы производите впечатление программера junior уровня, не видно профессионального подхода к делу.
Некоторые тупее, многие умнее, всяко бывает. Можно сидеть и разглядывать идеи в плохих проектах, но у каждого свой путь. Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов. Если владелец решил быстро студенческими руками налабать продукт и побыстрее срубить бабла, то это его личные проблемы, меня они никак не интересуют. Возьмет в долю — задумаюсь. А так — увольте. Вобщем это уже вопрос отношения к работе и философия. Вопрос тут не в этом.
Здравствуйте, 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. [...]
Здравствуйте, kosmik, Вы писали:
K>А если это не фриварный проект, написанный одним человеком за пол-года?
уверен, что тогда есть шанс найти такой кусок кода, который, с одной стороны, продемонстрировал бы соблюдение (или не соблюдение) разработчиками определенной культуры кодирования, а с другой не содержал бы в себе know how.
не обязательно посылать кусок кода по e-mail. можно показать распечатку. а потом забрать, сжечь и растворить в кислоте.
далее: мы все знаем, что продукт редко ценен одним кодом. более того: беда, если компания устроена таким образом, что может разориться в случае кражи исходных кодов.
всегда можно попросить подписать соискателя NDA.
наконец, если компания не доверяет соискателю на этапе готовности взять его в команду, то будет ли она доверять ему в дальнейшем.
Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
Здравствуйте, kosmik, Вы писали:
K>Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
Всегда можно продемонстировать соглашения о кодировании, если они претенденту достаточно близки, то и проблем с чтением у него не возникнет.
K>>Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка?
U_E>примерно такой же объем информации, что и от примера кода, который принесет соискатель. U_E>мысль я понял, панацеи нет, никто не спорит
Код все-таки будет кандидата (неадекватных я не рассматриваю), хотя лучше дать ему задание и посмотреть.
K>>Вообще-то я к тому что в реальном проекте код — разный. Как минимум, написанный разными людьми. И что можно вынести из какого-то не факт что репрезентативного его участка? D>Всегда можно продемонстировать соглашения о кодировании, если они претенденту достаточно близки, то и проблем с чтением у него не возникнет.
Не всегда они оформлены в виде формального документа.
Вас нанимают копать могилы. Вы приходите и видите недокопанные ямы и жалуетесь, что ну до меня тут одни ламеры копали , да я докапывать за ними не хочу , мне или с чистого места под тенью кипариса могилку копать правильной лопаткой или я могу постоять в хорошо вырытой могилке для сурьезности момента.
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, michael_isu, Вы писали:
H>>>Здравствуйте, michael_isu, Вы писали:
_>>Вы рассуждаете как владелец бизнеса, меня не интересуют интересы конкретных бизнесов.
A>Вон из профессии.
Как только за мой труд перестанут платить адекватные деньги, так сразу
да элементарно распознать
собеседование же проходит не в одну калитку
тебе задают вопросы
ты задаешь вопросы
если контора готова тебя взять, она охотно отвечает на твои расспросы
вот тут и надо их на гавне ловить
Здравствуйте, Хэлкар, Вы писали:
Х>А может стоит иногда попробовать разобраться? Построить архитектуру, ввести правила? Просто проектов где идеальный код, все написано красиво и правильно очень мало (я думаю процентов 10). Так что ждать от моря погоды очень долго можно.
Минус за оптимизм по поводу 10%.
Здравствуйте, nigh, Вы писали:
N>The Joel Test: 12 Steps to Better Code N>ответы на тест точно скажут, что за проект перед вами
Совершенно бессмысленная статья, впрочем, это, наверное, для священных войн.
5, 9, 11 просто бессмысленны.
Если вкратце, то в описанных выше проектах все разумные ответы будут "да", вот только ужасными они от этого не быть не перестанут.
Здравствуйте, Handie, Вы писали:
H>Во первых, надо перестать думать что другие прораммеры тупей тебя. Keep mind open и даже в плохих проектах можно найти немало удачных идей и кусков кода. Во вторых изменить свое отношение к "говнопроектам", какая разница писать с нуля или рефакторить чужой код? Мне собственно никакой. В третьих надо ставить интересы бизнеса выше своих прихотей. Можно конечно переписать часть кода ради "эстетического удовольствия", но это может ничего не дать вообще.
Хороший ответ в общем то. Согласен со всем, но хочу добавить, что говнокод часто может значить овертаймы; работа без отпуска; в нервной обстановке; и в конце концов увольнение всей команды из-за проваленого проекта. Подробнее об этом написано в книге "Путь камикадзе".
