0,0
рейтинг
17 июня 2012 в 13:44

Разное → Когда я говорил…

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

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

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

Когда я говорил, что нельзя всех подряд называть «синьорами», вы продолжали их создавать. Теперь у нас куча 23-летних синьоров и все равно х*р его знает, чем абстрактный класс отличается от интерфейса.

Когда я говорил, что люди важнее процессов, вы продолжали устраивать agile тусовки и устанавливать скрам-доски. Теперь у нас тотальный скрам, а проекты, согласитесь, делаются все так же хер*во.

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

Когда вы говорите, что программисты зажрались, то вы правы – ведь вы сделали все правильно!

* «Я» — это собирательный образ, любые совпадения случайны.
Краковецкий Александр @sashaeve
карма
435,2
рейтинг 0,0
CEO DevRain Solutions
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разное

Комментарии (443)

  • +12
    Это в большинстве компаний сейчас так, к сожалению. Острый дефицит квалифицированных кадров, раздутые зарплаты, некомпетентные сотрудники, и, что самое печальное, никто не знает, что со всем этим делать.

    С другой стороны, такая ситуация выгодна для квалифицированных сотрудников, которые будут на вес золота.
    • +21
      По поводу высококлассных специалистов, думаю, вам будет интересна моя предыдущая статья.
      • +4
        Service Unavailable
        • +1
          Может хабраэффект?
        • +3
          23-синиоры девелопили?)
          • +1
            девелопили, девелопили да не выдевелопили.
      • +3
        хорошая статья, во многом Вы правы
        • +1
          Спасибо.
      • +1
        С юмором, а все правильно написали, спасибо :) Еще на том сайте улыбнуло, что при наведении на аватарку комментатора выскакивает «Показать профиль %(name)»
    • +23
      Квалифицированные сотрудники часто зарабатывают меньше идиотов.
      • +7
        каждый сремится достичь уровня своей некомпетентности, а переход на каждый новый уровень (обычно) сопровождается повышением зарплаты.
        • +1
          1) Как определить когда этот самый переход произошел?
          2) А уж тем более как заставить начальство понимать, что это произошло и что это надо как-то поощрять?
          • 0
            1) когда вас больше не повышают или, ещё хуже, повысили, а потом понизили
            2) начальству есть смысл поощрять пока он не достигнут, когда достигнут — только удерживать и то не факт.
            • 0
              1) Я имел в виду что это за событие «переход на новый уровень»:)
              2) Как я понял не так давно, не всякому начальство понимает что есть смысл поощрять. Мало того, некоторое начальство вообще имеет странную философию, а именно: «Почему вы думаете что зарплата человека со стажем и опытом должна расти?» У меня прям челюсть отвисла и понял что разговаривать тут больше не о чем.
              • 0
                1) когда знаете, что можете больше денег получать за ту же работу
                2) А почему должна? Должна если увеличивается производительность при требуемом качестве. Да ещё если это повышение положительно отражается на прибыли фирме.
                • 0
                  1) Да человек то знает, а толку от его знания, если в компании на это могут просто закрывать глаза и сами не заикнутся о том что они знают:)
                  2) Я тут с Вами отчасти согласен. Но:
                  — с опытом растет качество работы(я сейчас говорю про хорошего разработчика а не пофигиста)
                  — Опытный человек становится учителем для новичков. А это твои новые обязанности
                  — Опытный человек участвует в отборе новых работников, отсеивая откровенно хреновый код и давая свою оценку.
                  — На этого разработчика с годами может сваливаться и другая работа. Т.е. он уже не просто разработчик, а и архитектор и разработчик и чуть ли не ПМ и тимлид и верстать сможет и области знаний у него шире и еще что-нибудь накинуть могут:)
                  А люди сверху как бы не замечают что на одном человеке много что держится, и он вроде на бумаге просто разработчик.

                  Это все к тому что с опытом в нашем ремесле должна и зарплата прибавляться. Начальство при этом прямого увеличения выхлопа в виде денег может и не замечать, потому что человек может делать много чего где прибыль посчитать невозможно, а работа его нужна.
                  • 0
                    Постоянный рост ЗП работника негативно сказывается на его мотивации. Звучит парадоксально, но это факт. До определенного времени знания напрямую конвертируются в деньги, но потом каждый дополнительный уровень опыта приносит только косвенную прибыль, потому что время ограничено, и именно оно является бутылочным горлышком у опытного работника. Осознавая этот факт, работник начинает уменьшать рабочее время, которое он тратит на работу, чтобы еще больше максимизировать прибыль от продажи своего рабочего ресурса, таким образом попадая в ловушку собственной лени и снижения мотивации.
                    • 0
                      Постоянный рост — да, хотя для всех это понятие разное. И понятно что у в данном регионе для данной отрасли есть определенный максимум, который превышать навряд ли будут. Но я не про эти идеальные случаи писал выше:)
                  • 0
                    1) Под «знает» я имел в виду прежде всего что ему предлагают работу в другой фирме с теми же обязанностями, но большей зарплатой.

      • +5
      • +7
        Квалифлюбые сотрудники зарабатывают столько за сколько смогли продаться на собеседовании
        • –9
          Вы умудрились обвинить много хороших людей в продажности, глупо.
          • +15
            Простите, а в чем суть работы? Не в том-ли, чтобы продавать своё время?
            • –8
              Не только и не для всех. Мне вот интересны задачи, чем сложнее задачи тем интереснее работа. Сложность задач. Объём работы. К примеру на основе сайтостроя:
              1. Штамповать сайты конвейерно на бесплатной ЦМС, работа — вёрстка. Как правило почти все на 80% однотипны. Оклад + % в зависимости сколько десятков сайтов на штамповал в месяц.
              2. Сложный портал/агрегатор/сервис. Тут уже полёт в усилении и развитии одного сайта. Развитие его, поиск стандартных и не стандартных решений. Новые технологии.

              Да, если охото тупо денег за протирание штанов и выполнение механической работы. То первый вариант самое то.
              • +6
                Работа это прежде всего продажа своего времени. Формы оплаты могут быть разные, но суть — продажа квалифицированного (или не очень) времени. Нашли работодателя (или он вас нашёл), который требует за свои деньги решать задачи интересные вам — молодец (или повезло). Но это остаётся работой. А если человек говорит: «сделай проект с такой-то функциональностью за N дней — получишь M денег», то уже не работа по сути, а выполнение заказа.

                • 0
                  В каком-то контексте работа является продажей времени, но, имхо, не прежде всего.

                  • +4
                    Естественно не чистого времени, а предполагается что в это время будешь выполнять должностные обязанности. Не будешь выполнять — уволят.
              • +3
                Т.е., если я правильно вас понял, можно у п.2 отобрать зарплату и его производительность никак не поменяется (я уже не говорю, что он просто сбежит)?
            • 0
              Суть работы в том, чтоб что-то делать, за что и получаться какое-то вознаграждение. Если бы вы сказали, что любые сотрудники продают своё время, за сколько умудрились договориться на собеседовании, я бы прошел мимо (хотя и так не все гладко, я знаю много людей которые не торгуются вообще, будучи высококвалифицированными). Но вы сказали, что сотрудники продаются, не время продают, а сами продаются.
              Быть может для вас нет разницы в этих формулировках, но для многих такая разница есть.
              • +1
                Честно, нет. Да, сейчас работа отличается от рабства. Появились плюшки, зарплата, смягчилось отношение к ресурсу, но в целом система работает. Вы работаете на кого-то, кто получает от вашей работы столько, что хватает вам заплатить, налоги и себе оставить. Это не продажа тела, но недалеко ушли от этого.
                • –1
                  Классика. Скажите, а доктор, он на дядю работает, он почти продал свое тело? А программист НИИ?

                  Ну а если на конкретного человека, то ему на самом деле часто не легко. Он берет кредит, создает фирму, платит зарплату и все разваливается. Так что не понятно кому легче.
                  • +1
                    На сколько я знаю, продают своё тело только проститутки и работники порноиндустрии (здесь я говорю непосредственно об исполнителях, если позволите так выразиться). Хотя, может быть я устарел и не успеваю за новыми течениями. Так что ни доктор, ни программист НИИ не продают.
                    • +2
                      Спортсмены еще.
            • 0
              Возможно всё же формулировка некорректна.
              Продавать свой труд — не то же самое, что продать себя (читай: свои принципы, убеждения, ценности). Бывает и такое, но всё же продажа рабочего времени или результатов труда — изначально этого не подразумевает.
      • +1
        Это от того, что умные сомневаются и колеблются, а идиоты самоуверенны. В том числе и при «продаже» себя на собеседовании.
  • +1
    А в Гугле продолжают задавать головоломки, и вроде у них все неплохо.
    • +7
      Всё таки те, кому задают головоломки — в подавляющем большинстве исполнители. Над которыми ещё есть несколько уровней людей, которые придумывают, что и как они будут писать.
      • –13
        Ерунду говорите.
        • 0
          Прочитайте произведение Айзека Азимова «Профессия»- возможно, это поможет вам понять zerkms
          • +1
            Какое отношение Азимов имеет к Гуглу?
            • +1
              Даже если не имеет отношения, все равно прочитайте. Хороший рассказ. :)
              • 0
                Подтверждаю
      • –5
        Если говорить в частности про Гугл, то это не так — никаких «нескольких уровней», решающих, что будут спрашивать интервьюверы на очных собеседованиях, не существует.
        • 0
          Существуют только внутренние курсы для интервьюверов. Но это же не считается, так ведь?
    • 0
      Вопрос скорее в том, на сколько смотрят на решение головоломок и на сколько на код.
    • +17
      Я очень рад за гугл. Но все чаще приходится по работе контактировать с людьми, которые охренительно решают головоломки, но не знают, как правильно работать с xml и чем в sql просто join отличается от left join. И обязательно на позицию senior. Потому что охренеть как классно решают головоломки. Ну просто мастерски.

      А код потом писать некому.
      • +5
        ключевая часть фразы была ", и вроде у них все неплохо. "
        • 0
          Не секрет, что у гугла головоломки служат простой цели: отсечь лишний народ. Поскольку иначе они будут не в состоянии провести собственно техническое интервью.

          Было бы хуже, если бы они вместо головоломок просто рандмно выбирали 1 резюме из 10 — большой вопрос.
          • 0
            Для отсечения лишнего народа есть телефонной скрининг и телефонное интервью. Головоломки для отсечения — очень странная методика, мне кажется.
            • +1
              Странная и неэффективная (как мне кажется). Но очень простая: даем девочке из HR пачку загадок с ответами — и получаем готового специалиста по первичному интервьюированию. Все при деле, отчетность в порядке.

              Что до телефонного интервью, то лично мне надоело слышать в трубке стук клавиш собеседника, судорожно ищущего ответ в гугле. :) К тому же нормальное телефонное интервью — это минус 20 минут работы квалифицированногт специалиста. Что весьма накладно.
              • +1
                По-моему, наличие фиксированных «ответов» уже убивает весь смысл такой загадки на корню, изначально. К слову, по опыту моего общения с гугловцами, они слишком адекватны, чтобы такое устраивать.
                • +1
                  «Загадки», которые загадываются в гугле на интервью своей целью имеют не получение фиксированного ответа, а понимание того, как мыслит кандидат. Необязательно давать правильный ответ, достаточно продемонстрировать интересный, неочевидный ход мысли. И в этом, как раз есть смысл: научиться новому языку программирования можно очень быстро, а вот научиться мыслить — совсем не быстро.
              • +2
                Вместо пачки с вопросами про люки можно с тем же успехом дать пачку с вопросами про сложность добавления N элементов в конец vector-а/ArrayList-а. Для HR одна фигня, что спрашивать, а пользы на порядок больше.

                На телефонном можно через гугло-док или любой IM, к примеру, простой код писать. А не задавать шаблонные вопросы, которые легко найти в поисковике. По времени получится сопоставимо, а по пользе, опять же, существенно лучше. Я когда работу подбирал, ряд зарубежных компаний этим походом пользовался.
                • 0
                  Про гуглдок очень хороший совет. Спасибо.
          • 0
            На телефонном головоломок не было (на очное не пригласили). Для отсева был короткий блиц во время первого телефонного интервью с HR.
        • 0
          им бы только понедельники — взять и отменить (с)
      • +8
        А в чем проблема-то? Не срабатываетесь с человеком в течение месяца-двух — расставайтесь. Никто же не заставляет только по головоломке оценивать уровень и брать после этого человека навсегда. Сдается мне, проблема с некомпетентными сотрудниками берет корни не из-за головоломок, а из-за того, что с человеком после начала работы толком никто не контактирует, не следит за результатами, не помогает, не мотивирует и т.д.
        • 0
          Испытательный строк — он не для того, чтобы выяснять вещи, которые можно узнать за 30 минут на собеседовании, если не тратить их на головоломки. Да, за два месяца я могу научить тому, что мне нужно. Это будет стоить 120-150 часов моего рабочего времени (объяснения, наставления, ревью кода) и от 200 часов нового сотрудника. Не проще сразу взять того, кого не нужно учить элементарным вещам?

          Кроме того, головоломки отсекают часть людей, которые вполне могли бы работать на этой позиции продуктивно с первого дня.
      • +4
        А я на собеседования не хожу потому что головоломки решать не умею, а вот про джойны знаю :) По крайней мере туда не хожу, где не хотят мне выслать тестовое задание предварительно.
        • +2
          Зря, IMHO. Тестовое задание вобще не всегда дается. Очень часто достаточно просто беседы.
          • 0
            Только несколько раз были околотехнические беседы или просили на бумажке или компе что-нибудь быстро написать. Куда чаще «Как должна рассчитываться зарплата таксиста? дворника? врача?», «почему люк круглый?», «почему вы выбрали нашу компанию?», «кем вы себя видите через 5 лет?» и т. п. Причём процентов 90 вопросов совпадают, особенно в веб-студиях, там близко к 100%.
            • +24
              У меня сложилось впечатление, что такие вопросы говорят ровно об одном: интервьюирующая сторона не в состоянии обеспечить настоящее техническое собеседование. Веб-студии — как раз очень характерный пример.

              Народ у нас начитанный, все ознакомились с «Как сдвинуть гору Фудзи», каждая вторая веб-студия видит себя среди «ведущих мировых компаний».

              Как должна рассчитываться зарплата таксиста, врача и дворника? Так, как скажет экономист. Я — программист. Сделаю, как он скажет.

              Почему люк круглый? Люк круглый потому, что так написано в ГОСТе (есть такой, без балды). Почему его сделали круглым разработчики ГОСТа — нужно спрашивать у них.

              Почему Вы выбрали нашу компанию? Потому, что только Вы были готовы встретитьс в 17:00. А в 15:00 и 19:00 у меня собеседования еще в 2 компаниях, которые я выбрал.

              Кем Вы видите себя через 5 лет? Программистом с опытом работы +5 лет.
              • –1
                Слышал и другое объяснение: так они якобы проверяют мою соображалку — если есть, то быстро научусь всему, если нет — то не смогу справиться с их самописным фреймворком/CMS.
                • +22
                  Бежать! Бежать от такой работы. Пусть сами разбираются в своем говнокоде, для понимания которого нужен программист, с ходу оценивающий количество тенисных мячиков, помещающихся в желудок дикобраза и стоимость автомобилей, выпущенных в Румынии в 2003 году. :)
                  • +2
                    В одну такую фирму я всё же устроился, но несмотря на то, что в вакансии в должностных обязанностях первым пунктом стояло «рефакторинг самописной CMS» (а я рефакторить говонокд люблю) за три месяца только проектно-специфичные костыли писал к ней, а по «мержил» свои и чужие костыли с «апстримом» (VCS не было).
              • –1
                > Почему Вы выбрали нашу компанию?

                Вы идиот(ка), да? Я, как и все кандидаты до меня и после меня, направил резюме в десяток мест. Где устроюсь быстрее и выгоднее — там и хорошо.

                > Кем Вы видите себя через 5 лет?

                Если я буду настолько бездарен, чтобы остаться в вашей компании на 5 лет, то меня не стоит вообще на работу брать. Да и компания ваша… Вот вам встречный вопрос: какие планы компании на ближайшие 5/10/20 лет? Что? Нет таких. Так если вы сами не знаете, что с вами будет через 20 лет, будет ли компания и какую нишу она намеревается занимать, то мне-то откуда это знать?
                Вы тут наркотики употребляете, не иначе.

                © боян
                • 0
                  Веселее слышать «Почему Вы выбрали нашу компанию?» от компании куда вас сами пригласили на собеседование. В Мейл.ру недавно меня так рассмешили.
      • +16
        Я вот был бы рад устроится в крупную IT компанию на позицию джунеора и достаточно долго искал такую работу, серьезно, мне интересно учится, интересно разбираться, да и сам не тупой вроде. Только проблема в том что на зарплату 15к рублей очень хреново получается «заплатить квартплату, купить пожрать, купить тех же книг, записаться на курсы, оплатить транспорт, купить одежду». Может поэтому и хотят на senior что на зп джунеора фиг проживешь? И это не зп раздутые, а у 23х летних «директоров» «молодых активно развивающихся компаний» через чур самомнение раздутое? Хотя за Москву и ваше зп говорить не буду, у вас там все не как у людей.

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

        вот как итог так и не знаю «чем абстрактный класс отличается от интерфейса»
        • +4
          Вообще говоря 15000 руб/мес для Иркутска и области это средний доход, грубо говоря половина народу у вас на них умудряется «заплатить квартплату, купить пожрать, купить тех же книг, записаться на курсы, оплатить транспорт, купить одежду». Они умудряются, а у вас не получается? Может всё же у вас запросы повышенные? Может потерпеть годик-другой и, скажем, одежду покупать на рынке китайскую, а не в фирменных магазинах (тоже китайскую :) )?
          • +5
            Ну это при условии наличия квартиры в собственности.
            Если жильё снимать — 15 тыщ уже не хватит.
            • +6
              Тоже варианты есть обычно, например снять квартиру-комнату на двоих-троих-…
              • +10
                Вот с кого надо многим пример брать. Человек не ищет причины, а ищет возможности.
              • +5
                как это так? Выпускник вуза, дипломированный специалист будет жить еще с какими-то неудачниками?

                Он сразу хочет квартиру, машину и зарплату 75 000 рублей, он же с дипломом, а то еще и с красным.

                Veider, не в вашу сторону, а вообще про «специалистов», только вышедших из вузов или не закончивших их вообще.
                • +12
                  Да хочу и не стыжусь этого, что в этом плохого?
                  Я хочу кататься на байке, ходить с девушкой в кино, рестораны, театры и жить отдельно, а не в общаге в 5м на кухне. Я именно для этого учился 5 лет в универе и пахал на работах по ночам чтобы оплатить учебу в перерывах читая книги по тер. веру и мат анализу, посадил зрение и заработал скалеоз пока бывшие одноклассники бухали пиво у подъезда. И я хочу это делать в 25-30 лет, а не мифическом будущем которое может быть, а может и не быть в 50 лет.

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

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

                  А слабо поставить условия чтобы к тебе шли люди прямо в уневере курсе на 4м на фриланс, неполный раб день, и практику, чтобы у них была возможность развиваться путь для вас это будет в убыток и 90% отсеются в итоге. Чтобы у вас были свои выращенные сеньер девелоперы какие нужны вам. Готовые за благо компании горло перегрызть. Которые её никогда не променяют на другую. Слабо? Тяжело? Не охота? Боишься что не оправдаешь затрат? Это не в стиле Российского нанобизнеса? Жалко денег и сил? Ну так и не надо ныть.
                  • +1
                    Да почему ныть, реальность такова, что большинство студентов еще думают, что будет как в школе. Или еще хуже, как в институте. Нет опыта, не социализированы, живут студенческими привычками и постоянно надеются на дядю. Мороки много, профит минимален.
                    Вы в универе учились для себя прежде всего, а дальше — байк, кино, ресторан и прочие прелести — это как в жизни повезет, ВУЗ никаких гарантий на хорошую жизнь не дает.
                    Все также понимают реальную цену этому красному диплому и реальным знаниям, выданным студенту в ВУЗе. Реально толковых — десятки, если не единицы.

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

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

                      Поэтому и работать до посинения с такими же людьми как и само руководство компании, которые будут надеются что надут готовый код которые появится за красивые глаза, большой стаж работы в трудовой, умение лизать жопу начальству и отделу кадров отвечать почему люки круглые, а все само по скомпелируется в последнюю ночь перед дедлайном, но при этом будут считать себя офигеть какими специалистами.
                      • +2
                        Не очень я понял ваш комментарий.
                        Руководству компании безразличен код, стаж, разные умения, глаза, дедлайны и прочее. Главный фактор — профит. Сейчас, к сожалению, от студентов профита почти нет. Как и от людей без опыта. С опытом, правда, еще решить как-то можно еще.

                        Студент на частичную занятость из шести оплаченных месяцев три будет отсутствовать, ему надо подобрать проект, который все же приносит денег, организовать рабочее место, обеспечить зп и социальные гарантии, выделить ментора. Со стороны студента зачастую имеем пофигительское отношение ко всему этому и также четкое утверждение, что ему все вокруг должны. Ну книгу-то он прочитал же и диплом красный корячится. А если в итоге не смог, то спрос маленький, два в зачетку — пересдача? Как теперь работодателю потраченное бабло отбить?
                        Мы бы брали студентов, и берем, но очень-очень мало. Основная масса так себя и ведет, к сожалению. Пока студенты не перестанут заявлять, что им все должны, парируя своим картонным дипломом и знаниями, которые невозможно приложить к практике, ситуация не изменится.
                        • +1
                          Посмотрел ваш профиль, да действительно берете. Я даже вам скидывал резюме года 3-4 назад, и меня не послали как обычно бывало во время учебы, а предложили практику. Но не сложилось, головной у вас в Новосибирске, а в Иркутском отделе ГИСы вам не особо и нужны, тут больше менеджеры требуются. А я в то время ещё мечтал стать разработчиком.
                        • +1
                          А ещё студенты через полгода-год работы мнут себя «Синёрами» и пофигу сколько сил уже вложила фирма в его обучение. Легко срываются на другую работу с +$100-200 профита.
                          • +2
                            А вот тут фирма сама виновата, если договор соответствующим образом не заключила и/или пропустила момент, когда за полученные на фирме знания другие готовы платить больше.

                            Или изначально стала платить/вкладывать неоправданно много. Хотя я не знаю ситуацию на рынке и не могу сказать есть ли много людей, готовых работать на первых порах за знания и опыт, ну и «за еду» (причём ближе к «доширакам», чем к ресторанам) и работа которых хотя бы знания и «еду» компенсирует за месяц-другой.
                            • +2
                              Моя первая зарплата была равна $7 или что-то около того. Но мне было на нее пофиг, так как я получал неограниченный доступ к компу и интернету. Следующая моя работа была уже за $100. И дальше по нарастающей. Где-то я работал ради денег, где-то ради ресурсов.
                          • +3
                            Если у вас студент работает уже год на 15 т.р. и перспективы только в обещаниях, а ему предложили 20+ то он естественно уйдет.

                            Ещё у нас кстати любят брать на испытательный 3 месяца и потом «забывать» повысить ЗП как обещали, а после начинают удивляться и негодовать почему это от них ушли.

                            А вообще если мне не изменяет память то по ТК при условии что человек работает официально и фирма его отправляла на курсы то он не имеет право уволится, если частично возместит стоимость этих курсов, там % возмещения от давности курсов я не помню если честно, но не мало. Поэтому если меня отправят на курсы оракла за 100 т.р. то я увольняться в тот же год ради ста баксов не буду точно. Так что может все таки причина в вас или в том что вы считаете «обучением»?
                            • 0
                              Кстати, встречал такой интересный ход: фирма организовывала «курсы» прямо у себя в рабочее время и типа давала стажерам типа займа на него. «Курсы» по сути заключались в том, что ведущий возился с этими стажерами, объясняя, например, плюсы и минусы разных вариантов реализаций, а не как бывает «на Фаулера и ГоФ — читай»), а их стоимость рассчитывалась как стоимость времени этого ведущего, потраченного на объяснения.
                              • 0
                                Мы пробовали делать что-то такое, только на халяву. Выпускники ничего не должны были платить за курсы, получали сколько-то даже, но после каждого месяца курсов менторы решали кого оставить. Так три круга Ада, как мы их прозвали. Те, кто прошли три месяца обучения и были одобрены менторами, получали предложение начать работать.

                                Но система себя не оправдала, сейчас точно не помню, но отсев был просто колоссальным.
                                • 0
                                  Не полная халява тоже не гуд. Во первых расслабляет во вторых есть люди что сразу ищут подвох если им предлагают халяву, я например в такое не верю =)
                                  По мне так лучшая система 30/70 или 50/50 деления стоимости обучения, но курсы можешь выбирать сам + пересмотр квалификации и соответственно зарплаты по итогам каждые пол года год в фирме. Причем сертификацию внутри фирмы проходят все сотрудники и при понижении квалификации ( да да такое очень часто бывает как не странно) ставка снижается.
                                  Но мне у нас в городе с подобными условиями IT компаний не попадалось, пошел бы не задумываясь.
                                  • 0
                                    А есть ли вообще приличные курсы, где можно поднять квалификацию программисту? Я вот сколько не искал ничего стоящего на глаза не попадолось — или явно для начинающих, или отзывы по типу «развод, маны пересказывают» при внешне интересно выглядящей программе.
                                    • 0
                                      Ну сходу я как минимум с удовольствием бы получил сертификаты Oracle PL/SQL Developer Certified Professiona + Zend + нужны хорошие курсы английского это уже задача не на один год, можно и по книгам готовится конечно. Но думаю хорошие курсы никак не могут быть хуже самоподготовки.
                                      • 0
                                        Посмотрел курсы на ZCE от «Специалист»:
                                        В этом курсе рассматриваются особо сложные темы (выделено мною), такие как шаблоны проектирования (Design patterns) (Синглтон, Фабрика, Стратегия — добавлено мною), отражения (Reflection), PDO, шаблон MVC (Model-View-Controller), без овладения которыми немыслима профессиональная разработка приложений на PHP.

                                        По окончании курса Вы будете уметь:
                                        Использовать шаблоны проектирования
                                        Использовать PDO для работы с базами данных
                                        Использовать функционал Standard PHP Library
                                        Применять шаблон проектирования MVC
                                        Уметь отлаживать и тестировать PHP-код
                                        Создавать и использовать документацию своего проекта
                                        Использовать Регулярные выражения и Пространства имен PHP


                                        Это пик того, что предлагается при подготовке, и курс с нуля до этого стоит 80к для организаций (128 часов аудиторных занятий). Платить за это 24к (если 30/70) как-то не хочется. За такие деньги я ожидал бы что-то вроде:
                                        — нагрузочное тестирование, профилирование, выявление узких мест «достойных» оптимизации
                                        — выбор политики кэширования (инструменты, уровни, алгоритмы инвалидации)
                                        — горизонтальное масштабирование, распределение нагрузки, решение проблемы сессий, блокировок БД и других разделяемых ресурсов
                                        — инструменты и методики эффективной командной работы (CI, всякие Agile и т. п.)
                                        И «курсовик» с хорошим code review как выпускная работа. На подобный курс даже кредит бы взял в сотню тысяч за свой счёт и думаю проблем особых с «возвратом инвестиций» не было бы. Ничего подобного не встречали?

                                        Английский да, полезная штука, но имхо, не английскому надо учить джуниора, который «не знает чем интерфейс отличается от абстрактного класса».
                                  • 0
                                    Подвох простой — в любой день можно получить прощальное письмо. Это сразу отличает тех кто пришёл половить халяву, играя в косынку, и тех, кто заинтересован.

                                    И это не курсы для сотрудников, это программа, которую хотели ввести для приёма людей, которые только — только встали на путь разработчиков (закончили колледж — graduate developer, как мы их называем).
                                    • 0
                                      По-русски, кажется, квалификация «техник-программист» (среднее профессиональное образование).
                                      • 0
                                        Колледж — это высшее. Степень бакалавра. Хотя, возможно не всюду так.
                                        • 0
                                          Это, наоборот, исключение.

                                          б) колледж — среднее специальное учебное заведение, реализующее основные профессиональные образовательные программы среднего профессионального образования базовой подготовки и программы среднего профессионального образования углубленной подготовки.
                                          • 0
                                            Это в российской системе образования. В нашей же всё наоборот:
                                            In the United States and Ireland, «college» and «university» are loosely interchangeable
                                            На пример PhD по робототехнике в великобританском колледже www.kcl.ac.uk/prospectus/research/index/name/robotics/alpha/ABC/header_search//keyword/computer-science
                                            • 0
                                              Сорри, всегда возмущался по поводу дефолт-сити в, например, вакансиях. Что сам буду выступать подобным дефолтщиком не думал :)
                                • 0
                                  Так у вас чисто обучение было или всё же текущие задачи они решали под чутким руководством старших товарищей?
                                  • 0
                                    Каждый день пол для обучение, вторая половина работа в командах над задачами, которые у нас уже решены, но мы не очень довольны результатами. Одновремено практива и потенциальная польза.

                                    Была такая корыстная мысль, что кто-то из них случайно найдёт решение лучше. Не нашли.
                                    • 0
                                      А предварительный отбор какой был? Средний начальный уровень?
                                      • 0
                                        Показывали один из популярных графиков (на пример f=cos(x)) и просили назвать. Без подвоха. Плюс курсант должен был знать синтаксис Embeded C, но это не проверялось и проблем не возникало.
                                        • 0
                                          Хех, а он от простого Си отличается? :) Вопрос риторический.
                            • 0
                              А причем тут я? )
                              Я просто констатирую факт на основе знакомства со многими такими вчерашними студиозами. Фирма тоже виновата, но от этого ЧСВ отдельных студентов меньше не становиться :)
                            • 0
                              У нас курсы до 100К размазывают равными долями на полгода, больше — на год.
                            • 0
                              Почти во всех договорах есть такой пунктик. Про возмещение стоимости потраченной на обучение сотрудника. Для себя решил что если вдруг «пошлют на курсы», то потребую какую — нибудь офф бумагу из бухгалтерии где будет четко прописано «сколько я должен компании за этот жизненно необходимый мне курс». А вообще считаю сей пункт большим свинством. Обучение сотрудников идет на пользу компании, по крайней мере они так думают ибо за просто так ничего бы не делали. А при увольнении удерживать деньги за эти самые курсы это нищебродство какое-то.
                              • 0
                                Ну а вдруг вы пройдёте курсы, получите сертификат и тут же уйдёте к конкурентам?
                                • 0
                                  Обычно плохой работодатель боится что от него уйдут ценные сотрудники. От добра добра не ищут.
                                  А если работодатель хочет «удержать» сотрудников «штрафами», то у меня для него плохие новости.
                              • 0
                                Не при увольнении, а при увольнении раньше срока, который вы определяете до обучения (и есть право отказаться же). Компания вас обучила — надо отработать. И это нормально.
                                Две недели, допустим, курсы — вам платят зп, хотя вы не работаете, за вас работает кто-то другой. Плюс подарок в виде месячной (двух, трех, четырех) зп в качестве оплаты за эти курсы.
                                Обучение идет на пользу в первую очередь вам. А как вы сумеете применить эти знания на пользу компании — это еще спорный вопрос. А вдруг не сумеете. Или вообще решите, что надо уволиться. Как же быть с этой зп, которая ни за что и с этим подарком?
                                Если сотрудник ценный и нужный, а его на старом месте держит лишь «курсовая кабала», то видел много примеров, когда новый работодатель просто проводит реструктуризацию долга и сам все выплачивает, зачастую безвозмездно.
                                • 0
                                  Не пишу обычно такого, но напишите хоть за что минусы и сразу в карму. Где-то по-другому делают?
                  • +2
                    Я именно для этого учился 5 лет в универе и пахал на работах по ночам чтобы оплатить учебу в перерывах читая книги по тер. веру и мат анализу, посадил зрение и заработал скалеоз

                    А кто вам виноват, что вы получали невостребованные на рынке знания или, хотя бы, не получили хоть какой-то опыт реальной работы по специальности? Вы определялись с тем какие знания нужны для желаемой работы? Проверяли выбранный вуз на то, даёт ли он эти знания? Получали ли «дельту» самостоятельно?

                    Вообще, положа руку на сердце, если вы учились на программиста (специальность «Программное обеспечение вычислительной техники и автоматизированных систем»), то способны были после получения диплома осуществлять «проектирование, разработку и производство программного обеспечения, как промышленной продукции, удовлетворяющей заданным функциональным, конструктивным и технологическим требованиям»? Я вот разрабатывать программное обеспечение худо-бедно могу, но не как промышленную продукцию. И потому периодически вместо зарабатывания денег ищу фирму, где могут этому научить в ходе работы, потому что не верю в способность нашего образования этому научить, включая и вузы, и многочисленные курсы а-ля «php за 24 часа». Деньги кончаются — ищу где бы денег заработать просто на разработке ПО, зарабатываю и по новой ищу где-бы научиться.
                    • 0
                      Промышленные подходы в разработке ПО на территории бывшего СНГ не преподаются. Просто некому.
                      • 0
                        То есть они вообще не используются в СНГ в принципе и я ищу чёрную кошку, которой нет?
                        • 0
                          Весь прикол в том, что промышленные подходы диктует не программирование, а экономика. Другими словами, необходимо прочитать базовый курс лекций по экономике, прежде чем приступать к принципам промышленной разработки. Иначе все слова будут совершенно непонятными для студентов.

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

                          Резюмирую. Промышленная разработка требует соблюдения множества правил, которые продиктованы эффективностью производства кода и функционированию компании в целом
                          • 0
                            Интуитивно я это понимаю. Подозреваю, что в фирмах типа Яндекса или Абби такая промышленная разработка имеет место быть. Знаю что, во многих веб-студиях ею не пахнет, по сути каждая задача решается в лоб, возможно с повторным использованием кода где-то, хорошо если VCS, но и всё пожалуй. Вот только не знаю как научиться той же работе в команде (не просто формально «нас 5 человек и мы делаем один продукт», а «правильной»).
                            • 0
                              Яндексу деваться некуда, их вынуждают размеры. Но она может вестись по наитию, а не осознанно или целенаправленно.

                              Если интересно, могу более детально в скайпе пояснить.
                              • 0
                                Воспользуюсь предложением попозже, ничего?
                                • 0
                                  Да без проблем ;)
            • +1
              в Воронеже хватит, например. Снял квартиру за 4к + коммунальные (при стандартной цене 7-8), хорошая квартира, только нет ни газа, ни горячей воды, ни душа (поэтому и спрос нулевой). Приобрел таз и кипятильник. 5к в общем выходит за квартиру. Год так прожил — купил бойлер, кладовку обили пластиком, поставили раковину ножную, провели трубы — заимел душ. Теперь за 5к имею квартиру с душем, короче, удобства.
              Согласен, вариант утопический, чтоб его советовать, но еще куча квартир без душа, сделанных из старых гостиниц. Если вообще надо уложиться срочно в N < «малоденег», есть тоже куча бывших общаг, где сдают автономные комнаты, но душ там, например, общий на несколько комнат.
              Но опять же, если не хватает денег — нужно утянуть пояс потребностей и искать варианты попроще, 15к для этого в большинстве городов России хватит.
              • +1
                >Снял квартиру за 4к + коммунальные (при стандартной цене 7-8)

                Зависть, у меня просто коммунальные 6200 примерно.
                • 0
                  >5к для этого в большинстве городов России хватит.

                  В Екб. комната — от 6к.р., квартира — от 10.к.р.
                  • 0
                    у нас квартира от 8-9. но варианты найти без газа && горячей воды и приделать все самому есть, я нигде не говорил, что это у нас все квартиры такие.
                  • 0
                    Я не знаю сколько в москве стоит комната, но квартира — где-то от 25к, если не браться совсем плачевные варианты.
              • 0
                4К, да даже 7-8 — люто завидую. При цене в 7-8К я бы снял квартиру поближе к работе, просто чтобы не тратить на дорогу деньги, а то через полгорода ездить тяжковато каждый раз.

                По молодости снимали с женой жилье за 11К (2007й год) и это был еще хороший вариант. Жена правда работала в трех кварталах (потому и выбрали). А мне на работу минимум час добираться, так это был еще далеко не самый край географии. Двух з/п нам хватало в принципе. Не шиковали конечно, но и нужды особо не испытывали. Зато опыта набирались (оба работали на первых работах). Потом появилась машина и мы перебрались в пригород, где потише и подешевле все. До работы правда пришлось ездить 50км, зато с комфортом и без пробок почти.

                Начинать всегда приходиться с малого. Такова жизнь.
                • 0
                  50 км — за городом? Да это же вообще около 5-7 населенных пунктов между работой и домом. Или для ДС это норм?
                  • 0
                    Ну во-первых 50км это не от города до города, а от порога до порога. Во-вторых 50 около 25 по городу. И да, я три населенных пункта по пути миновал. Это кстати не ДС. Речь про Ростов-на-Дону. А жил я в Новочеркасске. У нас в компании трое оттуда ездили. При этом в силу специфики транспортной системы я доезжал быстрее, чем народ из других районов собственно Ростова, ибо пробки. У нас это довольно распространенное явление (как наверное во всех крупных городах). БольшАя часть населения городов и деревень в радиусе 30 км от города работает тут. У нас в компании около 30%, как бы сказали в ДС, замкадыши. Хотя все эти города и деревеньки официально считаются Ростовской агломерацией.
          • –1
            То что половина народа живет в нищете в 5м в одной квартире и их это устраивает, это их проблемы, но не как не мои. Я не жалуюсь, мне вполне нравится моя жизнь, зарплата, хорошие перспективы и независимость от всяких царьков, ибо фриланс всегда открыт. Интересные моменты есть и в такой работе и их достаточно много, а если нет то всегда можно по вечерам заняться чем то своим и интересным. Просто когда то я был идеалистом и стремился к другому, так бывает.

            А вы дальше работайте с теме кто соглашается «потерпеть», только вот если кто то терпит что к нему относятся как к расходному материалу, а не человеку это уже говорит об определенных качествах характера, так то не надо удивляться потом что им ничего не надо кроме как придти посидеть на вконтактеке получить ЗП и уйти.
        • +2
          Видимо, компании были недостаточно крупные. В достаточно крупных компаниях зарплата junior'а — это все-таки не 15к (правда, с тем, чем отличается абстрактный класс от интерфейса, придется разбираться до того, как идти на собеседование). И речь не только о Мск.
          • 0
            Да не, у нас вот те же Бридж Квест (не реклама) и прочие сначала предлагали пару лет назад как раз 15-20. Зато потом там есть куда расти! И ого-го как расти!
        • +2
          О, привет, земляк. Надо было стиснув зубы за 15 тыщ пару лет поработать. Все мои знакомые офигенные программеры так и начинали. И сейчас они — офигенные программеры с нормальной зарплатой в Иркутске. Я не в счет :)
    • +5
      Серьезно что ли? Ни одно головоломки на собеседовании я не услышал) А вот технические вопросы и хорошие рассуждения как сделать что-то – выше крыши.
      • +1
        Странно. У меня на каждом собеседовании была хотя бы одна головоломка.
        • +1
          Возможно, ваш собеседник просто не замечал, что решает головоломку, для него это как дышать.
      • +2
        Вам попался очень вменяемый интервьер. Они вымирают.
        • 0
          Все 7 или сколько там было человек на собеседование в Google? )
    • +3
      Это называется «культ Карго». Почитайте в Гугле. Если вкратце — бездумное повторение, без понимания принципов.
    • +2
      В Гугле их уже несколько лет как не задают.
      • 0
        Прошлым летом задавали. Не в Москве, правда.
        • 0
          Интересно, а где задавали? И что были за головоломки? (можно в личку)
    • –1
      Что у них неплохо кроме поиска?
      • 0
        Основной бизнес, например (контекстная реклама).
      • 0
        Офисы неплохие, говорят.

        p.s. gmail, googledocs, адсенс, аналитикс…
    • 0
      А там фокус в том, что сначала отсекают тех, кто не умеет писать код. Все равно больше, чем нужно. И уж *тогда* идут головоломки.
    • 0
      Что можно Юпитеру, то не дозволено быку. Мода играть с HRными финтами нынче повальна, а уровень проектов такой как у Гугла… хотя бы у 1 из 10 контор? )))
    • НЛО прилетело и опубликовало эту надпись здесь
  • +9
    У вас звездочка в последнем обсценном слове совсем не справляется со своей функцией
    • +22
      Учитывая то, что «хер» — это не обсценное слово, нормально.

      Кстати, для многих становится открытием, что слово «хер» происходит от буквы Х (хер) кириллицы. Соответственно слова «похерить» или «перехерить» — обозначает что-то перечеркнуть, удалить. Употреблялось, например, выражение «перечеркнуть красным хером». Почему «хер» и другое слово из трех букв вдруг стали синонимами — неизвестно.
      • +6
        Выражение «слово на букву хер» сократилось до «хер».
      • +1
        Где-то встречал тезис (был какой-то программист, много общавшийся с бухгалтерией), что похерить — это тоже самое, что покрыжить, только под углом 45 градусов.
        • 0
          Да, я когда от бухгалтеров услышал что галочка чекбокса — это «крыжик», очень веселился.
          • 0
            А я Вам, как переводчик, добавлю, что это «флажок».
        • 0
          Вообще в бух учете «крыжить» означает ставить крестики или галочки при сверке документов. Как сюда угол можно применить?
          • +6
            Нашел таки ссылку на те записки. Вот этот фрагмент:
            Разбирали с программистом бухгалтерский сленг. Пришлось даже залезть в Даля, чтобы выяснить происхождение некоторых слов. Выяснилось, что «крыжить» происходит от «крыж», то есть крест, и исходно значило «помечать крестом», хотя сейчас большинство бухгалтеров крыжат галочками. Заодно разобрали слово «херить», происходящее от «хер», старого названия буквы Х, и означающее по Далю перечеркивать или помечать косым крестом. Программист подумал и сделал вывод, что херить – это крыжить под углом пи на 4.
          • 0
            Крестик может быть вертикальным, а может быть повёрнытым :)
    • +3
      А я с первого раза прочитал, что это x* p — переменная-указатель p на тип x. И вроде вписалось в концепцию «абстрактные классы/интерфейсы» =)
  • +29
    Чем абстрактный класс отличается от интерфейса — это ещё ерунда…
    На собеседованиях по PHP тогда нужно спрашивать, чем $arr1 + $arr2 отличается от array_merge($arr1, $arr2)
    Или на собеседованиях по JS спрашивать, как реализовать прототипное наследование…

    Чем больше таких вот вопросов задается, чем больше у людей создается ощущение, что эти знания обязательно нужно использовать в повседневной работе, хотя всё как раз наоборот: чем меньше «наворотов» в коде и чем он проще — тем лучше, а не наоборот. Простой код легче писать, легче отлаживать и легче поддерживать. Знание тонкостей языка хорошо лишь тогда, когда требуется разобраться в проблеме, но не для того, чтобы писать новый код.
    • +10
      Такие сложные навороты, конечно, использовать в коде не нужно. Но именно эти навороты получше любых головоломок показывают на сколько граблей кандидат уже наступил и сколько опыта у него за плечами.
      • 0
        Для PHP я наверное не самый адекватный пример привел, но я имел в виду, что не нужно задавать типовые вопросы, если хочется понять, насколько человек опытен. Проблема с ними в том, что они ничего не показывают — человек может просто подготовиться к собеседованию и заучить ответы на типовые вопросы. Я бы не стал давать советы по тому, как надо правильно подбирать людей, но просто хотел озвучить те вещи, с которыми мне пришлось столкнуться, когда я искал работу.
        • +6
          Мы вообще плюнули на типовые вопросы и даем оплачиваемые тестовые задания на 3-5 рабочих дней. Естественно, подходит только тем, кто активно ищет работу и сейчас не работает, но в целом, позволяет гораздо лучше отсеивать людей. Собеседование при таком раскладе можно вообще провести в скайпе, а личную встречу сократить к минимальной необходимой, чтобы просто посмотреть на самого человека.
          • 0
            Само по себе собеседование требуется не для того, чтобы оценить уровень кандидата — для этого вполне подойдет испытательный срок — а для того, чтобы понять насколько человек впишется в команду.
            • 0
              Кроме совсем уж вопиющих случаев, я бы сказал, что это задача как раз для испытательного срока (впишется ли в команду). Можно, конечно, покорчить из себя психолога, но это все профанация, обычно.

              Мое мнение — для проверки скилов — тестовое задание, для проверки, впишется ли в команду — испытательный срок. Принимать решение по обоим пунктам после собеседования имеет смысл только в случае, если нет возможности уделять кандидату много времени (или у него нет возможности тратить время на потенциального работодателя).
    • +1
      Я прошу прощения, но «чем абстрактный класс отличается от интерфейса» всё-таки не «тонкость языка», а азбука ООП. Разве нет? (Я даже не программистом работаю, если что.)
      • 0
        Всё от контекста зависит. Главное уловить какой контекст имеет в виду собеседующий.
        • +1
          Можете более конкретно пояснить, что именно вы имеете в виду?
          • +3
            Отличий интерфейса от абстрактного класса много — от синтаксических до идеологических. Нужно угадать что хочет услышать спрашивающий.
            • 0
              А — ну, по-моему, в таких ситуациях (они достаточно часто бывают на интервью) достаточно сначала сказать «отличий много, от синтаксических, до идеологических», и начать рассказывать сначала одно, потом второе. Пирамида минто решает :)
      • –1
        В случае с Java (или другими сильно ООП-языками) это наверное так. В случае с динамическими языками я бы не был так категоричен. Более того, это знание при программировании на том же PHP вам скорее всего понадобится очень нескоро.
        • +2
          Причём здесь вообще конкретные языки? Это общий, теоретический вопрос.
    • +2
      У меня есть несколько вариантов ответа насчёт абстрактного класса и интерфейса (в зависимости от контекста), я примерно представляю себе как реализовывать прототипное наследование в JS и при наличии под рукой консольного интерпретатора JS или Firebug минут за 15 подберу рабочий синтаксис, с PHP я вообще никогда не работал, но и там есть несколько вариантов какие в принципе бывают варианты сложения/объединения двух массивов и какие могут возникнуть проблемы в обоих случаях.

      Я полностью согласен с Вами в том, что писать простой код жизненно необходимо!

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

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

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

      Можно не знать тонкости языка, на котором пишешь мало и редко, но если квалифицированный профессионал (а ведь речь о них!) за несколько лет работы не удосужился разобраться в тонкостях языка, который все эти годы использовал — возникает вопрос, а квалифицированный ли он и профессионал ли?

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

      Резюмируя: знать тонкости используемых инструментов необходимо, если вы считаете себя квалифицированным профессионалом достойным интересной работы и высокой зарплаты. А вот использовать все эти тонкости в большинстве случаев действительно не требуется и даже вредно — но если вы настолько хороши, насколько сами думаете, то вы это и сами должны понимать. Поэтому задавать такие вопросы на собеседовании вполне уместно.
      • 0
        Ещё зависит от собеседования на какую позицию.
  • +7
    Крик души.
  • +15
    Плюсую! Именно поэтому я собрал команду, и мы начали заниматься построением Community в Питере:
    1. Мы перезапустили Java User Group — jug.ru и
    2. cделали сообщество CodeFreeze — codefreeze.ru

    Мы стараемся действовать именно в «хардкорном» стиле с минимумом плюшек и максимумом полезного.

    Почти одновременно с нами девчонки из DataArt запустили в питере IT-Talk: it-talk.spb.dataart.ru/?page_id=9

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

    Короче, работа ведётся. В Питере — нами. В планах поднять/реанимировать не только JUG, но и другие User Groups.

    Кстати, если кто-то из хабровчан хочет заняться Community-работой — пишите мне: подскажу направление, дам пинок etc.
    • +12
      Отписался в личку.
      • +10
        Не минусуйте Яшу, он мне помощь в личке предложил! Плюсы ему ставьте!
        • 0
          Сироткин?
          • 0
            не, Яша Сомов, читайте его никнейм!
    • 0
      Молодцы, реанимировать jug — общественно полезно
      Жалко, что только в Питере пока
      • 0
        ну дык в других местах JUG могут делать другие люди! Более того, мы готовы помочь!
  • +42
    Проблема еще и в том, что — таки да — в наших краях как правило software engineer-ами называют «слесарей от IT», а вовсе не инженеров. Тех, кто знают свой «станок» (Java, Linux, etc.), но не Computer Science. Спрос на них — это нормально, ведь бОльшая часть нашего оффшор-девелопмента занимается несложными и достаточно рутинными задачами «по накатанной».

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

    В очередной раз имеем Культ Карго — копирование внешнего вида без понимания содержания и целей.
    • +1
      Жаль кармы мало чтобы поставить плюсик. Поэтому одобрю комментом:

      > В наших краях как правило software engineer-ами называют «слесарей от IT», а вовсе не инженеров. Тех, кто знают свой «станок» (Java, Linux, etc.), но не Computer Science.

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

      И когда встаёт задача сделать какую-нибудь систему N, какой-нибудь там фоновый демон или сокет-сервер, тогда начинаются такие пляски с бубном вокруг «любимого и крутейшего PHP» (или чего там ещё любимого и крутейшего), что у меня уже виски поседели на всё это смотреть.

      А потом ещё заявляют что, де, «я программист на XXX, а свой YYY можете в жопу засунуть, я на нём делать ничего не буду, и точка»; где XXX — что-нибудь этак из 1970-ых.

      Наболело, в общем.

      PS: Моё личное желание «свалить» на красивом красном тракторе, кстати, вызвано не столько политическими диктаторскими замашками всяких там национальных лидеров, как у многих, сколько вот этим вакуумом достойных собеседников и соперников на техническом поприще. Хочется уже немного challenge'а.
      • +13
        > где XXX — что-нибудь этак из 1970-ых.

        Так а даже если из 2010-х — нет никакой разницы. Языки программирования, фреймворки, технологии — это просто инструменты. Возводить инструмент в ранг религии — абсурд. Никто же не станет закручивать шурупы молотком, потому что «у него такая офигенная ручка, намного круче, чем у отвертки». А в IT такое — сплошь и рядом.

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

        Но когда сложных задач нет и не предвидется, и алгоритмика простая как двери, все что остается — канонизация технологий :-(
      • 0
        Нормальные специалисты есть, их много, они хорошо получают и редко меняют работу в виду отсутствия такой необходимости. И если Вы не встречаете вызовов, советую поменять место работы…
      • 0
        Когда надо написать демон или сервер, я спрашиваю у заказчика согласен ли он ждать (и частично оплачивать) пока я разберусь скажем с, C++ или лучше быстро (и дешевле) написать на PHP. Не один ждать не захотел.
        • +1
          Мир полон языков гораздо более высокого уровня, позволяющих быстрое прототипирование (в чём PHP несомненно хорош), но работающих за рамках подхода «request-response» без костылей (ну, почти). Python тот же. Его даже в убунтах всяких используют для GUI местами. Erlang. Ruby. А на C/C++ сейчас решают только сверх-специфичные задачи, типа мега-гига-нагрузок или мини-нано-памяти или чего-то такого.

          Собственно, вы сами привели пример такого «слесаря от IT», который кроме свеого любимого и прекрасного культового языка ничего учить не хочет, и находит отмазки почему бы это не делать далее. Без обид.
          • 0
            Веб-интерфейсы я прототипирую на рельсах, GUI и CLI утилитки пишу на Python, Erlang с Nitrogen, каюсь, не осилил, если что-нибудь одно, то может и смог, а то захотел сразу и язык, и фреймворк, да и мотивации особой не было. И вовсе не считаю PHP, который был, кажется седьмым моим языком, если не считать диалекты и хелловорлды, прекрасным и любимым — он начал меня раздражать 10+ лет назад своим синтаксисом и слишком большой свободой при обращении с типами, но привлёк инфраструктурой. Ещё был вариант Perl изучать, но уж больно он мне write only показался, а PHP почти как любимый (тогда) Си, да и литературы на русском по PHP тогда больше было. Резюме я свои посылаю практически на все Junior вакансии независимо от языка, если не требуется опыт работы и в/о (не закончил, потому что понял, что программировать меня учить не будут, не в тот поток попал), а в «сопроводиловке» прошу выслать тестовое задание на день-два.
            • 0
              Вы душка. Но тогда странно что демон или сервер предлагаете заказчику писать на PHP.
              • +2
                Это единственный язык, на котором я могу писать без постоянного подглядывания в гугл/маны. Язык для которого я гуглю не «как сделать то-то», а «сделал то-то так-то, но работает не так как вроде следует из манов». В конце-концов язык, приложение на котором я разверну на голом сервере опять же без гугла и более-менее понимая что каждая введенная строчка или исправленная в php.ini делает. Я почти не сомневаюсь в своей способности написать демон или сервер на ruby/python/c#/java/js/c/c++, но это явно займёт больше времени из-за поверхностного знания синтаксиса и полного незнания даже стандартных библиотек, не говоря о сторонних. И очень сомневаюсь в своей способности за разумное время самостоятельно разобраться с грамотным деплоем на «голый» сервер, а не дай бог ещё не debian-based. А разворчивать production по хаутушечкам, не понимая что делаю, я отвык лет 10 назад, когда прочитал где-то «поставьте права 777 чтоб работало» и попал на пару тысяч долларов (тогда однушка в Питере 6 стоила).
            • +1
              А что мешает посылать на вакансии где в/о требуется? Опыт показывает, что это требование в 90% случаев — чистая формальность.
              • +1
                Слишком эмоционально отношусь — отправляю, а потом каждую минуту почту проверяю, день, другой, неделю, потом в депрессию.
                • 0
                  Тю, у меня нет ВО, и я по этому поводу абсолютно не комплексую. Обычно я спрашиваю, вам нужно чтобы диплом работал, или человек? Если диплом, то мне с вами не по пути
                  • 0
                    Там где не написано требования в/о, так редко речь о нём заходит, если только вскользь "- Учились где? — ЛЭТИ, ФАВТ — Хороший вуз — Ага". А где написано так там обычно ещё и требование профильного, а у меня 3 курса да ещё «железячной» специальности, по программированию в вузе максимум «paint» делал на MFC/C++ и «edit» на ассемблере. Ту же теорию алгоритмов, СУБД, ОС, компиляторы и прочее SC не изучали.
                  • 0
                    Но ведь и ваш годовой доход не так велик?
              • 0
                Последнее время количество вакансий в которых в/о вообще фигурирует стремится к нулю, по крайней мере складывается такое ощущение, ибо постоянным мониторингом не занимаюсь. Зато вот опыт 3-5 лет требуют практически везде.
                • 0
                  Мой мониторинг показывает другое. А опыты года два просят.
  • +4
    И приходят потом джуниоры в другие компании, и молвят, что хотят получать (не зарабатывать) $2К… И берут их на работу, потому что лучше плохенький джуниор в офисе, чем профи в Cloud'e…

    Печально это все, печально…
  • +3
    Ага, недавно на работе думали что делать с кодом, который такие решатели головоломок налабали — для примитивной задачи, которую можно было на голом PL/SQL написать — сделано 5 (ПЯТЬ) уровней наследования и все через ORMы с понятным быстродействием.
    • +5
      Хм… а может вы против OOP потому что он «медленный и память жрёт»? 5 уровней для примитивной задачи много, но с другой стороны в обход архитектуры можно много чего индусить «быстро и просто». Кто знает, возможно это вы недооценили задачу (потому что головоломки не решаете :-P)
      • +3
        Нет, я за то, чтобы не колоть орехи микроскопом без надобности.
    • +11
      Если примитивная задача делается в рамках проекта, в котором есть сложившаяся архитектура требующая пяти уровней наследования и использования ORM то все сделано правильно.
    • +4
      5 уровней это не страшно. Если код хороший и некоторые уровни не требуются от слова совсем — их убрать должно быть достаточно просто.

      А вот попался мне недавно проектик на 400 000 строчек, которй в течении 10 лет быдлокодили… 3 раздельных системы для учета денег, 6 вариантов отправки писем, 150 табличек в БД, причем на одну сущность иногда встречается до 8 табличек, завязанные через 3-4 уровня связей, 3 админки с разным функционалом. Местами присутствуют классы. есть 4 разных класса с одним именем и три почти одинаковых класса с разными именами.

      Работает достаточно быстро, но разобраться в этом достаточно сложно.
      • +12
        Мне кажется, вы слишком политкорректны :)
      • +1
        С одной стороны, звучит как ппц, а с другой стороны всё-таки мало того что «работает, так ещё и „работает быстро“… Сколько проектов с хорошей архитектурой не могут этим похвастаться?
        • 0
          Ни одного. Если проект не работает быстро или просто не работает — у него плохая архитектура. В данном случае архитектура плохая, потому что проект изменять адски сложно. Его можно только дописывать, увеличивая нагромождение кода. Любая правка выливается в то, что «тут сменили, а тут, тут и вон там — нет. А еще вот тут вот телефон написан, от которого уже 5 лет как отказались».
        • 0
          Единственная причина, почему его нельзя выкинуть — оно работает. Если бы не работало. сразу бы ушло в корзину.
  • 0
    к большому сожалению, такое положение дел можно наблюдать практически в любой индустрии.
  • +25
    Так это… чем абстрактный класс отличается от интерфейса? ;)
    • +64
      так написано же — никто не знает
      • +24
        Тогда где мои теннисные столы, футболка, айпад и звание Senior`a?
        • –1
          За вышивание крестиком сеньора не дают ;)
          • +2
            Senior Krestik Vishivatel.
            Знает всё в области вышивания крестиком. Обучает джуниор вышивателей. Распределяет задания и холст между обычными вышивателями. В принципе, обычные вышиватели знают тоже, что и сеньёр вышиватель, но сеньёр несёт ответственность за общую красоту и прочность холста, за скорость выполнения и адекватность выбора соответствующих нитей и иголок.
            Знает разницу между целлофановой калькой-интерфейсом для вышивания рисунка и абстрактным холстом-заготовкой, и очень этим гордится. Иногда сам создаёт как кальки, так и заготовки. Джуниоры вышивают без заготовок — сразу в лоб и с нуля, пришивая к холсту деревянную рамку, собственный рукав, галстук и сдерживающий рисунок скотч, иногда получая за это в тык.
    • +8
      Интрефейс есть совокупностость методов, описывающая взаимодействие с объектом, и подходит для множественного наследования.
      А абстрактный класс, это уже всё-таки класс, который может содержать не только абстрактные методы, но и поля, операторы, шаблонные методы.
      • –8
        Интерфейс — класс в котором все методы абстрактные.
        • +8
          Это частный случай, например в С++, т.к. там нет отдельных конструкций для описания интерфейсов. Более того, в С++ достаточно хотя бы одного pure virtual метода, чтобы класс стал абстрактным.
          • –3
            В Java тоже достаточного одного abstract метода, что бы бы класс стал абстрактным и что? Собственно то что меня тут минусуют хорошо показывает, кругозор людей. Хорошо хоть один человек нашелся, который знает что такое C++ и его особенности. Да в C++ есть множественное наследование и нет необходимости в ключевом слове interface как в Java, но сути это не меняет. Интерфейс и есть полностью абстрактный класс, то есть ни один из его методов не имеет реализации.
            • +6
              Мне кажется имелся ввиду более академический (ГОФ/Макконнелл) подход к определениям: любой класс обладает интерфейсом, в то же время полностью абстрактный класс — некоторое его выражение на уровне кода, потому что по смыслу совпадает со стоим интерфейсом.

              Вообще вопрос не стоит выделанного яйца и выполняет в статье символическую роль.
            • +2
              В Java достаточно назвать класс abstract. А вот abstract метод в обычном классе — это ошибка компиляии, да
            • +6
              Собственно то, что вас минусуют, хорошо показывает, что с кругозором у людей, слава аллах-акбару, пока ещё всё в порядке. Ибо вы дали чисто техническое отличие, а вопрос предполагал скорее концептуальное.

              «Велосипед — это мотоцикл, у которого отсутствует глушитель»
              • –4
                Наверное поэтому и родилась обсуждаемая статья ;-)
                Я сформулировал кратко и по-делу. Тот кто не понимает пишет кучу слов о сущности описании сущности и прочие, и прочие, и прочие… Я так тоже могу, но зачем умничать?

                И у велосипеда, таки ДА, нет выхлопной трубы ;-)
                • +8
                  Дело в том, что ваше краткое техническое описание — это всего лишь следствие концепции.
                  • –4
                    Мое краткое описание — констатация факта. То что куча хабравчан минусует это, лишь доказывает обоснованность обсуждаемой статьи, вот и все.
                    • +4
                      Да уж, заминусовали аж до -2 :)
                      А минусуют, думаю, из-за того, что ваша констатация факта отвечает не на тот вопрос, который подразумевается большинством, в том числе и людьми, принимающими собеседования.
                      И вопрос этот — в чём концептуальная разница между интерфейсами и абстрактными классами? В каких случаях нужно использовать одно, а в каких другое?
                      И вот в процессе ответа на эти вопросы, ваше краткое техническое описание обычно должно всплыть в разговоре само собой.
                      • –7
                        Ну вот нет в C++ ключевого слова interface и при этом понятие интерфейса во всю используется C++ разработчиками. Это возможно лишь понимая суть, и как раз понимание того, что интерфейс — полностью абстрактный класс и дает возможность в C++ использовать понятие интерфейса.
                        А по поводу ожидаемых ответов на собеседовании могу лишь написать большое такое «ОЙ». Прискорбно, если на хабре большинство сидит лишь для того, что бы наблатыкавшись умными словами, успешно пройти собеседование.
        • +3
          И нет свойств/полей/переменных тогда уж.
        • +2
          Дайте я тоже попробую.
          Интерфейс — если по сути — всего лишь набор функциональных требований к классам. Плюс в ряде языков интерфейс может служить контейнером для констант.
      • –1
        Интерфейс — абстрактный класс, в котором вообще нет реализации, только сигнатуры методов.
        • +8
          Ключевой момент в том, что интерфейс это не класс
          • +3
            В языках где интерфейсов нет как элемента синтаксиса они реализуются через абстрактные классы без свойств и только с абстрактными методами. Интерфейсы — частный случай абстрактных классов, сахар.
            • 0
              А почему не наоборот? По всей логике как раз абстрактные классы — частный случай. Вот прикиньте сколько языков с интерфейсами как отдельными сущностями, и сколько в виде абстрактных классов.
              • +2
                Интерфейс содержит только абстрактные методы., абстрактный класс может содержать и не абстрактные. Интерфейс не может содержать свойства, абстрактный класс — может. Абстрактный класс, если угодно, наследник интерфейса. Что является частным случаем чего?

                И вроде во всех мэйнстрим ООП языках либо есть и интерфейсы, и абстрактные классы, либо только абстрактные классы, либо вообще просто классы, а за их абстрактностью и интерфейсностью предлагается следить разработчику.
                • 0
                  Можно наследоваться только от одного абстрактного класса, но можно реализовать несколько интерфейсов. То есть, на абстрактные классы наложены более жёсткие ограничения.
                  В языках, где есть полноценные интерфейсы и полноценные абстрактные классы, это два разных понятия, ни одно из которых не является частным случаем второго.
                  • –4
                    C++ есть множественное наследование, если наследовать от нескольких полностью абстрактных классов, то и получится реализация нескольких интерфейсов.
                    • 0
                      Прошу Вас, не пишите более о C++, пожалейте читателей!
                  • 0
                    > Можно наследоваться только от одного абстрактного класса
                    По теории или в какой-то конкретной реализации (C#)?
                • 0
                  Вы не с той стороны подходите к вопросу. Интерфейс это не синтаксический сахар, это концепция в рассматриваемой парадигме. С точки зрения реализации в конкретном языке интерфейс может быть специальной конструкцией, которая описывает именно интерфейс, либо роль интерфейса выполняет например абстрактный класс. Но при этом само понятие интерфейса никак не является классом само по себе. Абстрактный класс это другая сущность, похожая по функциональным возможностям, и в частных случаях их заменяющая. Если брать в расчет конкретные реализации данной концепции, то никак нельзя сказать, что интерфейс это класс, ибо там где он есть это не класс.
                  • 0
                    Я только с точки зрения реализации.
                • +1
                  > «Интерфейс не может содержать свойства»

                  Это еще почему? Что вы называете свойствами?
                  • 0
                    Переменные в классе. Это уже реализация.
                    • +2
                      Поля (fields) и свойства (properties) — разные вещи. Поля это переменные класса, а вот свойства реализованы через два метода: геттер и сеттер.
                      Это все в терминах C#, но, насколько я знаю, это общепринятая терминология. По крайней мере, в языках, где проперти вообще реализованы.
                      • 0
                        Там где отдельного сахара для этого нет — синонимами считаются де-факто. Тогда можно переформулировать: «в интерфейсах не может быть полей и реализации свойств», реализации методов естественно тоже быть не может :)
                        • 0
                          Я думаю, что в интерфейсе вообще не должно быть реализаций по умолчанию, даже для вырожденных случаев типа:
                          virtual int GetA() = 0;
                          virtual int GetB() = 0;
                          virtual int GetAPlusB() {
                              return GetA() + GetB();
                          }
                          

                          Причина: интерфейс всего лишь говорит о том, что должен делать объект, а предлагать для этого различные реализации (отвечая на вопрос «как») должны абстрактные («как это делают представители данного рода») и обыкновенные («как это делают представители данного вида») классы.
                          • 0
                            Ниже s0rr0w привёл ещё один хороший пример про парикмахерские.
                    • 0
                      Речь не о конкретной реализации — а именно о свойствах о конструкции, неявно использующей getter и setter, как указал Shedal. Выставить наружу часть состояния объекта, или даже дать возможность его изменения — полностью укладывается в концепцию интерфейса. Да, на каком-то уровне это «сахар», но на каком-то уровне все абстрактно.

                      Кроме public-свойств интерфейс, вполне может определять индексаторы, для обращения к объекту, как к массиву и содержать public-события, на которые можно подписаться. Все это не мешает интерфейсу быть интерфейсом.
                      • 0
                        В моём основном языке «сахара» для неявных геттеров/сеттеров нет и предполагаю, что изменение состояния должно происходить только через методы.
                        • 0
                          Тогда все верно — внутреннее состояние, очевидно, не может быть интерфейсом (контрактом с «внешним миром»). Но тогда я бы использовал только термины «поле» (field) и закрытое свойство (non-public property).
                • +1
                  Что является частным случаем чего? Ничто, абстрактный класс и интерфейс существуют параллельно, и решают они разные задачи.
                  • 0
                    Задачи решаемые интерфейсом можно возложить на абстрактный класс? Имхо, можно (опустим для ясности невозможность множественного наследования в популярных языках где интерфейсы есть). Есть какое-то действие, которое можно произвести с интерфейсом, но нельзя с абстрактным классом?
                    • 0
                      Интерфейс — один из способов использования абстрактного класса. Соответственно, абстрактный класс — один из способов реализации интерфейса (там, где это возможно). Так что они (точнее, их воплощения в нашем мире) пересекаются, но не более того.
                    • 0
                      Так нельзя же опускать столь важную деталь. Это часть концепции интерфейса. И если это не реализовано на уровне языка, то должно быть конвенцией.
                      • 0
                        О, теперь и я вижу тот ответ, который мне импонирует. В моем понимании интерфейсом является декларация возможностей или унифицированный «язык» общения между объектами/модулями/компонентами. Интерфейс можно использовать даже не в ООП языках.
                        • 0
                          Это скорее «контракт» или есть различия?
                          • 0
                            Не, именно декларация. Например, парикмахерская в своем прейскуранте указывает, что она предоставляет услуги стрижки, укладки, маникюра. Это их интерфейс. Не важно кто именно там работает парикмахером и как именно стрижет, количество услуг не изменяется.
                            • 0
                              В прейскуранте она ещё указывает цену, плюс есть различные пост- и предусловия, инварианты и т. п. (какую валюту принимают, касса, защита прав потребителя и т. п.). Это, имхо, именно контракт, который парикмахерская предлагает заключить клиенту. Интерфейс же декларируется где-то в «правилах оказания услуг»
                              • 0
                                Не, это все возникает, когда начинают работать другие интерфейсы. Цена — частный объект в интерфейсе «оплата услуг». Защита прав потребителя — свой собственный интерфейс, или часть интерфейса «законные действия».

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

                      Ну и реальный пример: в приложении нужен платежный шлюз (ПШ), который должен уметь проводить платежи через несколько платежных систем (ПС). Вопрос как лучше реализовать?

                      1) Возможность расширения плагинами не предполагается: В этом случае наиболее рационально и просто реализовать класс Абстрактной ПС (АПС), от которой будут наследоваться все остальные ПС и переопределять необходимые методы (но вот часть методов логично расположить именно в АПС, поскольку они будут одинаковыми для всех ПС). Сам ПШ будет оперировать только АПС.

                      2) Решили дать возможность плагинам добавлять свои ПС: Можно оставить предыдущую модель, но в этом случае сторонним разработчикам придется разбираться в вашей реализации (в большом старом приложении 100% будет куча подводных камней в АПС, да и сам код, скорее всего, будет закрыт). Поэтому вместо этого логичнее вынести общие для всех ПС методы из АПС в Интерфейс ПС (ИПС) и заставить все ПС реализовывать его (фактически только АПС, которая в этом случае никуда не денется). Сам же ПШ вместо АПС станет оперировать ИПС.

                      ЗЫ: А данном контексте: публичный — совместно используемая библиотека; закрытый — конечный проект (код нигде повторно не используется).
                      • 0
                        Первый абзац порезался :( (читать сначала этот комментарий, а потом тот что выше)

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

                        Про выбор читаем выше.
                      • 0
                        А при чем реализация к интерфейсу?
                        • 0
                          В смысле?

                          ЗЫ: См. чуть выше пропущенную первую часть.
            • 0
              А почему без свойств? Если свойство — это открытое «наружу» состояние — интерфейс (концептуально) вполне может его содержать.
              • 0
                Через геттеры/сеттеры, по-моему, только, потому что открытое наружу свойство (переменная класса/объекта) это уже деталь реализации.
        • 0
          Интерфейс — это прежде всего набор правил (с точки зрения ООП) взаимодействия с тем или иным объектом.

          В этом смысле любой класс, обладает интерфейсом.

          Тем не менее, интерфейс классом считать нельзя, т.к. интерфейс — это не абстрактная реализация, а набор правил.
          • 0
            P.S. Запятая во втором предложении самопородилась в процессе редактирования. Время редактирования, к сожалению, истекло.
    • –10
      Интерфейс — класс в котором все методы абстрактные.
      • –1
        Раз все так серьезно. Тогда:
        Интерфейс — класс в котором только методы и только абстрактные.
        Абстрактный класс — класс в котором хотя бы один абстрактный метод.
        Ну и применение у них разное. И если его не считать, то интерфейсы — подмножество абстрактных классов.
        • +2
          Говорят, в той же Java (и PHP тоже) в интерфейсах можно ещё иметь константы… ;)
          • +1
            Константа — не реализация, в интерфейсах не должно быть реализаций.
          • 0
            А ещё говорят, что в Java в интерфейсы могут быть вложены интерфейсы и классы(!).
            Например Map.Entry.
          • +1
            В C# ещё и проперти
            • +1
              В C# ещё и event'ы, если уж на то пошло.
        • +1
          В Java могут быть статические final поля, но суть вы поняли верно.
      • +2
        Интерфейс — это не подвид класса.
        Вы путаете определение со свойством.
        То, что в некоторых языках программирования классы, у которых все методы абстрактные, могут выполнять роль интерфейсов, не означает, что интерфейс — это класс у которого все методы абстрактные.

        Если я могу забивать гвозди микроскопом, то это не значит, что молоток — это крепкий микроскоп с удобной ручкой.
        • +2
          Нет, это лишь значит, что микроскоп это штука, которой можно забивать гвозди. Этой штукой может быть молоток, может быть камень, может быть кусок металлической трубы.
          Когда вы проектируете класс, вы сначала описываете, то как он взаимодействует с внешним миром (интерфейс), а затем реализацию этого интерфейса. Но вот реализацию можно не делать и останется только интерфейс, вот и все.
          Поэтому, и у микроскопа и у молотка суперкласс — штука. Какой-нибудь абориген незнакомый с классами молоток и микроскоп будет общаться с ними как со штукой, вот и все.
          Вот кто-нибудь из спорщиков может мне привести пример задачи, которую я не смогу решить, или сильно усложниться решение если я буду придерживаться мнения: «Интерфейс — полностью абстрактный класс»?
          • 0
            > Вот кто-нибудь из спорщиков может мне привести пример задачи, которую я не смогу решить, или сильно усложниться решение если я буду придерживаться мнения

            Я не спорщик но позвольте попробовать: в большинстве императивных ЯП класс может реализовывать несколько интерфейсов, но может быть отнаследован лишь от одного класса.

            С этой позиции ваше решение «усложнится» (точнее говоря — вообще станет невозможным), если вы продолжите придерживаться своего мнения.
      • 0
        Интерфейс — не класс. Методы интерфейса — не абстрактные методы. Само понятие «абстрактный метод» подразумевает метод с абстрактной реализацией. В то время как метод интерфейса — это всего лишь правило, но никак не реализация.

        Изначально стоит упоминать, с какой именно точки зрения вы смотрите на этот вопрос. Если с точки зрения конкретной реализации в конкретном языке — возможно, вы правы. Но имхо, это очень упрощённый взгляд на вещи.
    • +26
      Интерфейс определяет, что можно делать с сущностью, а абстрактный класс — к какому общему классу сущностей принадлежит что-то.

      Пример:
      интерфейс «стучабельность» — по всему, что его реализует, можно стукнуть (независимо от того, к какому классу эта вещь принадлежит)

      абстрактный класс «дерево» — не определяет, что конкретно растёт на этом дереве, но говорит, что в общем у него есть корни, ствол и ветки. Конкретные реализации могут определять наличие\отсутствие веток, плодов, поддержку каких-то интерфейсов и т.д.
      • 0
        Ну, и как дополнение, хотя и достаточно очевидное после вашего объяснения, — в большинстве современных ОО-языков, класс может реализовывать несколько интерфейсов, но наследоваться может только от одного класса (абстрактного или обычного.)
      • +4
        Ну наконец, правильный концептуальный ответ. Я пока все комментарии выше вашего прочитал, у меня волосы дыбом встали от того, что и правда никто ж не знает. Спасибо за вернувшуюся веру в хабр и его обитателей.
        • +1
          А не понятно какого ответа в каком контексте ждут.
          • +1
            Исчерпывающего. Да и дело не в ответах на вопросы. Речь ведь в статье шла не столько о собеседованиях, сколько об отсутствии понимания базовых принципов в процессе работы. А в работе важно понимать не только технические нюансы интерфейсов и абстрактных классов, но и семантические — то есть, в каких общих ситуациях что применяется и почему, с точки зрения архитектуры и проектирования.
            • 0
              Базовые принципы можно выучить за неделю. А вот научиться эффективно и самостоятельно решать сложные задачи, с этим как раз проблемы.
              • 0
                Тем более, раз можно выучить за неделю, и надо проверять. Только почему-то комментаторы выше не удосужились даже эту неделю потратить…
                • 0
                  Неделю то можно потратить, но если тебе кто-то это доходчиво будет пояснять всю эту неделю. Иначе слово «интерфейс» не имеет никакого смыслового контекста для новичка. Можно хоть тонну книг прочитать, но это не избавит от проблемы проверки знаний и закрепления верных выводов.

        • 0
          Концептуально интерфейс — это набор правил взаимодействия. Важно понимать, что любой класс обладает интерфейсом. Так что концептуально сравнивать интерфейс с классом некорректно. Аналогично можно спрашивать, чем отличается ТК РФ от зарплаты.

          Так что в исходном вопросе стоит уточнить, о чём мы говорим: о концепции или о конкретной реализации в разных языках программирования.
      • 0
        Это объяснение (принимаемое как правильное, судя по заплюсованности) говорит о восприятии человеком двух этих сущностей. То есть чисто психологически интерфейс человеку говорит одно, а класс — другое.

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

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

        О… Паттерны это была религия одно время. Если не знаешь названия паттернов — считай не программист. Сейчас поутихло. Все как и раньше пользуют MVC, singletone, factory и какие ещё нужны, но уже не раздуваются от гордости по этому поводу.

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

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

        А между тем, чем отличается интерфейс от абстрактного класса, сродни вопросу про то, чем похожи ворон и письменный стол из загадки сумасшедшего шляпника из Алисы в Стране Чудес. Не суть чем они похожи или чем они отличаются. Суть в том — для чего тебе ответ на этот вопрос. Если для того, чтобы пройти интервью — ты что-то делаешь не так.
        • 0
          Черт с ними, с интерфейсом и абстрактным классом — выяснили же уже, что никто не знает точно, в чём отличие. Но если на собеседовании не задавать задачки на логику, не спрашивать основы ООП и паттерны — то о чём вообще говорить? Как Спартак вчера сыграл? Где на рынке лучше мясо покупать?

          Ответы на задачки и разговор об ООП хотя-бы даёт представление о общей логике человека, попытках думать, показывает его неравнодушие к теме и какие-никакие знания. Есть мысли, что нужно спрашивать?
    • –10
      Мне сразу вспоминает начало одной из замечательных книг Брюса Эккеля «Философия C++»
      Картинка оттуда: image
      Думаю не сложно догадаться, что является абстрактынм классом, а что интерфейсом.
      • 0
        `абстрактным' конечно же
      • +3
        И что? «Фигура» может быть абстрактным классом, может быть интерфейсом (не в C++ конечно), а может быть абстрактным классом «реализующим» интерфейсы Colorable, Drawable и Movable :)
      • +6
        Если это UML диаграмма, то на ней изображены только классы и обобщения (наследование) без интерфейса(ов). Абстрактных классов на ней тоже нет.
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Пишу в контексте языка PHP.
      Во-первых, тем же (всем), что и класс вообще от интерфейса. Как класс отличается от переменной, так и массив отличается от функции и переменная от трейта. ПРосто разные вещи.
      Во-вторых, наследовать можно только от одного класса, но зато от нескольких интерфейсов.
      В-третьих, интерфейс не может содержать логику (код).
      В-четвёртых, интерфейс обязует написать некоторые методы, а абстрактный класс позволяет их опустить вообще.
      В-пятых, изменение абстрактного класса влияет на логику и ход работы программы. Изменение интерфейса может привести только к ошибкам на этапе запуска.
      В-шестых, и самое главное, говоря упрощённо, абстрактный класс — это класс, который не может иметь экземпляров (от него только наследуются), а интерфейс — это некий список методов, которые класс обязан реализовывать.
      В-седьмых, класс, наследуемый от абстрактного, может не содержать методов (исключение — абстрактные методы). Класс, наследуемый от непустого интерфейса, обязан содержать методы.

      Вообще, более интересные вопросы:
      1. Чем абстрактный класс, все методы которого абстрактные, отличается от интерфейса?
      2. Что общего между абстрактным классом и интерфейсом?
    • +3
      Насколько я понимаю, интерфейс — ничто иное, как протокол взаимодействия, некоторый набор свойств. А вот абстрактный класс — это тот же протокол, но нагруженный частичной реализацией.

      И интерфейсы, и абстрактные классы позволяют работать с деревом потомков как с единым типом. Не это ли суть ООП?

      Как советуют сильные мира сего, следует использовать интерфейсы везде, где только возможно, а абстрактные классы — только в случае крайней необходимости (ну, например, при реализации паттерна проектирования Template Method). Хотя это весьма спорный момент, но время идёт, а базовые концепции ООП пересматриваются.

      В C++ интерфейсов нет, хотя они и достаточно просто реализуются средствами языка. Но так как их нет, они и не используются особо. Java же вынуждает реализовывать интерфесы в тех случаях, когда необходим аналог «множественного наследования».
    • 0
      Ну, насколько я могу судить (не читая особо углубленно про эту тему) из чистой практики использования интерфейсов и абстрактных классов:

      Интерфейс — есть выражение того, как объект (инициализированная сущность класса) ОБЯЗАН выглядеть для окружающего кода, то бишь какими методами он будет гарантированно обладать (если проверять объект на принадлежность именно к нужному интерфейсу) и свойствами (пример из IRL: есть интерфейс чайник, да, с моей колокольни именование предмета чайником — есть обозначение принадлежности предмета к интерфейсу Чайник, что имеется ввиду под названием Чайник? Он должен уметь кипятить воду, не важно как, просто должен кипятить/разогревать, и все, а наличие отверстия для выливания жидкости уже другой интерфейс равно как и наличие ручки у него так же совершенно другой интерфейс).

      Абстрактный класс — есть потенциал потомков этого класса, то бишь это нечто гораздо большее, по своим возможностям, чем интерфейс, но не является таковым, ведь мы можем просто объявить класс-наследник от абстрактного абсолютно пустым, но он будет уметь все то же, что и абстрактный родитель, в отличии от интерфейса.
      • +1
        Скорее «Чайник» это должен быть абстрактный класс, реализующий интерфейсы «Кипятибельный», «Выливабельный», «Держабельный». А уже от него наследуются конкретные типы чайников «Чайник алюминиевый артикул 123456» или «Чайник электрический Example модель SuperBoiler 178» (возможно через другие абстрактные классы типа «Чайник металлический» или «Чайник электрический»). Если, конечно, домен требует работы с конкретными экземплярами чайников конкретных моделей.
  • +2
    Зло но по существу до безобразия жизненно.
    Сказал бы — сермяжная правда жизни.
  • 0
    Спасибо вам! Дочитав пост взял книжку и разобрался таки, чем абстрактный класс отличается от интерфейса. :) На всякий случай — книга Java2 Том 1. Основы Хорстманна и Корнелла.
    • 0
      Очень рекомендую изучить разницу в принципе, а не с точки зрения конкретного языка.
      • 0
        Совершенно согласен. За что и люблю эту книжку — там более-менее ООП разжёвано.
  • –15
    Три с половиной раза написать «чем абстрактный класс отличается от интерфейса»… это сильно. Так чем же простите, с точки зрения реализации? Просто удобный сахарок. Да и то, удобство весьма сомнительно.
    • +20
      Так вообще-то все языки, начиная с базового синтаксиса, через ключевые слова и конструкции, и заканчивая стандартными библиотеками — не более чем «сахарок» над тру-хардкорным ассемблером. А то, знаете ли, можно и сайты на ассемблере писать, причём на ООП, ибо Virtual Method Table — не такая уж и сложная вещь на на уровне реализации.
      • –1
        Утрировать не стоит.
        Нет в языке интерфейсов, значит будет применяться upcasting. Без расслоения и прочих ужасов. И абсолютно никаких различий между интерфейсом и абстрактным классом.
        Есть интерфейсы, значит будут использоваться они. Тогда действительно будет различие, но на уровне реализации ООП в рамках рассматриваемого языка.
        • 0
          В некоторых языках где есть интерфейсы нет множественного наследования. А значит не всегда можно тупо заменить интерфейс на абстрактный класс. Частный случай, конечно, но имеет место быть.
          • –1
            Не могу понять, чем же ваш пост отличается от моего по смыслу…
            Но, разу уж вы его написали, то быть может приведете примеры популярных языков программирования, которые поддерживают и интерфейсы и множественное наследование?
            • 0
              Что есть различия, что не всегда можно заменить интерфейс абстрактным классом и тем более, наоборот,, а не И абсолютно никаких различий между интерфейсом и абстрактным классом.

              Не припоминаю таких, но т. к. не все языки знаю, то подстраховался и написал «в некоторых», а не «во всех» :)

      • 0
        ООП и без виртуальных функций бывает.
        • 0
          Хм… Да? Интересно. Можно пример реализации полиморфизма без виртуальных функций?
            • +1
              А можно краткую выжимку этого 42-страничного математического труда о жизни, вселенной и всём таком?
              • 0
                И печеньков? :)
          • +1
            Сами представить не в состоянии? Назову один из примитивных способов — switch
            Табличная реализация (vtable) — просто частный случай.
            • 0
              Ну вообще-то не очень в состоянии. Switch нарушает инкапсуляцию: это кто-то другой знает о том, какую фукнционал вызывать для данного класса в зависимости от его типа или (хуже) от его данных. Да, в общем-то, и наследование он слегка нарушает. Что делает такой подход не-ООП'шным. Ну или я просто не понял схему со switch.

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

              В любом случае, изначальный вопрос был про фразу «ООП и без виртуальных функций бывает». Я пытаюсь представить себе как именно.

              • 0
                это кто-то другой знает о том, какую фукнционал вызывать для данного класса в зависимости от его типа или (хуже) от его данных.

                Не очень понял, но выглядит примерно так:
                class SomeClass
                {
                
                  public function __construct($arg)
                  {
                      switch (getype($arg)) {
                        case 'integer':
                          // integer argument
                          break;
                        case 'string':
                          // string argument
                          break;
                        default:
                          // other cases
                      }
                  }
                
                  public function someMethod()
                  {
                      switch (func_num_args()) {
                        case 0:
                          // no argument
                          break;
                        case 1:
                          // one argument
                          break;
                        default:
                          // other cases
                      }
                  }
                }
                
                
                $obj = new SomeClass(1); // integer behavior of constructor
                $obj->someMethod(2); // one argument behavior
                
                • 0
                  Первое (конструктор) — это не ООП. Если именно integer/string рассматриваются как «как бы полиморфные без виртуальных функций».

                  А если сам SomeClass — то вообще к полиморфизму и ООП этот пример отношения не имеет, и является примером ручной перегрузки конструктора разнотипными параметрами.

                  Второе (функция) — пример динамического набора параметров; в лучшем случае — тоже про перегрузку функции. Тоже не про «ООП без виртуальных функций».
                  • 0
                    Ну да, перегрузка — частный случай полиморфизма. Мне в холиварах часто «плюсанутые» указывали на этот недостаток PHP (отсутствие перегрузки по сигнатурам, вернее по количеству/типу параметров), а «мою» перегрузку называли грязным костылём, но потом переходили на невозможность перегрузки операторов. Полиморфизм через наследование в PHP тривиален, если, конечно, класс/метод не объявлен как final. Но ключевого слова virtual нет :) Теперь кажется понял про что вы. Когда-то (когда в PHP ООП не было вообще, а после C++ мне его сильно не хватало) делал вот так примерно:

                    Кучка быдлокода
                    function constructObject($class, $args) {
                      global $classes;
                    
                      $constructor_name = "{$class}_construct";
                    
                      if (isset($classes[$class]['parent']) {
                        $object['__class'] = array_merge($classes[$class]['parent'], $classes[$class]);
                      } else {
                        $object['__class'] = $classes[$class];
                      }
                    
                      $constructor_name(&$object, $args);
                    
                      return $object;
                    }
                    
                    function invokeObjectMethod(&$object, $method, $args) {
                      $method_name = $object['__class']['name']
                        . '_'
                        . $object['__class']['methods']['method'];
                      return $method_name($object, $args);
                    }
                    
                    function someClass_construct($this, $args) {
                      // ...
                    }
                    
                    function someClass_someMethod($this, $args) {
                      // ...
                    }
                    
                    $classes = array(
                      'someClass' => array(
                        'name' => 'someClass'
                        , 'methods' => array (
                          'someMethood' => 'someMethod'
                        )
                      )
                    );
                    
                    $obj = constructObject('someClass', array('someParam'));
                    invokeObjectMethod($obj, 'someMethod', array('onterParam'));
                      
                    


                    Написано на коленке в буквальном смысле слова, прямо в инпуте хабра, но думаю идея понятна. Подобное можно реализовать и на Си, только карты надо будет реализовать и «методы» по указателю назначать и вызывать. И кто скажет, что это не ООП :)
                    • +1
                      > перегрузка — частный случай полиморфизма

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

                      > И кто скажет, что это не ООП :)

                      Это ООП. Причём это VMT и есть. Вот чистая голимая VMT:

                      $classes = array(
                        'someClass' => array(
                           'methods' => array (
                            'someMethood' => 'someMethod'
                          )
                        )
                      );
                      


                      А перенеси вы хождение по parent из constructObject() в invokeObjectMethod(), то получилась бы DMT (Dynamic Method Table). Это из Object Pascal & K.

                      PS: Такой же фигнёй сейчас занимаются JS'ры, которые пытаются сделать «красивый ООП как у других». LOL :-)
                      • 0
                        но вот наследования из него уже не родишь, а значит ООП не получится.

                        Можно и наследование сделать, в свитче вызываем протектед функции вроде some_method_noarg/one_arg, которые можем переопределить в наследнике по одной, то есть для наследника переопределить вызов метода с одним аргументом не трогая другие случаи, благо LSB есть.

                        Это ООП. Причём это VMT и есть.

                        Надо же, опять велосипед изобрёл, а ведь так гордился :)

                        то получилась бы DMT (Dynamic Method Table)

                        Первая реализция у меня была с полностью динамическим вычислением имени функций типа $func_name = $class.'_'.$method; $func_name($obj, $args);, потом по каким-то причинам сделал «таблицу» — это тоже DMT?

                        PS: Такой же фигнёй сейчас занимаются JS'ры,

                        Ну хоть не только PHPшников будут велосипедистами называть. Для нас это пройденный лет 10 назад этап :)
                        • 0
                          Сделали, наверное, по причине того, что если в каком-то «класса» функцию таки не переопределить, то она и не вызовется, так как именно для этого «класса» будет не создана (а только для родителя).
              • 0
                Видимо речь все же шла о случае, когда виртуальные функции не реализуются языком разработки.
                Напрмер, в JavaScript ООП нет, но эта парадигма реализуется уже программно (например, в ExtJS). Так что формально виртуальных функций (или все-таки полиморфных? а то ведь термин скорее относится именно к C++) нет. А по факту — ООП в конечном продукте используется.

                ООП — это парадигма. Есть в нем идея полиморфизма, а уж как она будет реализоваться — с помощью VMT или с помощью прототипного наследования или switch'ей по массиву указателей на функции — это уже детали.