Здравствуйте, _FRED_, Вы писали:

_FR>А вот когда человек "работал в большой команде, которая писала проект на N мильонов строк кода…" то оказывается гораздо сложнее оценить вклад (и эффективность) человека и его работоспособности.

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

УЁ>Вклад в проект оценивается не количеством написанных строк. А работа в проекте с миллионом строк говорит о том, что человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".

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

Здравствуйте, Ушастый Ёж, Вы писали:

_FR>>А вот когда человек "работал в большой команде, которая писала проект на N мильонов строк кода…" то оказывается гораздо сложнее оценить вклад (и эффективность) человека и его работоспособности.

УЁ>Вклад в проект оценивается не количеством написанных строк.

Верно, их качеством исключительно.

УЁ>А работа в проекте с миллионом строк говорит о том, что

Сама по себе "работа" ни говорит ни о чём. Говорят детали: то, как и с помощью чего человек выполнял поставленные перед ним задачи. Насколько хорошо (по его словам и по описанию). Какую из целей выполнения задачи (время, надёжность, полноту) он ставил на первое, второе место и почему? И эти характеристики не зависят от объёма работ.

С другой стороны конечно, когда нужен разработчик a-la monkey-coder то "миллиощик" самое оно и спорить не буду

УЁ>человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".

Если вышеприведённую цитату представить, как характеризующую человека-одиночку-фрилансера, то она по прежнему останется верна, не правда ли? Опиши тогда те самые "определенные задачи", которые _выгодно отличают в лучшую сторону_ работника с рпытом в большой команде на огромным проектом от совсем небольшой команды с десятком небольших проектов?

Здравствуйте, bkat, Вы писали:

B>Да и вообще.... Писать новый код — проще паренной репы
B>Сложно его писать так, чтобы его было легко сопровождать.

+1000 (много-много нулей ). Выучила уже не одного новичка — многие поначалу даже не понимают, зачем некоторые вещи писать именно так, чтобы его было потом легко сопровождать, а не как они привыкли.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Размеры проектов мелкие. Ну что такое 2000 строк, сами подумайте?

Какие 2000 строк, сейчас типичные шараварки это 20 — 200 тысяч строк.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, mik1, Вы писали:

КЛ>[]

M>>Не меньше, чем Lead Architect требуй
M>>А если сурьезно — не видел людей с двухлетним опытом, которым не страшно было бы отдать что-то больщее, чем рисование формочек. А до лидов с таким опытом — как до Пекина р....

КЛ>не везет тебе с командой

Причем страшно невезет

Здравствуйте, Ушастый Ёж, Вы писали:

УЁ>Здравствуйте, MozgC, Вы писали:

MC>>На самом деле в проекте 30000 строк написанных именно вручную, проект развивался постепенно в течение 2.5 лет, а дополнительную кучу обязанностей я начал выполнять только в последние 5 месяцев. Так что опыт на серьезном проекте есть, и я считаю что этот опыт лучше, чем выполнить 10 простых проектов, так как при развитии одного проекта с каждым разом выполняются все более сложные вещи, выполняя же постоянно много простых проектов можно застопориться на одном уровне. Это мое мнение.

УЁ>30,000 строк это очень мало. Вот когда в проекте кол-во строк зайдет за миллиончик — тогда можно надуть щеки и сказать что проект серьезный.

Может проэкт с 1кк строк пора рефакторить или уже позно?

Здравствуйте, _FRED_, Вы писали:

УЁ>>А работа в проекте с миллионом строк говорит о том, что

_FR>Сама по себе "работа" ни говорит ни о чём. Говорят детали: то, как и с помощью чего человек выполнял поставленные перед ним задачи. Насколько хорошо (по его словам и по описанию). Какую из целей выполнения задачи (время, надёжность, полноту) он ставил на первое, второе место и почему? И эти характеристики не зависят от объёма работ.

Вот представь себе, берут на работу пилота пассажирского авиалайнера. Кандидат рассказывает как классно он в воздух самолеты поднимает, сажает коробочкой в любую погоду, и все такое. Но одна проблема, что летал он на высоте 3-4 метра от земли, а боинги летают на 10000 метрах.

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

_FR>С другой стороны конечно, когда нужен разработчик a-la monkey-coder то "миллиощик" самое оно и спорить не буду

Не перестаю удивляться, как часто люди рассказывают про мифического кодера-обезьянку, который умеет писать 1000 строк в день, главное сказать ему что писать. Дайте мне в проект таких? Человек 10. А я буду говорить им что писать, и еще еду приносить, чтобы работали 24 часа в сутки.

УЁ>>человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".

_FR>Если вышеприведённую цитату представить, как характеризующую человека-одиночку-фрилансера, то она по прежнему останется верна, не правда ли?

Нет, она не остается верна. Если одиночка-фрилансер работал в больших проектах, он знает реальную цену юношской идеи переписать все с нуля. В проекте в 30000 строк это реально, за неделю-две, переписать какой то кусок проекта с нуля, одному. Но в реальных проектах это невозможно. Потому что во-первых зависимости в системе на порядок выше (и не надо рассказывать сказки про слабо-связанные системы, они к сожалению только в книжках бывают), и ничего не поломать становится так же на порядок сложней, а во-вторых в таких проектах всегда есть куда более приоритетные задачи. Я уж молчу о проблемах рефакторинга и мерджинга, когда используется несколько бранчей для разработки. В таких случаях даже класс переименовать может стать особой проблемой, что уж там говорить о переписке с нуля.

_FR> Опиши тогда те самые "определенные задачи", которые _выгодно отличают в лучшую сторону_ работника с рпытом в большой команде на огромным проектом от совсем небольшой команды с десятком небольших проектов?

Смотри выше.

Здравствуйте, Maxim S. Shatskih, Вы писали:

УЁ>>Вклад в проект оценивается не количеством написанных строк. А работа в проекте с миллионом строк говорит о том, что человек сталкивался с определенным видом задач, и когда завтра в систему нужно будет добавить новую фичу, он не будет переписывать все с нуля, мотивируя это тем, что там "все так криво написано, что разобраться просто невозможно".

MSS>По-моему, такие вещи, как переписка с нуля, требуют санкции начальства всегда, даже во вполне себе правильно построенных командах без строевой муштры во фрунт и идолопоклонства процессам.

Какие могут быть санкции начальства, в проекте-карлике с одним разработчиком? Он просто никому не скажет о задуманном. И будет сидеть 2 недели без выходных по 12 часов, переписывать и переписывать, при этом удивляясь почему это заняло не 2 дня, как ему казалось в начале. Хорошо если еще вовремя одумается и сделает ролл-бэк.

Кстати часто в маленьких проектах, особенно с 1 разработчиком, системы контроля версий вообще не используются, и хорошо если остался бэк-ап.

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

Здравствуйте, Ушастый Ёж, Вы писали:

УЁ>Дело в том, что в проектах "миллионниках" происходит так свойственный этому миру количественно-качественный переход. И все проблемы, которые в маленьких проектах кажутся пустяковыми, могут оказаться принципиально невыполнимыми.

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

Но я просто не могу в это поверить: за, примерно, три десятка пережитых собеседований, никто ни одного подобного вопроса не спросил Наоборот даже: в небольших компаниях (где < 30 разработчиков) разговор про систему контроля версий и технологии и тонкости работы с ними (а так же про организацию работы с базой данных и уместность использования ассертов в тех или иных случаях) был гораздо душевнее, чем в больших компаниях, где упор почему-то, в полный противовес вашим словам, делался на паттерны, тонкости синтаксиса и знания библиотек. Почему так? Или вот: все, у кого уже есть большая система рассказывают, что им как-раз таки нужны люди для серьёзно переделки больших её, системы, кусков, потому что заказчики уже есть, торопиться, как при стартапе, не надо и самое время подумать об удобстве будущих нововведений

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

Да неужели и вы в своей компании или в других, на собеседованиях говорите больше про тонны кода, а не про небольшие конкретные кусочки, выясняя, что в них хорошего, а что — не очень?

Здравствуйте, Ушастый Ёж, Вы писали:

УЁ>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.

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

Здравствуйте, _Obelisk_, Вы писали:

_O_>Просто вы с большими проектами не сталкивались. Когда работаешь с проектом где несколько миллионов строк кода, то 30 000 — это совсем не много.

Работа с миллионами строк называется по-другому — обслуживание.
С другой стороны, я, например, где-то полгода работал над алгоритмом, который получился всего-то в 2000 строк.

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

Здравствуйте, McSeem2, Вы писали:

_O_>>Просто вы с большими проектами не сталкивались. Когда работаешь с проектом где несколько миллионов строк кода, то 30 000 — это совсем не много.
MS>Работа с миллионами строк называется по-другому — обслуживание.
Это если их нужно обслуживать. Если же надо развивать проект, добавлять туда новые вещи, улучшать старые — то это уже совсем отдельная песня. Количество переход в качество

Можно в пример тот же Линукс взять — код в большинстве файлов абсолютно тупой, но никто же не утверждает, что любой средний программист справится с поддержанием такой системы.

MS>С другой стороны, я, например, где-то полгода работал над алгоритмом, который получился всего-то в 2000 строк.
MS>Но должен признать, что по неким вторичным половым признакам те упомянутые 30000 строк — это абсолютная банальность.
Алгоритмы — это тоже отдельная песня. Ну не всем же нравится ломать голову над деталями кривых Безье

Здравствуйте, Cyberax, Вы писали:

C>...Количество переход в качество

Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется.

Здравствуйте, _FRED_, Вы писали:

УЁ>>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.

_FR>Это "на раз" решается вменяемым менеджментом (без которого в большом проекте никак, верно?), так что сильно удивлюсь, если подобные проблемы действительно причиняют неудобство.

Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает? Еще раз, он никому не скажет, что собирается все перепахать с нуля. Пообещает результат за 2 дня, менеджер подумает и скажет хорошо. Через день спросит — как там идут дела? Разработчик скажет что все по плану, завтра будет готово. А на самом деле нифига завтра готово не будет.

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

Здравствуйте, _FRED_, Вы писали:

C>>...Количество переход в качество
_FR>Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется.
Нет, я имею в виду, что при большом количестве поддерживаемого кода, нужны уже качественно другие навыки, чем при поддержке кода в 30000 строк.

Здравствуйте, _FRED_, Вы писали:

УЁ>>Дело в том, что в проектах "миллионниках" происходит так свойственный этому миру количественно-качественный переход. И все проблемы, которые в маленьких проектах кажутся пустяковыми, могут оказаться принципиально невыполнимыми.

_FR>Из всего сказанного напрашивается вывод о том, что определяющими качествами разработчика являются умение мёрджить; не переписывать, а поддерживать всё на имеющемся средненьком, или даже ниже, уровне; и, конечно же, работа в условиях сильносвязанных систем

Для начала вынужден вам сообщить, что шансы попасть на проект, который только только начинает разрабатываться — близки к нулю. Почему так происходит — отдельная тема. В нашей реальности вы попадаете в проект, который уже находится в продакшене и требуется его развитие и поддержка. Конечно в таких проектах не только баги фиксят, но и пишут дофига нового кода, но этот код нужно приклеить к существующему, причем наилучшим в рамках имеющегося времени образом. Т.е. опять встает проблема умения работать с тоннами чужого кода. Во-вторых, как я уже сказал, слабосвязанные системы бывают только в сказках, где нет индусов, аутсорсинга и просто криворуких разработчиков. В при этом программисты-малометражники (с проектами из 30000 строк) будут в числе тех самых криворуких.

_FR>Но я просто не могу в это поверить: за, примерно, три десятка пережитых собеседований, никто ни одного подобного вопроса не спросил Наоборот даже: в небольших компаниях (где < 30 разработчиков) разговор про систему контроля версий и технологии и тонкости работы с ними (а так же про организацию работы с базой данных и уместность использования ассертов в тех или иных случаях) был гораздо душевнее, чем в больших компаниях, где упор почему-то, в полный противовес вашим словам, делался на паттерны, тонкости синтаксиса и знания библиотек. Почему так?

Ответ очень прост. На интервью рассказывают сказки о чудесном проекте, в котором все шоколадно и работать одно удовольствие. Если на интервью задать вопрос "а как вы относитесь в баг-фиксингу", то половина кандидатов сразу разбежится. Вот и спрашивают про всякие паттерны и прочий модный булшит, создавая впечатление мега-технологичной компании. Я ни в коем случае не говорю что не надо знать паттерны и спрашивать о них, я лишь говорю что по вопросам на интервью (адресованных кандидату) далеко не всегда можно понять, что там за кашу варят. Хотите узнать как обстоят дела на самом деле, то задавайте прямые вопросы о проекте.

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

_FR> Или вот: все, у кого уже есть большая система рассказывают, что им как-раз таки нужны люди для серьёзно переделки больших её, системы, кусков, потому что заказчики уже есть, торопиться, как при стартапе, не надо и самое время подумать об удобстве будущих нововведений

Опять же, скорее всего это следует понимать как "требуются люди для бак-фиксинга и развития системы, да так, чтобы не поломать все нафиг".

_FR>Исходя из вышесказанного, никак не могу согласиться с тем, что решающим фактором (да вообще сколь угодно значимым) может быть опыт работы в больших проектах. Хотя бы потому, что привить его — дело нескольких месяцев, а вот выучиться на толкового девелопера — много сложнее.

Толковый девелопер без опыта работы в больших проектах сгодится только для написания cd-эректора. А для промышленной разработки он будет начинающим (пусть и толковым).

_FR>Да неужели и вы в своей компании или в других, на собеседованиях говорите больше про тонны кода, а не про небольшие конкретные кусочки, выясняя, что в них хорошего, а что — не очень?

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

А нафига у кандидата спрашивать о небольших конкретных кусках нашего проекта я не понял...

Здравствуйте, Ушастый Ёж, Вы писали:

УЁ>>>И придя в большой проект, такой разработчик может никому ничего не сказав начать что то переделывать, как всегда пообещав (в том числе самому себе) что все закончит через 2 дня.

_FR>>Это "на раз" решается вменяемым менеджментом (без которого в большом проекте никак, верно?), так что сильно удивлюсь, если подобные проблемы действительно причиняют неудобство.

УЁ>Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает?

Нет, это не правильное понятие менеджмента.

УЁ>Еще раз, он никому не скажет, что собирается все перепахать с нуля.

Чушь. Крышу может снести у кого угодно и спорить об этом бесмысленно. Дураком может быть кто угодно, не зависимо не от чего. Откуда, если не секрет, у вас стереотип о человеке без опыта работы в команде? На основании чего вы обобщаете своё мнение на всех "одиночек"? Если я начну рассказывать с какими примерами "коллективизма в условиях большого проекта" сталкивался, то у меня на клавиатуре некоторые кнопки с буквами, которые чаще всего встречаются в ругательных словах, поломаются или сотрутся

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

УЁ>Пообещает результат за 2 дня, менеджер подумает и скажет хорошо.

С каких это пор (если говорить не о ком-то конкретно)? От том, как можно или не нужно поступать, вовсе не обязательно знать из личной опыта: достаточно общего мнения.

УЁ>Второй сценарий — разработчик таки поймет, что переделать все невозможно, надо воткнуть нужный функционал в существующий код. Но вот она засада — опыта работы с миллионами строк чужого кода у него просто нет, и задача за 2 дня все равно не будет решена. И пройдет много времени, прежде чем он перестанет вздрагивать от вида тонн чужого кода, как правило далеко не лучшего качества.

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

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

Здравствуйте, Cyberax, Вы писали:

C>>>...Количество переход в качество
_FR>>Что под этим понимается? Количество чего? Я всегда эти слова понимал так, что количество вложенного труда переходит в качество результата, но не могу эту трактовку применить к вашим примерам: труд, затраченный на написанием миллионов строк на качестве, в хорошем смысле этого слова, не скажется.
C>Нет, я имею в виду, что при большом количестве поддерживаемого кода, нужны уже качественно другие навыки, чем при поддержке кода в 30000 строк.

Да, с этим соглашусь, но ни где раньше не видел употребление обсуждаемой фразы в подобном контексте. Это не переход, а требование. И (если специально этому вопросу не уделять много внимания), зачастую (насколько видел и слышал я), переход, ведущий к снижению качества отдельных частей ради поддержания общего качества на существующем уровне. Пример — есть какой-то кусок (у многих такое есть :о)), который сделан ... не хорошо, скажем так. Все про это знают, но возможности переделать не находят. При необходимости как-то затронуть этот кусок приходится делать прикрутку не на столько хорошей и удобной в будущем, как могло бы быть. Но иначе нарушится и "общая картина", общий стиль. В результате количество кода разбухает, качество остаётся на одном уровне => проблем больше, так как стоимость повышения качества растёт или, что более точно, стремится к бесконечности.

Здравствуйте, _FRED_, Вы писали:

УЁ>>Вменяемый менеджмент — это тот, который будет пастись вокруг горе-программиста 24 часа в сутки и смотреть что он там на самом деле делает?
_FR>Нет, это не правильное понятие менеджмента.

Вы не заметили что это был вопрос, а не утверждение? Да к тому же с сарказмом?

УЁ>>Пообещает результат за 2 дня, менеджер подумает и скажет хорошо.
_FR>С каких это пор (если говорить не о ком-то конкретно)? От том, как можно или не нужно поступать, вовсе не обязательно знать из личной опыта: достаточно общего мнения.

Вы меня извините, но я не понимаю о чем вы пишите. Вы перечитываете свои сообщения перед отправкой?

УЁ>>Второй сценарий — разработчик таки поймет, что переделать все невозможно, надо воткнуть нужный функционал в существующий код. Но вот она засада — опыта работы с миллионами строк чужого кода у него просто нет, и задача за 2 дня все равно не будет решена. И пройдет много времени, прежде чем он перестанет вздрагивать от вида тонн чужого кода, как правило далеко не лучшего качества.

_FR>Коментировать ваши фантазии или страхи (ведь мы, повторюсь, говорим не конкретно о ком-то, а вообще о разработчике, не учавствовавшем в проекте на несколько миллионов строк) нет никакого желания.

Все понятно, вам кажется это фантазией, потому что вы с этим еще не встречались. Ну тогда все еще впереди.

_FR>По моему предвзятому мнению, мне удалось высказать свою точку зрения, которая заключается в том, что не количество строк и человеко-лет проекта делает разработчика ценным. Даже хоть сколько-нибудь ценным. Качество и умение являются определяющими факторами и если в какой-либо компании на собеседовании говорят или требуют, в первую очередь, не этого, идти туда не стоит, потому что вынести от туда можно лишь пресловутый, поставленный у меня по сомнение, опыт.

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

_FR>Вы прекрасно описали, что там ждёт. И кому такого надо? А зачем?

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