Пользователь
0,0
рейтинг
13 декабря 2013 в 17:30

Разработка → Страсть к программированию. Глава 8. Будь специалистом из песочницы

Продолжаем переводить книгу Чеда Фоулера «Страсть к программированию» совместными усилиями. Готов координировать работу с остальными переводчиками.

Глава 8. Будь специалистом


— Каким образом Вы можете добиться падения JVM используя только возможности Java?
В ответ — тишина.
— Вы меня слышите?
— Извините, я не понял Вас. Повторите, пожалуйста, вопрос.

В голосе прозвучало отчаяние. Я знал из своего опыта, что повторение вопроса не поможет. Тем не менее я повторил вопрос, медленно и громко.

— Каким образом Вы можете добиться падения JVM используя только возможности Java?
— Эм… Извините, я никогда не сталкивался с подобной задачей.
— Я уверен, что не сталкивались. Как насчёт такого вопроса: как бы Вы написали программу, которая бы никогда не приводила к сбоям JVM?

Я искал действительно хороших Java разработчиков. В начале интервью я попросил этого человека (и всех людей, которых я интервьюировал в течение той недели) оценить себя по шкале от 1 до 10. Он сказал девять. По моим ожиданиям он должен быть невероятным специалистом. Если этот парень так высоко оценивает себя, почему он не может придумать ни одного трюка который приведёт к сбою JVM?
Недостаточно глубокие знания.

Этот человек утверждает что он разбирается в Java. Если бы Вы встретили его на вечеринке и спросили как он зарабатывает свой хлеб, он бы ответил: «Я Java разработчик». При этом он не смог ответить на этот простой вопрос. Он даже не смог дать неправильный ответ. На протяжении двух с половиной недель в поисках кандидатов на вакансии в Индии такая картина не была исключением, это было правилом. Тысячи Java специалистов претендовали на вакансии, практически никто из них не мог объяснить как работает загрузчик классов Java или описать в общих чертах как виртуальная машина Java управляет памятью.

Ладно, Вы не должны знать все эти нюансы для того чтобы писать простой код под присмотром опытных специалистов. Но предполагалось что эти соискатели были экспертами. Похоже на то, что очень многие из нас верят в то, что специализация означает то, что Вы попросту не знаете ничего другого. Например, я мог бы назвать мою маму специалистом по Windows, поскольку она никогда не работала с Linux или OS X. Или, я мог бы назвать своих родственников из глубинки в Арканзасе экспертами в кантри, потому что они никогда не слышали другой музыки.

Представьте что Вы на приёме у Вашего семейного врача, жалуетесь на странное уплотнение под кожей на правой руке. Ваш врач направляет вас к специалисту для проведения биопсии. Что если бы этот специалист считался таковым лишь потому что в медицинском учебном заведении он не учился ничему, что бы не было непосредственно связано с биопсией? Я не подразумеваю что он углублённо изучал всё что связано с биопсией. Возможно он лишь вскользь пробежался по материалам по данной теме, но не знает ничего другого. Если бы Вы спросили у этого специалиста:
— Что если тот аппарат начнёт издавать звуковой сигнал во время операции?
— Хм, не припомню чтобы такое случалось, вряд ли это случится в этот раз. Я не знаю что делает это оборудование, но оно ещё ни разу не издавало звуков.
К счастью от результатов работы большинства разработчиков не зависят жизни. Если они облажаются, их работодатели теряют деньги, а не жизни.
К сожалению в нашей индустрии множество таких узких специалистов, которые используют термин специалист как оправдание для того, что они не знают ничего другого. В медицине специалист это человек с действительно глубокими знаниями в конкретной области. Врачи направляют пациентов к специалистам, потому что в некоторых ситуациях специалист окажет им более квалифицированную помощь чем врач широкого профиля.

Так кем же должен быть специалист в нашей отрасли? Я могу сказать Вам кого именно я искал в своей поездке с целью нанять квалифицированных разработчиков. Я искал людей которые глубоко разбираются в Java разработке и ориентируются в среде в которой будет работать разрабатываемое программное обеспечение. Я искал людей которые могли бы сказать «знаю, делал» в 80% ситуаций в которые мы можем попасть при разработке и глубина знаний которых позволит им справиться с оставшимися 20% незнакомых ситуаций. Я хотел найти таких специалистов, которые работая с высокоуровневыми абстракциями понимали бы низкоуровневые детали того, что позволяет реализовать эти абстракции. Я хотел найти человека, который мог бы справиться с любой проблемой связанной с внедрением разрабатываемого продукта, или по крайней мере знал бы к кому обратиться за помощью.
Это специалист который выживет в изменчивой индустрии разработки программного обеспечения. Если Вы .NET специалист, это не является оправданием отсутствию знаний чего-либо кроме .NET. Это значит, что если речь идёт о .NET — Вы эксперт. Зависшие и нуждающиеся в перезагрузке IIS сервера? «Без проблем». Интеграция системы контроля версия с Visual Studio? «Будет сделано». Клиенты в ярости из-за непонятных проблем с производительностью? «Дайте мне полчаса».
Если же Вы не согласны с таким определением специалиста, надеюсь Вы не называете себя этим словом.

Действуй!


1. Вы используете компилируемый язык, который работает в виртуальной машине? Если да, потратьте некоторое время на изучение внутреннего устройства данной виртуальной машины. В случае с Java, .NET, Smalltalk существует очень много книг и онлайн ресурсов посвящённых этой тематике. Ознакомиться с данной тематикой проще чем Вы думаете.
Зависит ли Ваш язык от виртуальной машины или нет, посвятите некоторое время на то чтобы разобраться, что происходит когда Вы компилируете файл с исходным кодом. Что происходит в процессе того как код, который Вы набирали, из текста превращается в инструкции, которые может выполнять компьютер? Что нужно для того, чтобы написать свой собственный компилятор?
Когда вы импортируете и используете сторонние библиотеки, откуда они загружаются? Что в действительности означает импортировать стороннюю библиотеку? Как Ваш компилятор, операционная система или виртуальная машина объединяют несколько кусков кода вместе в одну связную систему?
Изучение этих вопросов приблизит Вас на несколько шагов к статусу специалиста в выбранной Вами технологии.
2. Найдите возможность (на работе, или во внерабочее время) обучать желающих тем аспектам технологии, в которых Вы хотели бы глубокого разбираться. Как Вы увидите в главе «Будьте наставником», обучение других это один из лучших способов научиться самому.
Илья @sdevelopment
карма
7,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +24
    Он искал готовых специалистов. Глупость. Искать надо людей, у которых был опыт вникания в работу систем. Таких легко можно адаптировать под тот зоопарк, который есть в компании. Искать спеца под зоопарк — нелепо.
    • +16
      Вы уверены, что человек, который X лет работал с Java и до сих пор даже не удосужился «вникнуть в работу» JVM сможет «вникнуть в работу» каких-либо других систем?

      Он ведь не спрашивал про свой зоопарк, он спрашивал про работу системы, с которой человек, предположительно, общается очень и очень много и в которой, предположительно, он чувствует себя очень и очень уверенно!
      • +9
        Java более всего ассоциируется с махровым энтерпрайзом. Почему программист, который работает в энтерпрайз компании должен вникать в то, как устроен его инструментарий? Ещё раз: почему энтерпрайз специалист должен вникать в устройство используемых инструментов?

        Если из этого предложения убрать слово «энтерпрайз», вопрос станет уместным. Для энтерпрайза он не уместен — есть вендоры, есть best practice, которым надо следовать. Есть планирование и задачи. Если человек много писал энтерпрайз кода, то он выполнял свои служебные обязанности, а ронять ява-машину в служебные обязанности у него явно не входило.

        Искать «хаккеров для явы» — это оксюморон какой-то.
        • +6
          Java более всего ассоциируется с махровым энтерпрайзом. Почему программист, который работает в энтерпрайз компании должен вникать в то, как устроен его инструментарий? Ещё раз: почему энтерпрайз специалист должен вникать в устройство используемых инструментов?
          Он никому ничего не должен. Пока он не пытается стоить из себя эксперта.

          Давайте сравним с токарем. Если у вас токарь работал «в махровом энтерпрайзе» (== огромной компании) и 10 лет точил себе простенькие гаечки на токарном станке, то это не значит, что он может делать вид, что он — токарь 6го разряда и претендовать на соответствующую должность — для этого он как раз должен уметь выполнять работы, требующие «комбинированного крепления и высокоточной выверки в различных плоскостях». Почему «Java-специалист 6го разряда» (ну хорошо, пусть 5го — он всё-таки себе 9 из 10 приписал, не 10) ничерта не знает про хитрости работы с его инструментом?

          Для энтерпрайза он не уместен — есть вендоры, есть best practice, которым надо следовать. Есть планирование и задачи. Если человек много писал энтерпрайз кода, то он выполнял свои служебные обязанности, а ронять ява-машину в служебные обязанности у него явно не входило.
          Совершенно верно: он Java-программист 2го (ну хорошо, может быть 3его) разряда. Пусть и с 10 годами работы. Какого фига он корчит из себя что-то большее?

          Искать «хаккеров для явы» — это оксюморон какой-то.
          Вау. То есть программисты на Java уже не должны никогда писать задачи, где ресурсы имеют цену? С чего вдруг?
          • +9
            Нет уж, если мы говорим про слесарей, давайте переводить на этот же язык.

            Слесарь 6ого разряда, говорите? А знаете ли вы как вызвать разрушительный резонанс на вашем станке? То есть вообще не знаете и не думали об этом? Да что вы за слесарь такой? Не 6 разряд, точно.

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

            • +8
              Слесарь 6ого разряда, говорите? А знаете ли вы как вызвать разрушительный резонанс на вашем станке? То есть вообще не знаете и не думали об этом? Да что вы за слесарь такой? Не 6 разряд, точно.
              Спасибо за понимание. Я не понимаю как у вас токарь превратился слесаря, но суть дела вы передали весьма точно. Да, если токарь не может объяснить как вызвать разрушительный резонанс (или, что практически важнее, не допустить, чтобы оный резонанс возник), то это не 6й разряд уж точно. Я понимаю, что Java-программисту убить JVM несколько сложнее, чем токарю угробить свой станок, но принцип, в общем-то, тот же.

              Почему человек, пищущий код на java и знающий стандартную библиотеку насквозь, да ещё хорошо знающий все общеупотребимые нестандартные, почему он должен хоть в зуб ногой по поводу jvm?
              #@$^%#&^@! Ну вы же, чёрт побери, сами всё прекрасно объяснили: не почему, а для чего — для того, чтобы претендовать на звание специалиста высокого класса, эксперта. Он может прекрасно продолжать работать в своём «энтерпрайзе» и следовать «best practice» (даже не пытаясь понять почему они «best» и когда они перестают быть «best»). Но зачем же приписывать себе квалификацию и заявлять что ты владеешь тем, чем ты не владеешь?
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Очень точно отражает действительность.
                  Остается еще добавить завышенную самооценку, и будет полный комплект.
                  :-)
        • +1
          Вы пытаетесь судить что нужно компании о которой ничего не знаете. Вполне вероятно что им нужен именно Java эксперт, а не JEE эксперт. В энтерпрайз проектах тоже бывают «сложные» места, на которые нужен опытный человек, который мог бы такое место грамотно разработать и огородить его от возможных поломок кривыми руками других девелоперов.

          Кстати до прочтения статьи считал себя Java экспертом :)
        • –1
          есть best practice, которым надо следовать

          А почему? Почему им надо следовать? Потому что Вася Пупкин так сказал?
          • 0
            Потому что последовательное следования практикам, изложенным в материалах вендора/книжке именитого автора экономит время ваше и тех кто через 5 лет после вас будет переделывать/поддерживать вашу систему при сохранении годного результата.
            Т.е. это как следовать руководству по эксплуатации технически сложного прибора, например.
            • 0
              Через пять лет могут оказаться популярными другие вендоры/авторы.
            • 0
              Большинство подходов устаревают.
              Более того, те же авторы через 5-10 лет говорят уже другие вещи, иногда прямо противоположные.
              Надеюсь, примеров не нужно? :-)
          • +3
            Потому что это энтерпрайз. Человек, который следует best practice всё делает правильно. Даже если получается ужасный монстр или ничего не получается, потому что бюрократия, размывание ответственности и прочие прелести крупных контор просто требуют следовать best practice и не выделываться. А те, кто выделываются — быстро вылетают (если не оказываются сверху).
          • 0
            Wiki в помощь — Best coding practices are a set of informal rules that the software development community has learned over time which can help improve the quality of software.
            Many computer programs remain in use for far longer than the original authors ever envisaged (sometimes 40 years or more), so any rules need to facilitate both initial development and subsequent maintenance and enhancement by people other than the original authors.
  • +15
    Так как уронить-то?
    • +9
      Например, можно поиграться с Unsafe и попереписывать участки памяти, занятые JVM.
      • +2
        А если попробовать просто вылезти за memory limit? И вообще, а если без unsafe или jni? С unsafe любой дурак может ногу прострелить себе.
        • +1
          Без unsafe и jni — только воспроизвести какую-либо ошибку (как сделал sdevelopment ниже). Спецификация JVM не предусматривает ситуаций, когда машина целиком может упасть (максимум — OutofMemeory или другая RuntimeException). Если упала — значит, ошибка.
    • 0
      Сам не являюсь специалистом в Java (и автором этой книги тоже), поэтому поискал что пишут по этому поводу на stackoverflow:

      public class Recur {
      public static void main(String[] argv) {
          recur();
      }
      static void recur() {
          Object[] o = null;
          try {
              while(true) {
                  Object[] newO = new Object[1];
                  newO[0] = o;
                  o = newO;
              }
          }
          finally {
              recur();
          }
      }
      }
      


      C:\JavaTools>java Recur
      #
      # An unexpected error has been detected by Java Runtime Environment:
      #
      #  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x000000006dad5c3d, pid=6816, tid
      =5432
      #
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode windows-amd64)
      
      # Problematic frame:
      # V  [jvm.dll+0x2e5c3d]
      #
      # An error report file with more information is saved as:
      # C:\JavaTools\hs_err_pid6816.log
      #
      # If you would like to submit a bug report, please visit:
      #   http://java.sun.com/webapps/bugreport/crash.jsp
      #
      


      источник, ещё один вопрос на stackoverflow с примерами.
      • 0
        del
      • +1
        На stackoverflow посоветовали добиться EXCEPTION_STACK_OVERFLOW… прям тавтология
        • 0
          рекурсия )
          • 0
            Stack Overflow высшего порядка :)
        • 0
          Слишком долго: обработка исключений занимает намного больше времени, чем просто вызов метода и возврат из него (по крайней мере в Java 1.6).
          • 0
            А, нет, посмотрел — выше именно его и добились, правда, сильно изощрённым способом…
        • 0
          Похоже, для этого требуется намного меньшая вложенность, чем просто для StackOverflowError…
      • 0
        В последней Java 8 уже не работает, и другие примеры со SO тоже. Unsafe это неспортивно (хотя и 100% «надёжно»). Поэтому вопрос совсем не тривиальный :)
  • +19
    >оценить себя по шкале от 1 до 10. Он сказал девять.
    а что вы ожидаете он ответит? «Я пишел устраиваться на разработчика, оцениваю себя на 5-6»?
    • +2
      «Я пришел устраиваться на эксперта» вообще-то. Умение реалистично оценивать свои навыки, и их границы — это даже не про эксперта, это просто про хорошего специалиста.
    • +11
      Ну не знаю, когда я спрашиваю кого-то на сколько баллов он оценивает свое знание С++ и если он отвечает «на 5+», то это очень серьезный повод усомниться. Себе я больше тройки не дам точно (да и специалистом себя назвать не смогу), хотя вроде как больше 10 лет работаю с этим языком. Но чем больше работаешь, тем больше понимаешь, что ничего не понимаешь. Ну или точнее, что существует огромный пласт информации помимо того «базового набора», с которым знакомишься в первый год.

      Здесь я думаю та же история. Если человек способен хотя бы обозначить эти сомнения, это уже показатель того что он заглянул дальше азов.
      • +1
        когда я спрашиваю кого-то на сколько баллов он оценивает свое знание С++ и если он отвечает «на 5+», то это очень серьезный повод усомниться
        По деситябальной системе?
        • 0
          Нет, по обычной
          • +1
            OK. Но все равно вопрос сложый, как же оценивать знание C++.

            Обычно есть некоторый упрощенный повседневный диалект, который отличается от проекта к проекту. Можно успешно писать на плюсах много лет, и даже не знать о продвинутой шаблонной магии. А еще иногда приходится заглядывать в спецификацию языка.
            • +1
              Как говорил тов. Филатов, преподавая в Одессе:
              «На 5 медицину знает только сам Господь Бог. На 4 — может быть знаю я. Так что никто из вас, студентов, выше 3 не получит».
              Г-дь Б-г тут может быть зменён на Страуструпа… хотя и в нём я не уверен…
              • +1
                Спасибо, я теперь знаю как отвечать на собеседовании, когжа меня попросят оценить свои знания чего-то :)
              • +7
                Страуструп оценивает свои знания С++ на 8 или меньше.
                • –1
                  По пятибальной шкале? ;-)
                • 0
                  Скажите, на сколько Вы знаете проект, который сейчас разрабатываете? :-)
                  Вряд ли кто-либо знает больше, чем на 8 из 10.
                  Так же и Страуструп :-)
      • +5
        Ну все нормально. Начинаешь с 5+, и так дальше, 5, потом 4+. Вот вы уже до троечки прокачались ;)
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Да, я тоже списываю подобные ответы на этот эффект. HR же вообще любые осторожные комментарии относительно предметной области склонны рассматривать как признак некомпетентности.
        • 0
          Давно сказано: «Я знаю, что ничего не знаю.»

          А ещё пример с окружностью. Чем больше наши знания (круг), тем больше мы соприкасаемся с неизвестным (длина окружности).
      • +1
        По идее, после такого вопроса «как вы себя оцениваете по n-шкале» должно идти разъяснение, что для вас значит максимальная и минимальная оценка. Иначе это просто демагогия, ибо разные системы оценки и понимания шкалы.
        • 0
          Большой плюс.
          Еще бы все HR это понимали. :-)
          Я лично вследствие вышесказанного избегаю давать численные оценки на собеседовании, ибо они могут сказать только об отношении человека к предмету, да и то косвенно. Вместо этого лучше обрисовать, какие области Вам известны, какие сейчас изучаете, какие в планах.
  • 0
    А где остальные главы? И где происходит перевод?
  • +2
    Прошу раскрыть упомянутый у вас простой вопрос о том «как бы Вы написали программу, которая бы никогда не приводила к сбоям JVM», очень интересно.
    • –1
      Ответил выше
      • +1
        Вы ответили как уронить, это я и сам могу: нитки, не хвостовая рекурсия, память и тд. А вот как чтобы никогда не приводила к сбоям — это другой, намного более интересный вопрос.
        • +5
          это же очевидно. лучший код — не написанный код, он точно ничего не уронит
          • +1
            Те, кто поддерживает чужой код, пожалуй, согласятся с вами в том, что лучший код — это ненаписанный код…
          • 0
            Это в пределе. :-)
            А вообще размер — нехороший показатель.
            Короткий код часто оказывается неподдерживаемым.
            • 0
              Короткий код не так жалко выкинуть и переписать для новых условий «по мотивам старого». А длинный действительно приходится поддерживать, и это может оказаться сложнее.
  • 0
    … а у врача можно спросить, как остановить сердце, не прикасаясь к пациенту. Если не умеет — это плохой врач!
    • +4
      Я конечно не врач, но по-моему есть куча способов остановить сердце, не прикасаясь к пациенту. Ведь любого рода смерть включает в себя остановку сердца (было это причиной смерти или следствием в данном случае не важно, задача — остановить сердце). И тут вам и отравляющие газы, и смертельная доза облучения, и шаговый удар током, и смерть от истощения/обезвоживания, и принуждение к самоубийству (так, хабр за это не забанят же?), скажем, с угрозой оружием. Использование третьих лиц для «прикосновений» к пациенту, опять же.

      А если придираться к постановке задачи, то можно подумать, что сердце нужно остановить самому себе, тут все еще проще! Но это уже неспортивные придирки, не спорю.
      • +2
        Смысл аналогии в том, что врач не обязан знать как, его работа знать почему — фибриляция, тромб, спазм миокарда и пр. Так и программист должен уметь увидеть по коду и признакам неверный JNI вызов, OOM, нарушение целостности стека и пр. Но уж никак не быть профи в намеренном создании этих ситуаций, если только он не мастер эксплоитов или энтузиаст-тесткр ВМ на прчность.
        • +2
          фибриляция, тромб, спазм миокарда


          Это не _почему_, это — результат. Почему — это посмотреть чем пациент занимался последние годы, вломиться к нему домой, и выяснить что могло привести к вышеописанному результату.

          • 0
            Хауз, не цепляйтесь к словам :) к OOM тоже может приводить не явная ошибка, а что-то, требующее изучения всего кода и времени жизни каждого объекта.
            • 0
              к OOM тоже может приводить не явная ошибка, а что-то, требующее изучения всего кода и времени жизни каждого объекта.

              «В ДНК у него ошибка...» И вообще, причина — в законах квантовой физики и общей теории относительности, кто их только придумал…
              • 0
                Самые большие проблемы в жизни вовсе не в теории относительности.
                И уж тем более не в квантовой физике.
                :-)
                Наиболее интересна с этой точки зрения психология, но там пока все неоднозначно и расплывчато, мало конкретных ответов, которые можно брать и использовать.
                • +1
                  И жизнь, и психология — результат действия законов КФ и ОТО. Или более глубоких ещё не открытых законов. Так что проблемы могут быть не в этих областях, но их причина — наверняка где-то там. Или, как вариант, в неправильном использовании квантовой физики для реализации жизни, а жизни — для реализации психологии…
        • 0
          Да почему же… знание кишков используемой архитектуры дает понимание КАК оно работает, и ПОЧЕМУ может быть первое второе десятое двадцатое…
  • +4
    Такой подход к собеседованиям напоминает подход из анегдота про милицию. Берут либо сильных либо умных. Мне кажется он найдет или специалиста или человека у которого всегда падает джава машина.
    • +2
      Ну почему же. Выше пара человек сходу привели идеи как это сделать. Тут ведь вопрос не в том, чтобы найти человека способного уронить Java-машину, а в том, чтобы найти специалиста достаточно высокого класса, способного хотя бы понимать, что за всеми этими слоями абстрации стоит железяка с её ноликами и единичками, что полностью от этого абстрагироваться нельзя и что как ни крути — это всё равно иногда вылазит в программы с любым количеством абстракций. К сожалению офигительное количество Java-программистов об этом даже не задумывается. Называть таких людей «экспертами» никак нельзя, разумеется, но у них часто бывает много лет работы и они регулярно впустую тратят время всех: и рекрутеров, и тех кто их интервьюирует и своё собственное.
      • 0
        Ну смотрите. Я например слышал что все x86 машины давно уже суперскалярные. Весь x86 код транслируется в совсем другие инструкции и выполняется совсем по другому. Все оптимизация что мы делаем на асемблере, актуальны для x86, но не актуальны под реальные процессоры. И я даже слышал что процессор может переименовывать регистры. И что процессор это виртуальная машина, которая имеет внутри микропрограмму и ее можно апгрейдить. Но я не могу уронить процессор, не могу!

        Я даже не интересовался как это сделать. Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC. Я пишу для тех кто будет мой код поддерживать.
        • +9
          Все оптимизация что мы делаем на асемблере, актуальны для x86, но не актуальны под реальные процессоры.
          Вот прям-таки все? А как тогда, собственно, кодеки люди руками на ассемблере пишут?

          Но я не могу уронить процессор, не могу!
          Вот прям-таки и не можете? Совсем никогда и никакой? И даже статью из Wikipedia никогда не читали?

          Да, процессор, вообще говоря, должно быть невозможно уронить. Но, в общем-то, это не так и сложно сделать из ядра OS. Или если в процессоре есть ошибка. Или если вы ему скормите неправильный микрокод (последнее, впрочем, не так просто сделать, так как он в последний версиях CPU подписан). Всё, собственно, как с Java или C#, почти один-в-один (только фатальных ошибок в процессорах поменьше, так как машинка-то в них попроще, а тестируют её гораздо тщательнее).

          Я пишу на шарпе и приблизительно знаю как работает GC основаный на поколениях. И я не буду никогда оптимизировать свой код для GC. Это проблема создателей GC.
          Вот нифига ж себе. Как вы это себе представляете? У вас программа тормозит и жрёт память, как не в себя, заказчик «рвёт и мечет», а вы ему так с вызовом так говорите «это проблема создателей GC»? Будете оптимизировать как миленький. Ну то есть если вы эксперт и задача действительно в GC упёрлась. Ну а если вы не эксперт — то с какого перепугу на подобное место претендуете?
          • –6
            Вот нифига ж себе. Как вы это себе представляете? У вас программа тормозит и жрёт память, как не в себя, заказчик «рвёт и мечет», а вы ему так с вызовом так говорите «это проблема создателей GC»? Будете оптимизировать как миленький.

            Не буду, это ошибка проектирования а не оптимизации. Необходимо перепроектирование системы.
            • +4
              Один раз в моей практике из-за ошибки в одной строке кода производительность просела более чем в 10 раз.
              Правильно ли я понимаю, что надо было запрашивать покупку новых серверов и ресурсов для проведения полного перепроектирования системы? Или все-же можно было ограничиться заменой неправильной строки кода на правильную?
        • +2
          Это больше говорит о проектах, в которых вы заняты, чем о том, что знать как устроен GC не нужно.

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

          Разработчики twitter — аналогично, можно найти много их выступлений о тюнинге JVM.

          Про Дойчебанк тоже есть информация, что они обучают своих разработчиков занятых на low latency системах как писать код, чтобы минимизировать использование GC
          • –4
            на конференциях рассказывают, что с ростом посещаемости были сильно поражены тому, как сильно удалось расширяться не за счет введения в строй новых серверов, а за счет переписывания кода с учетом работы GC.

            Это самая большая ошибка программирования. Написание кода не для людей а для машин. Поэтому мы до сих пор все всегда пишем с нуля, потому что существующий код неозможно поддерживать или портировать.
            Страутруп писал вроде, что инструменты заставляют нас писать код под эти инструменты. Самый простой пример это прекомпилед хедерс. Только подумайте, мы меняем код только для того чтобы он быстрее собирался! В глобальном смысле это и ведет к тому хаусу что мы сейчас имеем в программировании.
            • +4
              Это самая большая ошибка программирования. Написание кода не для людей а для машин.
              Это было актуально лет 40 назад. В узких областях актуально и сейчас. В биржевой торговле время машины до сих пор время машины стоит много больше времени программиста: лишняя миллисекунда — и конкуренты опередили.
              • 0
                В биржевой торговле рулят алгоритмы (быстрые) а не оптимизации под железо. Пересекались, знаем.
                • +1
                  Трейдеры с Вами немного не согласны: habrahabr.ru/post/163371/
                  Иногда, они и свое железо под задачу пилят, а не только софт под железо.
                • 0
                  В возражаемом вами комментарии говорилось об оптимизации под GC, а не под железо…
                  • 0
                    GC это домен для шарпа как и процессор для байткода.
                    • 0
                      Не писал для CLI, может быть, GC для CLI меньше допускает оптимизацию кода под него, чем GC для JVM…
            • +1
              Друзья, зачет минусуете? (смайлик) Вы же помните о чем написано в книгах о паттернах. В них почти все паттерны для управления сложностью кодом и упрощение модификации и поддержки — это все для людей а не для машин! Нас учат писать код для людей!
              • 0
                Это не отменяет следования best practices, которые ориентированы на различные аспекты: уменьшение вероятности непреднамеренной ошибки, повышение понятности для человека, «правильная» работа с абстракциями (в том числе, в тех местах, где они протекают).
  • +1
    Однажды столкнулся похожим на собеседовании. Вопрос был оцените по 5-и бальной шкале свое знание JavaScript (хотя вакансия вообще была не связана с этим). Я написал 4 без особых колебаний (до этого я прочитал книгу и сделал пару учебных скриптов для собственного развития), но решил, что вобщем-то всё равно для этой вакансии. На что собеседователь (видимо «По моим ожиданиям он должен быть невероятным специалистом») очень обрадовался и начал задавать заковыристые вопросы по неявному преобразованию типов и каких-то особенностях DOM, на которые я конечно не смог правильно ответить. И в конце он так торжественно так спросил, почему же я поставил себе 4? Я ответил, что это субъективная оценка и 4 значит, что я уверен, что спокойно смогу решать задачи и на JavaScript
    • 0
      Коммуникация помогает преодолевать барьеры различного трактования одних и тех же символов.
      Лично я как разработчик еще пять лет назад сделал неутешительный для себя вывод, что большинство проблем адекватнее решать на уровне коммуникации, а не на техническом уровне.
      На техническом уровне уже нет пространства маневра, и приходится делать хаки.
      В Enterprise-разработке самая большая проблема — постановка задачи.
      И попытка решать эту задачу путем технической гибкости — IMHO, слишком большая цена.
  • +1
    Я устроился на первую работу ровно 3 дня назад. Эти три дня я официально называю себя Java-разработчиком. Я долго шел к этому. Заканчивал химический факультет.
    Те вопросы, что упоминаются в статье(положить JVM, работа загрузчиков классов и т.д.) с легкостью ответил бы. Сейчас, вчера и завтра. Но вчера, когда ресурс_менеджер услышал, что я хочу не 600 долларов, а 1000 — ответил, что ему нужно с кем-то бесседовать и нет никаких гарантий, что я подойду им по бюджету. Компания очень крупная.

    Повторяю, это моя первая работа в IT. И у меня нет опыта разработки. Но судя по вашей статье — я эксперт!
    • +1
      Ну и как положить JVM?
      • –3
        например StackOverflow'ом. Даже пустой метод в джаве занимает память. Просто объявите метод и вызывайте его рекурсивно. Машина вскоре ляжет. А для быстроты, уменьшите размер стека при запуске JVM до минимального значения — и получите результат очень быстро.
        • 0
          Или OutOfMempryError: Для простоты эксперимента уменьшите heap JVM специальтым ключом и попробуйте поработать с большими объектами. К примеру Bitmap'ами
          • –2
            Одним словом, любая Error из дерева иерархии ошибок, выброшенная не вручную, а самой машиной — это конец JVM
            • +2
              Ясно. Следующий!
            • +1
              Error — это не падение JVM. Часть приложений, в особенности запускающих недоверенный код, перехватывают Error (обычно просто все Throwable) и иногда принимают какие-то попытки восстановления.

              Сходу в голову приходят сервлет-контейнеры, апплет-контейнеры, IDE/отладчики, различные механизмы модульности (при невозможности загрузить модуль). После части ошибок возможно восстановиться и продолжить работу. Например, после OOM в пользовательском приложении контейнер может его завершить и выгрузить. Или после неудачной попытки загрузки класса (не важно, ValidationError случился или какой-нибудь NoClassDefFoundError).

              Уронить JVM означает, что JVM не может продолжать работу (это могут быть, например, проблемы загрузки классов System ClassLoader'ом, OOM по PermGen, проблемы в JNI, неудачная работа с sun.misc.Unsafe).

              Из недавнего: в драйвере MongoDB (я наблюдал проблему с 2.7.2, исправлена в 2.9.0) можно получить забавный java.lang.Error: Maximum permit count exceeded, связанный с неправильной работой с семафорами и переполнением int. См. тикет.
              log
              Caused by: java.lang.Error: Maximum permit count exceeded
                      at java.util.concurrent.Semaphore$Sync.tryReleaseShared(Semaphore.java:197) [rt.jar:1.7.0_45]
                      at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_45]
                      at java.util.concurrent.Semaphore.release(Semaphore.java:431) [rt.jar:1.7.0_45]
                      at com.mongodb.util.SimplePool.done(SimplePool.java:129) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.util.SimplePool.done(SimplePool.java:103) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBTCPConnector$MyPort.done(DBTCPConnector.java:382) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:181) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:138) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:261) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:211) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBCollection.insert(DBCollection.java:57) [mongo-java-driver-2.7.3.jar:]
                      at com.mongodb.DBCollection.insert(DBCollection.java:102) [mongo-java-driver-2.7.3.jar:]
            • 0
              Про NoClassDefFoundError — неверно, про остальные — не конец, но нередко (а OutOfMemоryError — практически всегда) признак того, что на надёжную работу JVM больше (до перезапуска) рассчитывать нельзя.
              • 0
                Что именно вы считаете неверным? Тот же slf4j при невозможности загрузить StaticLoggerBinder кидает NoClassDefFoundError (caused by ClassNotFoundException) при отсутствии имплементации логгера, но это не мешает пользовательскому софту продолжить работу без логгирования.

                Такие же методы (ловля NoClassDefFoundError) иногда применяются при загрузке опциональных модулей.

                P. S. Извините, считал, что вы отвечали на мой комментарий.
                • 0
                  Я имел в виду, что неверно, что это «конец JVM».
        • 0
          То есть любой апплет в интернете может уронить мне JVM и вместе с ней браузер?
          • 0
            простите, не силен в апплетах. А причем тут браузер?
            • +1
              Ок, стоит уточнить, что подразумевается под «уронить». Одна из возможных интерпретаций — повреждение структур данных JVM в памяти с аварийным завершением процесса (если джава встроена в какое-нибудь приложение, браузер например, то все падает вместе). Я джавы не знаю совсем, но мне казалось что такой ситуации возникать не должно.

              Странно что после переполнения стека нельзя поймать исключение, и продолжить дальше как ни в чем не бывало.
              • –2
                Иерархия ошибок в джаве делится на Exception и Error. Это наследники Throwable. У Exception есть еще наследник RuntimeException.
                Так вот, Error и RuntimeException и их наследники классифицируются как unchecked exceptions. Их можно ловить тоже на самом деле. Но в случае с Error сложнее. Если самому выкинуть через throw new Error() — то можно поймать ошибку, обработать и продолжить работу. Но если ошибка брошена JVM — то нет. Поскольку машина выкидывает их, когда ей чего-то критически недостает(памяти) и она попросту не может функционировать.

                Браузер не должен ломаться, когда ложится JVM. Просто апплет перестанет работать.
                • 0
                  Итак, всем внимание. Ценная информация!

                  То что я изложил выше — это теория. На практике я уменьшил размер стека до 1 килобайта, а размер хипа до 2 мегабайт. В случае с пустым рекурсивным методом и с созданием большого количества объектов я получил ошибки StackOverflowError в первом случае и OutOfMemoryError во втором и смог их перехватить и обработать. Программа работает дальше!

                  Я так думаю, скорее всего просто не гарантируется корректная работа JVM после выбрасывания Error.
                  • –2
                    UPD:
                    Вот что пишет спецификация.
                    An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.


                    Подтверждаю свое последнее предположение и иду спать спокойно )
          • 0
            а вообще — да
        • 0
          То, что пустой метод занимает память и рекурсивный вызов кладёт JVM — не связанные факты. При бесконечной рекурсии стек переполнится из-за параметров и адресов возврата, а не байт-кода метода.
          • 0
            Подумал, и — да. Кажется ты прав. Это не связанные факты. Но это не меняет дела.
    • 0
      Когда я начинал разрабатывать на Java, я смотрел лекции Мирончика, где он в самом начале очень подробно рассказывает про то, как JVM работает с памятью и про загрузчики классов.

      Сейчас я это порядком подзабыл, так как работаю в основном в уровнем повыше: Spring и подобное.
      А код стараюсь оптимизировать на уровне алгоритмов.
  • +4
    Я, быть может, зануда, но единственно верный ответ на вопрос разработчику «оцените X по шкале от 1 до 10» это «уточните критерии оценки». Разработчик всегда должен уточнять нечетко поставленную перед ним задачу, а не выдавать первое попавшееся решение, формально соответствующее ТЗ.
    • +1
      Тут не угадаешь. Если речь на собеседовании и вопрос об оценке собственных знаний, это уже значит, что началось что-то мутное
    • +3
      Иногда может, наоборот, цениться умение «обходиться без лишних вопросов» и понимать «VIP»-а с полуслова…
    • 0
      100% зависит от собеседующего и его целей.
      А в цели входят не только технические знания, но и человеческие качества.
      Которые также проверяются подобными вопросами.

      Так что если Вам задают подобный вопрос — вряд ли интересуются техническими знаниями.
      Скорее — самооценкой, внимательностью и т.д.
  • +17
    > Тысячи Java специалистов претендовали на вакансии, практически никто из них не мог объяснить как работает загрузчик классов Java или описать в общих чертах как виртуальная машина Java управляет памятью.

    Сперва они выбирают для своих проектов язык, написанный под лозунгами «ваш единожды скомпилированный код будет работать везде без изменений» и «вам больше не нужно думать об утечках памяти». А потом ищут специалистов, которые должны знать как будет работать загрузчик классов на конкретной платформе, а также как все таки происходит в java управление памятью. Тут наверняка есть какой-то хитрый план.
    • +3
      Да нет тут никакого плана. Проблема в том, что все более-менее высокоуровнеые абстракции в IT протекают. И если у вас в команде 10 человек, твёрдо верящих, что «в Java не нужно думать об утечках памяти» и один эксперт, который знает не только что на самом-то деле таки иногда надо, но и когда об этом важно задуматься и что делать, чтобы разрулить проблемы вызванные GC (когда проблемы-таки возникают) — то всё в полном порядке. Когда ни одного такого эксперта нет — дело очень плохо. Простейшие проблемы, которые можно решить посмотрев на «живую» кучу приложения и обнаружив, что у вас короткоживущие переменные по какой-то причине уезжают в «долгую» кучу и вводят JVM в не совсем штатный режим работы, что приводит к резкой потере производительности будут отлаживаться годами.

      Вот, собственно в статье и была описаны попытка нанять нескольких экспертов. Проблема же заключается в том, что по неизвестной науке причине куча разработчиков проработав лет 10 и так и не научившись разбираться с подобными хитрыми случаями начинает претендовать на звание «экспертов», больше ни в чём. Как уже было написано в статье: эксперт — это тот, кто что-то знает досконально, не «вширь», но «вглубь», а не тот, кто запомнил 100500 акронимов.

      • +9
        Предлагаю сойтись на том, что есть люди, которых автор статьи считает специалистами, а есть специалисты, которые считают автора идиотом. И первый непременно найдет себе хорошего, в его понимании, специалиста, а последние устроятся на работу в ту компанию, где, в их понимании, вопросы на собеседовании задают правильные. И все будут счастливы. А к единому мнению о том, каким же должен быть настоящий Java-эксперт, при нашей жизни точно не придут.
  • 0
    .
  • +6
    Типичный пример эффекта Даннинга-Крюгера.
    Хороший специалист никогда не скажет, что он знает на 9 из 10. Никогда. И только посредственный специалист поставит себе высший балл, ведь он думает, что знает всё. В то время как отличный специалист с более глубокими знаниями понимает, что он знает далеко не всё.

    Поэтому я никогда не доверяют оценкам, которые сами себе ставят собеседуемые. И вообще, забудьте про вопросы типа «на сколько баллов из 10 вы себя оцениваете» — всегда получите неадекват.
    • 0
      Ну как сказать… наверное, что-то из серии «вы просто не умеете их готовить»;-) В конце концов, можно просто выбросить результат ответа;-) оставит кандидата в размышлениях…
      • 0
        … оставив
    • +5
      А по-моему ерунда в том, что под разными числами разные люди понимают разные смыслы. Если бы вместе с каждой оценкой шло бы пояснение, что она означает для вопрошающего, то и отвечающий смог бы подстроить свою картину мира под эти оценки, и дать более адекватный ответ.
      Так кандат может заранее иметь такую оценку значениям:

      5 — видел синтакс у соседа на экране
      6 — пишу хелловорд без словаря
      7 — знаю синтаксис
      8 — пишу код
      9 — пишу код и правлю свои баги
      10 — правлю чужие баги и цитирую учебник

      А собеседователь представляет все иначе, например:
      6 — пишу код
      7 — пишу сложные проекты
      8 — офигенно пишу код и разбираюсь в тонкостях архитектуры и паттернах
      9 — понимаю все низкоуровневые этапы работы
      10 — разработчик языка

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

    Ищет лжецов-фантазёров?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        60% проблем с производительностью решаются за пару месяцев до их появления… Если конечно следить за ними.
      • 0
        «99% статистических данных выдумывается тут же, из головы.»
      • 0
        Не ставлю под сомнение, но может есть где годные статьи на эту тему?
        • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Индия, тысячи кандидатов… 'Торговец черным деревом" приехал на колониальный невольничий рынок. Товар с душком, зубы не те, и дороговато. Такое сложилось ощущение.
  • +2
    Бытует мнение, которое я разделяю, что связка современное железо + современные языки программирования всё ещё далеки от своих хоть сколько нибудь оптимальных реализаций, а IT индустрия, фундаментально, представляет из себя в гораздо большей степени исследовательскую область, нежели чем практическую. Если угодно это мой призыв растить специалистов более широкого профиля, готовых идти на эксперименты, и развивать базис для альтернативных подходов.
    • 0
      термин «специалист/эксперт» это прежде всего обобщение, а что не обобщай то результат всегда получается очень однобоким и неверным во многих случаях — это примерно тоже самое, что — все «мужчина/женщина/нацианальность/страна… такие то» — для кого-то эксперт это человек который способен решить чисто бизнес задачу техническими средствами (пусть даже и очень коряво), для кого-то человек который может решить чисто техническую проблему с «подковыркой» в очень специфичной области, для кого-то это просто человек который умеет работать в коллективе по его правилам и не нарушать «экосистему» и еще многочисленное число вариантов — по этому когда спрашивают подобные вопросы то в большинстве случаев вопрос об одном а ответ о другом.
      В реальности востребованны все виды «специалистов» просто в разных областях, но вакансии на них чаще всего выглядят одинакого.

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

      именно по этому на мой взгяд все не стоит на месте и постоянно развивается, чутли не каждый день появляется новый язык — это и хорошо и плохо,
      тк очень похоже, что все пытаются решить общие проблемы по своему распыляя усилия
  • 0
    очередное бла-бла-бла.
    • 0
      Не проскочил :)
  • +1
    За всю мою практику мне все же как-то удалось уронить JVM с вылетом последней. JDK 5 HotSpot, насколько помню, это происходило при одновременном параллельном формировании OpenPGP ЭЦП с одним и тем же инстансом ключа. Вся реализация — 100% pure java. Выяснить причины падения удалось только благодаря трейсам при креше JVM. Вылетало где-то в недрах native-реализации (jvm, не 3rd party).
    • 0
      Ищешь работу?)
  • 0
    Мне кажется, важно знать, в чем именно «эксперт». Можно быть экспертом в ломании JVM, а можно знать, как построить с нуля сложную распределенную систему. Или быть экспертом в Spring. Но я согласен с автором, если заявляешь о себе как об «эксперте в Java», то детали JVM хорошо бы знать.

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