Синьоры и лиды не знают элементарных вещей
Serzh-GT
За последний месяц я провел около 10 собеседований по.NET. Взяли только 2-ух или 3-ех. Собеседовал людей с опытом по 4–7 лет. В прошлом синьоры и лиды. Так не знают элементарных вещей. Например, разницу между массивом и списком. Также вводят в ступор слова — «это никто не использует», «лучше всегда использовать классы вместо структур», «GC сделает все сам и мне не нужно беспокоится о мемори ликах», «зачем вы меня по теории грузите, спросите лучше по практике» и т.д. Ребята, Вас же не на джуниора собеседуют. Вы возможные кандидаты на синьор и лид позиции. На Ваши плечи в будущем ляжет оптимизация, дебаг и повышение перфоманса приложения.
—
kievbs
2 Serzh-GT
Не согласен. Имея 4–7 летний опыт, теорию можно подогнать за неделю другую, если чего-то будет не хватать для конкретного проекта. Научиться тот же профайлер запускать и ловить мемори лики, если раньше не приходилось. А вот теория опыта не заменит. Личное наблюдение, народ который хорошо рассказывал теорию на собеседованиях частенько на практике оказывался довольно бесполезными. Так что лично я против собеседований по теории, гораздо эффективнее подбирать людей с опытом по тематике проекта.
—
volf
2 Serzh-GT
Простите, но вы действительно «оптимизируете» заменой списков на массивы???
Был сам на «таком» собеседовании (Java dev), когда по «массивом» имеют ввиду «ArrayList», а под «списком» — «LinkedList»...
Или например «внутренний клас, обьявленный внутри метода, НЕ МОЖЕТ ИМЕТЬ ИМЕНИ и поэтому называется анонимным».
З.Ы. может это мне конечно так повезло, но был на 2 собеседованиях в оной компании, и оба раза был неприятно удивлен отношением со стороны собеседователей.
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
414 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівЭлементарные примеры отбора разработчиков: — Часто на синьёров аутсурсинга берут переводчиков с английского, а не специалистов с опытом C++/Java, потом спустя время не знают куда его деть, и его английский как таковой не очень нужен и джаву/С++ не осиливает вовсе.
или — Берем того, кто мля умеет на C++ завернуть абстрактно код. Типа, завернул так что бы сразу не было даже спецу понятно — БЕРЕМ, иначе в сад...
или — Смотрят мол, на основы, типа расскажи мне ООП. И их не гребет что у человека 6−8 лет опыта программирования большущих систем. Потом найдя какой то «недовыговор» по заданному вопросу, и сразу же делают вывод — нет, не потянет. Да я за 10 минут подтяну всю необходимую теорию, если есть необходимость!...
Люди мы разные, по разному смотрим на жизнь, взгляды пересекаются, но это не значит, что все разработчики будут как один.
Просто на рынке труда IT у нас, мало кто смотрит на потенциал и уровень самообучаемости.
У многих контор одно и тоже: вот от сюда и до обеда...а не? значит нет!...
Повторюсь: ИМХО, специализация — это разработка приложений с использованием конкретной технологии. Дальнейшее расщепление градации, или нахождение своей ниши в разработке, и заниматься в пределах сугубо этой ниши, и дальше не высовываться — признак ущербности.
Отличие хирурга от знатока инструментов в том, что хирург лечит, а знаток инструменты точит.
To Вовка: не совсем так. Хирург людей оперирует. Диагноз ему ставит другой врач или даже несколько, еси он консультируется сразу у нескольких. Сдает анализы и т.п. И кахдый вчачь знет свой «зажим». Хируг знает свои инструменты, знает как решать свои задачи (оперировать определенные органы и системы).
To @HT0x@: ок, зажим из2-х деталей. На станке 5 зажима и кнопка вкл/выкл. Чувак знает тока как включить, выключить и читал про то, как пользоваться 3-мя из 5 зажимами. 1-м зажимом пытался пользоваться сам. Так понятней?
To @HT0x@: Спасибо Кэп (про эргономику). Какая разница как это называется. Я про суть и смысл, а не про название. По сути сказано ноль.
Джуниор санитар детектед?:) Зажим, по-русски говоря, это как ножницы, но с концами различной формы, только они фиксируются в одном положении. Деталей там не пара сотен, а как у ножниц, так что аналогия неуместна.
Потом, после неудачной операции, пациент попадает в морг. Сначала его встречает санитар без опыта, на испытательном сроке, который просто его разденет и правильно положит на стол, чтобы другим специалистам было удобно его разделывать. А если он трупы будет укладывать неправильно (рука свесится, или нога, а то и сам труп соскользнет во время вскрытия и упадет на пол) — его карьера на этом и закончится. Потом подходит джуниор разметчик, который фломастером на теле рисует линии разрезов. Рисует он везде, кроме головы (опыта маловато). По нарисованным линиям
специалист по базам данныходин санитар делает скальпелем разрез на груди, и большими клещами вскрывает грудную клетку. Мастерски и профессионально, одним движением руки. Ну может двумя — он на этом деле собаку сьел. Потом работает второй санитар — он вскрывает брюшную полость, вынимает и шинкует все внутренности. Потом приходит сениор разметчик, и начинает размечать для вскрытия череп. Потому что если не там разметит — черепушка криво откроется, поэтому джуниор разметчик эту ответственную работу и не выполняет. Хотя и интересуется, читает книжки, наблюдает за работой своего старшего товарища. Вот, а потом приходит тим-лид, и делает вынос моска: накернил долотом по разметкам на черепе, сделал несколько надрезов, и потом ЧПОК! — черепушка открылась, всем спасибо, проект законченДа блин, все это называется одним словом — эргономика, я ж писал. Загляни в педивикию что это такое. Если б кнопки управления магнитолой были бы возле педалей — да, это было бы странно.
Хирург, это не специалист по использованию зажимов — это специалист по лечению людей. Аналогия понятна?
TO: можно и такое сравнение привести. Только в таком случае не нужно забыть упомянуть, что зажим состоит из пару сотен деталей, имеет кучу насадок, переходников, режимов и так далее. И это круто, если человек его досконально знает. Я думаю, что никто не хочет, чтобы хирург слабо знал каким инструментом ( «зажимом» ) работать в конкретной ситуации. И вместо лучшего вырианта лечения выбрал «шото среднее», которое все знают, но дороже, больнее, опасней и т.п.
Язык программирования это инструмент, примерно такой как станок? Тогда специалист по фреймворку есть специалист по определенному зажиму, левому снизу:)
1. про отупение — никто не мешает чиать книги и развиваться. Я про специализацию. Про то, что специалистом ты не будешь везде и сразу. Это невозможно. Можно знать что-то хорошо. Что-то неплохо, а что-то на базовом уровне.
А теперь вопрос — что лучше, человек, который все знает на базовом уровне, типо «кодю на всем, что горит» или человек, который профессионал в какой-то своей области (база данных, язык программирования, фреймворк)?
Мое мнение —
И может
А про мотор позаботится его товарищ.
Про устаревание знаний — так это не секрет. Любому ИТшнику нужно постоянно учиться, каким бы умным он не был, чтобы не оказаться ненужным. Это относится ко всем, а только к тем, кто крутит гайки М. Это вопрос элементарной адекватности.
2. про «p.s. скажу по секрету — автоматика в самолете работает только на автопилоте. 99%». Не понял при чем тут автопилот и аварии. Я про автоматизацию, про увеличение эффективности работы пилота, про его разгрузку от рутинной, сложной и автоматизируемой компом работы, про подготовку данных для наиболее быстрого восприятия.
Советую погуглить термины «авионика», HOTAS, HUD. Не просто так в современных авто делают управление магнитолой, круизом и т.п. на руле. Эти «новшества» пошли от последних2-х понятий, проверенных на боевой технике. И это все увеличивает эффективность и безопасность.
На символ первых христиан похоже. Видно знак того, что он подставил правую щеку...
начальник, к стати, не менее уныл, но себя не оштрафовал ни разу — вот они двойные стандарты в действии...
Вот лично у меня самый гордый штраф был за то, что мой отдел слишком быстро работает. Предлагали либо штраф, либо уволить одного из ребят. Я выбрал штраф на себя и на них, после их согласия, а через 2 месяца дружно все спетляли после отпусков и больничных. Правда, подлецы начальствующие справку о таком штрафе не выдали.
После штрафа он ходил со значком рыбы — капли, приколотым к пиджаку. И просто светился от счастья.
Вот дятлы — можно подумать, если человека штрафануть — он будет сиять от радости. Небось, после штрафа у него лицо стало еще более унылым. Может он был просто эмо:)
да в Булате... мы тоже гордимся его штрафом...
В булате было дело такое, как я слыхал, не? Очень гордо. Лично я бы гордился таким штрафом.
на одной работе, одного художника оштрафовали за унылое лицо, хотя лицо начальника было не менее унылым...
А жаль, что не карточная игра. Не пройти собеседование, т.к. не умеешь играть в карты — это уровень. Я бы у них попросил себе сертификат даже, удостоверяющий, что я не прошел собеседование по этой причине и крайне бы им гордился. На стену повесил.
Для багфикса (в терминах аутсорса) это- крупный проект, как по мне. ЗА год не справидца с багами и надстройкой функциональности небольшой — это надо уметь. Полная переработка — займет уже больше, но полной переработки в нашей промышленности не бывает. Только надстройки, которые — аналог багфикса и дописывания индусокода в аутсорсе.
Ну, ты ж не знаешь, сколько там человек на проекте на 6 месяцев, не? Может, там 200 челвоек арт отдела и 50 проггеров. В итоге, не такой уж и маленький проект, не?
я знаю что бывают крупные проекты, ты просто сказал что 4 человека и год это крупно, я подметил что это не крупно...
просто пару месяцев назад пришло предложение, где крупным проектом назвали проект длинной 6 месяцев...
Не помню, в какой теме ты писал о человеко-годах в ембеддеде и ентерпрайзе, отвечу здесь. Человеко-столетия — это весьма малый термин в полноценой встраиваемой или промышленной деятельности, когда идет разработка с нуля, а не переработка или доработка. Простой пример — черновая клеть блюминга и визулизация. Срок выполнения системы автоматики — 2 года четырьмя людьми + система визуализации + отладка система и мониторинг во время эксплуатации — еще пару лет. Но, это сравнимо с доработкой системы (багфиксингом) в аутсорсе, т.к. идет простая переработка предыдущей система управления.
А теперь, давай рассмотрим разработку с нуля такого устройства, принимая, что софт, САПРы, и производство железа не идет в зачет челвоекочасов, т.к. производится сторонними конторами (сервера и софт от сторонних в интерпрайзе тож не относят обычно к челвоекочасам).
Так вот, проектирование стана — пара лет работы инженерно — техническим отделом из 30 человек. ПРоектирование первоначальной системы автоматики — около 3х лет десятком челвоек. Сбор шкафов управления, дублирующих систем, систем визуализации — около года 30ю спецами. Монтаж, установка, строительство, проведение коммуникаций, пусконаладка — около 150 человек в течении года. Смотрим дальше, это я рассказал про один стан, а их на линии 15 + печи и клещевые краны, системы сортировки, системы взвешивания, системы порезки и т.п. ТУт уж интерпрайз тихонько курит в сторонке. Просто, стоит учитывать, что таки доработка систем автоматики — это не создание продукта с нуля, а простой багфиксинг и доработка в терминах софтостроителей, не?
но зато знаю, на что нужно обратить внимание в дальнейшем развитии...
А Саттера и Александреску для.Netчиков никто и не отменял. Как впрочем и Кнута.; -)
public class List< T>: IList< T>, ICollection< T>, IEnumerable< T>, IList, ICollection, IEnumerable
{
// Fields
private const int _defaultCapacity = 4;
private static T [] _emptyArray;
private T [] _items;
private int _size; ...}
Ну и так далее...
Ще можу проти «разжижением мозга» порекомендувати матан читати на ніч.
Це у вас наслідки радянської освіти. Не праця, а мова і мовлення зробили з бібізяни людину.
Це ви тіпа дотепник?
А когда просят сравнить список и массив, обычно имеют ввиду классическую теорию структур и алгоритмов, а не прямой перевод (List в.Net c массивом в.Net)
може хватить слоганів,
он ГЛ пишуть, що
А ще є класика «Труд сделал із обєзяни чєловєка».Ао коні скільки в полі не пахали, щось не видно у них росту навіть до рівня неардентальців.
Мля, а как насчёт ефєкта взрива моска от таго шо многа думаєш?
Ты не указал, из какого языка сии выдержки.
Но могу предположить, что List< T> и < T> [] — далеко не одно и то же.
Разумеется, если List< T> во фреймфорке не реализован с помощью массива.
В смысле по порядковому номеру.:)
— список — структура, в якій елемент має значення та адресу наступного елементу, теоретично може рости до нескінченності, щоб добратись до Н-го елементу, тре перебрати всі попередні. — масив — структура фіксованого розміру, доступ до елементів відбувається по індексу
кагбе сінйор дотнет детектед?
После второго курса, 6.5 лет назад я как-то месяцок мотал дросселя. Называл этот эффект «разжижением мозга» и очень ему сопротивлялся. Мне, конечно, это не грозило всего за месяц, впереди было ещё три года универа, через полгода работа программиста.
Индекса в смысле по ключу:)
А что вообще подразумевается под эпическим «список vs массив»? Напиши предметно, список — это List< T>, или ArrayList ()? А массив — это < T> []? Или как? Если да — вопрос-г0вно, потому что у них всех есть итератор, да и разницы особой в производительности не будет. И индексов ни у списка, ни у массива нет (если я правильно понял вопрос) — это ж не dictionary или hashtable
2Юрий
Это был не ответ?
я встречал, что некоторых ребят называли тимлидами за «выслугу лет». программировать они видимо никогда и не умели, но вот сливать ветки и раздавать задания у них получалось хорошо.
А вот если ты этого не знаешь, а уже тимлид — то интересно узнать, кто тебя нанял.
главное список с массивом не путать;)
Спасибо, я всегда путаюсь, думаю что конец этой проблеме все еще не положен, через месяц опять забуду как правильно; -)
Граммар наци: Нет слова проЭкт. Есть слово проЕкт.
ушел читать в чем разница между списками и массивами. Я тоже хочу быть тимлидером.
Я никогда не утверждал что «методологии» нужны в маленьких проэктах и командах, я считаю что если проэкт дорастает до определенной фазы, то «методологии» дают ощутимые бонусы в плане контроля бардака.
Сидя в Украине можно с определенным уровнем комфорта работать и с штатами и с индией, хотя на одной из моих прошлых работ достаточно большой процент народа решал что это не для них в конце концов, а вот штаты с индией это другой расклад,
Я выводы делаю на основании вашего отстаивания методологий и прочей чепухи, а не того, где вы сидите.
Это зависит от отношения в компании — если все с 8 до 5 — то тогда временные зоны — это плохо. У нас же все были гибкие — и график более-менее сместился. Когда жена в декрет ушла, обнаружили что ходить утром в кино — очень классно. И свобода распоряжаться своим временем — это одна из самых больших ценнностей (мдя, с понедельника прийдётся отказаться: ()
Тебе проще, а когда в Калифорнии начинается рабочий день Индусы как раз идут спать и наоборот.
Кагбэ, Генри Форд изобрел конвейер, если знаете. Это дало сумашедший прирост производительности труда. Потому что действия всех работников, участвовавших в процессе, были быстрыми, точными, и доведены до автоматизма. Но было одно НО — у людей снижался IQ, и они тупели. Ну вот ты знаешь, что тебе нужно прикрутить вот там, там и там гайку М5. А потом нажать на кнопку. А потом снова прикрутить эти гайки там, там и там. И снова нажать на кнопку. И так 8 часов в день, 5 дней в неделю, на протяжении нескольких лет. Ты вообще не думаешь. И ты тупеешь. А потом окажется, что эта модель автомобиля снимается с производства, и тебя могут списать в связи с этим, потому что никому и нафиг не нужен квалифицированный, с многолетним опытом, специалист по вкручиванию гаек М5, даже если ты работал на заводе самого Генри Форда. Так что ну его на икс специализацию. ИМХО, нужно стремиться быть самодостаточным. Вот как в эпоху Возрождения — люди стремились стать универсалами, постичь все науки (благо, знаний тогда было мало, даже Парацельс знал мне кажется даже меньше первокурсника мед. института). А фреймворк нужно знать весь, ну может процентов 90, а остальное понадкусывать. А фуле тогда делать? Про базы данных и SQL я вообще молчу. И вообще — волка ноги кормят. Чем больше знаний — тем более самодостаточен и независим.
p.s. скажу по секрету — автоматика в самолете работает только на автопилоте. 99% — человеческий фактор. И эргономика. Вот даже, когда под Пермью несколько лет назад разбился Боинг, основная версия — неумение пилота управлять, из-за отключения автоматики (они оказывается прошли краткое обучение вождение Боингами). А в 2006 году, ТУ-154 упал под Константиновкой, так это ж была не автоматика, а плоский штопор — ручное пилотирование, недопустимый угол подьема при наборе высоты, вес задней половины самолета у этой модели превышает переднюю, плоский штопор, и кирдык. А вы говорите — автоматика...:)
У меня похожая история, так что не нужно делать лишних выводов.
Был комманда-из-одного-человека в организации (совсем проект непрофильный) — с понедельника подамся в офисные хомячки, за визу продался...
Ни малейшей проблемы за несколько лет. Потому что не было «процесса разработки» в понимании офисных хомячков — с ежедневными сборами всех. Все вопросы отлично решались P2P -, а двум людям пересечься нетрудно.
Для динамичного стартапа команда из 6 человек в трех отдаленных часовых поясах — это совсем не круто.
Ты говорил что _продукты_ _пишутся_.
А ты сейчас принципал архитектор в маленьком стартапе, или все таки офисный хомячек?
Кто-то сказал что продукт был кривой, и пользователи недовольны?
Не употребил это слово, день прожит зря?
Команда распределённая. И я не говорил что нас было 3 человека — нас было 5−6 человек (я на Украине, 1−2 в Индии, 3 человека в Штатах — распределённая комманда — это круто). Я говорил что компании _начинаются_ с 2−3 человек.
А кто сказал что были дырки? Был энтузиазм. Были горящие глаза. А менедмент как мог — так и остужал (хотя сами местами не лучше — они были и разработчиками). Просто проект был реально больше чем могла потянуть комманда. Но — увы — расширить комманду не получалось (регулярно появлялся кто-то новый -, но обычно у него был менталитет офисного хомячка и он не мог прижится).В общем — перед релизом было желание «а ещё это проверю». «А ещё это исправлю». И т.д.
Но — как я сказал — офисным хомячкам не понять. Поэтому они и работают в большой корпорации (Гугл, правильно?) рядовым винтиком.
Лично мне кажется, что, как обычно, истина где-то посередке. Но не согласен с тем, что сениор должен знать все и сразу. Вы забываете, что:
1 — все в мире относительно. В одной конторе сеньор это одно, в другой — другое.
В реальном мире, в котором мы все живем нет ничего абсолютного. Что для русского хорошо, то для немца смерть.
Неужели не видно параллелей с реальным миром? Простой пример — авиация. Чем больше ручной работы у пилота и меньше автоматики, тем дольше и сложнее подготовить новых пилотов. Тем сложнее управление и больше риск катастрофы из-за ошибки человека.
Если же часть работы заберает автоматика — дешевле и быстрее готовить летчиков, меньше нагрузка на пилота. Для боевых самолетов это значит больше шансов сбить, а не быть сбитым, а значит выполнить свою роль, быть эффективным и экономически оправданым.
Та же фигня с коробкой передач автомобиля — 2 руки на руле, больше внимания на дороге, нет риска втыкнуть не ту передачу и заглохнуть/перекрутить двиг, лучше экономиться топливо за счет минимально возможных оборотов (актуально для современных КПП)
Та же фигня с компьютерами. Именно благодаря окошкам и простым ГУЯм непрогеры смогли сесть за тазики и фигачить в них отчеты, документы, и т.п. Без надобность юзать медленную почту, писать вручную и т.п.
Колличество знаний постоянно растет. Не может быть человек профессионалом во всем. Специалист знает свою область и за нее отвечает. Он решает свои задачи. А требовать от.НЕТтчика знать все алгоритмы, их временную сложность, структуры данных, кучу теории да еще и фреймворк, к нему веб сервисы, к нему знание базы данных, к этому кучу библиотек компонентов, библиотек «бест практик» типа ентерпрайз либрери, CAB, SCSF как-то дофига, не кажется ли?
Все равно, что требовать от врача делать операции, лечить народной медициной, делать анализы в лаборатории, специализироваться на всех органах и системах человека, вести психотерапию и т.п.
В таком случа врач, ИТшник, да кто угодно ничего толком знать не будет. Не зря есть специализация. Для того одни клепают окошки, другие пишут алгоритмически оптимальных код, третий проэктирует базу, четвертый проэктирует модель приложения.
И так далее — в мире рыночной экономики важно, чтобы то, во что вкладывается бабло — приносило прибыль. Именно поэтому есть и Индия с ее г@внокодом, и Украина с аутсорсом.
А если бы вместо ночи поработали бы следующим днем без горячки и косяков, потеряли бы рынок? Если у вас была дата релиза, то у вас были видимо разбиты майлстоуны, и можно было бы намного раньше определить отставание? Или настоящим прозженным ветеранам-синёрам не до этого? Я понимаю, разные ситуации бывают, особенно когда включается человеческий фактор, но бить себя пяткой в грудь и называть остальных лохами, потому что просидел ночь перед релизом считаю по меньшей мере странным.
Ну и раньше речь шла про маленькие команды из трех человек, а тут оказывается что и начальство работало (что они делали то?) и народ в Индии. Как то не сходится, тем более что это большая глупость иметь команды в сильно разных часовых поясах, когда хочется скорости, оперативности и мобильности.
И да, я считаю непрофессионализмом манеру менеджмента, при которой дырки затыкаются переработками. Потому что, что бы программистам эфективно работать в рабочее время, им нужно правильно питаться, хорошо высыпаться и заниматься спортом, а иначе производительность упадет. Исключением является только проблемы в продакшн.
Ну и высокие рейты при почасовой олпате — это мифическая серебрянная пуля, если человеку платить в два раза больше это совсем не значит что он будет работать в два раза лучше, а в случае переработок, как раз наоборт.
Приступы телепатии?
Не такие же конечно.
И?
Не, они не заработали бабло, так как у них его не появилось никак — они взяли в долю больших дядь, которые заплатили денег на равитие проэкта, а уже потом после нескольких раундов финансирования некоторые компании вышли в паблик, и создатели компаний смогли продать свои акции, но финт в том что без дядь и больших коллективов ничего этого не произошло бы.
Банальный отказ от ответственности. Т.е. учить-учим -, а за результат не ручаемся. Я же говорю — как всякие НЛП.
Вся комманда работала в таком ритме — и начальство и Индия. Просто потому что все хотели выпустить максимально качественный продукт и вовремя.
«Кот в наушниках» — проект пишется через «е», и никак не через «э».
Чукча не читатель, чукча писатель?:)
Таки не всегда, министр здравоохранения это не врач, министр здарвоохранения это чиновник. Лечить людей и управлять теми кто лечит — это разные вещи.
Ну дык все-таки колупание в г0внокоде — это всего — лишь ступенька в карьере:)
Хех. В нормальных странах министр здравоохранения предварительно проктологом таки поработал, не?
Ну это как кому повезет — то ли работать проктологом, и бомжей принимать, то ли работать министром здравоохранения:)
Ну дык я сразу и сказал, что надо читать код, а не рассказывать о паттернах и прочей теории, не?
Та тут все правы:) Каким бы ты не был умным — вот посадят на проект, у которого гуй на сторонних контролах — и даже черный пояс по методологиям разработки не поможет — будешь в интеллисенсе и обджект броузере лазить, изучать:)
Вы оба не правы! Знания можно извлекать и из книг и из проектов, но количество ни книг, ни проектов не о чем не говорит. Я знаю людей которые прочитали много книг и участвовали в десятках законченных проектов, но их код гуано (и это не только мое мнение).
Вы торгаш или инженер? Кстати вспомните Билли, который сначала продал дос, а потом его купил.
Поэтому в начале всех книг и докладов говорят: «Нам помогло то-то и то-то, а что нужно вам это вам решать»
Значит платят почасово и с высоким рейтом. Офисному планктонцу сего не понять, не?
Челвоек может лешко не знать терминологии на одном из языков, не? Если он знает, что есть List, но не знает, что такое список, то что в этом такого? Я тебе привел прямой пример, я вообще почти не знаю русской терминологии своей специальности. И ничего.
Кока-кола и макдональдс — точно такие же стартапы.Эппл начали и МС с гаража.
Ну так правильно инвестиции = доход = бабло. Они заработали бабло, когда были в гараже, не? И заработали они его не засчет основания компании, а за счет своего гаражного продукта.
Вот тут я полностью согласен, если перед релизом ночь не спали, то у менеджера определенно есть талант
развода лохов-программистовмотивации сотрудников; -)«Квалификация» — это расплывчато. Заучки под этим понимают количество прочитаных книг, я — опыт на реальных проектах.
«Чтобы продать что-то ненужное, нужно вначале купить что-то ненужное»Никакие навыки «торгаша» не дадут продать то, чего нет. Я и утверждаю что главное в проекте — его довести до конца. Буквальное следование книгам (особенно по XP) — гарантия провала проекта. С опытом ( «сеньёрностью» ) приходит способность более адекватно воспринимать реальность — и не говорить догмами («если перед релизом неделю не спали — то менеджер — идиoт»)
ну да, э така фраза, щоб бути успішним не тре бути розумніше за інших, тре хоча б на один день швидше
Когда говорят «знать паттерны», подразумевают «уметь их использовать», а не тыкать лиш бы написать «у нас использовано 147 паттернов». Паттерны — это просто стандартные решения, от знания которых хуже не будет (джуну), а синьор должен знать (или вы предлагаете «изобретать велосипед»?).
У вас проблемы с логическими связями. Навыки программирования и то чем именно мотивирует себя человек ничем не связаны. Не все хотят «захватить мир».
Мы все — «программирующие дельцы» (пишем ради денег). Точнее — не все, некоторые просто офисные хомячки — которые занимаются программированием только потому что они ничего больше не умеют (да и программировать они особо не умеют).
Чтобы запустить любой проект в момент «когда просто не оказалось конкурентов» — надо его уметь написать быстрее конкурентов. Что никогда не сможет сделать комманда заучек.
Ещё раз, для самых маленьких — ничего новаторского в их разработке не было, они прочувствовали потребность рынка в данном интерпретаторе и выдали его на гора. Если вы так же прочувствуете, чего не хватает рынку, вам не придётся загадочно улыбаться и обещать оппоненту бесспорное поражение в фаллометрии — всё будет налицо без лишних объяснений.
Но я всё к тому, что в прорыве Гейтса нет программистского гения, просто он уже тогда был программирующим дельцом (только не надо говорить, что интерпретатор они написали для своего удовольствия, а потом уже это случайно дало денег). И выход на новый рынок не имеет ничего общего с нашей работой в условиях жёсткой конкуренции и высоких требований — среди нас наверняка нет ни одного юзера того Бейсика, но каким бы косым и кривым он ни был — у него на тот момент просто не оказалось конкурентов.
Они сделали — вы нет.
Это было точное попадание в коммерческом смысле. Ничего революционного они не сделали, не было в языкописании в то время уже никакого новаторства, а литературы хватало. А вот в нужное время в нужном месте прочувствовать, где можно взять денег... "Потому он Король, а вы держите фигу в кармане! "© И. Бабель про Беню
ГейцаКрика.так мы и писали прогу за одним компом — я на клавиатуре, он рядом — вторым мозгом... написалось все успешно, хотя алгоритм был из тех, что сейчас называют нечеткой логикой... помучились мы с ним.
так вот, про хп — много лет потом, «неожиданно» мы узнали про хп и очень удивились:)
і оцінювати що і як документувати повинен керівник проекта (ЛЮДИНА ВІДПОВІДАЛЬНА ЗА РЕАЛІЗАЦІЮ ПРЕКТА) котра в рахі невдачі буде хоч чимось та відповідати (хоча б авторитет).
Все інше не більш чим набір рекомендацій на зразок: повітрям треба дихати чистим (проте мільйони живуть в загазованих мегаполісах), спати по 8 годин на день (хоча мільйони не досипають) і тд
Что характерно — кто такой сейчас Кент Бек? Например, Эрих Гамма (который писал намного менее завирательные «шаблоны» ) сейчас в IBM, занимается большими проектами (Jazz, Eclipse JDT). А Кент Бек — занимается проповедованием своего учения — ездит с лекциями. После того как наруководил проектом в Крайслере.
Так сталося що в індустріїї знаходиться велика кількість людей, котрі поверхнево нахватались всіляких термінів, окремих понятть, іншого флуду
і в розмові починають тобі цей флуд виливати...
На одній з конференцій по скраму лектор що кидався всякими «спрінтами», «мастерами» і тд, просто був не в стані сформулювати основні ідеї скраму кількома реченнями...
Тому знов таки з свого досвіду після отримання подібних питань необхідно просто попросити співрозмовника українською (російською)
мовою просто і лаконічно пояснити що він питається і для чого це йому, і взагалі для чого це питання.
В цій дискусіїї знов таки ми бачимо «юніттести», «діаграми», «еджайли» і тд...той самий флуд.
Давайте просто візьмемо юніттест — нехай хтось чітко лаконічно опише що це таке, для чого, своє бачення застосування і тд після цього буде хоча б предмет дискусії.
Знов з свого досвіду так юніттест дуже часто корисний і є ситуації коли він дуже потрібний, а є коли він НЕ ПОТРІБНИЙ, ось і все.
І мені на спвбесіді вистачає 30 хв щоб зрозуміти хто сидить навпроти. Саме тому що той, що говорить вже з першої хвилини розуміє, що треба буде пояснювати
те імена (терміни) чого він промовляє. І повірте розмова змінюється ну дуже відчутно...
Тут спекуляция на терминах, говорим «проэкты», а примеры приводим «компаний», выше говорим «пишется», а теперь уже только «начинается», про «большинство» видимо тоже голословное утверждение, так как очевидно что Bing, Windows, MS SQL Server начинались делаться сразу большой командой людей, и статистики про удельную часть обоих случаев ни у кого под рукой нету.
Все правильно, но как я уже говорил несколько раз выше, у продукта наступает момент, когда уже дальше без взрослого процесса разработки двигаться труднее.
«Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. [6] Beck became the C3 project leader in March 1996 and began to refine the development method used in the project and wrote a book on the method (in October 1999, Extreme Programming Explained was published). [6] Chrysler cancelled the C3 project in February 2000»
Т.е. кроме книги, ничего и не получилось у Бека.
«Инвестору» нужен результат — двести диаграмм и пять гигабайтов «тест-фёст» юниттестов — не результат.
Кроме этого, большинство софта (мелкие приложения — в т.ч. всякие iPhone) пишется маленькими компаниями на свои деньги.
Билл с другом написали Basic для Альтаира — вот и будущий MS.
Все компании начинаются с пары человек. Что потом — это уже куда кривая вывезет. Но если бы Пол и Билл делали перекрёстное кодревью и писали юниттесты — то кто-то другой успел бы до них продать Альтаиру Бейсик.
Эпл и Майкрософт — это компании, у которых большинство успешным проэктов/продуктов сделано командами в больше чем 3 человека.
Кока-кола, макдональдс — я не в курсе, мы обсжудали индустрию ПО, или уже на металургию перейдем?
Бабло — это сколько? Бабка торгующая семками — это успешный проэкт?
Почему ты ушел от моего ворпоса про гугл? Тебя не смущает что adwords, на котором гугл начал колотить деньги появился только в
У тебя в списке куча компаний которые развивались по пути:
1. Сделали прототип.
2. Получили денег от инвестора.
3. Наняли людей, которые довели все до успешного продукта.
И без пунктов 2 и 3 не было бы ни гугла ни фейсбука и многих других.
Если вопрос упрается в терминологию — основать компанию vs разработать успешный продукт, то тут уж я пас, такой ерундой не страдаю.
Моё последнее
последнее сообщение моё
Спор на тему надо\не надо можно продолжать до бесконечности.
Если говорим о терминологии, то в конце концов мне вообще не ясно:
как человек может хорошо разбираться в предметной области, и совершенно не знать ее терминологии.
Хоть в русском, хоть в английском варианте, в зависимости он языка документации.
Тю. Глухонемой — есть ИМы для общения. Эт раз. А во вторых, незнание терминологии лично мне никогда не мешало работать. ПРичем, ни с местными, ни с иностранцами. Более того, в нормальном коллективе терминология наверстываедца в течении недели, нет? Скажем, кодга работал по ЦОСу, то очень быстро обучил своих ребят базовой аглицкой терминологии, т.к. на использовать русскую просто не имело смысла, да и «слепая развертка», «гистограммное выравнивание», «фазовый вокодер с адаптацией по сегментам спектрограммы», «проблема коктейльной вечеринки» и прочие меня просто передергивают. Где-то неделя и ушла и отлично. Как по мне, у нас не настолько много спецов, чтобы работодатель мог ими разбрасывадца на основании того, что они просто не знают терминологии (естессно, к протирателям штанов и формошлепам это не относидцам, т.к. оных развелось сверх меры).
Даже если он хорошо код строчить умеет, он ведь должен как-то общаться с коллективом.
Ну вот я ж и грю, что теоретики зохавали мир, не? И это, несмотря на то, что теория — это ничто. ТЕм более, теория на русском/украинском.
Може вже є які шаблони, патерни, а не в курсі.
Думаю, здесь не структура данных имеется в виду:)
Чесно кажучи, що таке список не знав до 2008 року, бо не стикався, поки не прийшлось малювати полілінії.
Що таке atoi, навіть зара не знаю.
Про дерева, ну знаю, що існують, і що, і до даного часу не було потреби його пробігати, так що?
Мене от недавно спитали що таке «крешстек» і як з ним боротись?
Що людина мала на увазі. Я так і не зрозумів. Може тому, що не приходилось таку структуру даних реалізовувати.
У мене підхід один — може людина поставлені задачі розв"язувати (тобто чи може підівчити прогалини), чи профнепригодний зовсім.
Якщо то сенйор, то повинен вміти менеджити модших, заміняти старших, і помогати тим та іншим, і працювати без особливого нагляду збоку.
Я так зрозумів, ми пішли по другому колу.
Путь учит матчасть.
Если у него совсем плого с терминологией, то на позицию синьора или лида я такого просто не взял бы.
Юрий, эт вы мне или 2trimm’у?
А если он не знает, как оно на русском называедца? Я ведь об этом и веду спор, что спрашивать и задавать наводящие вопросы — нерезонно в контексте того, что челвоек просто может не знать терминологии (а в век общей интернетизации и распространенности иностранных языков, это весьма вероятно). ЗАчем спрашивать, а не дать простое тестовое на структуры данных?
Ну, если ты расшифруешь, из моих почти все смогут сказать, тчо такое фифо и лифо. Расшифруй пжалсь РАБ и СБ, хоть проверю, знаю ли я такое. Интересно.
Очередь и стек — любой из знакомых. Циклический буфер — это круговой буфер (circular buffer)? Если да, то не сможет написать пара злостных похапешников. Еще пара не учтет особенностей и не вставит проверок на переполнение. Буфер с произвольным доступом — это что? Буфер в котором можно получить любой из его элементов? Если да, тогда все.
Очередь от стека тоже вообще то отличать не мешает. Особенно синьору.
Скільки людей із кола знайомих прогерів може розказати, що то за структури FIFO, LIFO, RAB, CB,
дати визначення і по ходу спрівбесіди реалізувати: чергу, стек, циклічний буфер і буфер із довільним доступом.
Если он с перепугу забыл, что за фигня называется списком, можно наводящий вопрос задать.
И тут мы приходим к тому, с чего я начал свою песнь. Как ты определишь, знает ли человек, что такое список, если ты его спрашиваешь: «Что такое список? », а он не знает, как это на русском называедца. Посему и надо давать тестовые на структуры данных и смотреть, как и что человек применяет, а не спрашивать теорию (что такое список? Как реализовать и т.п.).
Личные оскорбления? А таковых не было в сиим треде. Ну, а если мы непрямые оскорбления считаем, то свой вопрос тебе надо было адресовать Антоше:
похоже ты уже зарвался. зачем обижать человека и переходить на личные оскорбления? Ты просто старый пень у которого небыло хорошей базы, вот и комплексуешь, прикрываясь опытом.
Как и в теме топика.
Под теорией как раз подразумеваю в первую очередь знание того, что и как работает и для чего предназначено, а не как это называется.
Назвать массив эррэем никто не запрещает.
Муха, не обижай так Антошу. Он и так срадает от осознания своей неполноценности и люмпеноватости. А тут еще и ты тыкаешь ему носом в то, что его хваленые технологии нужны только крайне интеллектуально неразвитым индивидам.
Читаем мое прошлое сообщение:
И что же мы там видим? А мы видим, что я вполне четко указал, что я нигде не говорю, что не надо знать структур данных, я говорю что не нужна терминология, которая и есть теория, в отличии от умения применять (которое я и предлагал тестить на собеседовании), которой так любят похвастадца теоретики, типа Антоши Мартыненко, которые успели хорошо протереть себе штаны, являясь офисным планктоном, зато нахватались умных слов и теперь этим кичадца, хотя, кроме умных слов, ни на что не способны. ХОтя, у таковых вообще с пониманием проблемы, даже не смогли понять по моим постам, что я программер из других областей, а не из CS, и, как типичная люмпенота, и сразу начали рассказывать о том, что я — неуч, даже не представляя, насколько они в своем формошлепстве жалки.Давай я тебе другой пример приведу, чтобы было понятнее. Я по системам автоматики и ЦОС вообще не владею теорией на русском. Ну не знаю я терминологии и все, т.к. источников на русском по моей теме почти нет, все статьи на английском. Посему, моя защита, скажем, выглядела весьма забавно, когда я объяснял русскоязычным преподам, что же я такого наворотил в своей адаптивной системе со скользящим регулятором. Тем не менее, несмотря на полное незнание терминологии, я вполне смог объяснить им все, используя английскую теорию и объяснения на пальцах, за что получил свою оценку. Так вот, теперь вопрос, при полном незнании теории, но умении ее применять, являюсь ли я плохим специалистом? Пока, как я вижу, овтет — нет, ибо работодатели ни разу не ныли, что я не могу им что-то пояснить.
Посему, я настаиваю, что теоретики не нужны, и один человек, умеющий применять знания будет сильнее ста человек, которые знают названия.
в програмуванні виходить, що може збіштись шобла і аджайлом нагородити чудо програму.
Це появилось тому, що в програмування пішло море людей інтелектом трохи вище за мавпу, і щоб хоч якось забезпечити прийнятнуякість кінцевого продукту у масовому кодінгу.
Повторюсь: теория необходима, по крайней мере базовые знания в алгоритмах. Но одного теоретического собеседования может быть недостаточно, чтобы оценить уровень специалиста.
Почему? Паттерны — вполне нормальная практика.И крайне полезна и правильном применении.
То, что кто-то там, впервые прочитав книжку гаммы, начинает строить замки из паттернов, где это надо, и где нет — это не вполне корректный аргумент против.
Ну не совсем. Есть такие методологии разработки, которые предполагают наличие навыков “архитектора” у всех. Например XP. При использовании парного программирование, TDD, Continuous refactoring и т.д. необходимо чтобы все знали паттерны, весь стек используемых технологий и т.д. Все эти инженерные практики появились эволюционно как средство борьбы с багами/сложностью и другими проблемами в разработке ПО.
Я не думаю, что в ембеддед у вас есть крупные проекты на сотни человеко-лет работы и с объемами исходников в сотни метров. В маленьких проектах совсем другие приоритеты.
В энтерпрайзе часто бывают действительно крупные проекты, и в них без тестов и паттернов дорога только одна — закрыть проект.
Так як патерни прийшли від ти же будівельників, то давайте їх залишим архатекторам.
Але якщо в програмістів у тімі кожен сам собі архітектор — то клініка з точки зору будівництва.
І нафіга рядовому прогеру знати много умних слов і пробувати ліпити архітектуру кода, коли тре тупо робити по тому як написано в специфікації або доведено до відома старшими?
Это значит, что теория не должна быть основополагающей, нет?
Смешно наблюдать, как формошел, который еле-еле осилил дотнетик рассказывает что -то о ковырянии в говне промышленному робототехнику.
Ой поржал. Что еще скажешь умного? Хотя нет, вопрос задан неверно, верно так: «Ты вообще хоть что-то умное сказать можешь? »
хто такий сінйор?
хто такий лід?
почнем з ліда — людина яка може вести інших за собою, тобто лідер
да будь 5 7 пядєй во лбу, якщо нема лідерський якостий лідом не бути
сінйор — головний.
Його задача — помогати меншим і середшим, і бути на поготові замінити ліда.
Я уже ніби приводив приклад, про соціальні структури.
Тобто щоб тім був успішний, тре щоб був, альфа-самєц (він же лід), і хоть один сінйор, щоб комогав-кункурував із лідом, що той не розслабляв булки і але й не перенапрягався.
Решта народу для окучування і мішання г-кода.
Якщо в кого настає ступор — сінйор розрібає.
Лід — задає общий тон і пріоритети.
А забули про ПМа. Цей такий собі абстрактний клас-інтерфейс, із поліморфізмом, який змінює поведінку в залежності
від лінків: клієнт, адміністрація і тім. Через які тім спілкується і кієнтом і адміністрацією.
Якщо тім спілкується з топами або клієнтом напряму — тут уже або модель або реалізація ПМства кульгає.
Візьмем приклад. Будова -
Прораб (ПМ).
Бригадир — ТЛ.
Сінйор — майстер, може бути і не один. Коли бригадир забухав, може виконувати його фунції.
І подавани і замішувачі бетону/розчину підмайстєр"є і т.д.
Вопрос, чи повинен майстер знати, як патерни як правильно бовтати розчин у кориті?
Конєшно приклад прикладний до девелопмента.
Ясний перець що в багфіксингу організовано всьо по другому.
Так кагде надо прилизати після бригади постройку до прілічного вида, щоб комісія могла прийнять з откритими глазами (пофіксать баги до нужного уровня).
Вопрос звучить так — чи можна на фіксанні багов (замазуванні дир і щєлєй і установкє подпорок) стать майстром-укладчіком?
Отієт — нє, сначало надо научіться дєлать багі, що знати їх природу.
Какой-то минимум все знают. Скажем, массив, сортировка «пузырьком», наследование, передача параметра по значению, итп — таким минимум и будет пользоваться. Другое дело, достаточно ли этого для проекта? (для многих, наверное, даже достаточно):)
Может быть и хуже, если он будет выбирать структуры данных, опираять на интуицию.
Да будь у тебя хоть 20 лет опыта в ковырянии гoвна — ничему, кроме ковыряния в гoвне, ты не научишься.
Так вот где собака порылась. Неуч пытается научить других уму-разумы. Иди дальше ковыряй свое гoвно под айфон и не смеши людей своими размышлениями о юнит-тестах и прочих областях, о которых ты понятия не имеешь.
Один написал, что взял на работу кадра с хорошей теорподготовкой, но который оказался ноль на практике.
И что? Это значит, что знать теорию — вредно?
Согласен, знание теории — это не достаточно для хорошего специалиста.
Но в большинстве случаев — это необходимо.
Тут фишка в том, что если чел знает, что такое список или там, стэк, может описать тот или иной паттерн — есть бОльшая вероятность, что он сумеет им воспользоваться, чем если он не знает/не может описать. В наиболее клинических случаях, незнание матчасти может вылиться в то, что чел будет тратить время на самостоятельное написание функций, которые уже реализованы в АПИ, но чел о них не знал.
Понятно, что нет смысла требовать знания реализации/интерфейса в деталях (для этого есть хелп), но знать о существовании, общее устройство и пользу применения чел должен.
Паттерны — это к теоретикам. Также, именно теоретики все поголовно знают, что такое список, а что такое массив. Я же привел личный пример, что до того, как попасть в сию тему, я не знал термина «список», хотя с успехом применял списки там, где они были необходимы. И да, мое образование с CS связано весьма отдаленно. Посему я и сказал, что надо не копать, знает ли челвоек терминологию (теоретик), а дать два тестовых и посмотреть, использует ли человек список и массив, когда в них есть необходимость.
По твоему, для программиста незнание простейших структур данных — это норма.
Ты бы захотел жить в доме, который проектировал инженер, не имеющий элементарных знаний по физике?
Речи идет о базе, которую должны знать все, кто закончил хотя бы один курс института.
Не обязан знать, какое О () у какой операции списка или массива. К практике это действительно мало имеет отношение.Но должен знать когда пользоваться одим, а когда — другим, и понимать почему так.
Требования к проектам (даже промышленным, встраиваемым в продукты, выпускаемые концернами) настолько часто меняются, что юнит-тесты, зачастую, будут устаревать к моменту окончания их написания.
К тому же, как правило, для успешного рефакторинга (ровно как, для производства более-менее качественного кода), достаточно растыканных по коду ассеpтов, здравого смысла разработчиков (и дальнейшей/повторной работы разработчиков с кодом) + десятка обезьян, сидящих в каком-нибудь Китае на тестировании.
и все же хотел ось бы дождаться ответа Сергея, а то набросить на вентилятор получилось, а разобраться — нет. Хотя, who cares?
Зато рассказывают тут, как без тестиков нельзя писать и что все вокруг — «не „сеньёр-разработчик“ и даже не мидл, ага. Гонора у вас реально на тим-лида, это да.»
С опытом понимаешь, что юнит-тесты до задницы, ибо ни они, ни что-либо еще не являюдца панацеей от плохого кода, которого пруд пруди. Но вот у вас за 10 лет, похоже, опыта достаточно не накопилось дял осознания настолько элементарной вещи.
Извини, но сложность выполнения операций — дело тонкое вообще-то. И да, человек вполне может не знать теорию, но пользовадца и тем, и другим. Скажем, до прихода в эту тему я не знал, что есть такая штука, как список, хотя использовал их до этого постоянно. Знание терминологии в принципе не являедца столпом, особенно, если люди из других областей программеры. Намного лучше — просто спросить пример и увидеть, умеет ли челвоек пользовать в нужные моменты времени массивы, а в нужное — списки. А то, в итоге, так и наймете себе теоретика, типа таковых, пхающих паттерна на паттерне и паттерном погоняющий, которые сверху еще будут присыпан тестами от недосиньоров, которые не в курсе о том, что же такое ООП.
Ок. Добью тебя по полной. Эппл, Микрософт, Кока-кола, МакДональдс. Мне все еще продолжать перечислять самые известные бренды в мире? Или ты таки тихонько пойдешь в угол скулить о своем сливе? А критерий успешности — он всегда один. БАБКИ. Ну как дите, е-мое. Извини, не засекал, но большинство стартапов стали успешными еще в эпоху гаража, а потом уж начали расширядца (Не веришь? Читай истории вышеупомянутых компаний).
К тому же это то, что так или иначе используется в 99.999 программ.
Программист должен понимать организацию структур данных и сложность выполнения операций с ними.Иначе там, где необходим быстрый доступ к элементам по индексам, он будет лепить списки, и долго думать, почему все так медленно работает.
вы все время носитесь с этим вопросом. А собственно, что вы вкладываете в разницу? интересен ваш ответ на этот вопрос.
Извините, но прогер, не знающий разницу между списком и массивом, это как писатель, не знающий букв. Или математик, не знающий цифр.
вы тут сначала определитесь что такое синиор/мидл/джун, а то похоже каждый по своему (под себя) это понимает.
увы, у меня для вас плохая новость — вы не «сеньёр-разработчик» и даже не мидл, ага. Гонора у вас реально на тим-лида, это да. Потому как только с опытом понимаешь, что юнит и другие тесты — это must have для любого проекта, который не надо завтра выкинуть в сад. Это настолько базовые вещи, как ref & value types в дотнете, или наследование/полиморфизм/инкапсуляция в ооп, что знать их просто нужно, вне зависимости от длины прибора. Алгоритмы/нормальные формы и пр. — это уже потребности по профилю, согласен.
Ибо приходят потом «сеньёры» и начинают педалить или рефакторить код без тестов, но зато с опытом. Первые недели успешно, а вот через месяц-другой получаем тот самый горячелюбимый говонокод, которые и поддерживать уже не возможно, ибо все разваливается при любом мелком чихе и выбросить жалко и дорого.
Странно что вы пишете о таком, работая над IDE. Хотя и notepad можно считать IDE... тогда да.
зы: у самого опыта 10+ очень интенсивных лет в больших и маленьких проектах, себя оцениваю как хорошего мидла, переходящего в сеньера, хотя по офф.должности — тим лид. так то.
Однако, сколько тебе понадобилось времени, что бы это заметить.
И так разговор перешёл на личности...
Ты считаешь это единственным чего ты мог бы стыдиться?
по теме,
Сергей, Вам вопрос.7 лет опыта реальных проектов — не малый период для получения хорошей, не то что базы, а основательных знаний в тех или иных технологиях. Не говоря про программирование как таковое.
Я думаю, Ваши вопросы на собеседовании не ограничивались «разницей между массивом и списком».
Наверное, кандидаты всячески пытались рассказать и показать свой опыт, знания и примеры решения каких-то реальных задач и проблем в проектах.
1. Насколько значительны были успехи этих людей? Не перекрывают ли они (успехи) проблем с базовыми вещами?
2. Мог ли фактор переживания, внутреннего беспокойства повлиять на устные ответы? (для многих людей собеседование морально не простая вещь, даже для зубров свернувших технические горы).
3. Можете пару примеров написать? (на уровне, «Я сделал то и то, и даже ВОТ ЭТО! А вот разницу между массивом и списком не знаю, потому что их никто не использует и за меня все делает JVM, и хватит меня теорией грузить! »:)).
Я не стыжусь что люблю комедии Кевина Смита.
Я уже понял что у тебя широкий кругозор в плане увлечений.
Ровные программы до релиза не доживают.
См. термин Dutch Rudder.
Да фигня все это — Ableton с эксепшеном в cpp модуле третий раз щас упал, куда мир катится? Нет нормальных программ на белом свете, как дальше жить...
Ну что же, очередной пример когда твой common sense расходится с реальностью.
бла бла бла.
Те версии, которые писались одним человеком, и то что стоит у меня на компьютере — несколько разного поля ягоды.
Что конкретно плохого в код ревью? То что тыкают носом балаболов в их гавнокод, и они потом уходят на другие «интересные» проэкты?
Опять за всех расписываешься? Может хватит дартаньянствовать?
Кваліфікований програміст тим і відрізняється від не кваліфікованого, ЩО РОЗУМІЄ ЩО ВІН РОБИТЬ причому розуміє глибоко.
Базових ідей ООП не так і багато (та і ніякі то не ідеї ООП — тим ідеям «100 лет в обед»),
людина котра дійсно їх глибоко пропустила через себе сприймає патерни
не більше як зразки застосувань певних ідей до певних умов, причому розуміє де в межах патерна закінчується одна ідея
і розпочинається інша і для чого була перша і для чого інша...
Тому в загальному код хороший якщо за ним проглядаєть чітка, струнка МОДЕЛЬ, котра відображає адекватне розуміння поставленої задачі, ,
а не велика кількість «мудрих» слів з посиланнями на «мудрі» книжки...
Common sense.
Этот проект убил во мне слепую веру в учебник. И это бесценный урок, которого так не хватает офисным хомячкам.
Посмотри на свой компьютер — на все программы. DOS (основанный на CP/M) — написал один человек, потом уже до Windows доросло. Excel (в виде Lotus 1−2−3) написал один человек. Всевозможные сайты и т.д. — всё это создаётся маленькими командами, которые понимают что бессонная неделя перед релизом — это не признак глупости, а просто работа программиста.А потом приходит инфантильный офисный хомячёк и начинает рассказывать про перекрёстные кодревью.
У меня были другие проекты — и я знаю что я за 1−2 недели могу сделать нечто, что можно показать заказчику и успокоить его, убедить что всё получится. Офисный хомячёк за это время только откроет пустую диаграмму в Розе и пойдёт чай пить.
Это подавляющее большинство успешных проэктов? Каков критерий успешности? Сколько времени прошло между тем как гугл стал успешным и они наняли4-го сотрудника?
Можно я за него отвечу? Гугл, фейсбук, твиттер, ютуб, чатрулет, групон. Продолжать?
И вас все тяготить необходимость постоянно упоминать это спорное мнение на этом форуме?
Вы тут кучу всего понаписывали, у вас и патерны и нормальные формы БД и документация — все фигня.
Можно посмотреть источники этой информации?
Они разрастаются когда переходят из стадии полусырого прототипа в стадию взрослого продукта, так как monkey patching дальше не проходит.
То есть вы поучаствовали в создании одного кривого продукта с оборотом в пару млн баксов в год, и это позволило вам считать себя мегазвездой?
Я же говорю — балабол.
Мне приходил сталкиваться с специалистами, которых я так характеризую. Поводов себя уважать в проф. сфере они не давали.
Я критикую слепое следование учебнику. И утверждаю что сеньёр — он тем и ценен, что не занимается ерундой. Глупо говорить что юниттесты и т.д. ничего не дают. Но бред требовать написание юниттестов во всех проектах и говорить догмами (менеджер-идиoт потому что релиз был напрягом). Подавляющее большинство успешных проектов пишется очень маленькими коммандами (макс 3 человека) — это они потом в бегемотов разростаются. Я не видел ни одного успешного проекта написанного по всем этим методикам.
Имел. В большом проекте. В котором сорцы были натасканы из кучи опен-сорсных проектов. У которого не получилось единой архитектуры. У которого не было юниттестов. Который работал с внешними системами, у которых не всегда были внятные интерфейсы для взаимодействия -, а когда и были то были или глючными или очень плохо документированными. Но у этого проекта несколько сотен тысяч пользователей, которые раз в год платят за подписку. Они недовольны его качеством — и сами разработчики недовольны его качеством -, но у него всё равно очень ощутимая доля рынка.Главное отличие взрослого от ребёнка — умение понимать что не всё делится на «белое» и «чёрное». В этом же и отличие сеньёра от юниора — юниор считает что следование догмам — главное, и будет сухо и комфортно. Меня больше удивляет такое же отношение — что иначе чем инфантильностью я это назвать не могу — у сотрудников банков.
Самая страшная проблема у разработчика в банке — обед остыл. Это я знаю.
Ну подозревайте.
Ваша развиртуализация! = меряние письками со мной. Вы здесь часто употребляете разные слова, типа — пионеры, хомячки и т.д., критикуете подходы, которые имеют место быть в индустрии, но что сами из себя представляете, имели ли опыт работы в больших проэктах, и понимаете ли какие там проблемы бывают непонятно, поэтому и возникает подозрение, что вы, уж извините — балабол.
Я же так понял — вы развиртуализации хотите?
А я предлагал?
Письками мерятся не хочу — всё равно проиграете.
Или балаболы, никто ж не знает кто скрывается за личиной анонимного дартаньяна.
Вот они — пионеры. У них есть даже паттерны определения идиoтизма менеджмента. Ни шагу от книги!
Проект просто рос спонтанно (сначала никто не ожидал что он так приживётся), количество разработчиков всегда отставало от потребностей проекта (достаточно специфичные умения были нужны)
«Гoвнoкoд-копипастеры» после этого проекта нарасхват — документально подтверждённый опыт, возможность увидеть код (немало стало опенсорсом), здоровый прагматизм. Это не безликие офисные хомячки — настоящие закалённые в боях ветераны!
а вообще, — дело нужное. даже очень.
кстати, а может кто слышал — есть спрос на такого рода работы на фрилансе?
А на мелком ширпотребе, типа ифона
Вы забыли про правоведение.
Антон, вы — профессионал везде. В экономике, автомобилях, программировании...
Поменяли тим лида =).
Код ревью есть на крупных проектах. А на мелком ширпотребе, типа ифона, его редко кто делает. Скажем, мне проекты доставались от прошлых программеров, которые не справились, т.е. ревью уже до задницы, когда прошлого программера уволили.
А код ревью слабо делать перед комитом? Теоретики блин...
Если тимлид алень, может стоит поменять проект/компанию?
У меня нет линкедина. В моей сфере он не особо популярен, а созадвать его ради ифона не имеет смысла, т.к. недостаточное портфолио. Если хочешь, пиши мне в ЛС www.developers.org.ua/m/trimm/ Я вряд ли смогу прямо сейчас занядца предложением, т.к. на следующий месяц-два уже есть обязательства, но может смогу посоветовать кого-нить.
Я тоже так считаю, ибо столкнулся с этим когда мой тим лид напихал их в проэкт везде. Все как и писал трим — читать труднее, суппортить труднее, более сложные решения в простых случаях, единственное что — расширять функционал, наверное, да, легче.
список впечатляет. кинь линк на свой LinkedIn, есть хорошее предложение
Я не совсем правильно видать пояснил, т.к. мыслю я все-таки на некстстеповских возможностях. Метакласс — это полноценная сущность, а не метаданные. Ты ее по протоколу можешь дергать как хочешь (хоть инициализировать, статические методы вызывать, хоть еще что), в т.ч. и инстанциировать. Мне не нужно ничего порождать. В том — то и дело. Мне надо создать приспособленца, скормить ему метакласс, чтобы затем приспособленец инстанциировал внутри себя метакласс, выполнил запрос этого метакласса, обработал через делегата выхлоп инстанса и выдал на гора результат через соответствующую нотификацию, чтобы каждый заинтересованный объект мог получить эти данные. Сам сей приспособленец по сути выступает, как прокси смешанный с делегатом. Ну, а метакласс передаедца простым свитчем в классе — хозяине (фабричный метод, если я правильно помню — это и есть приближение). Зачем кучу абстрактных фабрик кидать я не понимаю до сих пор. Просто заново запилил класс, получил кода раза в три меньше, при этом большую гибкость.
Опять я неправильно объяснил. Классы полностью независимы, выхлопы их независимы. На простом примере: скачана картинка, об этом событии создаедца сигнал, который идет в приложение. Есть куча обхектов, которые хавают картинку. Инстансы некоторых могут существовать на данный момент, другие не существуют. Так вот, по сигналу никакие объекты не инстанциируются, но все те, которые заинтересованы в картинке и инстанциированы, получают ее. Предположим, один инстанс ее умнеьшает, а другой, который являедца кнопкой, отрисовывает ее на себе, третий матаданные картинки в базу. Так что тут наблюдатель в тему, а посредником отдаленно можно назвать объект, который отослал нотификацию всем заинтересованным объектам. Цепочка ответственности — это слегка не то, хотя они в ифоне есть на уровне реализации объектной модели (если я правильно понимаю, что это). Сигналы — это нотификации, которые получает наблюдатель. Тяжко с терминологией, т.к. я опять же привычен к некстстеповской.
Это факт. Но пхать их всюду поряд — тоже моветон, нет?
На данный момент не тим-лид, а самозанятый. Тим-лидом бывал. Нате вам 3: система обработки и фильтрации одно-, дву- и трехмерных сигналов, система управления нестабильным балансирующим объектом (аналог сегвея, загнулся, т.к. заказчиков в колчья порвал кризис им пришлось отпустить народ на волю, т.к. денег не было даже на прототип), система управления и учета порезки металла на маятниковых и летучих ножницах (проект без внедрения). Это из крупных. Из мелких — разный ширпотреб на ифон.
Ну это ты примерно описал приспособленца, которому фабричный метод штампует метаданные. А делегат уже «дергает» приспособленца. Типа того. А абстрактная фабрика тут наверное и не нужна, т.к. она производит инстансы классов, взаимодействующих друг с другом, а в данном случае, я так понял, тебе нужно породить определенный класс в зависимости от определенных условий.
Для этого можно использовать, конечно, наблюдателя исигналыцепочку ответственности, но лучше использовать Посредник, т.к. в теории он принимает запросы между независимыми, несвязанными объектами и реализует заданную логику взаимодействия всех этих классов, которые по-прежнему остаются ничего не знающими обо всех других участниках процесса.ИМХО, знать шаблоны не означает их правильно применять. Много спорных вопросов.
хотите серьезно? вы действительно считаете что ПП редко необходимы? вы тим-лид? расскажите о своих проектах.
Стебадца изволите?
в мемориз!
Именно поэтому, массовое пхание пионерией паттернов приводит к тормозам системы с бешенными оверхедами и абсолютной нечитаемостью и неподдерживаемостью кода. ЭТо происходит из-за того, что апологеты паттернов забывают о очень простой вещи — разделяемости на решения на блоки, чему должны способствовать вообще-то паттерны с полиморфизмом и чему на практике мешают, т.к. системы получаюдца в итоге абсолютно неразделяемыми и крепко завязанными.
И именно по этой причине, код надо писать не с тоннами паттернов, а руководствуясь здравым смыслом и принципом разделяемости кода, а применять паттерны только когда они дийсно необходимы (что на самом — то деле бывает редко).
Ну не знаю... Фабрики тем хороши, что порождающие классы имеют абстракцию, и тебе переписывать ничего не нужно в основном — расширяй базовые классы, и наращивай функциональность, сохраняя при этом предыдущую (у класса А есть абстрактный класс, у класса БЭ тоже, и у фабрики). Фабричный метод тот вообще заменяет тупое создание инстанса на инкапсулированное создание инстанса с его инициализацией... Можно, конечно, доказывать, что class a = new class a (); лучше, чем фабричный метод, потому что всего одна строчка кода, и читается лучше, но... в месяце — 30 дней, базовых паттернов — 23, сделай себе «День паттерна» — каждый день глубоко бури новый, и через месяц ты преобразишься:)
Постулат № 1, который сильно отличает банк от стартапа: система уже работает, она уже кому-то нужна, поэтому новые ошибки в системе по определению делают её менее нужной. Это — не стартап, где «ай, да блин, потом исправим, всё равно сейчас ещё ни хрена не работает». Что подразумевает намного большее включение мозгов при написании нового кода. И да, если систему загнать в угол, то разгонят нафиг весь отдел. Поэтому юнит тесты.
Постулат № 2, который сильно отличает банковские системы: система по определению уже устаревшая и завтра будет ещё более устаревшей. Поэтому все новые изменения нужно вносить с прицелом на то, что завтра вам этот код придётся переписывать. То есть придётся переписывать полностью, и хорошо, если вам, а не Пете, который придёт через три года на ваше место — и даже если вам на это плевать, то на это не плевать вашему начальнику. Поэтому документация.
Постулат № 3, который сильно отличает банковские системы: требования к новому функционалу рождают люди, далёкие от программирования. Им глубоко пофиг на то, как вы элегантно нарезали классы и таблицы в своей системе; им нужно, чтобы воооот здесь появилась воооот эта кнопочка, которая делала воооот это — и им плевать на то, что из-за этой мелкой фичи вам придётся переписывать половину кода. Причём эти люди правы, потому что именно они платят вашу зарплату. Поэтому модулярность, избыточность кода, наличие «точек врезки» для потенциально нового кода, наличие write once кода для задач, которые непонятно, как будут сериализировать, и вообще бизнес-подход к программированию.
Я понимаю, что на ранних этапах стартапа все эти вещи неактуальны, так как ещё ни хрена не работает, бабки не идут, а если потом что-то нужно будет — то перепишем. Я понимаю, что у стартапа действительно важны несколько другие требования: придумать и продать приносящую бабки идею, быстро написать работающий код, который можно относительно безболезненно поддерживать на ранних этапах жизни продукта, выбрать актуальные продукты и т.п. Поинт в том, что вся байда с юнит-тестингом и поддержкой кода у успешного стартапа впереди, поэтому обсерать людей, поддерживающих уже работающие продукты, мягко говоря, недальновидно: я видел немало примеров, когда программеры, у которых клава горела под пальцами в стартапах, остепенялись, приходили в что-то устоявшееся — и заваливали проекты или писали совершенно неадекватный код, так как исходили из других приоритетов при программировании.
2Антон Мартыненко:
Значит это также говорит и о качестве сертификатов Майкрософт. К сожалению на собеседованиях мы проверяли только теорию и результат был крайне положительный. Как проверить практику на собеседовании с общим лимитом в 1 час я не знаю. Кстати, знаком еще с одним человеком, который очень сильно подкован теоретически, часто ходит по IT мероприятиям и в курсе всех новых технологий. НО! Код писать он не умеет, в результате что-то получается, но это просто мрак. И это тим лид! И может быть обратная ситуация: человек толком ничего сказать не может, но может хорошо сделать! Может у Вас, Антон, такой талант, что видите человека насквозь, но насколько я ориентируюсь в пространстве, есть такие персоны, которые проскочат все ваши тесты, собеседования и т.д. и в результате окажутся негодными работниками. Иначе никто бы не устраивал испытательные сроки.
А как же вижуал студия? =)
Неделя неспанья перед релиз означает несколько вещей:а) Менеджер проекта идиoт. Он не смог организовать нормальный процесс разработки с нормальными техниками программирования (парное программирование, код рекью, TDD, функциональное тестирование, UAT и т.д.)
б) Программисты, которые сие чудо писали — гoвнокод копипастеры. Ибо нормальный человек рано или поздно уходит с проекта, в котором «неделя неспанья» и неадекват менеджер, который не понимает зачем нужен код ревью, рефакторинг и TDD
И да, лично я предпочитаю читать код, а не документацию на живом проекте. И рефакторить почаще.
Я хз, кому они там мешают, но мне сейчас приходидца работать на ноуте без второго моника. Скажу тебе честно, что это менее удобно, т.к. у меня на втором висит дока, а в одномониторном конфиге тебе приходидца переключадца между окнами, что дает потерю времени и концентрации.
Если у тебя есть претензии в эклипсу, значит тебе никогда не приходилось писать нетбинсе, кдевелопе и прочих отродиях.
В смысле? Я ничем не размахиваю. И одна из прелестей опыта — я не подвязан на конкретные технологии.
валяние дурака в саппорте — ловушка для дураков.
Шеф, я бы на вашем месте не очень бы и размахивал флагом. Eclipse конечно популярное решение, сам им пользуюсь, но по прожорливости к ресурсам и умению упасть в самый ответсвенный момент ему нет равных.
550 Кбагзов/год — это большой клиент? Клиент увидел данные другого пользователя и свалил, испугавшись что кто-то получит доступ к его данным.
Чья бы корова мычала.
Вот опять — теоретики начинают приводить надуманные аргументы.
В нормальных компаниях есть тестеры. А не программисты ерундой занимаются.
Есть еще функциональные тесты. Никто не говорит про 100%, но качество автоматическое тестирование обычно поднимает.
Еще раз, если уйдет большой клиент — то могут почувствовать все.
Очевидно что я не это имел в виду.
Как показывает богатый жизненный опыт — подобные лажи (на реальных данных) не ловятся юниттестами и могут пролезть при любом методе разработке — или юниттесты уже 100% гарантия безбажности?
Банк разберётся -, но программист ничего и не почувствует. Разве что — без бонуса оставят. Если смогут чётко выяснить чья вина.
Угу. Когда компания живёт с уже готового продукта, который практически не развивается и вся исходная комманда «фанатов своего дела» сбежала. Несколько лет можно и дурака повалять — пока деньги не начнут кончатся. Я обычно «фанат своего дела» — ухожу когда интересное заканчивается.
Это когда — на следующее утро после корпоратива?
Во первых далеко не все и не везде можно откатить. Во вторых ошибки не только в значениях транзакций могут быть, например если клиент увидел чужую транзакцию из-за кривого сиквела, это уже ацкий скандал будет.
Кривущий — подразумевает множество ошибок, а у банка могут быть проблемы уже из за одной.
Разные ситуации бывают, и в маленьких компаниях можно балду пинать, и в больших могут выжимать как лимон.
Поздно, батенька, пить боржоми, если печень посажена:)
Не бывает таких ошибок. Там многоуровневый контроль — и при необходимости транзакции откатываются.
Конкуренты выпустили свой продукт раньше — все на улице. Продукт кривущий — пользователи разбежались — все на улице.Для программиста — работа в большой компании — это ноль ответственности. От этого и разжижение мозгов начинается, от скуки шизоидные идеи появляются — всякие перекрёстные код-ревью и пятимониторные конфигурации (меня всегда поражала любовь у ламеров к мульти-мониторным конфигурациям — хорошо же известно что они больше мешают (lifehacker.com/...boost-a-myth))
Вот не надо ля-ля, как говорится. Я лично тоже был когда-то г0внокодером, и писал г0внокод, и считал, что вся сила — в знании фреймворка, а на собеседовании на вопрос о дизайн паттернах ответил, что да, дизайнил в Фотошопе. Паттерны — это, конечно, не панацея, но каждый паттерн служит для выполнения определенной узкой задачи. Которую до тебя успешно решали. И тебе предоставляется возможность не изобретать велосипед (например, как сделать undo / redo, бляха муха, а его почти никто не делает, не нужно городить свои километры г0внокода, для этого есть memento — все просто до безобразия) и тратить время на его изобретение. Потом, стоимость. А как насчет стоимости сопровождения? Если придерживаться парадигмы г0внокода, то стоимость его будет велика, и дебажить будешь довольно долго, зафикся один баг, и наплодив другие. А есть проекты, в которых гуй сделан на UI application block и соотв. библиотеки инфраструктуры от майкрософта. И ты рискуешь его просто поломать, если будешь программить не по правилам. Просто, паттерны — это чисто шаблоны для выполнения конкретной «миниатюрной» задачи, в рамках всей инфраструктуры (если она может быть в г0внокоде), которые тебе конкретно облегчают разработку и сопровождение. Лично у меня получилось достичь такого дзена, когда внесенные изменения даже дебажить не нужно — все работает на ура, с первого раза. И не надо искать по всему солюшну, а где ж блин у меня используется такая-то переменная, и что оно будет, если ее выкосить.
Опять же ИМХО, но в маленьких компаниях — стартапах цена ошибки часто меньше, поэтому и экономят на ресурсах что бы побыстрее выкатить полусырой продукт.
В общем — сеньёр vs. несеньёр — это банальное «да вы пороху не нюхали». После недели неспанья (перед релизом) всю ночь фиксить баг, который вылазит у реальных пользователей (просто из-за их обьёмов данных), с полным ребилдом и поинт-релизом — тут не до шаблонов проектирования.
Тесты и прочие красивости в банке важны потому что цена ошибки может быть намного выше чем в маленькой компании,
Я был в ситуации подобной автору статьи. И я провёл почти 5 лет работая над успешным -, но жутко кривым — продуктом. Это был самый полезный опыт в моей жизни — я это понял уже на новом месте. Потому что меня научили добиваться результата — и на новом месте были поражены когда я за пару недель сделал нечто, что уже выглядит как продукт.
Тесты и прочие красоты — это круто. Когда сидишь в банке и никому результат не важен. А когда это маленькая компания (или стартап) — то важны два показателя:
1. Стоимость
2. ТТМ (time-to-market)
И в таких условиях не до парного программирования, тестов, группового онанизма и прочих студиозных изысков.
Мой подход — задать вопросы кандидату в разных областях и оценить его по сово_купности (автомодератор увидел здесь слово — с_о_в_о_к; -)) критериев. Ну и конечно нужно ориентироваться на область в которой будет работать кандидат, очевидно что разработчику ИДЕ знать нормальные формы БД необязательно.
Основная мысль автора такова"документация не нужна, читайте код«. Юниттесты, шаблоны проектирования тоже не столь важны, вот цитата.
Т.е. получается, что нужно разучивать код наизусть. Теперь ответьте, какова моя ценность как разработчика при переходе на новый проект, если я забью на «дизайн-паттерны, книги по ОО проектированию и буду тупо читать код»? Скорее всего нулевая. Да, я буду знать наизусть текущий проект, но не смогу написать ничего нового — у меня не будет ответов на вопросы почему сделано так, а не иначе. Не забываем, что далеко не все проекты написаны наилучшим образом. Получается, с точки зрения работника данный подход тупиковый.Может он выгоден с точки зрения работодателя — нет, не выгоден. Т.е. он дает некую краткосрочную выгоду за счет того, что писать код неправильно быстрее, чем правильно. Но люди увольняются, болеют, переходят на другую работу, в конце — концов смерть никто не отменял. И если код не документировать, буквально через год разработки получится монстр который будет совершенно невозможно поддерживать. Я такое видел на нескольких проектах: тонны монструозного кода, люди которые его писали в разное время давно поувольнялись (крепостное право отменено), в результате исправление одного бага оборачивается тремя новыми. Набрать новых сотрудников на такой проект, на рыночный уровень зарплат тоже невозможно. А нафик нужно такое счастье, вместо нормальной работы сидеть над глупыми багами с утра и до забора? Значит приходится переплачивать и во много раз. И это все для того, чтоб закончить пилотную версию на месяц раньше, стоит — ли оно того?
Есть очень много умений, которые приходят только с опытом — например, умение разбираться в незнакомом кривом коде или плохо документированных системах (я когда-то делал инструменты для удалённого деплоя на WAS — это было весело). Отличие сеньёра от несеньёра — это более практичные знания. Несеньёр — пионер, у которого не хватает ума что-то делать не по учебнику. Он заучивает умные слова, а в реальном проекте — начинает плакать что юниттестов маловато.
Ну дык и хорошо. Значит, оне себе таковых и хотят.
Получить знания можно и за год, можно даже за меньший срок, если есть способности и огромное желание их получить. Но практически в каждом резюме стандартное требование — от 2−3 лет работы, участие в проектах. Т.е. налицо требования к статусу, а не знаниям.
Braindump-ы рулят:)
Скорее это говорит о качестве вашего собеседования. Не зря Джоэль писал: «вы же не наймете жонглера на работу не попросив его показать как он жонглирует».
Вот как-то взяли человека дважды сертифицированного Майкрософт, теоретически он ответил лучше всех кандидатов. Не верили своей удаче! Через несколько месяцев пришлось нам расставаться — как практик оказался очень слабым и поломал все что только мог. Чинили после него долго. Вот вам и теория...
ну может кому то будет важно мое мнение:)
Капец. Еще упомяни квартирный вопрос и право на работу за бугром и эта тема соберет снова всех флудеров форума.
По поводу начальной темы с алгоритмами. Мое мнение что человек с позицией сеньор девелопер должен уметь решать разнообразные задачи проекта.и не только на родном для своей должности языке, и должен понимать алгоритмы и структуры данных не для того чтоб их реализовывать (т.к они уже есть написаны и оптимизированные), а для того чтоб реализовавать бизнес требования используя в нужных местах эти алгоритмы и подходы..., а для этого господа необходимо понимание базовых механизмов (не обязательно знать реализацию) и вообще выссшее образование желательно...
Тепер коли самому приходиться інтервювивити, бачу що ситуація така є. Про те які недоліки сінглтона, можна вже не говорити.
Хорошая статья. Достаточно часто приходилось ковыряться в новом/незнакомом коде разных (в т.ч. очень больших) размеров. На мой взгляд, в статье опущен существенный нюанс — чтобы прийти в состояние «дзен» и начать ориентироваться в коде, походить по коду отладчиком (с параллельным чтением проходимого кода и функций вокруг), куда эффективнее одного лишь чтения. По крайней мере, для меня.
Что же касается организации кода — тут, обычно, есть внутрифирменные стандарты на кодирование (шапки модулей/функций, нотация, итд). Считаю необходимым: — дополнительно описывать функциональность сложных функций (которые нелегко читаются, в виде кода из-за размера или сложности алгоритма) — разбивать длинные функции на несколько или выделять вспомогательные классы, чтобы не получать функций, длинее пары-тройки экранов — стараюсь размещать определения классов в персональных хидерах (1 хидер = 1 класс), названных, по имени класса без заглавного «С» — отдельные нэймспейсы (пространства имён), для отдельных предметных областей — избыточно расставлять по всему коду ассерты (помогает и, как средство автодокументирования кода — показывая ограничения на принимаемые переменной значения) — осмысленное именование классов/функций/переменных, по принципу «чем больше область видимости — тем длинее название» — расставление комментариев с отметокой «TODO: » для вещей, которые должны быть изменены/исправлены/добавлены — стараюсь избегать дублирования кода. Если есть возможность реиспользовать существующий код — реиспользую — стараюсь использовать шаблоны проектирования, если возможно
Исторически сложилось с тех времен, когда команда одновременно работала на С#, Java, Delphi. (в придачу три сервера БД — MySql, Oracle, MS Sql Server). Пришлось как-то сближать стандарты кодирования. Многие моменты потом прижились.
BE — неймспейс, Article — класс.
а — используется как префикс для обозначения аргумента метода
_ — для внутренней переменной
f — для приват поля в классе
Конечный автомат
1) Это скорее исключение, особенно для ненавистного многим здесь «интерпрайза».
2) Если не надо бороться за каждый тик проца, то я бы разбил такой метод на логические блоки (если это возможно)
Вопрос ведь немного другой:
Ключевое слово именно «сделать», то есть существуют способы разбить на небольшие методы, но программист сознательно пишет метод на 100−150 строк и получает выгоду.Интересен именно такой пример.
Вы не боитесь летать на Боингах, там используется этот код в управлении полётом?
Спецификацию Вам микрософт забыл подарить, а вам надо её вызвать в своём коде из их библиотеки, причём завтра библиотека будет новой версии, с залатанными дырами, но при
будет блюскринчикто пишем 2 boundary cases типа инфинити, потом проверяем спорный момент 10, 9.9, 10.1 и потом можно еще 2 с произвольными числами rand (> 10) & rand (< 10)
то есть всего 7 в сумме, но как это соотноситься к фабире или дипатчеру?
примеру у вас есть 200 разных сообщений и нужно проверить коректность вызова обработчиков, тут будет достаточно 200 + пара off range тестов что бы это валидировать...
Сколько тестов надо написать в общем случае для проверки функции
так как количество ожидаемых состояний by design = N (3) поэтому и нужно 3 тест кейса что бы их валидировать...
{
case 1: bla1 (arg1);
case 2: bla2 (arg2); break;
case 3: bla3 (arg3); break; }
когда исполняется bla1 (arg1); arg2, arg3 могут измениться, заметтьте нет break; в первом кейсе
к примеру
switch (int i)
{
case 1: bla1; break;
case 2: bla2; break;
case 3: bla3; break; }
порадит 3 случая + 2 баундари кейса, а не 8?
100 — это сто веток switch
2silverwolf — представте себе обработчик сообщений операционной системы — там их может быть куда больше чем 30−50... к примеру так реализован диспатчер в VCL насколько я помню, и такой паттерн часто встречал в Win API приложениях...
2xaxa -
почему такое число? и почему это означает что они не могу существовать?в случае диспатчера где бывает критично время исполнения switch иногда работает быстрее чем подписка или регистрация обработчиков в каких-то структурах данных.
2junior_dev
А можно поподробнее. Если я вас правильно понял, то для того что бы метод был 100 строк в switch должно бить 30−50 case?
бывают такие задачи, что не удается разбить. тут уже ничего не поделаешь., но как правило это можно сделать
2 junior_dev
Такие конструкции невозможно отладить тестами полностью из-за ограничения времени проверки. Вам надо проверить 2 в степени 100 вариантов
У вас там были проблемы с переполнением стека что ли?:)
Вячеслав Землянский, тем что вы тут написали вы себя дискредитировали. Тут не было б ничего плохого (всегда можно восполнить недостающие знания, да и можно быть хорошим менеджером даже с плавающими знаниями), если б не два момента: 1) слепая уверенность в своей крутости, 2) вы собеседуете людей. И вот это все уже печально.
первое что пришло на ум, один из вариантов реализации диспатчера или фабрики на С++ через switch
2Вячеслав Землянский
Хотелось бы увидеть пример такой задачи (подзадачи). У меня есть пару примеров, но все они достигают 100 строк, только за счет форматирования.
А мне вот кажется что основной критерий разбиения на методы — это декомпозиция задачи на под-задачи. А конкретный размер метода — это скорее всего рекомендация, которую не всегда легко выполнить.
Это все стандартные код гайдлайны для ОбжЦ кода, почему товарищь их в ЦРешетке применяет меня не спрашивай.
Ну вы сами подумайте какую ахинею вы несете, линейные размеры монитора больше, значит он может вместить больше информации, следовательно больше строк кода может поместиться на монитор с большей диагональю. О каком разрешении вы говорите?
Зачем артикль в параметре?
Зачем метод не с прописной буквы?
Что за чудо BE.Article? Nested public class?
Какие дюймы??? Вы что, домохозяйки? Или на 40 дюймовом ТВ будет строк больше чем на 17 при одинаковом разрешении?
Мониторы можно поставить один над другим, да и еще в портретной ориентации.
Я уже представил этот22-дюймовых монитора:)
говнокод с функциями на 2Определять допустимую длину метода не понятностью кода, а количеством «экранов» это какой то клинический кретинизм...
у меня другой критерий оптимальности — метод должен быть легким для понимания., а понять легче тот метод, который короче. 6−7 строк — в самый раз. 10 — если не повезло
Вячеслав, здесь народ интересуется о типах полиморфизма от Вашего знакомого Жеки
о которых, по его словам
Собственно интересует пункт 4 с неотносящимися к рефлексии атрибутами:)
Можно пример. Когда есть смысл такое делать? Или вы экономите на вызове методов?
У нас стандартная конфигурация рабочего места — два по 22 либо два по 23 дюймовых монитора.
Оптимальной считается длина метода не более чем на один экран компьютера, чтобы можно было прочесть не листая.
фигасе. я думал что короткие это до 6−7 строк, длинные — 10.
экрана смартфона?
Мы тоже редко пишем комментарии в коде. Только, когда что-то неочевидное.
Но есть пару моментов, которые соблюдаются:
1. Осмысленные название ВСЕХ методов, параметров и переменных, таблиц и полей, кроме общепринятных (типа i, j в цикле), которые ОТРАЖАЮТ суть происходящего на АНГЛИЙСКОМ языке. Никаких русских слов в транслите, никаких сокращение типа svExtInf (опять таки, кроме общепринятых типа SOAP, TCP).
Пример:
2. Короткие методы в один-два экрана
3. Продуманная структура классов ядра и типовых шаблонов реализации той или иной функциональности.
4. Вся более-менее сложная бизнес логика детально прописана в документации.
В итоге большинство вопросов решаются в течении нескольких минут после просмотра кода. По расчетным алгоритмам вначале читается документация, потом смотрится код.
Читай код — новая идеология запущенных проектов, где менеджеры стали выставлять часы на написание документации и тестов, а заказчик отказалася что ли?:)
Спасибо
fprog.ru/2009/issue3
И комментарии писать не надо, все-равно их потом никто не читает.
Читай код© gaperton.livejournal.com/32772.html
это вполне адекватный ответ на, кстати, странный вопрос.
а ти, очевидно, інтерв"ювером був.
попалив сам себе.
Был на таком собеседовании, спрашивали такой бред, кое что наверно дочитывали как раз перед собеседованием. Ну доказали мне что они гуру, мне то что. Предложили скосить 300 у.е. от запрашиваемого, отказался. Позвонили через 3−4 дня, говорят приходи на зп которую указал в резюме. Ну пришел, думал там проект вершина инженерной мысли, а там только заказчик жирный, а код использует либы написанные американскими индусами, ни junit, ни javadoc. Спрашиваю как работает метод? отвечают поищи поиском в коде, найдешь пример, так и используй. Вообщем ушел через 2 дня, а вакансию надо называть не senior java developer, а senior java debugger.
Наверное так утверждают те, кто считает серебряной пулей ООП вообще и ООП-синтаксический сахар в частности.
И после этого кто-то еще пытается утверждать что Си убог
похоже начальство глючит
А что такое полиморфизм? Вызов различной реализации через одну сигнатуру метода. И все.
Піпець, а в якій мудрій книжці таке пише?)) А наслідування від абстрактного класу чи реалізація методів які є оголошені і можуть бути реалізовані в «частковому» класів, що є новою фітчою.NET 4, або ж використання «extensions», тоже окремий поліморфізм?) Мені особисто здається, що є такі сеньйори (що співбесідують), які завчили мудрі слова — «цікавинки» на яких тупо можна ловити майже всіх і тим показувати який він модний перець, а по нормальному можна просто перефразовувати попростіше питання.
Надо сказать, что это та штука которой мне лично дико не хватает в C#, куда как элегантнее получаются некоторые решения на Python, нежели на решётках. Впрочем:) статическая/динамическая типизация это известный холивар.
А можно поподробнее, я в этом (ФЯ) пока новичёк, в Эрланге с таким понятием не сталкивался.
Ну смысл хотя бы в том, что в одном случае тебя возьмут на работу, в другом — нет...
Ну там по си-шарпу вопрос был. Хотя вот у меня лично подозрение в адекватности (ну или если хотите академической точности) определения полиморфизма через рефлексию и аттрибуты. Само собой возможно я не так понял ответ сэя Евгения:)
Очевидно, что смысл в поднятии ЧСВ господина Землянского...
BTW: знание всех видов полиморфизма — это конечно не лишнее, но лично я в этом не вижу огромного смысла
+ есть градации полиморфизма в ФЯ (ad hoc), которые отличаются от ООП языков:)
Тогда еще 5: с помощью реализации абстрактных методов. Гы.
Да, про полиморфизм очень некачественный вопрос получился — чем принципиально отличается 1 и 2? Очевидно что такая класификация специфична для конкретного ЯП, так как в Ц++ никакой рефлексии нету, а в джаваскрипте все делается через рефлексию...
Совсем никакого? А к чему они тогда имеют отношение?:)
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)
примеры можно?
1. Стандартный способ используя наследование
2. С помощью интерфейсов
3. С помощью рефлексии
4. С помощью аттрибутов (да-да аттрибуты не имеют никакого отношения к рефлексии)
Каюсь, что определение
По теме топика:
Лично мое мнение, что синьйора НЕ характеризирует количество известных ему технолоний или фреймворков (может быть косвенно), а степень ответственности. Если вы можете решить бизнес задачу, потратив при этом наименьшее количество ресурсов (прежде всего времени), и оставив достаточную гибкость для дальнейшей разработки и поддержки — вы можете считать себя синьором. Если вам доверяют только написание тестов — вы уж точно не синьор...
а кладут
Я вообще когда пришел работать мне сказали, что эти НФы не нужны вообще, а настоящие мачо проектируют базу так чтобы она быстро работала и без лишнего количества всяких иннер жоинов. Потому в таблицах много дублирующейся информации и на НФы все ложат.
меня тоже очень интересует 4 способа. кроме того интересно как рядовой начальник формошлепа, регулярно использует полиморфизм.
славик, скажи
есть библиотека из 100 контролов. они отвечают на какие-то встроенные gestures (типа ховер там или придумай что-то еще).
и есть аппликейшн, который использует все контролы. тут внезапно кодерок решил добавить парочку контролов и новый gesture better_hover.
вопрос: как ты бы все это организовал, чтоб библиотечные контролы могли отвечать на новые пользовательские gestures (не меняя пользовательский код который уже использует контрол. КО). и как это лучше сделать на статик и дайнамик тайпед языках и что бы ты выбрал.
> чем отличается 2 от 3, то как он будет работать с такой базой?
отлично он будет работать. 3я нф интуитивно понятна и ее достаточно.
о 4 способах?
Это базовое понятие для любых ОО языков програмирование. Не понимаешь сути полиморфизма — не используешь значительную часть возможностей языка. К примеру, в С# есть минимум 4 способа реализации полиморфизма — и все имеют свою область применения.
А по поводу нормальных форм — при проектировании реальных баз данных обычно используются 2 и 3, причем в некотором миксе и в сочетании с нестандартными конструкциями. И если человек на собеседование не может внятно объяснить, чем отличается 2 от 3, то как он будет работать с такой базой?
Что пристали к человеку? Ну, не знает он ответа.
-
-
-
-
-
-
-
-
-
-
2down by the water
А вы задавали какой-то вопрос?
это как-то отвечает на мой вопрос?
Полиморфизм это не динамическая типизация
.
славик, а что для тебя полиморфизм в свете перечисленных тобой в профайле статик тайпд языков?
Таки да, найти хорошего сеньора или техникал лида серъезная проблема. Многие из претендентов не могут внятно объяснить, что такое полиморфизм или третья нормальная форма БД.
У Нейгела точно є, а також звичайно в MSDN: msdn.microsoft.com/...y/he2s3bh7.aspx
По моему даже в Рихтере (у меня бумажная по 2.0) есть поверхностный обзор коллекций.
>> 2PomAH4uK
Ха, справді здивували, я так думав)). Ну от прочитав по самому.NET 5 книжок, і жодного згадування про LinkedList. До такого мабуть практика приводить. Чи є специфічна літературка якась хороша, кромі Ріхтера (читав, по GC не всьо поняв:)), де про цікавинки дотНета згадуються?
Якщо під списком малось на увазі сішарпний List< T>, то я вас мабуть дуже здивую що насправді це трохи продвинутий масив (аналог std: vector< T> з C++). А списком насправді є LinkedList. Ось тому і важливо питати такі питання.
Фреймворки это решение для всех... решение для всех, никогда не будет лучше решения только для вашей задачи (всегда есть ограничения изветные вам by design которые могут оптимизировать общее решение с разных точек зрения), а синьер это один из людей который начинает отвечать за решение (solution) и принимать решения (decisions) для развития проекта, этому в его же интересах знать как устроен фреймворк что бы знать что из него можно выжать, а что нужно будет подпилять...
а смотреть как утроен фреймворк тож не зазорно для синьера, если не он то кто? когда остальная команда не знает что делать?
По поводу питання, ніколи не юзав. Понятно що для першого варіанту додавання обєкту буде швидшим в простому Дікшенері, пошук обєкта буде швидшим для Сортованого, тобто якщо дікшенері більше для читання, то СортедДікшенері, якщо часто міняється то просто дікшенері. З другим затрудняюсь (тому і не сеньйор:), можливо СортедДікшенарі для класу має сенс коли клас реалізує інтерфейс IComparer (якось так)?
-
и например для случаев SortedDictionary< MyClass, int> VS Dictionary< MyClass, int>?
Уточнення, окрім коли вам потрібна спеціальна колекція, як SortedList etc.
Гг, матьоро ви хочете щоб сеньйор кожного фреймворку знав деталі і щоб алгоритми знав на память. Я не сеньйор, пока думаю до мідла доріс, але ніколи не доводилось працювати з самописними структурами, чесно кажучи неясно де це може бути корисним в.NET. Я думаю в.NET є більш важливим знання особливості технологій, там найбільше можна оптимізувати швидкість, використання ресурсів (LINQ запити, конфігурація WCF, багатопоточність, GC), а також знання паттернів/ооп. Нераз жертував швидкістю заради простоти коду, небачу в цьому проблему, хіба що б прийшлось писати високонагружений сервіс який не можна розприділити, думки що краще використати список чи масив взагалі не виникає, завжди список — так легше:). Тим не менш різницю цього на мій погляд сеньйорові треба знати. Взагалі думаю для складних алгоритмів мають використовуватись математики, а для написання сторед процедур розробники баз даних, а не майстер Вася, що на всі руки герой.
Прошу прощения, просто было впадло переключать раскладку, обычно я таки использую англ написание
Вот откуда у вас эта привычка — equals, multy threading — икуалсы, МАЛТИ ТРИДИНГ (первый раз вижу такое обозначение)?
Никто и не предлагает их править.
Для того что бы не выжирало память и не тормозило все и вся. Необходимо знать и понимать когда и как хебернейт пишет и читает в базу, как и когда происходит флаш, как он рабает с кэшем, как происходит инициализация коллекций, какие есть особенности при работе с хибернейтовыми проксями, как работает HQL, и как его писать что бы он не делал по стопицот запросов в базу, более узкие вопросы типа «в какой версии можна получить доступ к внутреннему представлению прокси, а начиная с какой уже нельзя? »
Интересная логика. Джун должен знать структуры данных, а синьор нет? У джуна можно спросить чем LinkedList отличается от ArrayList, для чего нужны Map. А вот синьора можно попросить реализовать мапу (хоть чтение/запись), поспрашевать про хеш коды и икуалсы (хотя можно найти и вопросы поинтереснее).
У джуна это тоже можно спрашивать. Разница в уровне знаний. Джун должен просто понимать что происходит и знать наиболее частые ошибки, в то время как синьор обязан уверенно работать с многопоточным кодом, если ему это надо. А если работа не подразумевает активной работы с многопоточностью, то смысла гонять нет.
p.s. Кстати, название топа несколько провокационно. Как минимум до тех пор, пока не будет дано определение того, что в ходит в круг ответственности сеньора/лида. Слишком широкое обобщение.
Сеньйоров, имхо нужно по малти тридингу гонять. (речь идет о жабе)
2 silverwolf
Я например не понимаю зачем мне понадобилось бы знать вунтренее строение хибернейта. Имхо, синйор в этом плане должен знать что это такое, как им пользоваться, какой перформанс геп, как тюнить, какие альтернативы и как пользоваться плеин ждбц. Зачем для этого внутренность хибернейта знать — непонятно. Править его сорцы при каждом случае — плохая идея. И если таки вдруг прижмет перформанс именно в хибернейте, а уйти от хибернейта нельзя — то невижу проблемы таки заглянуть внутрь сорцов.
Касательно того чем отличаеться сеньйор от мидла — то тут зависит от контор. У нас например это степень доверия.
Это была суровая правда жизни...: (
Это был сарказм?
Кто-нибудь другой. Неясно кто, но определенно не такая важная птица, как сеньор на Люксе-Глобале-Эпаме.
Целый день висеть на ДОУ-ВКунтакте-Фишках-Youtube.
Размером ЧСВ.
2. ЧСВ больше еще.
2eugene_n
Два вопроса:1) Тогда кто это должен знать? Кто должен принимать решение использовать кукую придлуду и использовать ли?
2) Что входит в обязанности синьора (кроме получения 2500 Кбагза)? Чем он отличается от мидла и/или джуна (кроме ЗП)?
По поводу трех плюсов абсолютно согласен.
-
-
-
-
-
-
-
-
-
По поводу же собеседований, я соглашусь с мнением о небольшом тестовом задании — совершенно не обязательно его задавать домой, достаточно на собеседовании не иппать мозги тремя китами ООП и ребусами из трех плюсов подряд, а вбросить что-нибудь из задач, на которые собсно и берут человека, и посмотреть как он подойдет к их решению. Так себе, на уровне блок-схемы, без кода на бумажке.
-
настраиваюсетаплят фреймворки? Я не синьор, спринг насетапил менее чем за час (насколько оптимально не скажу, проект «домашний» ), с хибернейтом было сложнее поскольку там где я работаю на него уже написана оболочка, которая значительно упрощает использование.Синьор (Джава) должен, кроме алгоритмов, понимать как работают те же спринг и хибернейт (для этого кстати надо понимать структуры данных:)), и уметь
ихих использование оптимизировать (например се=делать так что бы код который использует хибернейт не выедал гиг памяти)Вариант для соискателя нигде больше не работающего. Человек с работой сможет засесть за твое задание только ближе к выходным.
Думаю, что в зависимости от того, каким конкретным образом складывалась карьера каждого конкретного программиста, мы получим совершенно разные ответы от разных людей.
Да, в общем-то, даже тот же перевод числа в пропись можно реализовать сильно по-разному стилистически, в зависимости от того, какие задачи были до этого у разработчика. Можно сделать очень эффективный алгоритм, можно сделать алгоритм с очень большим оверхедом, ну и все градации посредине.
Сеньор — это тот, кто может «насетапить... и прочую фигню»?
А где вы видели безработных сеньоров?... Покажите плз, у нас в компании за них бонусы 500−1000 баксов.
Я думаю на собеседовании стоит использовать смешанный подход. Вопросы по алгоритмам это хорошо, но реально их почти никто не использует. Вот те же паттерны куда важнее для дотнетчика/джависта.
Можно часик поспрашивать по теории, потом дать относительно простое задание (но не примитивное!) и посмотреть как человек его реализует (например, в Карговайзе было: написать программу, которая переводит сумму денег в цифрах в сумму прописью). Можно уложиться в 3−4 часа и дать ответ в кратчайший срок.
Grez, ИМХО, человек, которого вы описываете — это джуниор. Ну или человек из другой области, который её меняет.
Речь идёт о безработных, ищущих работу. С работающими, обычно, всё несколько проще (в смысле квалификации) -, но сложнее, в смысле зарплат.
То на что у человека концентрируемого на алгоритмах уйдет неделя времени, у такого синьйора займет пол часа.
Для того что бы проверить кандидата существует обыкновенный «испытательный строк». Собеседование нужно для того что бы узнать стоит ли тратить ресурсы компании на «испытание» кандидата. Если кандидат-синьор не знает основ программирования (алгоритмы/структуры и тд), то на мой взгляд тратить на него ресурсы не имеет смысла (по крайней мере расценивая его как синьора), ИМХО.
и кто в здравом уме на это согласится?, а что рассказывать на текущем месте работы? простите, я недельку пособеседуюсь, если чо — то останусь у вас, а потом еще недельку в другом месте.
Если хочется проверить реальный уровень квалификации подходящего по бумагам и интервью соискателя-разработчика — можно дать ему оплачиваемое задание, скажем, на неделю работы прямо в офисе. Т.е., чтобы каждый рабочий день в течении недели чел приходил в офис, как на обычную работу и работал по заданию, на выделенном ему рабочем месте. Своего рода «испытательный минисрок».
Думаю они их не дают в первую очередь потому, что нет возможности проконтролировать что кандидат выполнил его сам. У многих людей желание попасть туда настолько велико, что скорее всего такие задания будут выполняться целыми индийскими селами...
А на тему украинских реалий это не проканает еще потому, что у нас очень непрозрачная процедура приема. Интервьюер как партизан молчит про вилку ЗП и пытается всеми силами вытянуть из тебя на сколько ты согласен. И заодно присматривается блефует кандидат или нет. В результате далеко не каждому хочется писать 2 дня задание для какого нибудь Самсунга что бы в результате узнать что тебе с барского плеча согласны предложить аж целые 1700 долларов.
Майкрософт и Гугл, кстати не дают таких заданий, а упор делают на соображалку. А люди не знающие разницы между массивом и списком отсеиваются после первого же телефонного интервью, если они каким то случайным образом на него попали.
Ага, только далеко не каждый уважающий себя кандидат будет сидеть на шару двое суток задание Вам делать. Если Вы конечно не в Гугль или МС собеседуете...
Я имею введу техническое собеседование.
Ну, например, я исключаю вариант дать задачу на месте и пусть решает. Во-первых потому, что в таком случае задача должна быть тривиальна, чтоб кандидат не сидел день в офисе, так как это скорее всего пугает человека (сужу по своему опыту). Либо какая-то специфическая, с чем кандидат вполне мог и не работать никогда. Получаеться, реально оценить знания таким способом нельзя. Как и теоретический подход, тоже бред ИМХО, конечно.
Приходит человек на собеседование и говорит «у меня была ЗП 2500» по вашей логике его надо брать, ибо синьор, а тот факт что он на мидла может и не тянуть и его предыдущий работодатель лох не рассматривается?
Знание «алгоритмов» и правду вторично, главное как человек сможет выполнять свои обязанности (программиста). Каким образом вы предлагаете проверить умения кандидата за пару часов собеседования?
класс!
В точку! Ну не зря же пословица такая есть: «Дурак думкою багатiє». Если кто-то не сеньор, то по крайнер мере он может себя самоуспокоить поначитавшисть алгоритмов:).
А вобще тут когда гер Антон Мартыненко правильно заметил — не получаешь 2500 значит не синьор, а все вот эти знания алгоритмов это как-бы вторичный признак.
Однозначно. Если код сложный и/или нужен узкоспециализированный анализ — то «кодеревьюверов» может быть и больше одного.
хорошо. поставим вопрос по другому. тот, кто ревьювит код, должен хотя бы минимально понимать что написано?
Ребятки! Может хватит выборочной модерации, да?
А по теме, я к сожалению встречал «сеньоров», которые были не в ладах даже не с алгоритмами, а с простой житейской логикой и в написании простейшего кода рвали гланды через жопу.
Антоша наверное думает, что если он земляк пахана, то ему тоже дадут маленький руль порулить.
Ничо, эмбеддеры с умениями обращаться с паяльником тоже без работы не останутся, когда надо будет узнать номер «счетика в Швейцарии».
Валите в бухи и юристы. С новым НК это станет архивостребованно.
А еще у вас нету паяльников и осциллографов, лузеры!
Ембеддеры, сиплюсплюсники и прочие унылые. Хватит завидовать джавистам и точканетчикам за их высокую зп и успокаивать себя что они «Не знают что такое О (n) ».
Это вопрос баланса технической (специализация в некоторых предметных областях) составляющей и управленческой. В разных ролях в разных организациях пропорции этих составляющих могут существенно отличаться.
Если рассматривать «начальника» как надпись на визитке и прибавку к зарплате — это одно. Если же это лицо, которое реально организует работу коллектива, принимает решения, обеспечивает достижение целей организации в рамках имеющихся ограничений (бюджет, сроки, требования) — то это совершенно другая история.
И для последнего типа сотрудников с сильным перекосом в организационную составляющую ключевую роль играют совершенно другие знания и умения. Что, впрочем, не исключает того, что кое-кто при этом будет разбираться и в деталях ООП, и особенностях классических алгоритмов.
Если бы я был начальником — специально бы обратился к гипнотезерам, чтобы навсегда забыть всю эту кодерскую муть.
начальник тот = программист + некоторые функции, которыми занимается только он
Зрозуміло що програміст повинен вміти думати і не знати що таке інкапсуляція, а розуміти. аналогічно з структурами даних 5, 10 чи 3 — яка різниця — головне щоб розумів що то за структура, для чого, міг на прикладі 2 чи трьох структур порівняльно охарактеризувати.
І дійсно в окремих випадках буває необхідність в власній реалізації необхідної структури (приклад — великі обєми даних, специфічний тип звязку між даними,
специфічний спосіб (поведінка) в обміні даними між структурою і споживачем).
Смотря что вкладывать в роль «начальника». Это может прозвучать немного странно для разработчиков, но у руководителей выше некоторого условного уровня несколько другие задачи, приоритеты и ключевые области знаний/умений.
я встречал начальника, который не знает что такое инкапсуляция
Прикольно. Модеры сами заинтресованы в разжиге срача?
Почему вы решили что к вам приходили сениоры и лиды? Так написано в вашем объявлении о работе? Или так написано в их резюме? На заборе тоже написано, а там дрова лежат... Переманить настоящего сениора или лида, врядли у вы такую зп платите:)
Не, ну я например носил, ибо ОпенСорц (ну типа), только их никто не спрашивал.
2 Serzh-GT:, а может там просто люди уважают друг друга?
там модеры более жесткие))
IT сообщество, IT сообщество.Курятник какой-то, а не сообщество. Все наровят клюнуть ближнего. Интересно, насколько часто подобные темы возникают на буржуйских форумах?
Тяжело за 1 час на практике оценить знания человека. Так что срез знаний будет очень ограниченный. А исходники с прошлой работы никто ж не понесет:)
1. реальное (посмотреть код)
2. нереальное, типа нерешаемого математического алгоритма или задачи ИИ. А потом разобрать как пытался решить.
аааааа, Гы испортил ржачную ветку (((
На фоне дурака всегда выглядишь умнее.
Я никого не пытаюсь опустить. Я сам по себе умный.
Если умеешь думать, то очень быстро найдешь себе занятие по душе. Ищи работу, где твои знания были бы востребованы
Пишущие умные велосипеды по чужим алгоритмам ржут с фреймворков.
Математики-исследователи, изобретающие эти алгоритмы, ржут с вас умников так же. Чем вы не такие же обезьянки?
Интересна природа человека, все желают опустить другого, чтобы стать выше и не двигаясь.
Возможно из-за своего скудноумия тут все этого еще не поняли, но думать надо всегда. Просто не всегда готовы платить за то, что ты будешь думать. Банальная экономическая целесообразность решает в итоге. И если бы существовали тренированные обезьянки, способные писать код безвоздмездо и хотя бы на уровне сегодняшних Жаверов и Дотнетчиков, жаберы и дотнетчики уже давным бы давно искали для себя новое занятия для зарабатывания денег...
Ну, значит так писали...
Господа, не надо гипербол. Банальную разницу между списком и массивом любой, кто претендует на синьора все же должен знать. Не говоря уже о том, что попадаются программисты с опытом 4−5 лет, которые тяжело различают интерфейсы и абстрактные классы, убеждены что если объявлен конструктор, то конструктор базового класса в жизни не вызовется и тд
Ну да, ну да, зачем нам думать, если все придумали за нас?
про жаву сказать ничего не могу. не моя специализация., но вот вместо некоторых алгоритмов.NET мы импользовали свои самописные. я не говорю что они не работали, но производительность приложения из-за них падала.
а вообще C# или Java программеры могут и не знать о том что такое стек, для них это нормально. этого может и нету в книгах по данным языкам.
Сорцы жабы смотрел. Впринципи все довольно понятно, аккуратно и грамотно выполнено. Ну да есть некоторые методы с сложной математической составляющей. Но я могу быть спокоен и не волноваться, ведь это наверняка писал кто-то из МИТа и наверняка с научной степенью, а не Вася из аутсорса.
Он виртуальный в смысле «магии фреймворка», так как ведёт себя как виртуальный. Ну по сути берёт данные из внутренних структур метаданных, куда напрямую нед доступа разработчику.
вы вообще смотрели исходники таких фреймворов? посмотрите исходники некоторых алгоритмов в.NET с помощью рефлектора. вас они приятно удивят.
Считай, что тебе повезло и небыло готовой либы, либо ты плохо искал и необоснованно потратил на это месяц другой. А вот если твой босс узнает, что ты писал ручками, то что уже давным давно есть в любом ОпенСорс проектике — то жди жопоболевых ощущений.
Правильно. Но большинство сеньеров C#/Java на этот вопрос не ответят. Так как всегда есть готовый фреймворк.
GetType не виртуальный))
ИТ инженерия с самого своего становления стремится к сокращению расходов, любыми средствами.
Я понимаю что большинство кодеров в Украине меряют только по своему унылоынтырпрайзу и веб-деву, но что если у меня в проекте написанные ручками реализации структур данных и некоторых алгоритмов потому что СТЛ не вписывался в тесные ограничения железа?
почитайте книги чем вообще важна рекурсия или вам на форум в ветку ’для новичков’.
да и вообще к чему вы всё это?
Если все так печально, то почему бы Вас не уволить, и не взять на Ваше место тренированную обезьяну?
Тем что такие задачи на собеседовании решаются на автомате. Смотрят на метод, а не на содержимое. В данном случае в обычном методе вызывается по сути виртуальный GetType ();
Спросите любого явиста или шарписта нафига в этих языках понадобился базовый класс Object. Из человек 15ти, ни один еще не ответил более-менее вразумительно.
Я не говорю уже про механизм работы вирутальных функций. Один товарищ мне заявил, что за него все делает JVM, и ему глубоко пофиг как оно работает:)
Тут правильно написали: в аутсорсинге подобные вещи зачастую никому не нужны. Есть же FRAMEWORKS! Но, как писал Блох, одними из основных качеств хорошего программиста являются высокая самообучаемость по собственной иннициативе, желание разобраться и понять «как оно работает» и написание кода дома just for fun. Посему любители FRAMEWORKS!, слепо исповедующие принцип «подключил и забыл», у Анонимуса зачастую идут лесом.
На сегодняшний день все это уже написано до вас. Нужно лишь знать примерно что это и уметь грамотно им пользоваться. А реализовывать это все будут высокооплачиваемые буржую в классных конторах и с нормальными сроками на задачи. Как то читал, что на написание генератора рандомных чисел для Java высококлассные спецы потратили не один месяц работы. В аутсорсе никто не будет ждать даже недели, пока какойто Вася пишет классные структуры данных. Аутсорс на это банально не расчитан.
Потому хватит играться в высококлассных инженеров, а элементарно давайте спускайтесь на грешную землю ко своему говнокоду.
Это как то отменяет необходимость знания на память сложности поиска элемента в хэш-таблице или рб-три? (даже если Вас разбудили с таким вопросом в 3 часа ночи с бадуна)
вы о чем? о_О какой еще виртуальный метод?
Тем что все эти структуры можно описать через все эти три определения.
ru.wikipedia.org/...структур_данных
С деревом ошибся. Правильнее граф. Так как дерево по сути ациклический направленный граф.
Умный вы наш. Тогда ответьте на простой вопрос — для каких структур данных наиболее важна рекурсия и почему?
Я счастлив услышать такое многозначительное заявление от столь авторитетного источника.
Что Вы этим хотели сообщать миру?
Под этим словом много смыслов. Вы что имеете конкретно в виду?
Не согласен. Дерево это самостоятельная структура. А вот матрица и вектор это массив массивов и обычный массив соответственно.
Обычно все умные пока им не приходиться самим отвечать на вопросы, я про анонимусов...
ааааа, Soft ещё сильнее лажанул:)
А дерево — список списков.
Так структур данных всего 3: — массив; — список; — дерево.
Остальное модификации от них. Например то же самое октодерево и бинарное дерево по сути обычное дерево с разным числом ветвей.
ааааа, Дмитриц Ковтун лажанул:)
Так это тест не на знание C#, а на внимательность. Вы бы еще картинки с дельфинами — найди 10 различий давали. Тоже сперва глянул на то что метод не виртуальный.
Тоесть ты не только не можешь назвать 10 структур данных и сортировок, но и даже не особо умеешь читать? Так ты не потянешь на лида по СРешетке, максимум синиора.
будет true, так как GetType возвращает тип созданного обьекта независимо в каком из родителей он был вызван
двойка тебе
Для одно и того же инстанса вызывается виртуальный метод GetType, и независимо от стека вызова вызовется реализация метода для класса B.
Ты написал «10 основных структур данных».
Причем товарищ выше (а по его сообщениям раньше в его адекватности я не сомневаюсь) 10 не назвал. Да и некоторые структуры с натяжкой можно было бы объединить в одну.
Ну так теперь давай, яви нам знания основных структур данных))
Это си#??? Не знаю его вообще, но могу догадатося что будет false ибо obj.Get () вызывает метод унаследованный который вернет type A, а obj.GetType () вызывает метод системый который вернет type B. С точки зрения типов это совершенно разные типы. Правильно ответил?
Мне интересно как они доработали до такого опыта. А меморилики бывают даже с GC.
Ну значит Вы исключение. Что никак не меняет общей картины.
Что значит громлю? Просто по своему опыту из универа и работы вижу, что туда идут не отягощенные душевными терзаниями по поводу алгоритмов и анализа сложности люди. Да и по работе оно им не надо в 99% случаев.
Это как в школе, когда люди которым на все положить поступают обычно на экономический.
Ты не можешь из головы назвать 10 структур данных/сортировок? Канонический точкаНЕТчик?
“True”?
class A {
public Type Get () {
return GetType ();
} }
class B: A {}
static void Main (string [] args)
{
A obj = new B ();
Console.Write (obj.Get () == obj.GetType ()); }
Таже тенденция касается и этого топика. Умные люди сюда не пишут.
Большая:)
Eго не меньше. Просто, пасётся такой «думающий народ» — в более приятных местах, чем совковая Украина.
А какая разница между массивом и списком? А то я вот уже месяц по собеседованиям хожу, никуда меня брать не хотят, все спрашивают в чем же разница, а я ничего толком родить не могу. И в гугле меня, кстати, забанили.
А придумать действительно нужную задачу тоже трудно? Помнится в той же ветке самсунга некоторые эмбеддеры писали, что за все время работы им такая функция не понадобилась ни разу.
Человек который бы не смог мне объяснить разницу между массивом и списком сразу бы пошел с собеседования домой. Еще в ветке самсунга пробегали возмущения людей, которые не могли перевести строку в число. А вообще это все печально, как то все меньше и меньше народу думающего.
До сложности алгоритмов иногда и не доходит много народу отваливается еще на стадии обработки ошибок;)
LOL. Назови плз десяток основных структур данных.
anonymous, а ты на чем пишешь? И почему же ты сишарперов громишь анонимно?
А зачем? Были здесь утверждающие, что нафиг алгоритмы, когда есть готовые фреймворки.
И как успехи? Какой процент претендующих, например, на должность мидла.НЕТ хоть что то понимает в оценке сложности алгоритмов и знает сложность десятка основных структур данных и сортировок?
Времменную сложность я спрашиваю часто. Но мне хватает обьяснения на пальцах, без цитаты учебников. Главное чтобы человек понимал разницу.
А вы кроме сложности алгоритмов ничего не знаете? Дальше не продвинулись? Это ваш порог компетентности? (Спасибо DedushkaGrga за инфу)
Интересный вывод)) С какой строчки моего поста вы его взяли?))
Я конечно не хочу никого обидить, но чего вы ждете от программистов на точкаНЕТ, что они реально будут знать, что доступ к элементу массива О (1), а к элементу списка О (н) и что они вообще будут знать что это за «О» такая и с чем ее едят?
по сабжу — бугога:)
внутри метода можно объявить классы в Java — это локальные классы. им можно давать имена. есть и анонимные
Так внутри метода объявить класс например в C# нельзя, можно создать объект анонимного типа. Может имелось ввиду это?
т.е. вы даже не предполагаете, что такое высказывание могло быть сделано намеренно? С целью посмотреть на реакцию.
Принцип Питера детектед.
Ну, а что тут удивляться? Я как то работал с ТимЛидом у которого за плечами 10ть лет. Так вот, не знать базовых вещей — для него это было нормой. Его гонор перекрывал брешь космического мастаба в его знаниях.
Собственно это издержки оутсорсинга: в большинстве случаев мы имеем проекты поддержки, изредка разработка новых фич, отсюда и подобное отношение.
сам обновляє топік
Ну это типа вброс был, думаю к вечеру тема наберет обороты...
Ну и?