Добрый день!

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

Уже делал несколько попыток, но то одно не так, то другое не эдак. Т.е. программка-то работает корректно, но товарищ "придирается" буквально к каждой строчке кода, всюду навязывая своё виденье. Видимо, до тех пор, пока код не будет на 100% соответствовать тому, как он сам бы его написал, сдать не получится .

(Для пояснения ситуации — сам я не совсем нуб. Общий стаж работы прогером у меня, думаю, лет на 5-10, как минимум, побольше, чем у начальника (он помоложе будет). Только с .NET я года с 2004-го работаю, до этого были и C++, и Java, и прочие "радости", не к ночи будущие помянуты
Конкретно в данной предметной области (и в данной конторе) у начальника стаж, конечно, больше, но и у меня не совсем 0 — я только что год отработал в конторе, занимающейся заказной разработкой биржевого софта. Т.е. как-то маловероятно, что я совсем уж "лажу" написал, которую на 100% переделать надо. Во всяком случае, ни в той конторе, ни во всех остальных, где я до этого работал, никогда подобных проблем не было).

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

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

kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

Подожди еще немного пока выгонят с позором

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

kkh>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

Мне кажется, что это не только к финансовым канторам относиться а и к тем, которые к своему коду небезразлично относятся.

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

Начинающие ребята сначала читают код, потом начинают потихоньку писать, и в это время тим лиды их начинают пинать. Таким образом разношерстных новичков подтачивают под паттерны которые применяются в продакшн коде, что-бы быть систематичным и последавательным с типичными задачами и правильно себя вести с нетипичными, которые требуют R and D.

Я в принципе работаю по такому же принципу, только в более маленьких масштабах С тимом в 3 человека.

Так по тихоньку тим и скалачиваеться. Когда один делаешь проект, тогда конечно все по другому.

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

kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?
на 90% зависит от вас и на 10% от руководства. у вас даже больше возможностей по нагибанию руководства.

сценарий N1:
руководство вас предоставляет ПЛАН на ста листах, где расписано все и вся. руководство целый месяц убило на этот план и только собралось в гагры, как вы его жестоко обламываете. например, некоторые компоненты системы требуют апдейтов. где они в этом плане? где прокси сервер и вся инфраструктура? где авторизация? где защита, а вот ведь блин "обновят" так, что мало не покажется.

сценарий N2:
руководство курит ПЛАН, а вам вдувает паровоз. типа ты делай, а я скажу, что не так и как это поправить. через пять секунд вы докладываете руководству, что написали типа int i, j; это нормально или как? не, ну вы можете int row, column; написать. только это все равно неправильно, поскольку тут по смыслу size_t больше подходит, но один хрен работать будет, поскольку у нас квадрат 100x100.

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


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

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

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

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

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

PP>Мне кажется, что это не только к финансовым канторам относиться а и к тем, которые к своему коду небезразлично относятся.

PP>Возможно я несу чуш, но я слышал что в больших канторах тип Г,М,А, к продакшн коду подпускают только через пол года а то и через весь год.

PP>Начинающие ребята сначала читают код, потом начинают потихоньку писать, и в это время тим лиды их начинают пинать. Таким образом разношерстных новичков подтачивают под паттерны которые применяются в продакшн коде, что-бы быть систематичным и последавательным с типичными задачами и правильно себя вести с нетипичными, которые требуют R and D.

PP>Я в принципе работаю по такому же принципу, только в более маленьких масштабах С тимом в 3 человека.

Я бы не сказал, что контора большая. Точнее, это небольшой бизнес-юнит (40 чел) большой конторы. Сначала у них был один прогер, потом, года 1.5 — 2 назад, взяли ещё одного (собственно, моего начальника). Сейчас, соответственно, под прогера №1 взяли двух людей, под моего начальника — меня

Есть подозрение, что это у него первый опыт руководства. Я одно время руководил отделом разработки, имея 4-5 прогеров в подчинении (в небольшом стартапе совсем в другой предметной области), и начинал как раз с такого же — сначала жёстко контролировал народ, чтобы делали ровно так, как я вижу. Это приводило либо к "трудовой миграции", либо к тому, что просто я писал весь код за них. Потом через какое-то время я решил контролировать народ по "граничным условиям" — код должен решать задачу + соответствовать некому заранее написанному набору требований (стандартов кодинга) + не иметь явных "дыр", которые реально создают проблемы. Это существенно упростило всем жизнь.

Т.е. тут 2 варианта:

1) это просто мне "воздаяние" за то время, когда я сам началил , и чувак аналогично мне научиться "на кошках", и станет более адекватным со временем. Тогда есть смысл сделать так, чтобы он на какой-то другой "кошке" поучился

2) или чувак, хоть здесь и не очень долго работал (и, видимо, не началил), пришёл откуда-то, где его научили так работать, и это общие практики.
Тогда надо терпеть (Эх, тяжело опять "пехотой" становиться, возраст уже не тот . Но чего не сделаешь ради "роботов"

В общем, посмотрю ещё на ответы, каких больше будет — в любом случае, спасибо большое!

PP>Так по тихоньку тим и скалачиваеться. Когда один делаешь проект, тогда конечно все по другому.

Здравствуйте, мыщъх, Вы писали:

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

kkh>>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?
М>на 90% зависит от вас и на 10% от руководства. у вас даже больше возможностей по нагибанию руководства.

М>сценарий N1:
М>руководство вас предоставляет ПЛАН на ста листах, где расписано все и вся. руководство целый месяц убило на этот план и только собралось в гагры, как вы его жестоко обламываете. например, некоторые компоненты системы требуют апдейтов. где они в этом плане? где прокси сервер и вся инфраструктура? где авторизация? где защита, а вот ведь блин "обновят" так, что мало не покажется.

М>сценарий N2:
М>руководство курит ПЛАН, а вам вдувает паровоз. типа ты делай, а я скажу, что не так и как это поправить. через пять секунд вы докладываете руководству, что написали типа int i, j; это нормально или как? не, ну вы можете int row, column; написать. только это все равно неправильно, поскольку тут по смыслу size_t больше подходит, но один хрен работать будет, поскольку у нас квадрат 100x100.

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

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

М>вы на окладе сидите? вот и славненько. главное, не нервничать, а выполнять ПЛАН руководства по мере его поступления. как вариант, можно научиться отстаивать свое видение и убеждать других в своей правоте, но в этом случае на вас могут повесить всех собак, даже если косяк совсем в другом месте и не по вашей вине.

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

М>на худой конец можно вспомнить слова покойного о том, что мы нанимаем светлые умы не для того, чтобы говорить что им делать. мы их нанимаем и платим, чтобы они говорили, что делать нам. покойный со своим другом (здравствующим до сих пор) утаили от народа только одну несущественную на первый взгляд деталь. когда лебедь, рак и щука трахались с возом -- СЖ и БГ уединялись в безлюдном месте, читая отчеты своих инженеров и решая кого казнить, а кому выделить ресурсов.

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

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

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

+10005000

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


kkh>Уже делал несколько попыток, но то одно не так, то другое не эдак. Т.е. программка-то работает корректно, но товарищ "придирается" буквально к каждой строчке кода, всюду навязывая своё виденье. Видимо, до тех пор, пока код не будет на 100% соответствовать тому, как он сам бы его написал, сдать не получится .

Это называется code review. И если он придирается к каждой строчке кода, то дело действительно плохо. Хотя, скорее всего, это такой КМБ, цель которого — донести до новичка основные принятые в компании подходы и обозначить границы no-go зоны.

kkh>(Для пояснения ситуации — сам я не совсем нуб. Общий стаж работы прогером у меня, думаю, лет на 5-10, как минимум, побольше, чем у начальника (он помоложе будет). Только с .NET я года с 2004-го работаю, до этого были и C++, и Java, и прочие "радости", не к ночи будущие помянуты

Судя по вышенаписанному, есть риск, что твои 10 лет опыта — это 1 год, повторенный 10 раз.

kkh>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

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

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

kkh>Есть подозрение, что это у него первый опыт руководства. Я одно время руководил отделом разработки, имея 4-5 прогеров в подчинении (в небольшом стартапе совсем в другой предметной области), и начинал как раз с такого же — сначала жёстко контролировал народ, чтобы делали ровно так, как я вижу. Это приводило либо к "трудовой миграции", либо к тому, что просто я писал весь код за них. Потом через какое-то время я решил контролировать народ по "граничным условиям" — код должен решать задачу + соответствовать некому заранее написанному набору требований (стандартов кодинга) + не иметь явных "дыр", которые реально создают проблемы. Это существенно упростило всем жизнь.

У него точно первый опыт руководства. Все тестовые задания даются во время собеседований. Если уже взяли, то человека надо знакомить с тем что уже есть и почему это есть так. В таких случаях очень хорошо работает pair programming. Опытный клавой рулит PM, начинающий AM. Через недельку упражнений результат будет у всех на лице, в виде счастливой улыбки или выбитых зубов. Не переживайте, чаще происходит первое

pair programming хорош тем, что тот кто рулит клавой, тот только работает клавиатурой а второй думает и предлагает идеи. Это позволяет первому не только не заснуть, но и спрашивать, почему это происходит именно так. Завязываеться рассуждения и находиться истина. Потом наоборот. Это очень помогоает избавиться от сюрпризов и не приятных разворотов типа: Давай Переделывай!

Если есть желание и возможность, попробуйте, рекомендую. Бос если в вас заинтересован может согласиться. Если он тупой и будет смеяться, то грош цена отношениям типа: я начальник — ты дурак. Я бы продолжил искать работу.

Здесь, в ЮК, если человек развернулся во время испытательного срока — это вообще никак не влияет на работника, абсолюно. Могут поинтересоваться конечно, просто нужно причину завернуть в красивый, адекватный пакетик с бантиком и больше об этом никто не будет переспрашивать. Более того это даже поможет не попасть к таким-же.

Здравствуйте, kkh, Вы писали:
kkh>(Для пояснения ситуации — сам я не совсем нуб. Общий стаж работы прогером у меня, думаю, лет на 5-10, как минимум, побольше, чем у начальника (он помоложе будет). Только с .NET я года с 2004-го работаю, до этого были и C++, и Java, и прочие "радости", не к ночи будущие помянуты
kkh>Конкретно в данной предметной области (и в данной конторе) у начальника стаж, конечно, больше, но и у меня не совсем 0 — я только что год отработал в конторе, занимающейся заказной разработкой биржевого софта. Т.е. как-то маловероятно, что я совсем уж "лажу" написал, которую на 100% переделать надо. Во всяком случае, ни в той конторе, ни во всех остальных, где я до этого работал, никогда подобных проблем не было).

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

__>в принципе, опытный программист, который пишет хреновый код это не редкость. особенно если сто лет работал в одной компании и слаще редьки ничего не ел. тут важна аргументация. можно примеры привести кода, который плохой по мнению начальника?

Полностью согласен но у меня сложилось впечатление что там какой-нибудь 25-летний начальник что тоже ничего хорошего не предвещает. Если ТС в Москве, то не исключенно что начальник считает что все должны программировать как он если код даже и не плох но хоть как-то отличается от его стиля.

В общем мало данных.

L>Это называется code review. И если он придирается к каждой строчке кода, то дело действительно плохо. Хотя, скорее всего, это такой КМБ, цель которого — донести до новичка основные принятые в компании подходы и обозначить границы no-go зоны.

По-моему слишком мало данных. У меня, например, сложилось впечатление что начальнику лет 25 и он может считать что все должны программировать так как он программирует даже если код и не плох.

kkh>>(Для пояснения ситуации — сам я не совсем нуб. Общий стаж работы прогером у меня, думаю, лет на 5-10, как минимум, побольше, чем у начальника (он помоложе будет). Только с .NET я года с 2004-го работаю, до этого были и C++, и Java, и прочие "радости", не к ночи будущие помянуты

L>Судя по вышенаписанному, есть риск, что твои 10 лет опыта — это 1 год, повторенный 10 раз.

kkh>>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

L>Судя по всему, ты впервые попал в компанию, серьезно относящуюся к инвестициям в собственный код. Прочитай code conventions документ, который там, хоть и формальный, но должен быть, и начинай знакомиться с code base, чтобы быть в курсе принятых в компании практик.

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

kkh>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

Думаю это просто конкретный чувак. Ты слишком мало данных дал.

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

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

kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

Не надо торопиться. И, главное, не надо нервничать — ваш заработок не зависит от потраченных нервов.

Ситуация обсусловлена комбинацией факторов:
1. Вы — свежий член команды. За вами будут более пристально наблюдать. Так везде и всюду, независимо от финансовости компании.
2. Ваш руководитель впервые в жизни пробует руководство. Все начинают с того, что хотят знать и контролировать всё. Что уж там, сам таким был.
3. Вы старше руководителя. Ему требуется самоутвердиться и почуствовать, что именно он вами руководит, а не наоборот. Постарайтесь проявить максимальное содействие, только не вздумайте сорваться в формальное издевательство. В конце концов, помогите человеку почувствовать, что его руководство принимают, и не в штыки, а — как руководство к действию.

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

PS: но по моим ощущениям, финансы все равно нервотрёпка. Своего рода компенсация за то, что деньги берутся из ниоткуда.

Здравствуйте, Олег К., Вы писали:

L>>Это называется code review. И если он придирается к каждой строчке кода, то дело действительно плохо. Хотя, скорее всего, это такой КМБ, цель которого — донести до новичка основные принятые в компании подходы и обозначить границы no-go зоны.

ОК>По-моему слишком мало данных. У меня, например, сложилось впечатление что начальнику лет 25 и он может считать что все должны программировать так как он программирует даже если код и не плох.

Вот именно, что мало данных. Может, начальник чудит, а может, это ТС конструктивную критику как личное оскорбление воспринимает.

L>>Судя по всему, ты впервые попал в компанию, серьезно относящуюся к инвестициям в собственный код. Прочитай code conventions документ, который там, хоть и формальный, но должен быть, и начинай знакомиться с code base, чтобы быть в курсе принятых в компании практик.

ОК>Да их там несколько человек всего. Сомневаюсь что у них есть кодинг конвеншнз. Скорее всего начальник просто неопытен и требует от своего единственного подчиненного писать в таком же стиле как пишет сам.

Размер компани ортогонален процессу. Более того, сегодня больше шансов нарваться на фашизм, диктатуру и инквизицию по отношении к стилю кодирования как раз в небольшой компании, нежели в "крупной респектабельной корпорации"

SD>PS: но по моим ощущениям, финансы все равно нервотрёпка. Своего рода компенсация за то, что деньги берутся из ниоткуда.

Ох как верно!

ОК>>По-моему слишком мало данных. У меня, например, сложилось впечатление что начальнику лет 25 и он может считать что все должны программировать так как он программирует даже если код и не плох.

L>Вот именно, что мало данных. Может, начальник чудит, а может, это ТС конструктивную критику как личное оскорбление воспринимает.

Так об этом и речь.

On 15.01.2013 21:38, kkh wrote:

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

On 16.01.2013 0:41, landerhigh wrote:

> Судя по всему, ты впервые попал в компанию, серьезно относящуюся к
> инвестициям в собственный код.
Судя по описанному он попал к типичному недоманагеру.

On 16.01.2013 3:21, SkyDance wrote:

> 2. Ваш руководитель впервые в жизни пробует руководство. Все начинают с
> того, что хотят знать и контролировать всё. Что уж там, сам таким был.
Не все, я никогда таким не страдал.

> 3. Вы старше руководителя. Ему требуется самоутвердиться и почуствовать,
> что именно он вами руководит, а не наоборот.
Еще одна классическая характеристика недоманагера.

Итого, 2 пункта из 3 о том, что манагер возможно абсолютно бестолков,
как менеджер.

On 16.01.2013 4:25, Олег К. wrote:

> SD>PS: но по моим ощущениям, финансы все равно нервотрёпка. Своего рода
> компенсация за то, что деньги берутся из ниоткуда.
>
> Ох как верно!
Просто эти компании находятся ближе к деньгам и конкуренция жестче между
этими компаниями. Отсюда и нервотрепка — 20 крокодилов на одну антилопу,
хоть и толстую.

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

kkh>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

Нет в finance district нет такой ерунды (просто потому что это непродуктивно). Просто на вашем пути попался идиот. Мой совет — реализовать все максимально корректно (чтобы все работало) и аргументировать свой код.

Здравствуйте, Олег К., Вы писали:

ОК>По-моему слишком мало данных. У меня, например, сложилось впечатление что начальнику лет 25 и он может считать что все должны программировать так как он программирует даже если код и не плох.
В этом, как ни странно, тоже есть смысл. Если все пишут в одном стиле, то это очень упрощает командную разработку.

On 16.01.2013 13:27, nightcode wrote:

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

V>Просто нужно архитектуру продукта нормальной делать, чтобы разные стили
V>в разных местах не мешали.
Пора выйти из страны эльфов в реальный мир.

On 16.01.2013 13:40, dr. Acula wrote:

> V>Просто нужно архитектуру продукта нормальной делать, чтобы разные стили
> V>в разных местах не мешали.
> Пора выйти из страны эльфов в реальный мир.
Во уже нормальная архитектура приложения стала считаться эльфизмом.
Дожились. Интересно сколько лет осталось до того, когда программа,
которая падает не сразу после запуска, станет считаться нормальной, а
которая сможет работать несколько лет в режиме 365/7 будет считаться
эльфизмом?
Сколько приходилось делать архитектуру программных продуктов ни разу не
мешали разные стили написания кода. Есть интерфейсы, через них все
общается, в внутри своего модуля, каждый пишет в своем стиле, главное,
чтобы его код выполнял все требования.

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

P.S. нет, не в любой банковской конторе так. бывает и наоборот

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

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

R>всегда дичайше радует столкновение типичного хабраайтишника с суровой реальностью

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

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

V>общается, в внутри своего модуля, каждый пишет в своем стиле, главное,
V>чтобы его код выполнял все требования.

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

On 16.01.2013 16:12, pavel783 wrote:

> для финансовой программы этого явно не достаточно, в контестке web
> запросов столько security дыр, что моделировать потенциальные атаки и
> делать антидоты к ним можно бесконечно, пока проблема не сведется к
> защите encrypt ключа.
Это называется смешались в кучу кони, люди...

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

V>Просто нужно архитектуру продукта нормальной делать, чтобы разные стили
V>в разных местах не мешали.
А легко править чужой код тоже "нормальная архитектура" позволяет ?

On 16.01.2013 16:38, nightcode wrote:

> А легко править чужой код тоже "нормальная архитектура" позволяет ?
Достаточно легко, особенно если этот код покрыт юнит тестами в ключевых
местах. Не, я понимаю, если бы я институт только вчера закончил и
никогда саппортом сратого кода не занимался, я бы может по молодости и
согласился бы с тобой.
Вот только к архитектуре это отношения не имеет.

Внизу правильно про руководителя написали. Чудит скорее всего чувак.

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

А на другой работе одного вчерашнего студента лет 23-24 поставили над нами тим-лидом.
Так вот он, помню, сидел прямо со мной (типа, парное программирование) и смотрел за каждой строчкой
Мол, так не пиши, да эдак не пиши, а это перепиши
Примеры были похожи на те, как мыщъх привёл: http://www.rsdn.ru/forum/job/5033202.1

Автор: мыщъх
Дата: 15.01.13

Потом проект закрыли, всех разогнали по-маленьку, а студент в манагеры пошёл в другую контору, ибо его любимой фразой было: "Чтобы программировать? Да н икогда!"

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

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

On 16.01.2013 17:32, nightcode wrote:

> Точно, когда каждый в команде пишет как хочет, то такой код легко
> саппортить
Никаких проблем. Главное чтобы код делал то что должен, не падал и не
тек и ключевые места были покрыты юнит-тестами.

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

L>Это называется code review. И если он придирается к каждой строчке кода, то дело действительно плохо. Хотя, скорее всего, это такой КМБ, цель которого — донести до новичка основные принятые в компании подходы и обозначить границы no-go зоны.

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

L>Судя по вышенаписанному, есть риск, что твои 10 лет опыта — это 1 год, повторенный 10 раз.

Насчёт "год повторенный 10 раз" — я бы не сказал... Я компаний 5-6 сменил за это время, из них всего 1 год сидел в конторе, которая для себя софт делала. Все остальные — заказная разработка, в самых разных предметных областях. И веб, и не веб. Одних языков программирования, если вспоминать, штук 7 "попробовал" (не считая всяких жскриптов и иже с ним). Попробовал — в том смысле, что не книжку по ним прочёл и хелло ворлд написал, а проекты реальные за душой имеются

L>Судя по всему, ты впервые попал в компанию, серьезно относящуюся к инвестициям в собственный код. Прочитай code conventions документ, который там, хоть и формальный, но должен быть, и начинай знакомиться с code base, чтобы быть в курсе принятых в компании практик.

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

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

M>ИМХО, топикстартер ни разу не похож на хабраайтишника. Хабраайтишники дружелюбные и открытые к критике, а он больше похож на старпера молоды-вы-еще-учить-меня-жизни.

не, я не хабрайтишник ни разу, скорее, старпёр (хотя 35 пока не стукнуло, но щас народ прогит молодой, так что таки да, увы)

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

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

M>А на другой работе одного вчерашнего студента лет 23-24 поставили над нами тим-лидом.
M>Так вот он, помню, сидел прямо со мной (типа, парное программирование) и смотрел за каждой строчкой
M>Мол, так не пиши, да эдак не пиши, а это перепиши
M>Примеры были похожи на те, как мыщъх привёл: http://www.rsdn.ru/forum/job/5033202.1

Автор: мыщъх
Дата: 15.01.13

M>Потом проект закрыли, всех разогнали по-маленьку, а студент в манагеры пошёл в другую контору, ибо его любимой фразой было: "Чтобы программировать? Да н икогда!"

блин, вот очень похожая ситуация была!!

нас с одним коллегой, в перерыве между внешними проектами, запихнули в один внутренний (чтоб не лоботрясничали). Опыт у меня был на тот момент небольшой, года 3, у коллеги побольше, но уже были у нас какие-то выполненные проекты и даже, возможно, небольшой респект начальства (хотя, может, это просто тогда так казалось ).
А поставили над нами пм-ом "студента", который только что в контору пришёл, как стал пм-ом, неведомо. Так этот деятель по ходу разработки н раз схему данных кардинально менял (в итоге, после н-1 почти кардинальных замен всея концепции оказалось, что версия номер н процентов на 90 совпадает с версией номер 1 . В итоге сроки, естественно, прокакали, господин пм куда-то "слился", а нам с коллегой нормальные внешние проекты нашли, с адекватными людьми. А за этот даже и ругать не стали, кажется — начальство фишку просекло

я помню, тот вундеркинд ещё на роликах любил по офису перемещаться — мы, случаем, не про один и тот же эпизод?

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

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

DA>Пора выйти из страны эльфов в реальный мир.

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

Пример — вы когда опенсорсные компоненты пользуете в своём коде (с доработками), вы их что, неужели все переписываете, чтоб под стандарты подошли?

V>Не все, я никогда таким не страдал.

Вы-то можете что угодно утверждать. Объективная реальность может быть другой.

V>Еще одна классическая характеристика недоманагера.

Все менеджеры с чего-то начинали. "Недоманагером" вы его сможете назвать лет через 5, если он всё так же будет себя вести.

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

V>Никаких проблем. Главное чтобы код делал то что должен, не падал и не
V>тек и ключевые места были покрыты юнит-тестами.

Давай конкретно ? Вот есть код который ты написал, в коде есть косяк, ты уволился. Вопрос — легко ли найти ошибку в твоем коде если никаких правил, принципов и общих подходов ты не соблюдал, а писал просто как тебе удобно ?

ЗЫ
я работал в конторе где примерно так и было, увольнение программиста там было катастрофой и его код, впоследствии, переписывался другими программистами.

V>>Никаких проблем. Главное чтобы код делал то что должен, не падал и не
V>>тек и ключевые места были покрыты юнит-тестами.

N>Давай конкретно ? Вот есть код который ты написал, в коде есть косяк, ты уволился. Вопрос — легко ли найти ошибку в твоем коде если никаких правил, принципов и общих подходов ты не соблюдал, а писал просто как тебе удобно ?

Понятный и поддерживаемый код можно писать разными способами и стилями. Думаем мы-то все по-разному.

N>ЗЫ
N>я работал в конторе где примерно так и было, увольнение программиста там было катастрофой и его код, впоследствии, переписывался другими программистами.

Код коду рознь. Я работал в компаниях в которых код тянется с 80-х и ничего. Есть код за который авторов нужно бить бейсбольной битой, есть код который я понимаю и могу править хотя и стили разные и отличаются от моего собственного. И ничего, живет код.

V>>Никаких проблем. Главное чтобы код делал то что должен, не падал и не
V>>тек и ключевые места были покрыты юнит-тестами.

N>Давай конкретно ? Вот есть код который ты написал, в коде есть косяк, ты уволился. Вопрос — легко ли найти ошибку в твоем коде если никаких правил, принципов и общих подходов ты не соблюдал, а писал просто как тебе удобно ?

Если человек умеет думать и пишет понятно, то неважно в каком стиле он пишет. Разобраться будет легко.

Если код писал какой-нибудь "программахер" которого вообще нельзя допускать к компьютерам, то это уже другой вопрос.

N>ЗЫ
N>я работал в конторе где примерно так и было, увольнение программиста там было катастрофой и его код, впоследствии, переписывался другими программистами.

Здравствуйте, Олег К., Вы писали:

ОК>Если человек умеет думать и пишет понятно, то неважно в каком стиле он пишет. Разобраться будет легко.
А если нет ? Обычная ситуация, кстати.

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

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

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

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

V>On 16.01.2013 17:32, nightcode wrote:

>> Точно, когда каждый в команде пишет как хочет, то такой код легко
>> саппортить
V>Никаких проблем. Главное чтобы код делал то что должен, не падал и не
V>тек и ключевые места были покрыты юнит-тестами.

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

On 16.01.2013 23:06, kkh wrote:

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

On 17.01.2013 0:54, SkyDance wrote:

> Все менеджеры с чего-то начинали. "Недоманагером" вы его сможете назвать
> лет через 5, если он всё так же будет себя вести.
Я знал многих менеджеров, которые сразу от начала менеджерской работы
таким не страдали. А вот те, кто страдали, обычно такими же придурками и
дальше оставались — называется такое "эффективный менеджер".

On 17.01.2013 1:50, nightcode wrote:

> Давай конкретно ? Вот есть код который ты написал, в коде есть косяк, ты
> уволился. Вопрос — легко ли найти ошибку в твоем коде если никаких
> правил, принципов и общих подходов ты не соблюдал, а писал просто как
> тебе удобно ?
Не надо свои неумения распространять на всех вокруг. Обычно у
большинства программистов со временем вырабатываются свои правила,
принципы и подходы, которые почему-то всегда близки к тому, что написано
в общеизветсных книжках. Но, еще раз напомню, люди не роботы и эти
правила у каждого немного отличаются, особенно стилистически. Так вот
поработав уже много лет и со своим и с чужим кодом, я убедился
полностью, что воспринять стилистику написания кода другого человека
достаточно легко.

On 17.01.2013 9:13, nightcode wrote:

> А если нет ? Обычная ситуация, кстати.
Нет, не обычная. Это ситуация типична для контор, которые экономят на
программистах и набирают исключитеьлно студентов, которых увольняют
через год.

On 17.01.2013 10:14, michael_isu wrote:

> Когда код рулит баблом в $млн, то в случае ошибок в модуле какого-то
> чувака тебя как тим-лида повешают за йайтса.
Не надоело еще в эти сказки верить?

On 17.01.2013 10:17, michael_isu wrote:

> Ты это потом боссу расскажешь, когда в чьем-то модуле произойдет дедлок
> в бою, и позиции вдруг не закроются когда нужно.
Хорошая характеристика вашей работы. Как оное указалось у клиента?
Телепатию включить и рассказать или не надо? Сам додумаешься до косяков
в вашей работе?
Хотя, чем быстрее таким перестанут заказы давать, тем лучше.

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

V>On 17.01.2013 1:50, nightcode wrote:

>> Давай конкретно ? Вот есть код который ты написал, в коде есть косяк, ты
>> уволился. Вопрос — легко ли найти ошибку в твоем коде если никаких
>> правил, принципов и общих подходов ты не соблюдал, а писал просто как
>> тебе удобно ?

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

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

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

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

On 17.01.2013 11:42, nightcode wrote:

> Ну не хочешь, не отвечай
"никаких правил, принципов и общих подходов ты не соблюдал, а писал
просто как тебе удобно" — это же ты про себя написал? Странно, что при
таком подходе вообще что-то работает?

On 17.01.2013 11:49, nightcode wrote:

> Нууу, началось. Ты то, понятное дело, супер-пупер программист, всегда
> пишешь только качественный код и критиковать его может только
> закомплексованный идиот начальник.
> Да, раздутое самомнение у многих программистов это тоже распространенная
> проблема. И неспособность воспринимать критику их кода тоже.
Это твои фантазии про супер пупер. Проекция?

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

V>Это твои фантазии про супер пупер. Проекция?
это вывод из твоей фразы:

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

корявый, непонятный код пишут отнюдь не только студенты

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

V>On 17.01.2013 11:42, nightcode wrote:

>> Ну не хочешь, не отвечай
V>"никаких правил, принципов и общих подходов ты не соблюдал, а писал
V>просто как тебе удобно" — это же ты про себя написал? Странно, что при
V>таком подходе вообще что-то работает?

ok, можешь продолжать кривляться дальше

On 17.01.2013 13:30, nightcode wrote:

> корявый, непонятный код пишут отнюдь не только студенты
Да, но для описанных выше контор ситуация типична.

On 17.01.2013 13:30, nightcode wrote:

> ok, можешь продолжать кривляться дальше
Так я так и не понял, ты помнишь или не помнишь что ты писал?

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

V>On 17.01.2013 10:14, michael_isu wrote:

>> Когда код рулит баблом в $млн, то в случае ошибок в модуле какого-то
>> чувака тебя как тим-лида повешают за йайтса.
V>Не надоело еще в эти сказки верить?

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

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

V>On 17.01.2013 10:17, michael_isu wrote:

>> Ты это потом боссу расскажешь, когда в чьем-то модуле произойдет дедлок
>> в бою, и позиции вдруг не закроются когда нужно.
V>Хорошая характеристика вашей работы. Как оное указалось у клиента?
V>Телепатию включить и рассказать или не надо? Сам додумаешься до косяков
V>в вашей работе?
V>Хотя, чем быстрее таким перестанут заказы давать, тем лучше.

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

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

>>> Когда код рулит баблом в $млн, то в случае ошибок в модуле какого-то
>>> чувака тебя как тим-лида повешают за йайтса.
V>>Не надоело еще в эти сказки верить?

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

А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

A>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

Мы всей истории не знаем и не узнаем. Может, тимлида давно уже хотели попросить, но не могли найти повод.

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

A>>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

SD>Мы всей истории не знаем и не узнаем. Может, тимлида давно уже хотели попросить, но не могли найти повод.

Ну так тогда это совсем другая история.

ОК>>Если человек умеет думать и пишет понятно, то неважно в каком стиле он пишет. Разобраться будет легко.
N>А если нет ? Обычная ситуация, кстати.

А если нет, то и кодинг гайдлайнз не помогут.

On 18.01.2013 1:50, michael_isu wrote:

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

On 18.01.2013 1:59, michael_isu wrote:

> Ошибка произошла в
> бою на очень специфичном кейсе, который не отловили при тестировании.
> Чья тут работа плохая?
Вашего начальства работа не просто плохая, а очень плохая. Не работа, а
бой

> В вашем заказном
> формоклепательстве да, там сложно накосячить, чтобы были прямые
> финансовые потери.
Ой, я вспоминаю местные срачи на оную тему, но это было лет 5-7 назад.
Как бы уже все повзрослели. Неужели где-то еще остались такие заповедники?

З.Ы. Кстати, телепалка у тебя совсем не рабочая.

On 18.01.2013 2:18, Abalak wrote:

> А QA куда смотрели, когда принимали код, корторый рулит миллионами?
Какие QA? Он же написал, что работа у них — "бой".

On 18.01.2013 2:40, SkyDance wrote:

> Может, тимлида давно уже хотели
> попросить, но не могли найти повод.
Хочешь сказать, что "слабый" тимлид настолько значимая фигура, что нужно
повод искать, что уволить?

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

V>On 18.01.2013 1:50, michael_isu wrote:

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

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

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

V>On 18.01.2013 1:59, michael_isu wrote:

>> Ошибка произошла в
>> бою на очень специфичном кейсе, который не отловили при тестировании.
>> Чья тут работа плохая?
V>Вашего начальства работа не просто плохая, а очень плохая. Не работа, а
V>бой

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

>> В вашем заказном
>> формоклепательстве да, там сложно накосячить, чтобы были прямые
>> финансовые потери.
V>Ой, я вспоминаю местные срачи на оную тему, но это было лет 5-7 назад.
V>Как бы уже все повзрослели. Неужели где-то еще остались такие заповедники?

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

V>З.Ы. Кстати, телепалка у тебя совсем не рабочая.

аминь.

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

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

>>>> Когда код рулит баблом в $млн, то в случае ошибок в модуле какого-то
>>>> чувака тебя как тим-лида повешают за йайтса.
V>>>Не надоело еще в эти сказки верить?

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

A>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

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

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

V>On 18.01.2013 2:18, Abalak wrote:

>> А QA куда смотрели, когда принимали код, корторый рулит миллионами?
V>Какие QA? Он же написал, что работа у них — "бой".

бой — боевой сервер — продакшн.

On 18.01.2013 10:53, michael_isu wrote:

> Ошибаются те, кто недавно пришел, при этом не имеют экспертных знаний, в
> конкретном случае в .net.
И как это опровергает народную мудрость?
Хотя, что это я, у вас возможно еще и речевки по утрам есть.

On 18.01.2013 11:02, michael_isu wrote:

> Если ты считаешь, что человеку можно поручать писать критичный код и без
> ревью отдавать его на продакшн — что ж, успехов.
Во-первых, я такого не писал, но и ревью здесь не причем.

> Хотя видно, что с
> финансами никогда не работал.
Ну, телепалка у тебя совсем неудышняя, не пользую ее, а то в какой-то
момент проблем не оберешься.

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

З.Ы. Хватит уже сказки рассказывать, все и так уже поняли, что и как у
вас на конторе устроено.

On 18.01.2013 11:22, michael_isu wrote:

> бой — боевой сервер — продакшн.
Знаешь что это мне напоминает: "борьбу за урожай" и "закрома родины".

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

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

A>>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

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

Код должен тестироваться в первую очередь. От отсутсвия код-ревью умерло гораздо меньше проектов, чем от отсутствия тестирования. Так что спрашивать нужно в первую очередь с ПМа, потом с QA как такой код оказался в продакшене.

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

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

kkh>Насчёт "год повторенный 10 раз" — я бы не сказал... Я компаний 5-6 сменил за это время, из них всего 1 год сидел в конторе, которая для себя софт делала. Все остальные — заказная разработка, в самых разных предметных областях. И веб, и не веб. Одних языков программирования, если вспоминать, штук 7 "попробовал" (не считая всяких жскриптов и иже с ним).

А по поддержке хоть какие-нибудь проекты были? Хотя бы на пару месяцев. Или сопровождение своих (разработанных и выпущенных) проектов в течение какого-то времени (полгода примерно)? Лучше, конечно, саппорт кода от более-менее типичной команды (со студентами в ней и т.п.). Подобный саппорт сильно влияет на видение того, "какой была программа". Все-таки часть проблем возникает именно в последствии. И часть из них — при чтении/поддеркже кода другими людьми. Если нет, возможно, замечания руководителя и по теме (хотя если он замечания не аргументирует, это плохо).

Еще вопрос. А что за языки? Некоторые друг от друга очень сильно отличаются, а некоторые очень похожи друг на друга и мало чем отличаются. Точнее, я чуть переформулирую вопрос. А сколько различнхы систем типов было в этих языках? Были ли языки с возможностью метапрограммирования (макросы в compile-time)? Хвастаться языками просто так особого смысла не имеет. Известно же, что "Опытный фортранщик на любом языке может писать как на фортране". То же самое и на других языках встречается. Т.е. одно дело "просто написать работающее приложение", другое — "написать приложение в идеологии языка". В некоторых случаях paradigm shift достаточно большой и переход на новый язык может быть достаточно длительным. Ну а стили радикально отличаются. Например, на функциональных языках (ocaml, haskell) внутри методы очень сильно по внешнему виду отличаются от таких же в императивщине без нормальной поддержки fp (js, java, python, etc...). Кстати, вы зря javascript не считаете. На нем можно делать вещи, которые в C#/Java даже и не снились. Вот в каком-нибудь nemerle можно, но там только макросами (система типов мешает ), а вот в js — вполне в рантайме, обычными функциями.

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

A>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

Может у них QA подчиняются тимлиду, бывает и такое.

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

kkh>В связи с этим, вопрос к знающим людям, кому в финансовых конторах / банках поработать довелось. По вашему опыту — везде такая же ерунда, что покуда несколько лет в данной (или аналогичной) конторе не отработал, за каждой твоей строчкой следить будут, и "учить жизни", как младшего программиста?
kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?

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

15.01.2013 21:20, UA пишет:
> kkh>Или это только мне так "повезло", и имеете смысл валить, пока не поздно?
>
> Подожди еще немного пока выгонят с позором

А на следующий день выдадут твою разработку за свою. Потому не стесняйся
туда запасхалить яиц.

А на вопросы "почему здесь так" отвечай "не помню".

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

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

_>Когда код рулит баблом в $млн, то в случае ошибок в модуле какого-то чувака тебя как тим-лида повешают за йайтса.

Работаю именно в такой конторе. И у всех все на месте. Потому что руководство настроено на конструктив, а не на поиск виновыных.

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

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

M>А по поддержке хоть какие-нибудь проекты были? Хотя бы на пару месяцев. Или сопровождение своих (разработанных и выпущенных) проектов в течение какого-то времени (полгода примерно)? Лучше, конечно, саппорт кода от более-менее типичной команды (со студентами в ней и т.п.). Подобный саппорт сильно влияет на видение того, "какой была программа". Все-таки часть проблем возникает именно в последствии. И часть из них — при чтении/поддеркже кода другими людьми. Если нет, возможно, замечания руководителя и по теме (хотя если он замечания не аргументирует, это плохо).

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

Ну, как-то была переделка кода, написанного не-студентом, но код был плох, объективно говоря (сам автор это потом признавал Честно проваландавшись с этим кодом в течение месяца (веря в то, что первый импульс "всё переписать" приходит к большинству из нас, и он не конструктивен , в итоге я всё-таки его весь выкинул к едреням и написал заново, в чём потом не раскаивался Я бы не стал ввязываться в поддержку некачественного кода, честно говоря. Рынок не настолько плох Если кода немного, переписал бы, как в вышеозначенном случае. Если много, и создаёт проблемы, и не дают переписать — думаю, проще было бы другое место найти

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

Проблема в том, что человек огульно предлагает исключительно свои подходы, игнорируя альтернативные. Это мне показалось плохим симптомом. Человек, который не понимает, что подавляющее большинство задач может быть решено >1 способом (и, следовательно, есть не-0 вероятность, что другой человек выберет способ, отличный от твоего собственного), на мой взгляд, создаёт очень большие проблемы.
Впрочем, со временем (непродолжительным) оказалось, что не всё так плохо — похоже, можно с ним сотрудничать, он способен слушать, слава Богу! Поэтому пока повременю с уходом

M>Еще вопрос. А что за языки? Некоторые друг от друга очень сильно отличаются, а некоторые очень похожи друг на друга и мало чем отличаются. Точнее, я чуть переформулирую вопрос. А сколько различнхы систем типов было в этих языках? Были ли языки с возможностью метапрограммирования (макросы в compile-time)? Хвастаться языками просто так особого смысла не имеет. Известно же, что "Опытный фортранщик на любом языке может писать как на фортране". То же самое и на других языках встречается. Т.е. одно дело "просто написать работающее приложение", другое — "написать приложение в идеологии языка". В некоторых случаях paradigm shift достаточно большой и переход на новый язык может быть достаточно длительным. Ну а стили радикально отличаются. Например, на функциональных языках (ocaml, haskell) внутри методы очень сильно по внешнему виду отличаются от таких же в императивщине без нормальной поддержки fp (js, java, python, etc...). Кстати, вы зря javascript не считаете. На нем можно делать вещи, которые в C#/Java даже и не снились. Вот в каком-нибудь nemerle можно, но там только макросами (система типов мешает ), а вот в js — вполне в рантайме, обычными функциями.

языки — c, c++, smalltalk (от visual age, кажется), java, vbasic (да-да, не vba, а реально vbasic — на нём, оказывается, можно не только макросы для офиса писать, но и dll с exe-шниками , c#. На этих коммерческие проекты были. Ну, те, которые "для себя", или в процессе учёбы, не привожу. smalltalk, напримем, настолько резко отличается по идеологии, что на нём затруднительно было бы писать, как на фортране

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

M>Еще вопрос. А что за языки? Некоторые друг от друга очень сильно отличаются, а некоторые очень похожи друг на друга и мало чем отличаются. Точнее, я чуть переформулирую вопрос. А сколько различнхы систем типов было в этих языках? Были ли языки с возможностью метапрограммирования (макросы в compile-time)? Хвастаться языками просто так особого смысла не имеет. Известно же, что "Опытный фортранщик на любом языке может писать как на фортране". То же самое и на других языках встречается. Т.е. одно дело "просто написать работающее приложение", другое — "написать приложение в идеологии языка". В некоторых случаях paradigm shift достаточно большой и переход на новый язык может быть достаточно длительным. Ну а стили радикально отличаются. Например, на функциональных языках (ocaml, haskell) внутри методы очень сильно по внешнему виду отличаются от таких же в императивщине без нормальной поддержки fp (js, java, python, etc...). Кстати, вы зря javascript не считаете. На нем можно делать вещи, которые в C#/Java даже и не снились. Вот в каком-нибудь nemerle можно, но там только макросами (система типов мешает ), а вот в js — вполне в рантайме, обычными функциями.

да, и Вы меня заинтриговали — а что такого можно делать в js, что нельзя в с#? Реально, интересно.
(Дело в том, что, как мне кажется, в c# можно делать почти всё. Единственное, о чём лично я "горевал" — это отсутствие макросов и работы с темплейтами, как в сях. Дженерики, всё-таки, меньше возможностей имеют, чем старые добрые темплейты, как ни крути. Но зато они и меньше возможностей запутать код дают

V>Хочешь сказать, что "слабый" тимлид настолько значимая фигура, что нужно
V>повод искать, что уволить?

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

On 21.01.2013 0:33, SkyDance wrote:

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

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

_>Прогер сделал ошибку в коде, не учтя некоторых тонких моментов многопоточного кода, а за ним никто не присмотрел. Ошибка произошла в бою на очень специфичном кейсе, который не отловили при тестировании. Чья тут работа плохая? Код не падал и не тек, делал что надо, тесты были. А должности лишат тебя.

Ты смешал ревью кода и обязательный единый стиль написания.

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

kkh>да, и Вы меня заинтриговали — а что такого можно делать в js, что нельзя в с#? Реально, интересно.
kkh>(Дело в том, что, как мне кажется, в c# можно делать почти всё. Единственное, о чём лично я "горевал" — это отсутствие макросов и работы с темплейтами, как в сях. Дженерики, всё-таки, меньше возможностей имеют, чем старые добрые темплейты, как ни крути. Но зато они и меньше возможностей запутать код дают

high-order functions (функции высшего порядка). Ну и "обобщенные" функции высшего порядка (название мое, в литературе вряд ли найдете. Это те функции, которые в системы типов вроде ML'евской и Haskell'ной не укладываются).

На пальцах. high-order functions — это всевозможные map, например. Т.е.

functiion map(fn, array) {
  res = [];
  for (var x in array)
    res.push(fn(x));
  return res;
}
function mapC(fn) {
  return function(arr) {
    return map(fn, arr);
  };
}

Вот map и mapC — функции высшего поярдка. Они принимают функции и иногда возвращают их. mapC — каррированная версия map (ну вот так она выглядит в javascript). Чтобы проникнутся удобством high-order function я бы рекомендовал OCaml или какой-нибудь другой из семейства ML-языков посмотреть. Заодно проникнетесь духом функционального программирования.

Второе, "обобщенные" функции. Это страшные вещи, которые с arguments работают вместо списка параметров. Один из любимых (правда, на firefox-диалекте, на простом js параметры нужно бы из arguments разбирать):

function bindf(fn, ...args) {
  return function(...args1) {
    return fn.apply(null, asArray(args))
  }
}

/// somewhere in a code
button1.addEventListener("click", bindf(navigateToPage, "abc"));
button2.addEventListener("click", bindf(navigateToPage, "def"));
button3.addEventListener("click", bindf(navigateToPage, "quit"));

/// another example
value1 = Reactive.variable(123)
value2 = Reactive.variable(321)
atanv = Reactive.apply(atan2, [value1, value2])
atanstr = str.rapply(null, [atanv])
setText.rapply(null, textField, atanstr)

Оба примера — вариации на реально и часто используемые библиотеки (там не совсем js, правда). Первое — биндинг функции к аргументам. В основном как раз для слушателей используется. Особенно для компонентов UI (для рендеринга какого-нибудь элемента в list, например). Там рендеринг элементов делается обычным методом (без классов) и слушатели удобнее прикручивать так, чем явно расписывать замыкание, вызов метода и т.п.

Второй пример — реактивное программирование. Внутренности не показаны (достаточно приличных пока нет для публики, хотя уже заказывали). Внутри — те же самые fn.apply(...) с обработкой аргументов. в примере atanv и atanstr автоматически изменяют значение при изменении value1 и value2. А еще в случае изменения вызывается setText(textField, atanstr.value()) (textField — не reactive). x.rapply(null, ...) == Reactive.apply(x, ...) — базовый как раз reactive а потом на него биндинг для функций делается. В UI оказалось очень удобно. А заодно оказалось, что в ui много функций, которые не имеют побочных эффектов (pure function) и зависят только от их входных параметров. Поэтому при желании их можно очень даже хорошо тестировать.

У вас в парадигмах примерно 2-2,5 видел (точно разные smalltalk и немного макросов в C++). Вам бы еще FP стоит посмотреть (тот же ML какой-нибудь, потом можно и Haskell).

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

M>high-order functions (функции высшего порядка). Ну и "обобщенные" функции высшего порядка (название мое, в литературе вряд ли найдете. Это те функции, которые в системы типов вроде ML'евской и Haskell'ной не укладываются).

M>На пальцах. high-order functions — это всевозможные map, например. Т.е.
M>

M>functiion map(fn, array) {
M>  res = [];
M>  for (var x in array)
M>    res.push(fn(x));
M>  return res;
M>}
M>function mapC(fn) {
M>  return function(arr) {
M>    return map(fn, arr);
M>  };
M>}
M>

M>Вот map и mapC — функции высшего поярдка. Они принимают функции и иногда возвращают их. mapC — каррированная версия map (ну вот так она выглядит в javascript). Чтобы проникнутся удобством high-order function я бы рекомендовал OCaml или какой-нибудь другой из семейства ML-языков посмотреть. Заодно проникнетесь духом функционального программирования.

а чем делегаты (ну, и пошедшие от них лямбды) в C# хуже? там тоже можно присваивать делегаты переменным, массивы делать из них, методы и делегаты могут принимать и возвращать другие делегаты (тривиальный пример — сортировка, где методу, реализующему алгоритм сортировки, передаём в качестве параметра делегат, осуществляющий, собственно, сравнение элементов), и т.п. И с точки зрения синтаксиса довольно элегантно сделано, на мой взгляд — например, та же концепция "захвата переменных".
Можем, например, практически "куски кода" (которые используют в т.ч. "захваченные" локальные переменные и поля/свойства классов) сложить в очередь и исполнить попозже, или передать кому-то, кто их исполнит из под аккаунта с повышенными (или пониженными) привилегиями, или из другого потока, и т.п. При этом такой делегат часть данных может получать в качестве параметров (т.е. в момент фактического исполнения), а часть, которые захвачены — как бы данные, "замороженные", на момент создания этого делегата (особенно, если к моменту фактического исполнения давно из "скоупа" вышли, где делегат создавался .

M>Второе, "обобщенные" функции. Это страшные вещи, которые с arguments работают вместо списка параметров. Один из любимых (правда, на firefox-диалекте, на простом js параметры нужно бы из arguments разбирать):
M>

M>function bindf(fn, ...args) {
M>  return function(...args1) {
M>    return fn.apply(null, asArray(args))
M>  }
M>}

M>/// somewhere in a code
M>button1.addEventListener("click", bindf(navigateToPage, "abc"));
M>button2.addEventListener("click", bindf(navigateToPage, "def"));
M>button3.addEventListener("click", bindf(navigateToPage, "quit"));

если я правильно понял идею, подобием этого на C# может быть нечто вроде:

void SomeMethod()
{
  button1.Click += (sender, e) => NavigateToPageAndDo( "http://abc", null );
  button2.Click += (sender, e) => NavigateToPageAndDo( "http://def", null );

  var someOtherObject = SomeObjectFactory.CreateSomeOtherObject();
  button3.Click += (sender, e) => NavigateToPageAndDo( "http://ghi", x => someOtherObject.SomeAdditionalAction(x) );
}

void NavigateToPageAndDo( string pageUrl, Action<string> _someAdditionalAction ) {
  
  // ... do navigation to page
  
  if ( _someAdditionalAction != null ) {
    ( new Thread( () => _someAdditionalAction( pageUrl ) ).Start();
  }
}

причём, никто не мешает и более сложно сделать, и передавать не просто Action<...>, а, скажем, Func<string, Action<string>>, который будет в зависимости от того, что ему передано первым параметром, возвращать различные обработчики Action<string>. Ну, и кучу аналогичных прикольных вещей можно делать :-)

M>/// another example
M>value1 = Reactive.variable(123)
M>value2 = Reactive.variable(321)
M>atanv = Reactive.apply(atan2, [value1, value2])
M>atanstr = str.rapply(null, [atanv])
M>setText.rapply(null, textField, atanstr)
M>

M>Оба примера — вариации на реально и часто используемые библиотеки (там не совсем js, правда). Первое — биндинг функции к аргументам. В основном как раз для слушателей используется. Особенно для компонентов UI (для рендеринга какого-нибудь элемента в list, например). Там рендеринг элементов делается обычным методом (без классов) и слушатели удобнее прикручивать так, чем явно расписывать замыкание, вызов метода и т.п.

да и в C# не слишком сложно (если, опять же, я правильно понял суть идеи)

Action Bind(
Action<string, string> action,
string param1,
string param2
) {
return () => action( param1, param2 );
}

в js, может, и удобнее сделано (тут вопрос вкусовых пристрастий, спорить нельзя), зато отлаживать, видимо, сложнее — если где "накосячил", это только в рантайме выяснится. А в C# скомпилиться не даст — для сложного кода это может быть существенной экономией времени.

M>Второй пример — реактивное программирование. Внутренности не показаны (достаточно приличных пока нет для публики, хотя уже заказывали). Внутри — те же самые fn.apply(...) с обработкой аргументов. в примере atanv и atanstr автоматически изменяют значение при изменении value1 и value2. А еще в случае изменения вызывается setText(textField, atanstr.value()) (textField — не reactive). x.rapply(null, ...) == Reactive.apply(x, ...) — базовый как раз reactive а потом на него биндинг для функций делается. В UI оказалось очень удобно. А заодно оказалось, что в ui много функций, которые не имеют побочных эффектов (pure function) и зависят только от их входных параметров. Поэтому при желании их можно очень даже хорошо тестировать.

M>У вас в парадигмах примерно 2-2,5 видел (точно разные smalltalk и немного макросов в C++). Вам бы еще FP стоит посмотреть (тот же ML какой-нибудь, потом можно и Haskell).

спасибо, если возможность будет — обязательно посмотрю

У меня был такой же случай.
Я как бы не совсем нуб, но молод еще и опыта у меня не много, так вот однажды я на испытательном сроке получил задачу.
Задача была на проектирование архитектуры классов.
Ну я делал так, как считал нужным и так же как у вас, ко мне тоже придирались буквально по каждой строчке кода.
Позже, когда я все таки доделал эту задачу, мне сказали о том, что я ее делал слишком долго. На задачу нужно было потратить минут двадцать, а я ее делал 8 часов. Тот кто давал мне эту задачу прямым текстом сказал мне — "Мне не понравилось то, что я проталкивал через тебя СВОЮ реализацию".
Так и хотелось сказать "А нах*я ты это бл*дь делал? НА*УЯ?". Ну конечно я ничего не сказал, хотя был зол дико.
На основе этого сделали, по моему мнению, не верный вывод о моей низкой производительности.
Конечно я пытался оспорить, но ничего не вышло. В итоге я не прошел испытательный срок.
В общем если бы я был на вашем месте, я бы подыскивал другое место.
На всякий случай, мало ли.

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

N>Ну я делал так, как считал нужным и так же как у вас, ко мне тоже придирались буквально по каждой строчке кода.
N>Позже, когда я все таки доделал эту задачу, мне сказали о том, что я ее делал слишком долго. На задачу нужно было потратить минут двадцать, а я ее делал 8 часов. Тот кто давал мне эту задачу прямым текстом сказал мне — "Мне не понравилось то, что я проталкивал через тебя СВОЮ реализацию".

Толсто, конечно, но на фоне этого

Автор: -n1l-
Дата: 18.01.13

выглядит даже забавно.

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

Опять какой-то детский примитивизм и юношеский максимализм. Когда ж вы уже повзрослеете-то.

Нет, это не толсто, это правда.

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

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

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

A>>>А QA куда смотрели, когда принимали код, корторый рулит миллионами? Девелоперы в такой ситуации самые последние с кого нужно спрашивать, если конечно нет умышленного саботажа.

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

A>Код должен тестироваться в первую очередь. От отсутсвия код-ревью умерло гораздо меньше проектов, чем от отсутствия тестирования. Так что спрашивать нужно в первую очередь с ПМа, потом с QA как такой код оказался в продакшене.

Сначала ревью, потом все остальное. Я не раз видел проекты, которые так или иначе рулили баблом (платежные, трейдинговые системы), были оттестированы и работали, но внутри понаписан полный ппц, что даже тим-лид боится там что-то править (автоматизированного тестирования не было или тесты уже не актуальны). И вокруг этого монстра обрастают костыли сбоку ещё.

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

Конечно ревью не панацея, просто уменьшает энтропию.

On 22.01.2013 0:48, SkyDance wrote:

> Опять какой-то детский примитивизм и юношеский максимализм. Когда ж вы
> уже повзрослеете-то.
Да не, протсо ты мир вокруг пытаешься воспринимать сильно сложно, а он
гораздо проще.

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

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

_>>Прогер сделал ошибку в коде, не учтя некоторых тонких моментов многопоточного кода, а за ним никто не присмотрел. Ошибка произошла в бою на очень специфичном кейсе, который не отловили при тестировании. Чья тут работа плохая? Код не падал и не тек, делал что надо, тесты были. А должности лишат тебя.

A>Ты смешал ревью кода и обязательный единый стиль написания.

Я пример привел.

Думаю не нужно объяснять, чем чревато написание кода аля фортран в классах аля *Manager, типа PaymentManager, в котором туева хуча методов и 2-3к строк кода в сумме. Видел немало людей 10+ опыта, которые так пишут. И даже если чел знает как юзать те или иные конструкции, это его никак не оправдает.

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

A>>Код должен тестироваться в первую очередь. От отсутсвия код-ревью умерло гораздо меньше проектов, чем от отсутствия тестирования. Так что спрашивать нужно в первую очередь с ПМа, потом с QA как такой код оказался в продакшене.

_>Сначала ревью, потом все остальное. Я не раз видел проекты, которые так или иначе рулили баблом (платежные, трейдинговые системы), были оттестированы и работали, но внутри понаписан полный ппц, что даже тим-лид боится там что-то править (автоматизированного тестирования не было или тесты уже не актуальны). И вокруг этого монстра обрастают костыли сбоку ещё.

Это уже вопросы к построению процесса разработки. Я комментировал ситуацию с уовльнением лида за пропущенный баг.

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

_>Конечно ревью не панацея, просто уменьшает энтропию.

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

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

kkh>а чем делегаты (ну, и пошедшие от них лямбды) в C# хуже?
Наличием типизации, очевидно. Местами типизация удобна, но далеко не всегда. Кстати, делегаты в C# используют номинативную или структурную типизацию? Т.е. delegate D1(int, String) и delegate D2(int, String) — это один и тот же тип или разные? Если разные, то все совсем печально (high-order на них вообще не написать). Ну а так — функции для делегатов с одним аргументом. с двумя аргументами и т.д. нужно писать.

kkh>там тоже можно присваивать делегаты переменным, ...
Это я все знаю. Это обычная функция как first-class object. Причем у меня вообще не js был а ActionScript3, там как раз функции у объектов получаются нормальными "делегатами" (примерно так же, как в python), а не так, как в js (с дополнительными приседаниями).

kkh>И с точки зрения синтаксиса довольно элегантно сделано, на мой взгляд — например, та же концепция "захвата переменных".
А там грабли лежат . Нижележащий bindf частенько и в циклах используется, где мне нужен как раз "захват значений". Ниже покажу.

kkh>если я правильно понял идею, подобием этого на C# может быть нечто вроде:

Ну да, как-то так. Только вот вы указываете в каждой строчке тип (sender, e). А он у меня не важен. И, к сожалению, местами различается. Все мои личные библиотечные контролы принимают туда функцию без аргументов (угу, даже карринг из fp не спасет). А вот ad-hoc собранные ui-компоненты получают event. В общем, у вас типы нужно писать.

И я бы даже согласился, что по обхему кода даже примерно одинаково получается. (хотя вот += у моих кнопок тоже нет, обработчик только один и идет в конструктор). Но есть еще циклы. А там захват значений ведет себя совсем по-другому.

for (var item in items) {
  var btn = createItemButton(item, Functions.bindf(showItemDetail, [item]))
}

Вот у вас при наивном переводе вы получите багу. Все обработчики будут работать с последним item. И обработчик нужно делать в каждом цикле. Я не помню, может, bindf как раз для циклов у меня появился (чтобы замыкания на значения делать), а потом разошелся по остальному коду. Замыканий "на переменные" мне что-то нигде нужно не было, нужны были именно замыкания на значения (примерно так же, как в "чистом" fp (там только значения) и в java для inner interface).


kkh>да и в C# не слишком сложно (если, опять же, я правильно понял суть идеи)
Идея чуточку сложнее. Есть подписка на изменения.

interface Reactive<T> {
  // listener :: (context) -> void
  public void addChangeListener(listener : Function);
  public void removeChangeListener(listener : Function);
  public T value()
}

delegate R D1<R, T>(T t)
delegate R D2<R, T1, T2>(T1 t1, T2 t2)

Reactive<R> Bind(D1<R, T> f, Reactive<T> value) {
  ReactiveImpl<R> res = new ReactiveImpl<R>(...);
  value.addChangeListener(res.update);
  return res;
}

Reactive<R> Bind(D2<R, T1, T2> f, Reactive<T1> value1, Reactive<T2> value2) {
  ReactiveImpl<R> res = new ReactiveImpl<R>(...);
  value1.addChangeListener(res.update);
  value2.addChangeListener(res.update);
  return res;
}

Reactive<R> Bind(D2<R, T1, T2> f, T1 value1, Reactive<T2> value1) {...}
Reactive<R> Bind(D2<R, T1, T2> f, Reactive<T1> value1, T2 value1) {...}

В общем, там еще на изменения нужно подписываться и слушателей поддерживать. Кстати, я не уверен, что там одной ReactiveImpl<R> хватит. Может, из-за типизации придется их много делать (по числу параметров). Это сильно реализацию усложняет. Можно, конечно генератор написать, но... Его еще тестировать нужно, да и в проекте будет куча однотипных классов. Я такое не люблю.

Еще интереснее становится, когда мы начинаем на базе Reactive делать более сложные вещи. Язык у меня однопоточный (что AS3, что Javascript), поэтому какие-то вещи приходится делать асинхронно. Иногда после асинхронной загрузки нужно запустить другую загрузку (картинки там подгрузить и т.п.). Так вот. Все асинхронные комбинаторы построены на том же Reactive. Там точный тип получается вроде Reactive<ProgressInfo<T>>. В ProgressInfo — информация об ошибке, о состоянии загрузки или данные. По интерфейсу оно очень похоже на реактивное. Реализуется через тот же reactive (там mapping или биндниг). Так что для всех Reactive.Bind нужно будет генерировать подобные им Async.apply(...) методы (с разными сигнатурами типов). В общем, грустно. Особенно учитывая, что в некоторых случаях количество аргументов в Async.apply доходит до 7-8 (может, чуть больше). Из них 4-5 штук — действительно асинхронные, остальные — передача каких-то параметров дальше в метод (это чтобы класс для хранение результатов вручную не изобретать и анонимную функцию для проброса параметров из замыкания не делать)).

kkh>в js, может, и удобнее сделано (тут вопрос вкусовых пристрастий, спорить нельзя), зато отлаживать, видимо, сложнее — если где "накосячил", это только в рантайме выяснится. А в C# скомпилиться не даст — для сложного кода это может быть существенной экономией времени.

У меня был AS3, там частичная типизация есть. На функциях — нет, и это было хорошо. Весь хардкор — только в библиотеках, которые unit-тестами обвешены (ибо regression отлавливать по всему приложению было бы совсем не круто). Все в клиенте даже если и не сойдется с типами, то не сойдется сразу. А я прилжоение запускаю и по всему новому/изменившемуся UI все равно прохожу. Так что если типы не сойдутся, то это будет сразу заметно. Да, не всегда очевидно место ошибки, бывает. Но крупные ошибки бывают редко, при частых запусках (угу, система сборки тоже тюнинговалась в свое время под быструю инкрементальную сборку в процессе разработки) контекст обычно понятен, так что ошибка быстро правится.

Динамическая же типизация требует все-таки другого подхода к разработке, чем статическая типизация. Я с питоном развлекаюсь. К сожалению, на нем можно писать так, как на java . Это мешает. Но вот в процессе переписывания кусков (что-то из библиотек берется, что-то вместо рефакторинга пишется заново) я таки опять прихожу к тому, что прошедший элементарный тестовый прогон говорит о том, что ошибок нет. Учитывая устройство питона (компиляция не нужна), искать ошибки примерно настолько же сложно, насколько сложно было бы их править при обнаружении компилятором. Ну и время экономится на "высокоуровневых" вещах (wrappers, обертки, комбинаторы и т.п.), так что можно сложные случаи разобрать.

Если что, я динамику не защищаю. Она не везде хорошо подходит. Для какой-нибудь алгоритмики я бы все-таки взял что-нибудь более типизированное (ocaml, haskell, scala). Для UI и сложного состояния программы — все-таки динамику. Или что-нибудь "не слишком строго типизированное". В какой-то мере можно scala использовать, например. Через implicit conversion вполне неплохой аналог Reactive получался, но со своими ограничениями. На haskell/ml мне не нравятся аналоги (разные операторы только из-за типизации). Но если хочется еще больше свободы, scala я тоже не взял бы (ну и эстетически не очень она нравится).

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

L>Судя по всему, ты впервые попал в компанию, серьезно относящуюся к инвестициям в собственный код. Прочитай code conventions документ, который там, хоть и формальный, но должен быть, и начинай знакомиться с code base, чтобы быть в курсе принятых в компании практик.

Скорее всего начальник самодур с завышенным ЧСВ.

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


HL>Скорее всего начальник самодур с завышенным ЧСВ.

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

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

N>>Тот кто давал мне эту задачу прямым текстом сказал мне — "Мне не понравилось то, что я проталкивал через тебя СВОЮ реализацию".

L>Толсто

Увы, такое реально бывает, сам сталкивался.
Обычно бывает с начинающими начальниками, которых повысили из программеров. Соответствено, они всегда и везде все сами знают, как лучше, и подчиненным свободы делать, как они считают нужным, не дают. Микроменеджмент в сочетании с "я начальник — ты дурак".

You will always get what you always got
  If you always do  what you always did

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

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

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


_>Прогер сделал ошибку в коде, не учтя некоторых тонких моментов многопоточного кода, а за ним никто не присмотрел. Ошибка произошла в бою на очень специфичном кейсе, который не отловили при тестировании. Чья тут работа плохая? Код не падал и не тек, делал что надо, тесты были. А должности лишат тебя. Скажешь это сказки? В вашем заказном формоклепательстве да, там сложно накосячить, чтобы были прямые финансовые потери. В софте, который рулит баблом, все по другому.

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

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


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

На самом деле единственная ситуация, когда тесты оказываются не только бесполезными, но и вредными и отнимают кучу времени — это когда их пишут из-под палки. Классический случай — пришел манагер и постановил "с сегодняшнего дня пишем тесты, покрытие не менее 95%". Закономерное следствие — куча времени тратится на забивание гвоздей электронными микроскопами.

В нашей практике использование тестов как по ТДД, так и само по себе только ускоряет разработку. Без исключений.

E__>Для всего остального нужны толковые QA.

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

А что касается косяков в многопоточных программах, то никаким тестированием их гарантированно не отловишь.