У меня похожий случай был — был на работе один человек, который очень любил принципы ООП, абстракцию и паттерны. Ладно бы просто любил, но он ещё и применял их везде, где только можно (и где нельзя тоже).
Вообще он переписал часть проекта, а потом уволился, время шло и понадобилось нам дальше развивать систему
— глянули и выпали в осадок: в том месте, где был простой функционал на пяток методов и разобраться в нём любой программист смог бы за полчаса, появились пара классов с функционалом, пара классов-хелперов, абстрактные фабрики и прочее O_o Если под дебагом смотреть по шагам что и куда ходит и наблюдать за кол-стеком, то обнаруживается, что функций 10 вызывается...
Здравствуйте, Davader, Вы писали:
D>Пример второго проекта в студию?
Если честно, то я примера первого не знаю. Во всех проектах, в которых я участвовал надо было хорошо головой думать, а они далеко не всегда были наукоемкие.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Интересно, а как можно использовать готовые парсеры, не представляя, что такое формальные грамматики?
Вообще-то можно. Чтобы заставить готовый прасер разбирать твои выражения и преобразовывать их во что-то нужно знать как указать парсеру какие входные данные и в каком формате являются допустимыми
Например в файле надо написать что-то типа такого:
символ ::= a-z|A-Z|_
цифра ::= 0-9
идентификатор ::= символ[символ|цифра]*
тип_данных ::= integer|string|float
объявление_переменной ::= тип_данных идентификатор;
P.S.
Я не говорю, что разработчик парсера не должен знать формальные грамматики, я говорю, что для использования готового парсера понимание его внутренних механизмов не требуется.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Davader, Вы писали:
D>>Пример второго проекта в студию? O>Если честно, то я примера первого не знаю. Во всех проектах, в которых я участвовал надо было хорошо головой думать, а они далеко не всегда были наукоемкие.
Ну, ясно, что про ручку это была аллегория. Везде надо головой думать. У нас же типа интеллектуальный труд и все такое... Тов. Pzz имел в виду, что есть некое деление на "более умные" и "менее умные" проекты. Я утверждаю, что 95% современных проектов по разработке корпоративных бизнес-систем относятся ко 2-ой группе. К 1-ой может относиться, например, разработка новых алгоритмов распараллеленного сжатия видео-потока или тому подобная хрень. А мы говорим про позицию developer 2-ой группы, насколько это описал тов. mymuss.
Здравствуйте, millevi, Вы писали:
M> — глянули и выпали в осадок: в том месте, где был простой функционал на пяток методов и разобраться в нём любой программист смог бы за полчаса, появились пара классов с функционалом, пара классов-хелперов, абстрактные фабрики и прочее O_o Если под дебагом смотреть по шагам что и куда ходит и наблюдать за кол-стеком, то обнаруживается, что функций 10 вызывается...
Вот тоже был случай — написали "как бы побыстрее", потому что "это просто" и "расширять не понадобится" и "любой программист может разобраться за полчаса". Через год глянули и выпали в осадок — классы с сотней методов, дублирование кода, глобальные функции, дикие зависимости в коде. Никаких юнит-тестов, а если под дебагом смотреть, до функций 100 вызывают друг друга непонятно для чего.
Здравствуйте, Davader, Вы писали:
D>Спрашивать надо только то, чем реально придется заниматься кандидату после приема на работу (он же берется на какой-то конкретный проект, конкретную должность).
Уверены, а давайте я в шутку вам отвечу (конечно я знаю ответы на ваши вопросы, но это не то "чем я реально занимаюсь после приема на работу").
D>Пример вопросов: "Есть ли множественное наследование в С#?",
У меня не было неоходимости во множественном наследовании, поэтому я не знаю есть ли оно. В реальной работе оно мне не нужно.
D>"Где можно хранить состояние в ASP.Net"
Я ни разу не хранил состояние нигде кроме "in process". В реальной работе мне не нужно знать где "можно" его хранить.
D>"Чем отличается Responce.Redirect от Server.Transfer?"
Последний раз делал Server.Transfer еще в 2001 году на ASP. В ASP.NET не делал ни разу. На практике оно мне не надо даже знать про Server.Transfer.
D>"Чем плох тип Double для работы с денежными суммами?"
Ни разу не считал деньги на C#. Про тип Money предложенный Фаулером не слышал (оно ж мне не надо на практике, ага)
D>"Тип String — value или reference type?"
А зачем оно мне? Мне достаточно знать, что String "неизменяемый". На практике этого достаточно. Плюс знание StringBuilder.
D>Таким образом, правильно сделанный тест является предметом дальнейшего разговора и экономит массу времени. Любой mid level и выше с легкостью отвечает на все вопросы.
Таким образом если бы я знал только то, что мне надо в работе, я бы на ваши "сугубо рабочие" вопросы не ответил бы. А все что вы спрашиваете было узнано не столько в процессе работы, сколько из любопытства "а как же оно там внутри"
D>Но пока не начнешь проводить собеседования — и не узнаешь, сколько неадекватов и людей с гипертрофированной самооценкой приходят к HR.
Это да.
D>В общем, проведя около трех десятков собеседований:
Я за два года провел их пять десятков. Это не показатель. Показатель — слаженная команда и успешно завершенный командой проект.
D>большая часть т.н. "тим-лидов" путались в эл. вещах и кричали об каком-то опыте "руководства", "анализа", "проектирования" и т.п.
Вы спутали лид-инженера/архитекта и тим-лида. Кстати даже лид инженер и архитект могут быть так задолбаны бюрократией и всякой тянучкой-текучкой, что забудут как "Hello World" написать. Это свойство роста по карьерной лестнице.
D>Имхо, максимально конкретные вопросы, ответы на которые реально требуются для работы на проекте, куда берется кандидат — лучший способ проведения техн. интерью.
Ага, меня так в одной конторе насобеседовали на тему делегатов и потоков, а потом я их ПМ насобеседовал на тему SMMI и риск-менеджмента. В итоге они мне сделали оффер на джун девелопера, а я их ПМа посчитал неквалифицированным как для его должности.
И ушел сениором в другую контору, где уже два года со смехом вспоминаю тот эпизод.
Здравствуйте, Davader, Вы писали:
D>Но пока не начнешь проводить собеседования — и не узнаешь, сколько неадекватов и людей с гипертрофированной самооценкой приходят к HR. Никогда бы не подумал, что человек, написавший в резюме, что он 2 года работал тим-лидом на ASP.Net проекте не сможет мне сказать, чем отличаются value и reference types, где может храниться сессия и можно ли реализовать несколько интерфейсов одному классу. Оказывается, есть и такие "работники". D>... D>большая часть т.н. "тим-лидов" путались в эл. вещах и кричали об каком-то опыте "руководства", "анализа", "проектирования" и т.п.
По-моему, есть люди, которые решают глобальные вопросы, не обращая внимание на детали.
Например, говорят даже, что начальник не должен вникать в детали и сам работать, а только руководить.
Да, в конкретном случае, похоже, автору нужен тим лид, который может ответить на его вопросы, и
упомянутые кандидаты "не туда попали".
Но, если автор называет их неадекватами, это, по-моему, показывает, что он такой же максималист,
как эти кандидаты.
Я о себе тоже могу сказать, что я тоже никогда не интересовался деталями и не мог ответить на
вопросы, чем отличаются value и reference types, итд., итп.
Это, конечно, нехорошо и часто на этом разговор с потенциальным работодателем оканчивается,
но, по-моему, это избавляет от проблем и работодателя, и меня.
Здравствуйте, landerhigh, Вы писали:
L>Вот тоже был случай — написали "как бы побыстрее", потому что "это просто" и "расширять не понадобится" и "любой программист может разобраться за полчаса". Через год глянули и выпали в осадок — классы с сотней методов, дублирование кода, глобальные функции, дикие зависимости в коде. Никаких юнит-тестов, а если под дебагом смотреть, до функций 100 вызывают друг друга непонятно для чего.
Если ты про то, что мы были не правы, когда реализовали этот функционал в пяток методов, то это не так — там действительно всё было понятно, прозрачно и могло модифицировалось без проблем.
Кстати, после того, как тот чел навороил всяких умных фишек, код не стал более модифицируемым.
Здравствуйте, Erop, Вы писали:
E>Ну уволили его по его обоюдному желанию. Он решил, что у нас скучно и ретрограды, мы решили, что он слишком крут для нас... Его правда честно пытались приспособить к чему-то полезному. Например он почитал желающим лекции на разные темы. IMHO неплохие, кстати... Но пользы из него никто так и не сумел тем не менее. IMHO он таким странным образом развлекался
Был и у меня такой коллега,правда он дров не наломал(даже наоборот),но тоже — почитал лекции и уволился...реально очень классный спец ,но такие ,зачастую, не нужны...
Здравствуйте, landerhigh, Вы писали:
L>Вот тоже был случай — написали "как бы побыстрее", потому что "это просто" и "расширять не понадобится" и "любой программист может разобраться за полчаса". Через год глянули и выпали в осадок — классы с сотней методов,
рефакторить периодически надо. и не писать каждый скрипт с расчётом того, что он когда-нибудь дорастёт до ОС
Здравствуйте, olegkr, Вы писали:
O>Я прекрасно помню, как обучают архитекторов (строительных), очень много практических знаний, которые непосредственно потребуются в дальнейшей работе, очень много работы руками. Теория тоже есть, как база, но не более того.
Ну сравнивать архитектуру и разработку ПО... скорость развития слегка разная...и пока вы будуте преподавать "работу руками" она устареет,а вот теория как НЕНАДО делать очень нужна,зачастую даже больше,чем очень развиное "умение работать руками" на какой-нибудь современной платформе...
Всё ИМХО
Здравствуйте, BulatZiganshin, Вы писали:
BZ>рефакторить периодически надо. и не писать каждый скрипт с расчётом того, что он когда-нибудь дорастёт до ОС
Воооооот!
Только не рефакторить, а проводить code review. Чтобы товарищ объяснил, зачем огород копал. И чтобы остальные имели шанс понять, что огород был не просто так. А рефакторить уже если все пришли к обоюдному согласию, что огород не очень нужен.
А то порой получается, что человек написал изящный и гибкий код с бустом, а остальные товарищи буст ниасилили, а шаблонов боятся как огня, про паттерны слышали только то, что синглтон имеет кучу проблем и от того кода приходят в священный ужас. А были бы code review — глядишь, уже и не боялись бы прогресса и сами бы такой код писали.
Здравствуйте, SE, Вы писали:
SE>Уверены, а давайте я в шутку вам отвечу (конечно я знаю ответы на ваши вопросы, но это не то "чем я реально занимаюсь после приема на работу").
Мы говорим про ASP.Net developer в данном случае, вопросы соответствуют тому проекту. Насчет хранения сессии — в проекте юзалось все 3 вида хранения и были некоторые тонкости при переходах от in proc к state server. Соответственно нужно всегда помнить, что несериализуемый класс нельзя запихнуть в сессию при не in proc модели хранения, т.к. там не бинарный вид сериализации юзается. Если вы не знаете, что можно ее еще хранить где-то кроме in proc — ну собеседование бы не прошли.
D>>Пример вопросов: "Есть ли множественное наследование в С#?", SE>У меня не было неоходимости во множественном наследовании, поэтому я не знаю есть ли оно. В реальной работе оно мне не нужно.
Нужно знать, почему не сделали его (намерянно) в .Net, чем оно плохо в тех языках, где оно есть (C++ как пример) с практической точки зрения. Это вопрос уровня mid level — максимум.
SE>Последний раз делал Server.Transfer еще в 2001 году на ASP. В ASP.NET не делал ни разу. На практике оно мне не надо даже знать про Server.Transfer.
Не понимая разницы можно натворить дел с обработкой ошибок, дальнейшей обработкой испорченных данных, например. Это не каждый день встречается, но нужно быстро находить и видеть такие вещи в коде.
D>>"Чем плох тип Double для работы с денежными суммами?" SE>Ни разу не считал деньги на C#. Про тип Money предложенный Фаулером не слышал (оно ж мне не надо на практике, ага)
Ну если вы не разработчик бизнес-систем на C# (или ASP.net), ничего удивительного. Если разработчик — поделитесь, как дошли до жизни такой? Опять таки мы говорим о собеседовании на конкретный проект. А там (как и во всех подобных системах) без хранения денег никуда.
D>>"Тип String — value или reference type?" SE>А зачем оно мне? Мне достаточно знать, что String "неизменяемый". На практике этого достаточно. Плюс знание StringBuilder.
О да. Не знать разницу между value или reference type стыдно даже junior'у.
SE>Таким образом если бы я знал только то, что мне надо в работе, я бы на ваши "сугубо рабочие" вопросы не ответил бы. А все что вы спрашиваете было узнано не столько в процессе работы, сколько из любопытства "а как же оно там внутри"
Соверщенно верно, вы бы не прошли однозначно.
SE>Вы спутали лид-инженера/архитекта и тим-лида. Кстати даже лид инженер и архитект могут быть так задолбаны бюрократией и всякой тянучкой-текучкой, что забудут как "Hello World" написать. Это свойство роста по карьерной лестнице.
Нет, ничего не спутал. Вакансия была — developer. Шли тим-лиды тоже, т.к. начинался кризис и все такое. Насчет архитектуры, паттернов и т.п. тоже спрашивали — те, кто тест прошел ответили и на эти вопросы, а те, кто нет — не ответили. Так что все закономерно.
Здравствуйте, Davader, Вы писали:
D>Соверщенно верно, вы бы не прошли однозначно.
Ну значит мне повезло, что я все эти вопросы изучил самостоятельно.
SE>>Вы спутали лид-инженера/архитекта и тим-лида. Кстати даже лид инженер и архитект могут быть так задолбаны бюрократией и всякой тянучкой-текучкой, что забудут как "Hello World" написать. Это свойство роста по карьерной лестнице.
D>Нет, ничего не спутал. Вакансия была — developer. Шли тим-лиды тоже, т.к. начинался кризис и все такое. Насчет архитектуры, паттернов и т.п. тоже спрашивали — те, кто тест прошел ответили и на эти вопросы, а те, кто нет — не ответили. Так что все закономерно.
Тогда понятно, мы тоже отсеяли пару лидов просто потому что у лидов знания вымылись. Кстати мы вынуждены были забраковать и человека, который ответил на все вопросы, решил все задачи, но вот проблема был помешан на оптимизации кода настолько, что ставил его важней понятности. Это была бы угроза всему проекту — заказчики просили именно улучшить понятность и сопровождаемость кода.
Хотя ваши вопросы он бы прошел на ура.
Здравствуйте, Vzhyk, Вы писали:
V> Нет, переделывают только только тогда, когда это нужно для бизнеса.
Не очень хорошее правило. ИМХО.
1. Как быть, например, с рефакторингом компонентов системы для подготовки их
к будущим изменениям. Бизнесу до него реально пофигу. Он просто не представляет своих
потребностей (если ему в этом не помочь). Как на него можно полагаться в той области,
в которой он не шарит потому что не должен?
2. Так можно и до копипейст-программирования скатиться ибо бизнесу пофиг как оно
там внутрях подсобляет ему зарабатывать деньги — быстро скопипейстили костыль,
чтобы не переделывать, и забыли — работает и ладно. Через какое-то время бизнес
может стать заложником тех подходов, к которым прямыми или косвенными действиями
подталкивает своих разработчиков — его попросту может завалить изнутри.
3. Если смотреть на Бизнес не как на цельномонолитное нечто, а разложить его хотя бы
на две составляющие:
Бизнес = СобственноБизнес + ТехнологическаяСоставляющаяБизнеса;
то можно сказать, что за разработчиком (за коллективом), в каком бы бизнесе он
не принимал участие, лежит ответственность за поддержку и развитие технологической
составляющей бизнеса.
Поддержка и развитие (особенно второе) предполагает некоторую (здесь, технологическую)
инициативу — результат которой представляет ту дельту, на которую осуществлятся прирост
на каждом цикле развития. Инициатива же происходит изнутри и подразумевает постановку
целей, и выработку плана действий, прямой необходимости со стороны СобственноБизнеса
часто вообще не озвучивается. Ибо СобственноБизнес "едет" распальцованный на
"ТехнологическойСоставляющаяБизнеса", сорит вниз деньгами за это и ему пофиг, что там внутри.
В силу этого "пофиг" никакой СобственноБизнес не определит объем работ по возведению системы,
которые должны проводиться — это область ответственности разработчика. И тут ориентация на
правило "только когда это нужно для бизнеса" в данном случае может сослужить плохую службу,
так как минимально достаточное решение для текущих нужд СобственноБизнеса далеко не самое
подходящее даже в самой ближней перспективе.
К сожалению большинство систем и их составляющих, с которыми приходилось сталкиваться мне,
реализованы именно с таким подходом и представляют (представляли) убогое зрелище — набор
хитросвязанных костылей от разных "микропроизводителей" (даже в пределах одного модуля) —
явный пример к чему приводит минимализм разработчика, вызванный пофигизмом бизнеса на свое
технологическое внутриустройство. Т.е. сначала мы в течении полугода экономим на разработке,
выполняя "только то, что нужно для бизнеса", а потом со взмыленной задницей в течение лет #б#мся
со своим детищем содержа при этом раздутый штат поддержки, тестировщиков, все тех же разработчиков
и прочих. При этом время внедрения новых разработок непредсказуемо, как и последствия установки
патчей. Просто потому, что в систему никто не заложил таких необходимых базовых возможностей —
ведь их необходимость с точки зрения бизнеса неявная, о ней не то, что не думали — просто не знали.
Нет. Я решительно против рождения уродов по принципу "переделывают только только тогда, когда
это нужно для бизнеса".
Здравствуйте, Erop, Вы писали:
E> Так что бывает и так, что разработчик для данной задачи слишком таки умён E> Даже для очень сложной задачи...
Ситуация известная. Но думаю, что здесь производится подмена понятий.
Слово "умен" здесь характеризует не соотношение требующихся и имеющихся
для решения поставленной задачи умственных способностей обсуждаемого
разработчика. Оно здесь "всунуто" насильно и неуместно.
Думаю, все пострадали не из-за ума, а из-за:
1. неопытность разработчика в подходе к решению задачи (в т.ч. в расстановке
приоритетов);
2. отсутствие своевременного контроля со стороны как непосредственного
технического руководства, так и со стороны менеджерского состава;
3. вероятно имел место некоторый первоначальный пофигизм со стороны
непосредственного технического руководителя, который не помог
подчиненному товарищу расставить приоритеты и не настоял на последовательности
разработки, выборе средств и прочего из-за чего исполнитель просто
заигрался и улетел в кювет.
Здравствуйте, МихаилС, Вы писали:
МС> 3. вероятно имел место некоторый первоначальный пофигизм со стороны МС> непосредственного технического руководителя
ЗЫЖ: Интересно, почему всегда забывается, что "рыба гниет с головы"?
Это всегда происходит на всех уровнях и на макро, и на микро. На уровне
государства, на уровне отдела разработки, везде.
Почему после того как работа с предварительной оценкой по временным
затратам 4-5-6 недель затянулась на 2-3 месяца никто не спохватился?
Почему нужно было тянуть 9 месяцев?
Здравствуйте, Erop, Вы писали:
E> Правда это самый вопиющий, из известных мне случаев излишнеквалифицированного сотрудника.
Да не является этот случай демонстрацией проблем с "излишнеквалифицированным"
сотрудником. Как бы он не демонстрировал обратной ситуации с отсутствием
квалификации:
— человек вероятно неправильно построил архитектуру системы;
— неправильно расставил приоритеты;
— не оценил своих сил;
— вероятно некорректно выбрал инструменты и технологии для реализации;
и:
— непосредственный технический руководитель, который в данном случае не выполнил
своих функции вообще никак.
Здравствуйте, Erop, Вы писали:
AVK>> Ты так и не смог доказать, что проблемой была черезмерная квалификация.
E> Черезмерная квалификация оказалась ресурсом, позволявшим морочить голову менеджерам.
Тогда наверное это относительная "Черезмерная квалификация".
Относительно низкой квалификации менеджеров.
