Является ли совет старших программистов всегда использовать книги хорошей идеей? [закрыто]

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

Одним из последних примеров было то, что мне пришлось сделать синглтон в многопоточном приложении. Я решил использовать этот метод. Как только Infestus увидел это, он быстро начал называть меня глупым и сказал мне использовать этот подход . Спросив его, почему он просто отмахнулся, так как это лучше, и вот как эта и эта книга о Java говорят, что это лучше.

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

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

РЕДАКТИРОВАТЬ : я совершенно потерян. Да, я знаю, что слепо следовать чему-либо - плохая идея. Но этот богоподобный программист Инфест, который, кажется, знает много, говорит мне, что единственный способ правильно программировать - это читать книги и следовать всему, вплоть до буквы T. Все правила, которые он навязывает, - те, которые написаны в книгах, поэтому мне просто интересно если книги - единственный правильный путь.

EDIT2 : Infestus не мой начальник. Он только один из старших разработчиков, отвечающий за просмотр кода. И большинство его комментариев после обзоров состоят из названий книг, где такой-то метод неправильный.

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

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

Только не будь придурком по этому поводу.

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

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

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

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

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

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

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

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

Я думаю, что вы также должны относиться к этому человеку с большим уважением. В своей голове вы называете его уничижительными именами и критикуете его подход к тому, что вы считаете «обучением». Остерегайтесь этого. С другой стороны, ты сказал, что он назвал тебя глупым. Это не круто, и вы должны сказать ему, что не круто называть кого-то глупым.

Идеи могут быть глупыми. Мы все совершаем ошибки и скучаем, даже старшие ребята. Когда в дизайне есть недостаток, лучший вопрос: «Почему вы делаете это таким образом? Разве это не сломается в ситуации X, Y, Z? Разве дизайн В не будет лучше?»

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

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

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

Этот инженер Infestus очень плохо обучает начинающих разработчиков, говоря им: «Это написано в книге, и вот почему». Он не проповедник, он инженер, и он должен быть в состоянии разбить его и представить концепции, чтобы юниоры могли учиться на своем опыте.

Я бы посоветовал вам поговорить с опытными разработчиками в вашей компании, задать им вопросы о плюсах и минусах различных методов программирования и т. Д. Это наряду с чтением книг и блогов (я бы порекомендовал Джоэла по программному обеспечению - просто Google, это обязательно) должен дать вам лучшее понимание.

ИМХО, здесь есть 2 аспекта, с которыми вам следует разобраться отдельно:

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

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

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

Много раз я заставлял кого-то исправлять то, что я первоначально считал «моим идеальным кодом», и просто расстраивался из-за того, что парень говорил мне, что делать, только чтобы потом понять, что он был прав все время, моя версия была плохой, его была хорошо, и слава Богу, он это видел! :) Так что я научился смягчать свои первоначальные импульсы: «Эй, не говори мне, что делать, ошибся!» и вместо этого, каждый раз, когда кто-то исправляет меня, я сначала действительно, объективно, перепроверяю свой код, затем проверяю его, и проверяю, не прав ли он, и это я делаю ошибку. Если это была моя вина, я благодарю его за помощь и удостоверяюсь, что я действительно понимаю, как работает его решение (а не просто копирую / вставляю его).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если бы я был, ты бы прочитал эти книги. Это поможет вам, предоставив вам больше аргументов, и в то же время вы можете обнаружить, что Infestus - возможно - ошибочно принимает эти книги в качестве аргументов, и его еще не заметили, потому что никто не знает содержания этих книг. Или вы можете обнаружить, что он на самом деле к

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

Количество указанной информации в интернете выше.

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

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

В случае синглетов, один аргумент, который вы можете сделать против подхода enum, состоит в том, что перечисления не могут расширять классы. Я часто пишу такой код:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

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

Некоторые другие аргументы против использования перечислений:

• это хак - он использует перечисления для чего-то, для чего они не были предназначены
• это сбивает с толку тех читателей, которые раньше этого не видели

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

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

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

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

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

Цели проверки кода в команде: 1) проверить код и 2) убедиться, что человек, пишущий код, понимает смысл улучшения кода. Это не место, чтобы сказать «измени это, потому что Мартин Фаулер так сказал в книге GoF». Тем не менее, это место, где можно сказать: «Измените это, потому что [краткое объяснение]; есть более подробное обсуждение этого в книге GoF».

Если ваш старший разработчик, по крайней мере, просто и тонко, не дает объяснения изменения и настаивает на использовании слов «из-за [книги]», он немного умник и придурок. Как вы справляетесь с этим? Упомяните это на собрании команды в устной форме и попросите своих товарищей по команде дать одно или два утверждения, кратко объясняющих преимущество или необходимость изменения, вместе с этим полезным справочником. Обязательно поблагодарите его за ссылку на книгу.

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

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

Я бы сказал, что изучение программирования только по книгам невозможно, но хорошие из них дадут вам огромный импульс. Это как каратэ - вы не получите черный пояс, только читая об этом;) Я полагаю, что в этом частичном случае г-н Инфестус ссылался на «Эффективную Яву» Джошуа Блоха. Это действительно отличная книга о разработке на Java, и вам обязательно стоит прочитать ее, если вы еще этого не сделали.