Чи є корисною порадою старших програмістів щодо використання книг завжди? [зачинено]

Я молодший розробник і працюю в галузі лише 5 років. У моїй теперішній компанії є старший, давайте назвемо його Інфестус. Інколи мені дають можливість світити і робити щось абсолютно нове з нуля.

Одним з останніх прикладів було те, що мені довелося зробити синглтон в багатопотоковому додатку. Я вирішив використовувати цей метод. Як тільки Інфест побачив це, він швидко приступив до називання мене дурним і сказав мені використовувати цей підхід . Запитуючи його, чому він просто зачистив його, як це краще, і ось як ця і ця книга про Яву говорить, що це краще.

І це звичайна закономірність: щоразу, коли я отримую можливість зробити щось нове, мене швидко збиває Інфестус, і єдине міркування, чому його метод кращий - це те, що ці книги були написані відомими програмістами. Він завжди намагається дати мені книги читати, щоб я міг "дізнатися", які способи програмувати.

Я програю на гроші лише 5 років, але чи завжди це гарна ідея просто сліпо слідувати книзі про найкращі шляхи вирішення проблеми, чи я повинен намагатися експериментувати раз у раз? Постійна сутичка скарг від Інфесту починає змушувати мене ніколи не пробувати нічого нового та наслідувати приклади в книгах.

EDIT : Я абсолютно загублений. Так, я знаю, що слідувати що-небудь наосліп - це погана ідея. Але цей богоподібний програміст Інфест, який, здається, знає багато, говорить мені, що єдиний спосіб правильно програмувати - це читати книги та виконувати все, що стосується Т. Усі правила, які він накладає, - це написані в книгах, тому мені просто цікаво якщо книги - єдиний правильний спосіб.

EDIT2 : Інфестус не мій начальник. Він лише один із старших розробників, відповідальний за перегляд коду. І більшість його коментарів після оглядів складаються з назв книг, де такий і такий спосіб неправильний.

Ви збираєтеся натрапити на таких програмістів всю вашу кар'єру. Немає нічого поганого в експерименті та навчанні самостійно. Звичайно, чудові книги. Багато разів приклади працюють у чистому середовищі, але якщо ви розробник для іншої компанії, немає такого поняття, як чисте (без втручання інших) середовище.

Завжди приємно знати, як робити речі «правильним» способом, але думки змінюються рік у рік. Тож дізнайтеся, що можете. Візьміть що можна від старшого розробника, змішайте його зі своїми знаннями, які ви дізнаєтесь самостійно. Зрештою, ви будете старшим розробником і будете брати з себе цей досвід і навчати молодших розробок.

Тільки не шукай з цього приводу.

Він насправді називав вас дурним, чи просто зневажав код? Закликати щось дурне нетактовно, але це не скасовує пропозицію. Я думаю, що Інфест зробив цінну пропозицію, і в майбутньому ви повинні серйозно поставитися до його пропозицій. Він, здається, багато читає, і, принаймні, у цьому випадку його думка є добре поінформованою. Синхронізація є і дорогою, і хитрою. Його рекомендована реалізація є більш ефективною та простішою, ніж ваша, і гарантовано працює.

Він завжди намагається дати мені книги читати, щоб я міг "дізнатися", які способи програмувати.

Це його вид. Він активно намагається допомогти вам, але ви, здається, не даєте своєму его заважати. Не сприймайте критику свого коду особисто. Код є дешевим у виробництві та легко змінюється. Якщо хтось показує вам простіший спосіб зробити щось, подякуйте їм.

І так, читання зробить вас набагато кращим програмістом. Усі знаючі мені експерти читали широко. Якщо ти мало читаєш, то в кращому випадку посередній, а через п’ять років ти можеш виявити, що ти вже не продаєш.

Читання книги не повинно бути сліпою: автор повинен намагатися переконати вас у достоїнствах свого підходу, коли він її презентує. Старший розумно вказати вам на книгу, яка пояснює його переважний підхід, а не просити його сам пояснити це: хоча він повинен мати можливість пояснити переваги своїх уподобань, не покладаючись на книгу, це також дублювання зусиль, які автор книги вже зробив.

Отже, прочитайте книгу, подивіться, що говорить автор книги, і якщо вона вас бентежить, або ви хочете підтвердити своє розуміння, або ви не згодні, тоді поговоріть зі своїм старшим про це, але тепер ви будете вміти вести більш продуктивну дискусію.

У будь-яких здорових стосунках є три ключові елементи. Спілкування, чесність та довіра. Це враховує всі стосунки, навіть робочі відносини. Ви повинні поговорити зі своїм керівником про ці проблеми.

Якщо ви не розумієте його причин відстоювання певного дизайну, то скажіть йому це . Скажіть йому, що ви не читали книгу, і що ви хочете зрозуміти, чому краще його спосіб зробити це. Ключовим є те, що вам слід намагатися зрозуміти його спосіб виконання справ.

Я думаю, ви також повинні ставитися до цієї людини з більшою повагою. У голові ви називаєте його зневажливими іменами та критикуєте його підхід до того, що ви вважаєте "навчанням". Слідкуйте за цим. З іншого боку, ти сказав, що називає тебе дурним. Це не круто, і ви повинні сказати йому, що не круто називати когось дурним.

Ідеї ​​можуть бути дурними. Всі ми робимо помилки і пропускаємо речі, навіть старші хлопці. Коли в дизайні є вада, найкраще задати питання: "Чому ти це робиш саме так? Не вдасться він зламати ситуацію X, Y, Z? Чи не буде дизайн B краще?"

Майте на увазі, що ви працюєте над цим програмним забезпеченням разом з іншими людьми. Це важкий навик для навчання. Не має значення, що ви нічого не пишете з нуля, завжди є місце для блиску, зробивши свій код найкращим кодом, який ви можете.

А "найкраще" дуже часто означає читабельне та зрозуміле . Ми, програмісти, проводимо багато часу, читаючи код інших людей. Якщо цей код зрозумілий і читабельний, це робить код справді цінним. Один із способів навчитися писати чудовий код - читаючи багато хорошого коду. Ви дуже часто знаходите дуже хороший код у книгах. Тож читання однієї чи двох хороших книг програмування, ймовірно, зробить вас кращим програмістом.

У компанії, де ти працюєш, це, мабуть, є. Це те, що вони вимагають від вас.

Цей інженер Інфестус робить дуже погану роботу, навчаючи молодших розробників, кажучи їм: "це написано в книзі, і саме тому". Він не проповідник, він інженер, і він повинен мати можливість розбити це та представити поняття, щоб юніори могли вивчити його досвід.

Я б закликав вас поговорити з знаючими розробниками у вашій компанії, задати їм питання про плюси і мінуси різних методик програмування тощо. Це разом з читанням книг і блогів (я б рекомендував Joel на програмному забезпеченні - просто Google це, це обов'язково) повинні дати вам краще розуміння.

ІМХО, тут є два аспекти, з якими вам слід розібратися окремо:

• Справа в тому, що хлопець поцупився, називає вас іменами і так просто тому, що він може (він старший, ви не, якщо хтось із вас скаржиться на іншого, він отримає користь від сумнівів) просто поведінка, що нагадує хулігана, і просто погана.

Постарайтеся не нахилятися до його рівня при цьому. Не намагайтеся його знущати назад чи «розповідати про нього» начальнику чи що-небудь. Зробіть все можливе, щоб ігнорувати цей аспект його поведінки, маючи на увазі, що він стає занадто екстремальним (тобто, якщо це впливає на вашу продуктивність і таке), ви повинні щось з цим зробити.

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

Багато разів у мене хтось виправив те, що я спочатку вважав "моїм ідеальним кодом", і я просто засмутився тим, що хлопець мені казав, що робити, щоб пізніше зрозуміти, що він був правильний весь час, моя версія погана, його було добре, і слава Богу, що він це бачив! :) Отже, я навчився звучати свої початкові імпульси "ей, у ні, не кажи мені, що робити, помиляюсь!" і замість цього, кожного разу, коли хтось виправляє мене, спочатку дійсно, об'єктивно, повторно перевіряю свій код, потім перевіряю його, і переконуюсь, що він насправді не прав, і я роблю помилку. Якщо я був з моєї вини, я дякую йому за допомогу і переконуюсь, що я дійсно розумію, як працює його рішення (а не просто копіювати / вставляти його в).

І ей, іноді я виявляю, що запропонована корекція насправді була гіршою, ніж те, що я робив спочатку, і тоді я намагаюся говорити все це з іншим хлопцем. Чесно кажучи, я помітив, що ніщо не завойовує повагу оточуючих вас швидше, ніж коли вони бачать, що ви можете прийняти виправлення, коли ви помилилися, але в той же час не боїтеся сказати, що ви один хто правий, коли ви думаєте, що це так, враховуючи, що ви можете відразу довести, що ви базуєте своє твердження на якомусь фактичному дослідженні, а не лише на его.

З цього моменту, я думаю, вам слід по-справжньому спробувати поговорити з хлопцем про те, що він пропонує, і що ви пропонуєте тощо. Покажіть йому, що ви думаєте, як ви дійшли до певного рішення і чому ви вважаєте, що це краще, ніж його (коли ви чесно і об’єктивно думаєте, що це таке). Або, якщо ви дізнаєтесь, що його пропозиція краща за вашу, скажіть йому, висловіть свою вдячність за допомогу. Це може відновити деякі згорілі мости.

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

Справа зі своїм начальником - це зовсім інша тема та підхід. Якби я хотів, щоб хтось робив щось саме так, як це було в книзі, я б сказав їм. Це тільки я, тому що я не зв'язуюся з читачами розуму. Ваш начальник робить це звичкою, просто запитайте, чи рекомендує він які-небудь книги чи довідники, коли ви отримуєте новий проект.

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

Після книги наосліп погана ідея, але є різниця між наступними книгами точно і після його наосліп .

Коли ви намагаєтесь зрозуміти речі в книзі, як правило , спочатку дотримуватися її саме спочатку, тоді як ви відчуваєте те, чого вона намагається навчити вас. Шанси полягають у тому, що ви все одно не зрозумієте все, коли закінчите - ось як це відбувається зазвичай, але слідування за книгою точно спочатку дасть вам щось експериментувати, коли ви намагатиметесь зрозуміти свої питання. Коефіцієнти знову хороші, що ви знайдете способи, що не погоджуєтесь із тим, що є в книзі, але ви зрозумієте проблеми, з якими намагалася вирішити книга, так що, коли настане час написати власний код, ви зможете звертайтеся до них по-своєму (або, можливо, по-своєму, принаймні частково), а не просто залишайте ці питання, щоб вас кусати пізніше.

Ще одна річ, яка не притаманна Яві, але все-таки особливо поширена в цій спільноті. Я думаю, я можу здогадатися, про які книги ви говорите, і вони складають основну частину лексикону спільноти Java. Розуміння їх та способів опису речей допоможуть надзвичайно, коли вам потрібно зрозуміти інший код Java, який ви знайдете. Це сама по собі цінна майстерність.

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

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

Насправді, якщо ви читаєте лише книги, це теж не допоможе. Окрім читання, є й інше, що нам потрібно зробити. Більш детальну інформацію ви можете знайти тут .

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

Річ у книгах полягає в тому, що вони - в основному - проходять через зміни, які мають кращі шанси помітити погані практики та помилкові уявлення. Крім того, "великі імена" - це досвідчені люди, які покладаються на те, щоб добре заробляти гроші, продаючи книги, таким чином, є кілька мінімальних гарантій якості щодо того, що вони кажуть.

Однак, читання книг, паперів та інших джерел - це, безумовно, хороший спосіб зростати як професіонал, коли це підтверджується практикою. Отже, вам добре прочитати ці книги (навіть ті, які рекомендував Інфест). Однак книги повинні в основному розширити ваше розуміння цієї теми, оскільки майже завжди знайдуться інші способи вирішити ту саму проблему.

Щодо Вашого підходу "йти сам", суть: чи можете ви підтримувати свою точку зору? Як ви довели, що ваше рішення є кращим за будь-який інший? Деколи ви можете самостійно розробляти яскраві рішення, але, порівнюючи їх з іншими відомими рішеннями, ви повинні мати можливість аргументувати причину, чому ваше краще, оскільки інші мають на користь принаймні випадки використання. Тоді будьте креативними та продуманими, але найголовніше, будьте ефективними.

Якби я був, ти б прочитав ці книги. Це допоможе вам, надавши більше аргументів, і, в той же час, ви можете виявити, що Інфест - можливо, - неправильно сприймає ці книги як аргументи, і він ще не був помічений, оскільки ніхто не знає змісту цих книг. Або ви можете виявити, що він насправді k

Мій досвід полягає в тому, що, коли переймаються питаннями програмування тематики, якість та подання інформації з адекватними поясненнями в книгах набагато краще, ніж при пошуку тієї самої інформації про предмет в Інтернеті. Інтернету часто не вистачає належного пояснення, контексту та якості.

Кількість зазначеної інформації в Інтернеті більша.

Тож моя загальна стратегія полягає в тому, щоб вчитися з книг, щоб глибше зрозуміти, а після цього вчитися в Інтернеті, щоб зазнати різного впливу і розширити свій досвід (і часто бачити, як не робити речі).

Я б дослідив достоїнства кожного підходу і прийшов би до вашого власного судження. Якщо ви вважаєте, що ваш підхід кращий, обговоріть його з Інфестусом, поки один з вас не переконає іншого. Якщо ви не можете досягти домовленості, ви можете або попросити другу думку, або просто прийняти підхід Інфесту, залежно від того, наскільки сильно ви ставитесь до цього.

У випадку з одиночними, один аргумент, який ви можете зробити проти підходу enum, - це те, що переліки не можуть поширювати класи. Я часто пишу такий код:

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

  private DateSerializer() {}

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

Це не можна зробити із перерахунками. Оскільки підхід «перерахунок» працює не у всіх випадках, ви можете стверджувати, що задля послідовності цього слід уникати навіть тоді, коли немає потреби в extendsзастереженні.

Деякі інші аргументи, які можна зробити проти використання enums:

• це злом - це використання переписок для чогось, на що вони не були призначені
• це бентежить читачів, які цього раніше не бачили

Я сильно покладаюся на книги як на джерело знань - це чудові основи, і я вважаю, що «Інфест» має рацію в тому, що вам слід вживати значну кількість книг у вільний час, оскільки вони дійсно прискорюють вашу майстерність. Книги - не єдине джерело інформації, хоча, на мою думку, ви повинні споживати - відвідайте місцеву групу користувачів, отримайте відповідні інформаційні бюлетені, що надходять у вашу поштову скриньку, читайте блоги.

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

Пропозиція попросити Інфесту переглядати пропозиції з вами є чудовою - піти, прочитати все та повернутися з купою продуманих питань, на які ви вже намагалися відповісти / вирішити для себе, разом із вашими підтвердженнями для ваших метод.

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

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

Цілі огляду коду в команді: 1) перевірити код та 2) переконатися, що особа, яка пише код, розуміє сенс вдосконалення коду. Це не місце сказати "змінити це, бо Мартін Фаулер сказав так у книзі GoF". Однак, це місце сказати "змінити це, тому що [коротке пояснення]; детальніше це обговорюється в книзі GoF".

Якщо ваш старший розробник не, хоча б просто і тонко, не надає пояснення щодо зміни та наполягає на використанні словесного слова "через [книгу]", він є трохи розумним і ривком. Як ти з цим справляєшся? Зазначте це на зустрічі команди, усно, і попросіть своїх товаришів по команді надати заяву або два, коротко пояснивши перевагу чи необхідність змін, а також корисну книгу. Обов’язково подякуйте йому за довідку про книгу.

Зіткнувшись з вами, ваша мета - оцінити пропозицію щодо змін і не бути демотивованим на ваше завдання чи роботу. Скажи йому це. "Я буду вдячний більше за пропозицію щодо змін, якщо ви можете коротко описати перевагу чи необхідність змін, коли ви переглядаєте мій код; адже саме так я вважаю, що ваші посилання на книги є дещо демотиваційними".

Якщо він продовжує відмовлятися надавати просте пояснення зі своїми посиланнями на книги, якщо ви можете надати іншу книгу чи ресурс з однаковою чи більшою популярністю в галузі з іншою думкою, і вона відповідає вашому сценарію, ви можете додати свою власну книгу посилання у вашому коментарі до відгуку щодо врахування збереження вихідного коду. Зробіть це достатньо разів, він може відступити. Будьте дуже обережні, що контраргумент є правильним та значно важливішим; це добре, щоб старший розробник не помилявся і все-таки мав свій шлях, це те, чого я навчився і постійно мушу вчитися.

Я б сказав, що вивчити програмування лише з книг неможливо, але вони хороші забезпечать вам величезний імпульс. Це як карате - у вас не буде чорного пояса, лише читаючи про нього;) Я вважаю, що в цьому неспокійному випадку пан Інфестус переглядав "Ефективну Яву" Джошуа Блоха. Це дійсно чудова книга про розробку Java, і ви, безумовно, повинні її прочитати, якщо вже не маєте.