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

53

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

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

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

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

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

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

Quillion
источник
100
Следовать чему-либо вслепую - хорошая идея?
FrustratedWithFormsDesigner
16
Следовать чему-либо вслепую - плохая идея, но не позволяйте "Infestus" портить вас в книгах. Чтение книг - один из лучших способов выбраться из зоны комфорта и расширить свои навыки программирования.
Kyralessa
21
Звучит так, будто старший может знать, почему он следует этим конкретным способам решения проблем, но, возможно, не хочет тратить время на то, чтобы объяснить вам, почему, а просто указывает вам на ресурсы, которые это объясняют. Вы читали ресурсы, на которые он направил вас? Они объясняют, почему выбрано выбранное решение?
Йорис Тиммерманс
28
Через 5 лет ты уже не младший, ты знаешь это? Infestus это знает?
iluxa
25
...brushed it off as this is better and that's how this and this book about java says it is better. Это должно вызвать немедленный сигнал тревоги. Если Infestus не может дать вам отдельное объяснение, он может не понять его сам. (Или ему нужна копия Иллюстрированной Книги Плохих Аргументов .)
Blrfl

Ответы:

87

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

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

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

webdad3
источник
65

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

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

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

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

кевин клин
источник
6
Вы делаете очень хорошее замечание, и статья, на которую вы ссылаетесь, очень интересна, но в конце ясно сказано, что блокировка двойной проверки не работает с JDK 1.4 и более ранними версиями (с этими моделями памяти JDK). Начиная с JDK 1.5 и выше он работает, пока поле, содержащее экземпляр, объявляется как volatile (что имеет место в примере, связанном с OP).
Шиван Дракон
4
Спасибо за совет :) и да, он действительно называет меня глупым (иногда безумным) всякий раз, когда он действительно злится на код. Мое эго мешает принять не только его ответы, но и то, как он пытается засунуть его мне в горло, и имена, которые он использует для меня и моего кода, но это другая история. Однако хорошо знать, что книги действительно дают представление :)
Quillion
6
@Quillion - лично я бы не стал мириться с тем, как его зовут. Похоже, вы очень устали от всего. Я бы серьезно подумал поговорить об этом с вашим менеджером, возможно даже с HR. Жизнь слишком коротка, чтобы кого-то оскорблять.
webdad3
2
@ Quillion - Никто не должен так обращаться с тобой. Мне все равно, кто они. И всегда помни, что каждый заменим. Я бы серьезно подумал сначала поговорить с Infestus, потом с вашим менеджером, потом с HR. Если вы не получаете удовлетворения, тогда двигайтесь дальше. Поверь мне, ты найдешь еще одну замечательную группу людей.
webdad3
1
У Инфеста эмоциональная реакция на то, что он считает глубоким безобразием. Возможно, он мог бы извлечь выгоду из того, что кто-то просит его контролировать себя.
Кевин Клайн
22

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

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

Эйдан Калли
источник
Я бы согласился. Если автор книги не может объяснить достоинства подхода, о котором он говорит, как кто-то, кто читает книгу автора, сможет это сделать, поэтому одна из двух вещей должна быть правдой. Либо есть объяснение это существует, и читатель просто не понимает этого, или объяснение не существует, и читатель должен попытаться найти объяснение для этого метода. Поскольку мы говорим о конкретной теме, в которой есть только несколько действительных способов сделать это, объяснение обязательно должно существовать. Другими словами, я согласен с вашим ответом.
Ramhound
17

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

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

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

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

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

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

Густав Бертрам
источник
Я на самом деле считаю его навыки благочестивыми и испытываю уважение. Однако суровая критика в отношении чего-то нового начинает демотивировать меня даже от того, чтобы пробовать что-то новое и придерживаться книг, и да, он очень вульгарен.
Quillion
6
Новое не всегда хорошо, а старое не всегда плохо. Если он критикует идею, требуй знать почему. Всегда спрашивай почему. «Потому что в книге так сказано» недостаточно хорошо. С другой стороны, прочитав книгу, он, скорее всего, имеет гораздо более широкую перспективу. Вы должны стремиться расширять свою собственную точку зрения, чтобы вы могли оправдать свой дизайн своими достоинствами.
Густав Бертрам
2
Не думай ни о ком как о божественном. Ты не всегда можешь положиться на него. Относитесь к нему как к сверстнику, у которого больше опыта. Если вы относитесь к нему как к богу, вы продаете себя коротко, и вас никогда не будут уважать.
webdad3
7

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

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

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

Майкл Круглос
источник
4

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

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

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

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

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

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

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

Дракон Шиван
источник
1
Я абсолютно согласен с вами :) и я стараюсь игнорировать его тон и всегда стараюсь принизить меня, так как полагаю, что это его характер. Но больше всего меня беспокоило то, что он говорил мне, что мой код неправильный (что хорошо, я не против), а затем вместо того, чтобы пытаться объяснить мне неправильные способы, он дал бы мне книгу и сказал бы мне: прочитайте это прежде, чем я попытаюсь написать более глупый код. Именно это заставляет меня задаться вопросом, есть ли в книгах ответы на все вопросы, потому что половину времени, когда я читал книгу, она совершенно не подходила для рассматриваемого сценария.
Quillion
Ну, да, я понимаю, что вы имеете в виду, но все это действительно зависит от книги и от того, как он ее рекомендует. то есть, если он говорит что-то вроде «ты сделал плохо, иди почитай несколько книг по программированию», это, конечно, плохо, но если он скажет: «Послушай, Effective Java 2nd edition дает более простой и лучший пример того, как делать Singletons, посмотри здесь, мой. safaribooksonline.com/book/programming/java/9780137150021/… "тогда я бы сказал, что это полезно для вас (опять же, оставив в стороне обсуждение тона доставки)
Shivan Dragon
Я бы никогда не проигнорировал это поведение. Там будет либо сесть с его боссом, либо пропустить разговор с его боссом, если я уже сказал ему, что имя не будет летать.
Рог
3

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

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

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

JeffO
источник
3

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

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

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

Ложка
источник
3

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

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

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

Саджад Деяргару
источник
Обучение на основе видео, обучение в классе или просто чтение исходного материала. В конце концов, они все разделяют одно: вы читаете (или слушаете) новый код и слышите / читаете объяснение причины, по которой был выбран этот подход.
Ramhound
2

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

климат
источник
1
Его навыки и программы, которые он пишет, ясно указывают на его превосходство в программировании. Однако большая часть рассуждений, почему он делает что-то особенное, всегда связана с книгами известных авторов. Однако мне все равно, что он чувствует ко мне, я хочу знать, действительно ли книги - лучший способ стать хорошей программой, и нужно ли им доверять, как если бы верующий доверял Библии.
Quillion
Вы должны определенно знать причины, почему стоит выбрать один подход по сравнению с другим. Переход к другому решению, о котором вы не знали, должен быть обоснован причинами, которые вы понимаете. В противном случае ваши (старшие) навыки не улучшатся. Вы можете получить идеи из книг, но идеи - это то, что важно, а не где или кем они представлены. Программирование не религия :).
Клим
1
Да, и не слишком пугайтесь его. Похоже, он может быть очень хорошим программистом, но не настолько хорош в руководстве и обучении людей.
Клим
@Quillion - Единственный способ стать хорошим программистом - сделать это за тонну, читая книги (или любой другой источник), вы можете дополнить собственно написание кода чтением. Вы даже читали эту книгу? Вы должны решить, стоит ли слушать автора кода, автора, который утверждает, что имел 20 лет на Java, является хорошим человеком для прослушивания. Это означает, что есть хороший шанс, он говорил с реальными разработчиками Java на определенные темы. Если бы я писал книгу по Java, я бы пошел к источнику для своего исследования и использовал свой опыт, чтобы объяснить тему.
Ramhound
@ Да, мне пришлось читать книги, которые он мне дал. И да, я согласен с его книгами по определенным темам. Однако проблемы с книгами, которые он мне порекомендовал, заключаются в том, что они изображают идеальный мир, в котором весь код сделан правильно, а в остальное время они чувствовали себя немного устаревшими. Но его постоянный поток спамовых книг на меня, чтобы читать и защищать все свои аргументы с книгами, вместо того, чтобы пытаться объяснить это мне, заставил меня подумать, что, возможно, книги не лучший источник. Однако, похоже, что они есть, и я буду дальше их изучать.
Quillion
2

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

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

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

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

user3067411
источник
1

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

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

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

Питер Б
источник
1

Я бы исследовал достоинства каждого подхода и пришел к вашему собственному мнению. Если вы считаете, что ваш подход лучше, обсудите его с 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предложении.

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

  • это хак - он использует перечисления для чего-то, для чего они не были предназначены
  • это сбивает с толку тех читателей, которые раньше этого не видели
Даниэль Любаров
источник
Хм ... зачем вам использовать сериализатор даты как синглтон? Если он не имеет состояния, вы можете ожидать, что его создание будет дешевым, а наличие нескольких экземпляров не должно быть главной проблемой. Если это не безгражданство, тогда вы должны сделать его синхронизированным, и есть вероятность, что оно станет узким местом ...
Стивен C
@StephenC для классов без состояния, просто странно разрешать множественные случаи, когда одного достаточно, и в чем преимущество? Единственный синглтон с состоянием, который приходит на ум, - это синтаксический анализатор пакетов - у вас может быть несколько одноэлементных классов, расширяющих AbstractParser. Правда, это требует синхронизации, если вы выполняете параллельный анализ, но важен обмен записанным состоянием.
Даниэль Любаров
Наоборот, мне кажется странным, что вы будете беспокоиться о синглетонах и их сложностях, если вам это не нужно. На мой взгляд, самый простой подход заключается в создании, использовании и выбросить «Трансформер» объекты ... кроме случаев , когда есть сильная причина / стимул для повторного их.
Стивен С
1

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

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

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

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

Стеф Лок
источник
1

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

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

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

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

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

оборота стимпи77
источник
1

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

Gwozdziu
источник