×Закрыть

Советы сеньоров: как прокачать знания junior .NET

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

Ярослав Ефименко, Senior Software Engineer, 12 лет опыта .NET разработки:

Всем привет! Прежде всего, хочу посоветовать нашим джуниорам две вещи. Во-первых, не бояться и верить в себя. Во-вторых, учиться, учиться и еще раз учиться. Пожалуй, порог входа для овладения стеком .NET будет выше по сравнению со сферой web-разработки, однако он же будет явно ниже, чем порог входа для разработки на С++, и примерно сопоставим с порогом входа для Java. Но это все не столь существенно по сравнению с одним соображением: самое главное, чтобы вам НРАВИЛОСЬ программировать.

Программирование, с одной стороны, — тяжелый умственный труд, получение массы знаний из самых разных источников, разбор головоломок багов иногда вообще без какой-либо помощи от тех самых источников, необходимость постоянно выстраивать в голове самые разные сложные конструкции (а способность к такому абстрактному мышлению есть далеко не у всех). Но, с другой стороны, программист — это творец и повелитель Вселенной! Маленькой J, которую он выстраивает силой своего разума и воплощает в строках программного кода. Конечно, внешняя среда (т. е. компьютерное железо и выбранный стек технологий) накладывает свои ограничения, но сравните, насколько они меньше по сравнению с ограничениями, например, инженеров-самолетостроителей. Ну и еще один маленький бонус — с такой напряженной работой мозгами склероз в старости вам точно грозить не будет.

С чего же начать? Я пришел в мир .NET, уже будучи опытным разработчиком (C++, Pascal и т. д.), поэтому фактически мне необходимо было изучить отличия C# от С++, а опыт работы с Microsoft Visual Studio у меня уже был. Здорово также помог опыт работы с Delphi и C++ Builder — было такое впечатление, что .NET Framework включал в себя лучшее из известных мне технологий. Поэтому для меня основными книгами стали учебники компании Microsoft для подготовки к экзаменам по .NET Framework 2.0: 70-536 (Foundation), 70-536 (Windows Applications), 70-528 (Web Applications) и 70-529 (Distributed Applications). Понятно, что сейчас эти книги уже не настолько актуальны, но есть и учебники по последним версиям .NET Framework. Кроме этого, мои любимые книги по .NET — это «Язык программирования C# 6.0 и платформа .NET 4.6» Эндрю Троелсена (в том числе ее более ранние издания) и «CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#» Джеффри Рихтера (опять же включая ее предыдущие версии). Также must read — это Гради Буч, «Объектно-ориентированный анализ и проектирование».

Но перечисленные книги новичку могут оказаться слишком тяжелыми для восприятия и недостаточно подробными для первых шагов. Поэтому начинать я рекомендовал бы с книг из серии «Head First»: «Изучаем C#» и «Объектно-ориентированный анализ и проектирование». Они написаны легким языком и доступны для изучения даже подростку (проверено моим сыном). Далее можно читать книги из той же серии, например, «Изучаем SQL», «Паттерны проектирования» и так далее.

Сразу хочу отметить две важные вещи. Во-первых, просто читать даже самые лучшие книги категорически недостаточно. Нужно ставить себе Visual Studio (благо Community Edition для целей обучения абсолютно бесплатна) и одновременно с чтением писать код. Поставьте себе задачу для начала написать, например, свой калькулятор, потом каталог с поиском для домашних книг или фильмов и так далее. Заведите свой аккаунта на GitHub и соберите коллекцию своих маленьких проектов — так будет проще и совета спросить, и показать, как вы учились, уже при поиске работы. Во-вторых, ни в коем случае не пренебрегайте общими принципами объектно-ориентированного программирования. Уверенное владение ими в чем-то даже важнее владения языком С#.

Что читать далее и в каком направлении развиваться — покажут время и ваши предпочтения. Повторюсь, самое главное, чтобы программирование вам нравилось. Кто-то будет писать сайты, кто-то Windows-приложения, еще кто-то — только Back-end. .NET Framework предоставит вам возможности для всех этих направлений и еще для массы других, о которых вы еще не знаете (да и я тоже всех не упомню). Творите — и да пребудет с вами Сила!

Павел Мальцев, Solution Architect, 10 лет опыта .NET разработки:

Редакция DOU спросила меня, как прокачать свои знания джуну. Вообще-то есть годная Programmer Competency Matrix, но я добавлю еще немного отсебятины.

Старайтесь концентрироваться на принципиальных вещах, а не на освоении максимально широкого количества библиотек или деталей. Разберитесь с Design Patterns, SOLID, DDD, ORM.

Если вы не заканчивали профильный вуз, у вас может не хватать базы, основы. Попробуйте восполнить этот пробел самостоятельно — алгоритмы, структуры данных, работа с памятью, TCP, HTTP, security, O(n), memory management, деревья, графы...

Постройте в голове четкую причинно-следственную связь для всех новых веяний в индустрии. Какую задачу решает технология? Какие ограничения? К примеру, почему появился MVC, ведь был же Web Forms.
Не отвлекайтесь на модное. Оно может не прожить и двух-трех лет, и ведь есть еще столько «классики», которая будет нужна всегда. Silverlight? Нет, не слышал.

Ставьте цели. Найдите свой интерес. Goals should be SMART. Постоянно спрашивайте «зачем». Когда вложенность вопроса-ответа дойдет до трех-четырех-пяти уровней, можно остановиться.

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

Заведите аккаунт на Stack Overflow. Разберитесь с Git. Многопоточность — это не просто async/await. Разберитесь глубже. В идеальном проекте применяется CI, unit testing, static code analyzer. Если у вас такого нет — сделайте свой pet project и примените там в любом начальном виде. Глубоко разберитесь с exception handling.

High Load не всегда вершина всего, но там много интересного. Вообще, вся архитектура зависит от нагрузки, помните об этом.

Требуйте code review! Пишите для других. Делайте комментарии в коде: что код делает видно из кода, а вот почему — очевидно не всегда.

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

И еще немного:

  • Заглядывайте в исходники .NET.
  • Полезный список.
  • 97 Things Every X Schould Know — неплохо.
  • Читайте Рихтера, Фаулера, Скита. Из наших неплохо пишет Сергей Тепляков.
  • Меняйте проекты, но не слишком часто. Старайтесь принимать участие в проектах, в которых есть реальные пользователи.
  • Всегда понимайте бизнес-задачу, которую вы решаете.
  • Не читайте бумажных книг, особенно в переводе — почти все они уже устарели.
  • Не пользуйтесь локализированным продуктами, «у пана атамана все английское».
  • На хабре часто комментарии важнее статьи.
  • В любой профессии может присутствовать творчество. На любом проекте всегда можно чему-нибудь поучиться. Но не скатывайтесь в рутину.
  • .NET — это еще и PowerShell c F#.
  • Фронт-енд — дело молодых, лекарство против морщин. Но потом может быть больно за бесцельно прожитые годы.
  • Изучите и используйте hot keys. Старайтесь вообще не пользоваться мышкой в меню.
  • Освойте слепой набор на клавиатуре. Я учился на «solo на клавиатуре» от Шахиджаняна.

Василий Гребинник, Senior Software Engineer, 9 лет опыта .NET разработки:

Успех превращения начинающего разработчика в компетентного программиста предполагает серьезное изучение теории и наработку опыта. Других вариантов нет, и просто прохождение курсов вам не поможет. Учить и читать придется много, очень много, причем в самостоятельном режиме, а не только то, что «задали». А опыт нарабатывается на реальных сложных проектах. Чем сложнее проект, чем тяжелее вам будет работать, но тем больше полезного опыта получите. И, если вы действительно хотите стать классным специалистом, трудности в проектах вас должны не пугать, а мотивировать. А теперь рассмотрим будущее обучение более детально.

Теория программирования

.NET программист — это в первую очередь программист. Начните с самых азов — то есть изучите до полного понимания фундаментальные структуры данных и алгоритмы. Посмотрите теорию графов, комбинаторику, теорию вероятности. Д. Кнута читать сейчас совсем не обязательно. Можно найти понятные для начинающих статьи в интернете. Если вам не понятна статья — бросайте ее. Автор скорее всего и сам не до конца разобрался в материале. Моим первым учебником была книга «Простое и сложное в программировании» Велихова Е. П. Я бы рекомендовал почитать ее. Отличное изложение теории, и еще в ней есть определение Э. Дейкстры, кто же такой компетентный программист.

Принципы ООП, SOLID, GOF, MVC, MVVM и другие паттерны надо не только прочитать, но и проработать. Нарисуйте схемы паттернов. Спросите себя, действительно ли вы понимаете, когда их нужно применять, чем они похожи, чем отличаются. Не слушайте тех, кто говорят, что никогда на практике их не использовали. Вы же не собираетесь всю жизнь заниматься проектами не сложнее Hello World? Сложные продукты подразумевают проработку архитектуры программ. Проработайте Microsoft Application Architecture Guide. Multilayer, 3-tier архитектура, монолит и микросервисы должны стать знакомыми понятиями. Посмотрите, какая архитектура используется на вашем проекте и что можно улучшить или ухудшить, применив другие архитектурные принципы.

Для изучения собственно C# и .NET я не буду оригинален и порекомендую классику: Троелсена — для С#, Рихтера — для получения более глубокой информации по .NET, «Pro ASP.NET 4.5 in C#» - для изучения ASP.NET. Я учил именно в таком порядке. Еще я бы порекомендовал почитать книгу «Accelerated C# 2010» Трей Нэш. Хотя она и несколько устарела с точки зрения описания языка, но там описано несколько полезных и интересных техник программирования. По .NET Core я использую просто документацию.

Выход .NET Core — настоящая революция в мире .NET, и хотя, как я считаю, он вряд ли вытеснит полновесный .NET Framework из Enterprise-сегмента, мы получили первое настоящее средство для создания кроссплатформенных приложений от Microsoft.

Еще я бы рекомендовал подписаться на тематические сообщества и посещать тематические митапы. В Киеве, например, регулярно проходит .Net café, который организует Intetics. Там мы обсуждаем реальные кейсы и практические решения сложных задач.

Практика

Самый главный совет по написанию кода — всегда пишите качественный код. Принцип «Quick and dirty» — ваш главный враг. Даже если менеджер говорит, что код нужен был на вчера, никогда не торопитесь, чтобы «сдать в сроки», не пишите плохой код. Лучше уделить чуть больше времени и избежать грубых ошибок. Не бойтесь: чем больше будет опыта, тем быстрее будете писать качественный код. Качество кода — это ваш профессионализм и репутация среди коллег. Окружающая среда, руководство и требования постоянно меняются, но опыт и репутация остаются навсегда. Нет ничего хуже репутации «#0%0кодера» для настоящего программиста. Прочитайте Боба Мартина «Чистый код» и ... еще раз перечитайте. Я рекомендовал другие книги выше, но эта — обязательна для прочтения.

Используйте лицензионное программное обеспечение. Получая деньги за написание ПО, надо и самому оплачивать труд других программистов. Постарайтесь договориться с руководством и получить MSDN-подписку. Это даст доступ к огромному количеству лицензионного ПО от Microsoft и не только. В подписку входит доступ к Pluralsight — источнику тренингов по различным областям ИТ.

Профессионал должен знать свой инструмент — изучайте возможности среды Visual Studio, особенно в отладке, навигации по коду и рефакторингу. Посмотрите на ReSharper, до выхода 2017 студии без него работать было не так приятно.

Аппаратное обеспечение

Ваш компьютер не должен сбоить и должен работать быстро. Поставьте максимальное количество ОЗУ, SSD. Инвестируйте в хороший большой монитор — берегите свое зрение. Заодно посвятите определенное количество часов в неделю физическим упражнениям и введите в рацион Омега-3-6-9 кислоты. Это позволит обеспечить хорошее кровообращение в головном мозге и даст возможность думать на все сто. И в целом, поможет вам поддерживать себя в тонусе. Все же ваше физическое состояние тоже очень важно, учитывая, сколько умственных усилий вы будете прилагать в работе.

Успехов в выбранной профессии, и не бойтесь начинать — все профессионалы когда-то были джунами.

Алексей Михалевич, Software Architect, Team Lead, 7 лет опыта .NET разработки:

«Для тех, кому интересно»

Программирование — это не про знание языков, библиотек, стандартов. Это логический образ мышления, умение разбивать задачу на подзадачи и четко представлять результат ваших действий. Как и любой другой навык, их надо прокачивать. Задачки, головоломки, личные проекты — все это тренирует ваш мозг в нужном направлении. Have fun!

Think outside the box

Будьте любознательны, выясняйте, как все устроено. Алгоритмы и структуры данных. ООП. Паттерны проектирования. Только не заучивайте определения, а прочувствуйте принцип. Практика — наше все. Напишите свой Dictionary, а потом попробуйте понять, почему он работает в несколько раз медленнее стандартного. Напишите мультипоточное приложение, используя low-level synchronization и половите deadlock’и. Решите уже наконец задачу коммивояжера, написав свой муравьиный алгоритм.

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

Не ограничивайтесь только рабочими задачами, создавайте что-то для себя (в нерабочее время :-)). Изучайте материалы по Data Science, Machine Learning, Deep Learning, AI.

Learn English

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

Be a team player

Будьте командным игроком: ответственно относитесь к срокам, помогайте другим, не стесняйтесь сами обращаться за помощью. Не бойтесь брать на себя ответственность и проявлять инициативу — это залог роста специалиста в компании. В правильной компании.

Practice

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

А языки, библиотеки, стандарты вам, конечно, придется изучить. А потом изучить новые. И еще новее. Но у вас уже будет базис.

Несколько полезных ресурсов:

  • stackoverflow;
  • CodeProject — ищите вопросы на интересующую вас тему и детально разбирайте ответы, не копируйте слепо решения;
  • Хабрахабр — ищите и читайте статьи, обычно они легче для понимания новой для вас темы и могут послужить хорошим стартом;
  • «Алгоритмы. Построение и анализ» Томас Х. Кормен, Чарльз Лейзерсон, Рональд Ривест, Клиффорд Штайн;
  • «Приемы объектно-ориентированного проектирования. Паттерны проектирования» Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес;
  • Также можете бесплатно скачать «Design Patterns via C#» Александр Шевчук, Дмитрий Охрименко, Андрей Касьянов;
  • «Язык программирования C# 6.0 и платформа .NET 4.6» Эндрю Троелсен, Филипп Джепикс.

Артур Швецов, Senior Software Engineer, 7 лет опыта .NET разработки:

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

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

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

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

В будущем вам необходимо будет проектировать новые модули и интегрировать их с уже существующими или же строить системы «с нуля». Для этого в вашем арсенале должны быть знания ООП, SOLID принципов, паттернов проектирования, DDD, TDD, а также подходов, которые помогают снижать сложность разработки проектирования и сопровождения кода.

Из must-read литературы по .NET, архитектуре ПО, рефакторингу и тестированию я бы порекомендовал следующие книги:


См. также другие советы сеньоров:
— Python
— Front-end/JavaScript
— Java
— QA

LinkedIn

Лучшие комментарии пропустить

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

151 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Давайте уже по ios, а то устал ждать. Просто интересно кто что скажет

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

по мере роста сложности проектов.

Для джунов.

сложно представить себе прохождение любого собеседования.

Для джунов.

От себя могу дать «не программистские советы»:
1) Всем пофиг на чем вы пишите, какой у вас стаж, какой длинный у вас... Все смотрят на продукт который вы сделали. А посему делайте продукт а не пишите код. Ну и не инвестируйте время в гавно работу чисто ради денег, это обойдеться дороже.
2) Вы продукт и специалист в одном лице. Вы должны уметь себя продавать за максимально возможные деньги. Ибо чел с 15лет опыта может получать 2к уе, в то время чел с 2 годами 10к уе. Просто потому что один ноль в общении и продажи себя. А посему знайте себе цену, и свои + и -. И умейте это грамотно использовать на рынке.
3) Рынок движеться. То что вчера стоило дофига сегодня стоит копейки. Сидя на жопе рано или поздно вы в ней и окажетесь. Учитесь новому, языки, технологии, базовые науки. Тут не важно что вам нравиться не нравиться. Вы должны смотреть что будет востребовано и стоить бабла а что нет. К пример сейчас это DS и ML.
4) хороший дев это не тот кто 50 лет юзал один язык. а тот кто за 2 часа может начать писать на любом, под любую платформу с любого старта. По сути это тот человек который решает поставленную задачу, а какова она не так важно. Я например писал более чем на 20 языка, и под нереальное количество фреймов систем и прочего. Просто потому что у всего есть +/- все имеет свою область приминения и цену реализации. И вы как спец должны это понимать. Тянуть все под свой стек это показатель непрофессионализма. А посему готовтесь что учиться вам прийдеться 24/7/365(в высокостный можете денек отдохнуть)
5) Ну и если хотите быть крутым — ебошьте. Чем больше и усердней вы будете ебошить тем быстрее достигните момента когда многие вещи стану проще, а клиенты выстрояться в очередь.

высокостный

как-то много для CTO.

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

давай конкретнее.. и желательно в примерах. Мои люди кто следовал этому успешно получают 8к+ и не бегают в панике.

и хоть один из них программист в украине?

Еще забавно что у более молодых советы более адекватнее)

У меня 15лет разработки и я выгляжу куда моложе.. Вот что делает .NET с людьми.
Люди задумайтесь надо ли оно вам? Лучше учите Python и ML здоровее будете)

У меня 15лет разработки

Странно, в линкеде список ваших достижений начинается с 2008 Откуда взялось еще 5+ лет?)

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

Дык он институт к стажу добавил :) возможно даже он там был тыжпрограммистом и компы админил, указанный опыт тоже вызывает большие вопросы, по крайней мере у меня

Современные айтишники мне иногда напоминают советских бабулек в одном аспекте. Бабульки очень часто верят «тиливизару», ставя понос, который оттуда доносится, превыше всего. Так и айтишники. Если это написано в КНИИГЕ, то всё — это правильно и всегда надо делать только так). Критическое мышление? Не, не слышали

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

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

вони якраз будуть їх повторювати буква-в-букву, причому там де не треба

Так для этого и нужны старшие разрабочики чтобы корректировать и направлять. А что джун напишет не читая книг?

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

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

Книги по объективным вещам джуну нужны, но тоже в разумных дозах.

Проблема в том, что если джун не читает книги то он ни мидлом ни синьером не будет их читать и станет синьером по выслуге лет. Но это комлексный вопрос. Одними книгами ограничиваться тоже не стоит. Да и сколько книг сможет разрабочик прочитать будучи джуном. Две-три?

А некоторые книги стоит перечитывать для переосмысления.

я не читаю книг) А знаете почему? потому что они лет на 5 отстают от реального мира.
А еще их пишут чтобы продать и там очень много заумной мути. Которой часто любят страдать энтерпрайз девы, которые суют патерны где надо и где не надо, вместо того чтобы думать головой. Я очень много видел «хелоу ворлд» на пару мегабайт пустышкового кода.

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

Ни одной книги не прочитали? Или больше не читаете? ML и CV изучали по stackoverflow? Алгоритмы по этим же дисцилинам тоже устарели? Вам виднее, конечно. Но фундаментальные вещи не устаревают или устаревают не так быстро.

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

Странно, что, вроде как, опытный CTO противопоставляет статьи книгам. Эти вещи должны идти параллельно. Книги формируют целостную картину. А фундаментальные вещи нет, как и вайпаперы. Мы же не говорим про книги о новом UI фреймворке.

А фундаментальные вещи нет, как и вайпаперы.

Имел в виду, что не стареют.

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

книги не дают главного — идей

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

И микросервисы — это скорее веяние моды, хотя и их чтобы научиться готовить одно книги недостаточно (хотя она и хороша) не говоря уже про статьи.

так а зачем читать книгу если у автора есть статьи и книга от них по времени отстает существенно.
Это не менеджмент где измения раз в 5 лет. это ИТ тут изменения каждую неделю. и читать то том что уже умерло смысла нет.

ну и как бы я потому и опытный, потому что набил себе шишек и понял что много «фундаментальных вещей» красивы только как картики в постах на ФБ.

На DOU пора вводить кнопку «Ну давай, расскажи мне больше!»...

потому что они лет на 5 отстают от реального мира

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

которые суют патерны где надо и где не надо, вместо того чтобы думать головой

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

Чтобы чел учился ему нада не кнгии давать а проекты

Ему надо давать и то и другое.

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

Человек который не читал про патерны не будет его никуда пихать ибо он нем банально не знает.. а будет делать то что максимально эффективно решает задачу.
А жизнь с паттернами очень похожа на работу с патернами в трейдинге. Вложите в крипту 5к и поторгуйте на паттернах без обдумывания и понимания.. и посмотрите как быстро ваши 5к превратяться в 0

Вы многих людей обучали?

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

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

Человек который не читал про патерны не будет его никуда пихать ибо он нем банально не знает.. а будет делать то что максимально эффективно решает задачу.

Просто ржу))

Вы многих людей обучали?

А вам хочется померяться обучалкой или к чему вообще вопрос?

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

Советы сеньоров: как прокачать знания junior .NET

і досвідчені розробники поділилися своїм досвідом, за що можна бути тільки вдячним. З приводу списку літератури — це дійсно must have, якщо ви ДІЙСНО хочете прокачати свої знання. Краще б порадили щось корисне для джуніорів, а не переводили все у нікому непотрібні «ІМХО».

Чи дійсно „Patterns of Enterprise Application Architecture” must have для будь-якого .NET розробника? А якщо він працює не з ентерпрайзом і ніколи працювати не буде, то воно йому потрібне?

Цитата із цієї книги (зовсім випадково я якраз зараз її перечитую :) )

I’ve written this book for programmers, designers, and architects who are
building enterprise applications and who want to improve either their understanding
of architectural issues or their communication about them.

Там совет как прокачать. Ты сам выбираешь нужно тебе прокачивать это или нет. Разве это настолько неочевидно?

І такий список, коли ти сам вибираєш, що прочитати, називається must read? :)

Я тоже не согласен что это

must read

но сиписок годный.

Паттерны это вообще е***ый пи***ц. особенно для людей которые мало шарят. Как гласит поговорка «Страшен не тот врач который не читал книг, а страшен тот который прочитал одну.»
Джунов нужно учить думать, а не копипастить гавно, ибо паттерны во многих случаях это именно оно. Лучший принципл это KISS.
Особенно печалят идеалисты кричащие «Код должен быть идеален, с тестами, красив, оптимизирован,...», бо таккие идеалисты часто не слышат людей с которыми работают.. тех же сейлзов, маркетеров, ПРщиков, СЕО, и т.д. И выглядит это как чел создавший идеальный ДВС двиг когда уже все юзают телепортацию.

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

Для долгоиграющего продукта, который уже устаканился — это маст-хэв всё-таки, нет?

Не его случай: или маленькие проекты или стартап на этапе хуяк-хуяк.

простой вопрос)) Что дешевле и эффективней покрыть весь код тестами при этом увеличить затраты по ресурсам на разработку в 2-3 раза, или покрыть кодом реально критические(фин части), а на половину оставшихся денег нанять QA?
Если что я ответ знаю, и не придуманный а протестированный на продукте овер $100млн+ и довольно большим количеством кода и сложностью архитектуры.

покрыть весь код тестами при этом увеличить затраты по ресурсам на разработку в 2-3 раза

На чём основаны эти фантастические расчёты? Реально интересно, какая зависимость приводит к этим цифрам — где смерть Кощея?)

а на половину оставшихся денег нанять QA

Их и так нужно будет нанимать.

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

простой вопрос, как проверить что тест коректно тестирует код, ведь тест это тоже код)))

Вот это правильный вопрос: www.manning.com/...​it-testing-second-edition. Код в тестах в первую очередь должен быть тривиальный с низкой цикломатической сложностью чтобы там очевидно небыло ошибок.

www.manning.com/...​it-testing-second-edition

Дать ссылку на книгу человеку, который выступает против книг? savepic.org/3077350.jpg

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

тривиальный тест можно разве что написать для тривиальной задачи)

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

нету понятия устаканившийся бизнес. если бизнес в стогнации это значит что очень скоро появиться новый игрок и его сьест.
Что касается разработки то все должно быть обосновано а не потому что так кто то гдето написал. Если ты не можешь обоснавать на цифрах почему код должен тестироваться — значит не должен. Говорить о таких вещах однозначно это всеравно что в нейронке на 200 слоев веса выставлять руками на глаз и говорить «я знаю так лучше».
Любое действие должно основываться на фактах. нету фактов — это грезы.
А весь этот идеализм зачастую именно грезы, так как практика показывает что большая часть его впихнутая не к месту не только не помогает но и мешает.
Посмотри например на UX, любая гипотеза проходит через АБ тестирование и только после этого считается достойной принятия и рассмотрения. А не потому что кто то сказал что зеленая кнопка лучше фиолетовой.

нету понятия устаканившийся бизнес. если бизнес в стогнации это значит что очень скоро появиться новый игрок и его сьест.

Почитай историю создания LinkedIn — там это всё доходчиво описано: большая часть продуктов начинает свой путь с задвиганием всех этих вещей на второй план, чтобы быстрее выстрелить и набрать обороты, а потом начинается наведение порядка, потому что рост системы начинает очень резко повышать риски от её волатильности — тушение пожаров начинает очень дорого обходиться. Армию QA нанимать и постоянно пополнять их штат, или всё-таки не выдумывать велосипед и писать тесты, наконец?

Любое действие должно основываться на фактах. нету фактов — это грезы.

С одной стороны — согласен. С другой, если перегибать, то можно дойти до того, что все мы живём в Матрице и всё вокруг — проекция). Есть какие-то очевидные вещи всё же.

Если ты не можешь обоснавать на цифрах почему код должен тестироваться — значит не должен. Говорить о таких вещах однозначно

...можно в случае, когда продукт устаканился. И это используется практически везде — да даже в Хроме и Мозилле, которыми ты, скорее всего, в данный момент пользуешься. Они такие дурачки?) Или продукт не устаканился? Да давно уже устаканился.

Посмотри например на UX, любая гипотеза проходит через АБ тестирование и только после этого считается достойной принятия и рассмотрения. А не потому что кто то сказал что зеленая кнопка лучше фиолетовой.

UX — это UX — субъективная вещь (нравится/не нравится, легко/сложно, быстро/долго, красиво/некрасиво), потому там и нужно A/B тестирование. При чём здесь тестирование кода? Технические решения с этим сравнивать — тёплое с мягким, по-моему. Вы же разные стеки технологий не выносите на A/B тестирование путём разных реализаций, а как-то сами решаете?)

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

Отлично, так что же в итоге увеличивает стоимость разработки «в 2-3 раза» при внедрении тестов? Что говорит нам наука?)

тесты и увеличивают. написание тестов это 2х-3х времени оверхеда.

Как эта цифра считалась? Было утверждение, что под всем должна быть наука. Почему при БА считается 2-3, а не 0.2-0.3 или не 200-300? Почему паттерны — это всё якобы фигня, а в утверждение про оверхед в 2-3 раза должно приниматься на веру?) Объясните, откуда эти цифры взялись. Потому что так получилось на одном-двух проектах с нуля до MVP, и теперь этот подход экстраполируется на всё подряд? Непонятно.

или всё-таки не выдумывать велосипед и писать тесты, наконец?

Делать стартап по феншую с 0ля — выкинуть деньги на ветер, если идея не взлетит (нельзя так просто взять и сразу взлететь). Вот и получается, что всякие линкедины пишут безграммотные, но дерзкие — говнячат прототип и продают его клиентам как передовые наработки. Пофиг что на соплях, зато быстрее конкурентов. Потом срубают бабло (один стартап из десяти или какая-там статистика) когда до них доходит, что продукт на соплях вот-вот сломается к чертям, нанимают грамотных спецов, что бы те уже сделали/переписали все по феншую. Ничего личного, просто жизнь.

Ну, я об этом и писал, собственно). Когда продукт устаканится — это становится вопросом выживания.

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

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

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

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

Тех. долг вещь которая существует в балансе.. если его нет это хуево, елси он слишком большой — это хуево.

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

проекты двигают как раз не те кто просто пишет код а тек кто создает продукт.

Вы путаете роли программиста и продукт-овнера. Человек может быть одновременно и программистом и продукт-овнером, и стартапером, да хоть слесарем... но программист — это одно, продукт овнер, стартапер, ПМ, и т.д. — это другие роли совсем. www.google.com.ua/...​search?q=Разделение труда

Отличный совет... для разработчиков по методу «х**к х**я и в продакшен»!

опыта вам нехватает чтобы понять что судь не в качестве кода вообще.

опыта вам нехватает

Ну давай, расскажи мне больше про мой опыт)))

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

Моя порада? Знайомитись поступово, на прикладах з коду, з декількох сорсів. Вам зустрічається DI — читаєте про це в різних курсах, блогах, створюєте якусь власну думку. Потім питаєтесь «старшого товариша», щодо всього цього, пишете код, проходите код-рев’ю і через призму усих цих дій в вас же формуються якісь сталі знання. І вже після цього, якщо маєте бажання отримати глибші знання, розставити все по полках, читаєте відповідну книгу. Таким чином, ви матимете шанс побачити, що добре, а що ні.

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

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

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

Як ви можете робити такі висновки, якщо ви

Саме з цього списку я не читав жодної книги

бо об’єктивні речі це те, що в C# є п’ять модифікаторів доступу, а те, який патерн у якій ситуації використовувати — це суб’єктивно. Мені здавалось, що це очевидно

Чтобы понять что что то говно не нужно в это вступать и пробывать на вкус)

Из must-read литературы по .NET, архитектуре ПО, рефакторингу и тестированию я бы порекомендовал следующие книги:
„C# 6.0 in a Nutshell: The Definitive Reference”, by Joseph Albahari, Ben Albahari;
„C# in Depth”, by Jon Skeet;
„Clean Code: A Handbook of Agile Software Craftsmanship”, by Robert C. Martin;
„Dependency Injection in .NET”, by Mark Seemann;
„Паттерны проектирования на платформе .NET”, by Sergey Teplyakov;
„Head First Design Patterns: A Brain-Friendly Guide”, by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Robson;
„Adaptive Code Via C#: Agile Coding with Design Patterns and Solid Principles”, by Gary McLean Hall;
„Microsoft .NET — Architecting Applications for the Enterprise”, by Dino Esposito, Andrea Saltarello;
„Implementing Domain-Driven Design”, by Vaughn Vernon;
„Patterns of Enterprise Application Architecture”, by Martin Fowler Signature Book;
„Working Effectively with Legacy Code”, by Michael C. Feathers.

Must read? Всё это? Seriously?)) Чувак наверное, из тех, которые спрашивают джуна подробности механизма сборки мусора

Так все этот вопрос задают. И на джуна тоже всегда его спрашивали.

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

А можна просто поцікавитися: що «толкового» ви питаєте?

Залежить від проекту та рівня співбесідника, починаю з якихось елементарних теоретичних речей, просто щоб переконатись, що передо мною не сидить зовсім нуль. А основні питання в дусі «А як би ти зробив в ситуації Х», «А якщо на цю ситуацію накласти обмеження Y», «З якими проблемами ти стикався і як їх вирішував. Чому обрав рішення Z, а не W?» Мені важливіше почути, як людина думає, бо якщо це вже існуючий проект, то технологію можна вивчити швидко, відлаштуватись під стиль кодінгу теж, а от навчитись думати — то важко

Так не я собеседования провожу. Это вопрос к тем кто проводит. Мне кажется например что не все понимают что проводить собеседования тоже надо уметь и это не так то и просто. Есть те кто хорошо проводит, есть те кто плохо. Иногда попадаются случаи когда кажется что тебя не на работу собираются взять, а топят любыми способами. Висты зарабатывают перед сидящим рядом PM. Так что сколько людей столь же и способов проведения собеседований. А собеседования на джуна это еще та жесть. Полный прогон по всей теории программирования, алгоритмов и работе .NET платформы. А вы думали откуда взялась фраза «ну тупые джуны пошли, не то что в наше время»?)

прозвучало просто, как будто вы поддерживаете такие вопросы джунам). На самом деле, собеседовать джуна это конечно челлендж. Ибо самое главное ИМХО — его обучаемость и умение мыслить, а это очень тяжело проверить в условиях, когда человек ни с чем в айти не работал.

Я не поддерживаю такие изнасилования мозга на собеседованиях. Просто делюсь своим опытом таких собеседований. Я не говорю что это хорошо и правильно, я говорю что такие бывают.
Сейчас требования стали намного жестче чем условные 5 лет назад. То что раньше хватало на middle сейчас junior. Что говорить если уже на trainee в требованиях я видел 1+ years experience.

А все-таки цікаво як часто тут людям доводилось з цим сміттєзбірником явно працювати?

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

Якщо вас там Артур тримає прив’язаним, ви підморгніть якось, ми вам допоможемо))

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

Книжки ІМО треба читати роздрібно, повільно і паралельно з практикою. Ну от прочитає джун цілу книгу по депенденсі інжекшн, а потім цілу книгу по SOLID. Як ви думаєте, багато інфи буде людина пам’ятати з першої книги?))

Такі адепти не працюють на проектах з маленькими аплікаціями ;)

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

Ну та якщо джун це все перечитав і знає (при цьому ще і розуміє), то він уже не джун :)

бгг) це утопія. Сухі книжки можуть зформувати невірні, непрактичні знання та розуміння. Знову-таки, я зустрічав людей, які знали всі 23 паттерни GoF, але на практиці вирішували проблеми, як говно.

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

не завжди. У книгах далеко не все ідеально, особливо в архитектурних. Читаючи лише книгу, люди формують невірне уявлення, в якому впевнені, бо вони ж це прочитали в КНИИИИЗІ, а не в якомусь бложику.

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

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

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

Условный Вася почитал денек блогов про DI, недельку поигрался с ним, поспрашивал у менторов, полазил на стековерфлоу, проанализировал, сложил своё мнение, потом поигрался еще и так далее.

Кто из них более ценный специалист? Петя, который прочитал мнение ОДНОГО автора по DI и ничего не сделал в практическом смысле или Вася, который прочитал мнение десятков авторов, сложил собственное, попрактиковался, пообщался и так далее.

Петя ценнее, книга must read без сомнения. Особенно вторая редакция, которая на подходе. У Пети формируется целостная картина, а не обрывки знаний. И Пете, ведь, тоже никто не мешает общаться и практиковаться.

У Пети нифига не сформируется после 11 книг. Когда практика начнет противоречить книгам, будет немножко когнитивный диссонанс. В то время, как Вася, добравшись до этой книги уже будучи каким-нибудь синьором-помидором, сумеет отделить зерна от плевел и уже тогда почерпнуть из этой книги что-то полезное для себя, чего уже не найти в обрывочных блогах

Если вы столь ярый противник книг, а фанат блогов и видео курсов, так помогите людям — добавьте комментарий с линками на блоги, курсы, сделайте что-то полезное.

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

Линки элементарные:
google.com
stackoverflow.com
coursera.org
и так далее. Ну а если человек не умеет анализировать информацию из нескольких источников и выбирать, что ему понятно, а что нет — ну грош цена такому специалисту. Давать ссылки на конкретные блоги и статьи — дело не самое лучшее. Это не особо отличается от того, чтобы дать тупо книгу. Если человеку дать ответ на вопрос, он только узнает ответ и все, а если человек сам ищет ответ, то по пути узнает еще много всего полезного.

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

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

а 2*2=4. Я не совсем понимаю при чем здесь одно к другому. Умение формируется прежде всего через практику. Поэтому в университетах есть практические/лабораторные, а не тупо на тебя выгружают сухую теорию и потом ты на экзамене сдаешь сразу практику Ну или, что больше подходит под описанный совет — семестр сухая теория, а потом семестр лабораторных.

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

омг. А можно цитату? Я предлагаю почитать инфу в инете (читай, теория), после этого практиковаться, потом пообщаться со «старшим товарищем» (читай, общение с преподавателем), а после всего уже читать книгу, как один из ресурсов с общей инфой.

:)
твои предложения помогут новичкам стать хорошими программистами (читай, говнокодерами)

людям, не умеющим анализировать информацию? Да, но им и прочтение книг не поможет стать хорошими программистами.

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

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

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

а вот не манкикодер хуже от этого станет?

Ну вот смотри. Я поддерживаю прочтение таких книг

«C# 6.0 in a Nutshell: The Definitive Reference», by Joseph Albahari, Ben Albahari;
«C# in Depth», by Jon Skeet;

ибо джун уже знаком с .NET, с какими-то базовыми вещами и в состоянии сравнить то, что говорится в книге с тем, что он УЖЕ писал. Таким образом его знания оформляются и структурируются. И то, на самом деле больше одной книге по подробностям C# джуну в данном случае ни к чему.

«Dependency Injection in .NET», by Mark Seemann;
«Паттерны проектирования на платформе .NET», by Sergey Teplyakov;
«Head First Design Patterns: A Brain-Friendly Guide», by Eric Freeman, Kathy Sierra, Bert Bates, Elisabeth Robson;

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

Условные Петя постиг дзен и понял, что такое DI и зачем оно надо. Условный Вася нихрена не понял что такое DI и до сих пор считает его какой-то бесполезной фигней, зато может привести с полсотни проектов, где оно используется. Потом спрашиваешь таких Вась, «какую пользу принесет DI в таком то случае», а он только глазами блымает и молчит как рыба. Или еще хуже, прийдет это Вася на нормальный проект и скажет «выкинуть DI нафиг — это сейчас не модно!» -
и накроется хороший проект через полгода, если Васю не выгонят. Зато Петя немного подумал и грамотно обосновал что зачем. Вывод — Петя ценнее.

Или еще хуже, прийдет это Вася на нормальный проект и скажет «выкинуть DI нафиг — это сейчас не модно!» -
и накроется хороший проект через полгода, если Васю не выгонят.

Если единственный джуниор решает, выбрасывать DI из проекта или нет, и способен единолично его положить за полгода, то у меня для Вас плохие новости — проект очень далёк от «нормального» и выгонять оттуда нужно чуть менее, чем всех).

джуниор

Нет, конечно же не джун. Ведь он придет на проект уже 21олетним синьором...

Значит, тех. интервьюер допустил фейл, что не спросил про DI, если он используется на проекте. Желательно было ещё в описании к вакансии указывать, что юзается DI — Вася может подумать, что проект его недостоин, и просто не придёт))).

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

То есть, для Вас следующая вереница событий звучит правдоподобно?)

— Вася, у нас на проекте используется DI, расскажите нам, что знаете и с чем сталкивались.
— Бла-бла-бла.
— Молодец, Вася, Вы приняты!
***
— Опа, DI. Фууу... ребята, это же ненужная фигня, давайте уберём её вообще.
— *все шморгнули носами и грустняво опустили головы* — Ну ладно, раз ты так говоришь..
DI выпиливается из проекта, занавес.

Зачем говорить о практически нереальном кейсе?

ну если DI на что-то другое заменить то может быть, а вот в таком виде думаю что нет

ну если DI на что-то другое заменить то может быть, а вот в таком виде думаю что нет

Даже если заменить, вероятность стремится к нулю. Когда ХХХ внедряется на проекте, люди понимают, зачем, и если условный Вася уговорит всю команду, включая вышестоящих сотрудников (которые должны за этим следить), что ХХХ на проекте не нужно, я скорее поверю в то, что оно действительно не нужно, чем что «21-летний синьор» заставил толпу людей сделать какую-то фигню.

Есть в команды, в которых нет синьеров: еле-мидлы или джуны. Например, синьер ушел сплавляться и проект остался без такового :)

Смех-смехом, а у меня на первой работе был супер-тандем «миддл + джуниор». По стечению обстоятельств миддла тоже звали Петя, и он тоже учился сам по книжкам, будучи по образованию математиком))). И мне очень повезло, потому что: 1) мы работали с Петей вместе 2) полная свобода действий давала нам возможность лупить в проекты всё самое новое, совмещая приятное с полезным 3) Петя успел вправить мне мозги, как нужно «готовить» ООП. Потому что когда Петя ушёл, работы стало столько, что новому джуниору я физически не успевал их вправлять, т.к. мы были на разных проектах. И когда уже в другой конторе через год случайно увидел его код с методом на 2 экрана, который сходу уменьшил в 10 раз с помощью LINQ и разбиения на 2 метода... Так что да, бывает.
P.S. Петя, если ты это читаешь, спасибо тебе)).

Так я на полном серьезе и писал :). Сам был в похожей ситуации, но скорее в роли Пети :).

а я сталкивался с таким, когда что-то базовое выпиливается или меняется на аналог, причины были самые разные, как и последствия

Разные-то разные, мы же конкретный случай обсуждаем). Если решения принимаются способом «Давайте» — «Ну ладно, давай» без фактического обсуждения — это очень странно, очень-очень подозрительно и в любом случае не ОК.

А вы можете сказать пользу DI в цифрах?) на какой процент увеличиться ROI за год?

Сначала докажите, что между DI и ROI есть корреляция.

спрашивают джуна подробности механизма сборки мусора

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

З.Ы.: Сам, кстати, не спрашивал, но меня спрашивали часто и на разные позиции. Вопрос как вопрос.

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

Есть опыт участия в собеседованиях не только «у нас». Поделитесь своим. Как понять на сколько хорошо кандидат владеет инсрументом?

Это несколько в другую тему вопрос. На абсолютном большинстве проектов, единственное что надо знать про сборку мусора — это то, что туда лезть не надо. Если у вас проект на C#, который регулярно трогает GC, хоть я и не очень представляю зачем (все эти задачи удобнее решать на С++ ИМХО), тогда конечно, нужно все это спрашивать. А когда у вас очередное формошлепство, то спрашивать GC — это просто показатель, что собеседующий не знает, что бы спросить.

А возвращаясь к вопросу. Опыт во владении инструментом переоценен. Я бы лучше взял в команду джависта, умеющего думать, чем чувака, который прочитал 5 книг по дотнету, но при этом в реальных ситуациях теряется. Овладеть инструментом можно быстро, сформировать мышление быстро нельзя. Как выявить хорошо мыслящего кандидата? Тяжелый вопрос и я не претендую на последнюю инстанцию, я задаю ситуативные вопросы для этого. То есть даже если бы я захотел спросить про GC, я бы задал что-то в духе «Для решения каких реальных задач ты бы обращался к GC».

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

Про джависта, умеющего думать, глупо было бы спорить. Тем не менее это уже не уровень джуна, наверное.

Да, это не везде нужно.

Именно. Если у вас на проекте какие-то знания критичны, конечно их необходимо спросить.

Так же стоит понимать почему не стоит везде реализовывать финализаторы и что с ними делать, если они есть,

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

По вашему мнению dotMemmory, ANTS, memmory profiler etc тоже для прохождения собеседований продают?

щито? Что продают?

Это профилировщики памяти, их используют что бы диагностировать использования памяти .NET приложениями — обычно в них можно получить статистику прироста использования в динамике, статистику по поколениям, использование manged/unmanaged памяти.

Еще раз, я не говорю, что никому не нужно. Но зачем это джуну?

Это несколько в другую тему вопрос. На абсолютном большинстве проектов, единственное что надо знать про сборку мусора — это то, что туда лезть не надо. Если у вас проект на C#, который регулярно трогает GC, хоть я и не очень представляю зачем (все эти задачи удобнее решать на С++ ИМХО), тогда конечно, нужно все это спрашивать. А когда у вас очередное формошлепство, то спрашивать GC — это просто показатель, что собеседующий не знает, что бы спросить.

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

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

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

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

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

любой дотнет проект трогает GC,

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

рано или поздно каждому программисту на дотнете достается задача «а разберись чего память потекла, долго когда работает программа 2гб+ озу начинает занимать» и у тех что не связывает проблему с GC поиски заканчиваются обычно ничем

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

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

В идеальном мире конечно лучше никого, в реальном мире зачастую приходится идти на компромисс

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

Ну если ты не способен задать уточняющие вопросы, позволяющие понять, разбирается человек или нет, то возможно не я тот человек, которому не стоит проводить собеседования)))

Ваши заявления могут сформировать ложное ощущение у начинающих разработчиков, что нет необходимости читать книги, ведь все

ситуативно гуглится

на скорую руку и нет необходимости иметь мало-мальски фундаментальных знаний в чем либо. Поэтому и возникают «вайтивайти» и тд. Посмотрите на курс CS любого из известных универститетов, например, MIT — они там тоже рассказывают студентам, что читать книги вредно и иметь хотя бы минимальный набор знаний в конкретной области бесполезно, потому что есть гугл?

есть разница в том КАКИЕ книги читать, в каком количестве, в каком порядке и с какой пропорцией с практикой. Книги, которые дают необъективные знания, должны восприниматься с определенной долей скепсиса, которой у джуна скорее всего не будет. Я не имею ничего против книг в общем. Я против навязывания огромного бессмысленного списка литературы.

Я против навязывания огромного бессмысленного списка литературы.

никто никому ничего не навязывает. это личное дело каждого, что и когда читать

естественно, личное дело каждого. Но когда синьор говорит, что это must have, то это здорово смахивает именно на навязывание конкретных источников.

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

чтобы вызывать его непосредственно как раз знать как он работает и не обязательно

Ну если ты не способен задать уточняющие вопросы, позволяющие понять, разбирается человек или нет, то возможно не я тот человек, которому не стоит проводить собеседования)))

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

чтобы вызывать его непосредственно как раз знать как он работает и не обязательно

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

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

ОМГ) интересно как он заберет себе инициативу?)) Ну исключая прямое хамство. О чем ты?

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

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

ОМГ) интересно как он заберет себе инициативу?)) Ну исключая прямое хамство. О чем ты?

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

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

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

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

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

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

возможно это бы звучало убедительнее, если бы пару постов назад ты не объявил основы дотнет платформы лишними; а откуда в Украине будут другие проекты, если синьор утреждает что про сборку мусора можно не знать?

Снова-таки это проблема интервьюера, а не интервьюируемого

Именно и от нее нет защиты, а ты говоришь что теорию даже не учите, а потом половина коллег бармены и грузчики

Если у тебя есть проблемы, что у тебя забирают инициативу, то это твои проблемы

Я не собеседую.

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

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

Может стоит тренировать собеседующих, а не пропагандировать дальше дурацкие вопросы?

вот именно

Как бы да. Статья позиционируется для джуниоров, а некоторые советы даются вплоть до синьора без особой градации, что и когда — этот момент упущен, хотя самый важный. Для джуна маст-рид может быть пара-тройка книг, не больше — это же не художественная литература, её на примерах разбирать реально долго). Тем более, в свободное от работы время время. Про паттерны, DI, DDD — он по одной теории нифига не поймёт просто. Две книжки по энтерпрайзу, три по паттернам — зачем?.. По-моему, именно для джуна, который получил какую-то базу в универе, пойдёт:
1) «CLR via C#» как достаточно доходчивое углубление после прохода по верхам в универе.
2) Дальше — паттерны от простых описаний до «Design Patterns: Elements of Reusable Object-Oriented Software» (всё равно пока с нужной проблемой не столкнётся — не поймёт) и unit-тестирование (для начала книги не обязательны — там не такой объём).
3) Дальше — DI (к этому времени уже подберётся к тому, чтобы понимать). Даст возможность посмотреть на эту проблему под другим углом, что полезно.
4) Дальше — по мере надобности: энтерпрайз, DDD, whatever. На этом уровне он уже сам будет смотреть, что нужнее).
Ну и искать контору, где проводят code review — это железнейшее условие (потому что ментора могут пообещать, а он будет всегда занят — как повезёт, нужно узнавать). Без этого так и будете продолжать писать говнокод хоть с сотней книжек, инфа 90% — ничего не работает так же хорошо, как обратная связь после review.

очень похоже что до них просто не донесли, что это для джунов, а не в общем

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

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

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

«Порог входа для овладения стеком .NET выше, чем Веб».
Чего-то я очень сомневаюсь в этом...

Веб это .NET + JS и 100500 его фреймворков + несколько разных БД. Так что вполне логично.
Позиции делятся на Front End и Full Stack.

Так если .NET по вашим словам получается только часть Веб, потому что еще плюс

+ JS и 100500 его фреймворков + несколько разных БД

То как вход в часть может быть сложнее входа в целое?

Согласен. Я там ошибся. Прочитал «выше», а ответил как будто там написано «ниже».

Спасибо, познавательно! Хоть я и не дотнетчик, и не целюсь туда, но даже общие советы довольно годные

Вот на всякий случай советы по другим направлениям:
dou.ua/...​nta/tags/советы сеньоров

и не стоит.. энтерпрайз для старперов) да и ценник там печальнее) Про печаль работы вообще молчу

Подписаться на комментарии