Final countdown. DevOps Stage 2018. Book your ticket today.
×Закрыть

Как учить .NET: подробная инструкция для новичков и пару советов для опытных

Всем привет. Меня зовут Влад. Я старший .NET разработчик в компании DataArt. В IT я около семи лет, из них больше пяти работаю c .NET. Хочу дать некоторые советы тем, кто только начинает свой путь в IT как разработчик, а также тем, кто уже имеет пару лет опыта. Надеюсь, мое видение кому-то поможет на пути.

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

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

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

Что хотят от джуниора

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

Как ни странно, для начинающего гораздо важнее то, что называют soft skills, и знание английского языка. Но стоит учитывать, что есть вещи, которые можно исправить и которым можно научить, а есть те, которым нельзя. Например, если человек не говорит по-английски, но понимает базовый словарь и грамматику — то научить его разговорному языку — это рискованная затея. Но если джуниор уже немного разговаривает, то натаскать его за полгода вполне реально.

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

Кстати, способность обучаться — тоже немаловажный фактор. Лучше взять специалиста, уже способного к самообучению, чем прививать это. Показателем могут быть, например, домашние поделки на GitHub или даже проекты в продакшене.

Ходит шутка (похожая на правду), что пройти собеседование на джуниора/интерна гораздо сложнее, чем на сеньора :) Так оно и есть. Опытный специалист имеет портфолио/резюме — это уже говорит о том, что он способен приносить результат. Но если человек раньше не работал или работал мало — рекрутеру необходимо только за одно собеседование и, возможно, тестовое задание выяснить все о кандидате.

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

Где выгодны джуниоры

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

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

Первые шаги

Если вы вообще не из IT, у вас нет друзей-разработчиков, нет профильного образования, и вы совершенно ничего не понимаете — можно начать с каких-нибудь курсов. Боюсь, что оставлю сейчас без куска хлеба владельцев инфобизнесов, но в интернете можно найти достаточно бесплатных материалов, например, на торрентах. Но, естественно, я не рекомендую вам скачивать пиратский контент :)

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

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

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

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

Замечу, что любое обучение должно сопровождаться практикой. Будь то самообучение или курсы, вы должны показывать результат. Это может быть макет, если вы учите верстку, веб-приложение или мобильное — не важно. Главное, все, что вы узнаете теоретически, сразу же примените на практике.

Далее я распишу свое видение, с чего лучше начинать и как двигаться дальше в мире .NET разработки.

Hard Skills

Я разделю все сферы знаний hard skills на такие части:

  • C# - синтаксис — это база. Нанимаясь на первую работу, вы должны знать хорошо хотя-бы это.
  • LINQ — расширение C#, фактически его очень важная часть. Сейчас большая часть бизнес-логики пишется именно на нем.
  • .NET — платформа, на которой работает все выше описанное. Понимание базовых вещей убережет вас от часов поиска в Гугле и непонятного для вас поведения проекта, если вы что-то сделали не так.
  • Фреймворки — средства поверх C#, с использованием которых и ведется разработка. Для web — это MVC/WebForms/WebAPI/SignalR, для десктоп — WPF/WinForms. Для веба главное — понимать MVC. WebForms используется реже. Можно также добавить ASP.NET Core и Store App, однако проектов по ним не так много, так что начинать учить MVC — беспроигрышный вариант. Cамый популярный фреймворк для работы с данными — Entity Framework. Де-факто стандарт. Также нужно уметь работать хотя бы с одним IoC-контейнером, например Ninject, понимать, как и зачем работает Dependency Injection и почему слабо связанное приложение лучше поддерживается.
  • SQL — очень часто требуется. Знание SQL — для вас огромный плюс. С .NET приложениями чаще всего используют MS SQL Server и язык запросов T-SQL.
  • Шаблоны проектирования и парадигмы — даже если вы их не понимаете — то заучите. С практикой придет понимание. Шаблон сам по себе — наилучшее, найденное в ходе эволюции миллионов человеко-часов решение какой-то общей проблемы.
  • Архитектурные гайды — лезть в вопросы проектирования поначалу глубоко не стоит. Но понимание, что такое SOA, N-layer, Microservices, поможет вам гораздо быстрее въезжать в суть дела.
  • Базовое понимание Front-end — очень часто от бекенд-девелоперов требуют минимальные знания фронта. Возможно, достаточно JQuery, который используется в достаточном количестве проектов, заходящих в наши аутсорс-компании. Если вы человек с чистым бекенд-профилем, то, может быть, будете более интересны продуктовым компаниям, где множество людей делают большие технологические продукты, но, по-моему мнению, попасть в такую компанию новичку сложнее, нежели в аутсорс.
  • Productivity tools — очень полезно приучать себя работать быстро с самого начала. Потом productivity tools сэкономят вам сотни часов времени, воспринимайте это как инвестицию.
  • Системы контроля версий — средства для организации командной работы. Фрилансерам, которые работают над проектами самостоятельно, они могут быть и не нужны, но в компаниях всегда коллективная работа — там без них никак.

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

Советы для интернов/джуниоров

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

C#

«C# 4.0 The Complete Reference» by Herbert Schildt

Хорошо подойдет для освоения базового синтаксиса самого языка. Лично мне никогда не нравились книги Троелсена, которые рекомендуют новичкам. По моим субъективным ощущениям, там много воды, а вот у Шилдте как раз все по делу и с примерами.

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

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

Методы стандартных библиотек .NET — это энциклопедические знания, и заучивать их тоже по началу не стоит. Это гуглится за пару секунд, и куда более продуктивно будет это делать уже по мере самой работы (учебной, разумеется) над какими-то своими поделками. Так у методов будет свой «вес», и потребность в них. Следовательно, запомнятся они куда лучше.

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

LINQ

«Pro LINQ: Language Integrated Query in C# 2010» by Joseph Rattz, Adam Freeman

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

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

.NET

«CLR via C#» by Jeffrey Richter

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

Я бы дал некоторые советы, как читать эту книгу:

Часть 1 — Основы CLR — очень глубоко вникать не нужно, достаточно понять, что такое:

  • строгие и не строгие имена сборок;
  • что такое CLR, по сути, и как устроена сборка, манифест, метаданные;
  • как запускается CLR через исполняемый файл exe и что еще в нем может содержаться кроме кода вызова;
  • JIT-компиляция и IL код;
  • CTS/CLS;
  • версирование сборок.

Часть 2 — Проектирование типов — эту часть нужно хорошо изучить целиком, важная базовая часть C#/.NET.

Часть 3 — Основные типы данных — заучивать функции работы со строками нет смысла, это все легко гуглится. Особое внимание уделите:

  • главе о делегатах — достаточно полная и базовая информация об этой части языка, понимание Func, Action;
  • что такое StringBuilder, как организованы строки в .NET;
  • интерфейсам ICollection, IEnumerable, IList;
  • Nullable-типам.

Часть 4 — Ключевые механизмы — советую очень хорошо разобрать:

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

Часть 5 — Многопоточность — слишком глубоко вникать, как это работает на уровне ядра ОС, не стоит, но надо понимать общие концепции:

  • про переключения контекста;
  • про то, сколько памяти выделяет поток;
  • что такое Task и как он соотносится с реальным потоком ОС;
  • как работает синхронизация потоков на уровне приложения и ОС.

SQL

«T-SQL Fundamentals» by Itzik Ben-Gan

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

Бонус #2
Дам вам исходный код змейки, которую я написал на T-SQL. Делать такие проекты — очень хороший способ выучить язык лучше.

А теперь челлендж: кто первый напишет тетрис на T-SQL — получит от меня бутылку ирландского виски :)

Frameworks & Tools

«ASP.NET MVC 5» Адама Фримена

Для веб-разработки рекомендую эту книгу. В ней неплохо разобраны базовые возможности ASP.NET MVC, контейнеры управления зависимостями (IoC), основы LINQ, AJAX, JQuery. Есть примеры с кодом, достаточно легко читается.

Также рекомендую очень хорошие сайты-справочники по фреймворкам на платформе .NET — Metanit.com и Professor Web. Есть очень много примеров.

Также неплохой специализированный ресурс по Entity Framework — Entity Framework Tutorial.

Productivity tools

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

Обязательно установите себе ReSharper — лично я не мыслю свою работу без этого дополнения к Visual Studio. Для тех, кто использует Rider, Resharper вообще, как родной.

Если вы используете MS SQL Server Management Studio, то must have расширение — это SQL Hunting Dog. Некое подобие ReSharper’a для более быстрой навигации по сущностям базы и переключения баз.

Если ваша разработка связана с Web — осваивайте Chrome dev tools (F12 tools).

Для 99% случаев отладки кода в браузере их должно хватить. Для более хитрых случаев перехвата и изменения трафика используйте Fiddler.

Шаблоны проектирования и парадигмы

«Паттерны проектирования на платформе .NET» Сергея Теплякова

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

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

Также советую ознакомиться с парадигмами SOLID, главная из которых, я считаю «S» — single responsibility principle. Все остальное уже производное от нее.

Front-end

Я не рекомендую читать самую известную ортодоксальную книгу с носорогом, которая называется «JavaScript: The Definitive Guide» (Подробное руководство) by David Flanagan. Очень академичный стиль изложения, очень много воды и несущественных деталей. Конечно, если вы разработчик front-end фреймворков, то эта книга для вас. Но я все же люблю более практичный подход. Самое лучше, что есть в Рунете по Javascript, это JavaScript.ru и Learn Javascript.ru.

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

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

Осваивать Angular, TypeScript или React вполне возможно на сайтах по официальной документации.

Из того, что мне показалось очень хорошим для вникания в React.js и современную инфраструктуру front-end разработки, это книга «Разработка веб-приложений в ReactJS» А. Хортона и Р. Вайса.

Вспомогательные средства

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

Clip2net — утилита, которая позволяет на ходу дорисовать что-то на скриншоте и тут же его сохранить или отправить.

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

Также есть онлайн-средства для тестирования небольших кусков кода, например, .NET Fiddle, или для регулярных выражений — RegExr.

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

Системы контроля версий

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

Если вы думаете, что работа с git это обязательно заучивание команд командной строки — то это не так. Думаю нет ничего зазорного в том, чтобы использовать визуальные клиенты. Это даже проще с точки зрения разрешения конфликтов или организации работы с большим количеством файлов. Например, мне нравится SourceTree.

Для начала достаточно понимать, что такое Repository, Branch, Pull, Commit, Push, Merge, Stash. Если хотите создать свой приватный репозиторий — можете использовать BitBucket. Если хотите кому-то показать свой код, то удобно будет создать публичный репозиторий на GitHub.

Stack Overflow

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

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

Методологии разработки

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

Недавно IT Ukraine Association выложила документ с набором необходимых навыков для junior-специалистов. В своей учебе можно также ориентироваться на него. Методологии разработки и релиз-менеджмент уже занимают там важное место. Начать изучать Scrum можно прямо с Wiki.

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


Бонус #3
Даю свой список вопросов для подготовки к собеседованиям, который я составил несколько лет назад. Если ответите на все эти вопросы, можно сказать, что вы знаете C#/.NET и Core-библиотеки на уверенном middle-уровне.

Советы для разработчиков Middle/Senior уровня

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

C#

«C# in Depth» by Jon Skeet

Книга Джона Скита, топового комментатора со Stack Overflow. Джон — профессиональный разработчик на Java в Google, но это не помешало ему написать бестселлер про тонкости синтаксиса C#.

Очень детально разбираются нюансы синтаксиса, разница в поведении в разных версиях .NET фреймворка и просто легко читается. Если Рихтер — больше о .NET, то эта книга именно о тонкостях C# и об эволюции этих языковых средств.

T-SQL

«Querying Microsoft SQL Server 2012» by Dejan Sarka

Книга по подготовке к экзамену 70-461 от «Майкрософт». Более структурного и внятного справочника по T-SQL я не находил. Темы очень четко разделены между собой, много наглядных примеров, даются все тонкости синтаксиса T-SQL. По сути, больше, чем в этой книге .NET разработчику, если он не является профессиональным Database developer’ом, знать и не нужно.

Архитектура

«Patterns of Enterprise Application Architecture» by Martin Fowler

Эта книга — отправная точка в изучении архитектуры корпоративных приложений. В ней достаточное количество рассмотренных фундаментальных средств и понятий.

«Enterprise Application Architecture with .NET Core» by Ganesan Senthilvel

Книжка дает понимание о современных течениях в архитектурах, раскрывает понятия CQRS, DDD. Полезна для саморазвития. Читать ее или не читать — решать вам. Такие подходы вы увидите не в каждом проекте, но важно уметь оперировать категориями и шаблонами, описанными там.

«Refactoring: Improving the Design of Existing Code» by Martin Fowler

Книжка Мартина Фаулера. Дается очень глубокий аналитический подход по рефакторингу и улучшению существующего кода.

Фреймворки

Если вас беспокоят вопросы производительности в старом-легаси проекте, а переписывать на чистый SQL вы не хотите — рекомендую гайд «Performance Considerations for EF 4, 5, and 6»

На Entity Framework можно писать достаточно производительный код, не прибегая к помощи Dapper’a или чистого ADO.NET, либо же переписывать уже существующий, оптимизируя его.

Также несколько книжек по более детальному разбору возможностей Entity Framework и производительности:

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

Обзор Open-source проектов

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

И еще можете глянуть самый знаменитый .NET Open-source E-commerce движок.

Нужны ли сертификаты от Microsoft?

Решать вам, в этом вопросе я не специалист. Однако скажу свое мнение.

Pros:

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

Могу отметить пособие по подготовке к экзамену 70-461 как отличный учебник, да и вообще пособия для сдачи экзаменов по базам данных — чудесные учебные материалы.

Cons:

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

Куда расти дальше

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

Могу посоветовать читать книги для общего развития, а также развития навыков в смежных специализациях. Например, по методологии проектирования UI можно ознакомиться с книгой проектировщика Apple — Джефа Раскина «Интерфейс. Новые направления в проектировании компьютерных систем».

Или же выбирайте базовые книги по проектному менеджменту: «Мифический человеко-месяц, или Как создаются программные системы» Фредерика Брукса.

Более академическая литература по проектному менеджменту — «Руководство к своду знаний по управлению проектами».

Или же можете записаться на курсы Stratoplan. Сам просмотрел пару штук, улучшил понимание процессов и людей в них. О «Стратоплане» как о курсах для менеджеров слышу только позитивные отзывы.

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

Ответы на популярные вопросы

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

Нужна ли программисту математика и алгоритмы?

Бывает по-разному. В программировании есть типичные задачи, решаемые типичными методами. Эти методы и можно назвать алгоритмами. Почти всегда все алгоритмические задачи так или иначе решены уже в каких-то библиотеках от сторонних производителей, и разработчикам остается только лишь использовать их. Так происходит в 99% случаев.

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

Для входа в IT, думаю, с головой достаточно понимать:

  • алгоритмы сортировки массивов (пузырек, слияние, quicksort);
  • алгоритмы обхода бинарных деревьев в ширину и глубину;
  • «О» большое и «о» малое, или временная сложность алгоритма;
  • базовые структуры данных (стек, очередь, лист, дерево, хештейбл) и временные сложности поиска и добавления новых элементов в них.

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

И несколько холиварных вопросов :)

Что лучше — Java или C#?

В мире разработки есть более или менее уместные средства решить задачу, в том числе важный фактор — возможность найти людей, знающих технологию, и их цена. Однозначного ответа нет. На Java больше open-source, в C# более модерновый синтаксис. Java хостится на Linux, C# требует Windows, хотя .NET Core разворачивается на Linux, что делает его хорошим выбором для микросервисов под бесплатными системами управления базами данных, например PostgreSQL или MongoDB. У всех технологий есть плюсы и минусы. Все зависит от конкретной задачи.

Ставить или нет нижнее подчеркивание для приватных членов класса?

Как хотите :) Однако если весь проект написан в едином стиле, его проще читать, и члены команды привыкают читать код быстрее. «C# Coding Conventions (C# Programming Guide)» — кое-что описано тут. Можно использовать StyleCop и блокировать компиляцию проекта в случае несоответствия форматированию. В целом стандартизация повышает скорость и понятность.

Что лучше — SQL или NoSQL базы данных?

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


Зачем эти вопросы? Своими ответами я хотел показать свое отношение к технологиям и разработке в целом. Не важно, каким молотком ты забьешь гвоздь. Важен факт забития гвоздя под нужды клиента, учитывая его потребности и возможные риски. Остальное — детали, которые ему, по сути, и не нужны.

Вот и все, если захотите со мной связаться, можете писать прямо на Facebook — Vladislav Furdak.

LinkedIn

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

Завтра ищешь в интернете книжку CLR via C#. По*** если ничего не поймешь. Затем идешь на msdn.microsoft.com и изучаешь FCL от корки до корки. Потом зубришь, именно, с**а, вызубриваешь C# 7.0 и ASP.NET Core Recipes, чтобы от зубов отскакивало. Когда напишешь свой первый форум на Kestrel, по пути изучив .Net Core, устанавливаешь и изучаешь любую ORM, рекомендую Entity Framework или NHibernate. Когда переделаешь форум, как минимум с REST’а на веб-сокеты, можешь идти дальше — тебя ждет увлекательный мир корпоративного легаси кода. Монструозные сайты на вебформах, сверхбыстрый SignalR, Razor’овские серверные страницы вперемешку с кодом на AngularJS 1.x и т.д. Отсос джава-петухов / просто неудачников типа кресто**ов или джаваскрипт-макак, которые сосут *** по жизни не заставит себя ждать и уже через год жепной боли ты будешь писать такие LINQ-запросы, что любой сервак будет о***вать при любом обращении к базе.

123 комментария

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

Неясен посыл от «классификации методов LINQ». Intellisense прекрасно в этом помогает,
одной стороны. А с другой, там нет самых интересных деталей. Например, метод All возвращает True если все элементы коллекции удоволетворяют условие ИЛИ коллекия пуста. Это очень важно! :)

А в общем спасибо за статью! Все очень хорошо расписано!


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

Junior должен знать все.
Middle должен уметь нагуглить то, что знает Junior.
Senior должен знать где сидят Junior и Middle.

Завтра ищешь в интернете книжку CLR via C#. По*** если ничего не поймешь. Затем идешь на msdn.microsoft.com и изучаешь FCL от корки до корки. Потом зубришь, именно, с**а, вызубриваешь C# 7.0 и ASP.NET Core Recipes, чтобы от зубов отскакивало. Когда напишешь свой первый форум на Kestrel, по пути изучив .Net Core, устанавливаешь и изучаешь любую ORM, рекомендую Entity Framework или NHibernate. Когда переделаешь форум, как минимум с REST’а на веб-сокеты, можешь идти дальше — тебя ждет увлекательный мир корпоративного легаси кода. Монструозные сайты на вебформах, сверхбыстрый SignalR, Razor’овские серверные страницы вперемешку с кодом на AngularJS 1.x и т.д. Отсос джава-петухов / просто неудачников типа кресто**ов или джаваскрипт-макак, которые сосут *** по жизни не заставит себя ждать и уже через год жепной боли ты будешь писать такие LINQ-запросы, что любой сервак будет о***вать при любом обращении к базе.

жаль тут нет смайлика посмеяться как на фейсбуке)

На: 🤣. Win + . на венде 10 в английкой раскладке.

Пичалька, браузер не умеет emoji. Это какой-то консольный браузер, что ли?

😀 😁 😂 😃 😄 😅 😆 😇 😈 😉 😊 😋 😌 😍 😎 😏
😐 😑 😒 😓 😔 😕 😖 😗 😘 😙 😚 😛 😜 😝 😞 😟
😠 😡 😢 😣 😤 😥 😦 😧 😨 😩 😪 😫 😬 😭 😮 😯
😰 😱 😲 😳 😴 😵 😶 😷 😸 😹 😺 😻 😼 😽 😾 😿

Все может, вы какой-то неправильный код вставили.

Да, может, не все поддерживаются. А что за винда?

Возможно, там нет этого шрифта. У меня 10.

Хз, у меня норм отобразился смайл.

Я ж джва года ждал этой пасты!

Хотелось бы добавить по поводу курсов. Я думаю, что лучше всего идти на курсы при компаниях. Это подтверждается опытом пары моих друзей из универа на старте, хотя и не на .NET (один — Embedded и Global Logic, другой — Java и Nix Solutions, но суть дела не меняет). Нужно пойти туда и проявиться, это прямая возможность познакомиться с людьми из компании и потом попасть туда на работу.

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

Есть какие-то исследования подтверждающие это? Мой непосредственный опыт говорит прямо об обратном.

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

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

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

Мердж — умение из двух версий файла сделать третью. При конфликтах это просто делается даже через notepad++, я больше говорю о больших энерпрайзах, там почти после каждого коммита придется делать мердж.

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

Надо валить! (к) (тм)

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

>>Как ни странно, для начинающего гораздо важнее то, что называют soft skills, и знание английского языка.
Ця фраза вже настільки задовбала, та вам треба гуманітаріїв чи кого, я будучу джунум в день з сеньйорами говорив 1-2 слова, сам сидиш і розбираєшся, а англійської треба щоб міг читати книжки і гуглити, говорити з замовником джуніору не потрібно. Та й взагалі ця фішка чисто аутсорсинга.

З власного досвіду можу сказати працював я перший рік в ЕПАМі не пустили на один проект через слабку англійську, потім через 3 місяці працював напряму віддалено на американський стартап, де я один був з України, та приходилось обходитись yes or no, але нічого робота йшла досить таки продуктивно:)

Але за статтю +, пишіть дальше, може комусь допоможе) Просто поняття софт скіллів і англійської для джуніора переоцінено, хоча його звісно тоді можна показувати у вебкамері та казати дивись який хороший)))

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

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

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

В конец-концов я давал рекомендации для людей которые хотят 100% найти работу.
Посмотрите на это глазами бизнеса.

Посмотрите на это глазами бизнеса.

Именно!

Правильно пишете, англійська у індусів краща, а експертиза джуніора нікому не цікава, тому на нього не варто витрачати час замовника :)

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

Все равно ума не приложу, что можно, кастомеру или ПМ, обсуждать часами с джуном, на английском.

В 99.99% случаев, задачу ему ставит местный спец, и контролирует работу тоже он.

В 89.99% случаев иностранная сторона с джунами никак по проекту не пересекается.

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

тем самым экономя время локальных менеджеров и тимлидов.

Джуны.

Всё чудесатей и чудесатей). Со старта пишут тесты, мерджат чужие ветки, а теперь ещё и занимаются менеджерскими задачами.

А в чем проблема позвонить уточнить задачу с человеком со стороны клиента? Джун или не джун.

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

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

Учитывая сакраментальное

тем самым экономя время локальных менеджеров и тимлидов.

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

Я имел ввиду свои ветки, ведь на больших проектах все работают в своих ветках, потом сливают в общую для текущего релиза, бывают конфликты.Я о проектах, где в солюшене по 50-60 проектов и EDMX модели на 20к строк.

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

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

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

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

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

Мало того, что никогда с таким не сталкивался, но и не вижу смысла в этом.
Ну вот просто подумать, есть тим-лид, в Украине, который стоит дорого.
У него в подчинениие 5 жунов, которые стоят ... копейки.
Есть абстрактный менеджер/аналитик из долины , время кторого стоит ооооочень дорого.

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

А тратить время

бизнес-аналитика

, 1 час которого стоит 500+ баков, на вдалбывание какдому джуну каки то ньюансов проекта, это уж слишком...

Ну это лично мое мнение, а там уж датаАрту виднее...

Не думали, просто что у нас джуны хорошие ?

в условиях текущего рынка это маловероятно.

Дело в том, что мы берем не с рынка. А сами выращиваем.

Я как дотнетчик не соглашусь с некоторыми советами.

Я новичкам рекомендую научиться писать console apps / web api на .net core и запускать их в docker container в любом клауде. Остальное можно выучить по ходу. Большинство из упомянутого в статье безнадежно устарело. Например LINQ & EntityFramework — мусор и вчерашний день. На серьезных проектах (с кучей таблиц или с хайлоадом) от них только проблемы. Если работать с SQL базами, тогда лучше что-то простое типа Dapper.NET.

LINQ ... — мусор и вчерашний день

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

linq2sql

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

Вот буквально вчера решал проблему на продакшене — престал работать один из сервисов. Причина — довольно простой linq запрос падал с OutOfMemoryException при агрегации данных из массива. Конечно же это чужой код, который долго работал пока не выросли объемы данных и в котором никто ничего не может понять. Я считаю что LINQ — это для тех, кто не научился циклы нормальные писать

LINQ — расширение C#, фактически его очень важная часть. Сейчас большая часть бизнес-логики пишется именно на нем.

Бизнес-логика на LINQ = говно и палки

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

Причина — довольно простой linq запрос падал с OutOfMemoryException при агрегации данных из массива. Конечно же это чужой код, который долго работал пока не выросли объемы данных и в котором никто ничего не может понять. Я считаю что LINQ — это для тех, кто не научился циклы нормальные писать

проблема вовсе не в линке, тот крендель что ее наваял в циклах бы еще больше набокопорил, проблема в нем

Це все тому що EF тихенько агрегує дані на клієнті, тому що не справився з LINQ запитом За це «рішення» я б голову відкрутив.

Скажите, вы бы пустили джунов на проекты с нуля? Я бы тоже не пустил, следовательно их стаффят на саппорт. Но на саппорте проекты 5-10 летней давности обычно

Например LINQ & EntityFramework — мусор и вчерашний день. На серьезных проектах

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

Если вы про аутсорсинг в Украине, тогда я согласен. Если про айти в целом — у нас в компании (и много где еще) толковые джуны пишут отличный код с тестами, докером и прочими приколами.

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

Владислав, я считаю что вы хорошо статью начали с

Как ни странно, для начинающего гораздо важнее то, что называют soft skills, и знание английского языка.

Но LINQ & EntityFramework это имхо примерно как знание Windows Forms — в принципе не мешает, но не является ключевым скилом, тем более для джуна

Ключевой навык — хорошее знание синтаксиса C#

Серьезные проекты с докером? Лол. Если там есть докер это и близко не значит что они вообще чём-то лучше кровавого Энтерпрайз на веб формах. Наоборот уровень на таких проектах как правило весьма бестолковый. Заканчивается все это тем , что в докере гоняют тесты, или ещё лучше ставят kuber на одну ноду on-premise железяку тли вовсе на проде через docker-compose запускают :facepalm:. Локальный девелопмент делать не могут потому, что оказалось, что ребилднуть контейнер в разы медленней чем пересобрать код локально. Использовать контейнеры для .net где build image донедавнего .net core времени по 2 гига весили это вообще отдельная песня. Хотя есть и упоротые персонажи, которые все это делают что бы рассказать на доу как они на контейнерах хостят веб сайты на net core. Как правило джуны с лыками тл и берут контейнеры на свои проекты. Так что джуны и контейнеры это норм связка

На Dapper переходять піся того як обломились з «супер популярним» фреймворком.
Після цього їм і в голову не приходить щось писати на linq. Хоча існують набагато просунутіші рішення які, навідь пресловутий Dapper, взувають по швидкості, хоч він і простенький маппер.
LINQ дуже непогано продумана технологія і, ящо її погано підтримують виробники провайдерів, то це лише їх заслуга.
Для себе багато років назад знайшов github.com/linq2db/linq2db і ні разу не пошкодував.

До речі, для тих хто застряг на EF Core і вже почав писати SQL ручками, або чіпляти Dapper: github.com/...​nq2db.EntityFrameworkCore

Блин только хотел поблагодарить за SQL Hunting Dog, а оказалось он в MS SQL Server Management Studio 2016 не работает :( Но все равно статья отличная, спасибо!

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

увы, но ты добавил такие же советы как и другие

Видимо они верные, плюс бонусы, а как ты видишь данную тему ? Что бы добавил/убрал ?

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

Согласен! Я это не указал в статье — что я дают диапазон от интерна и до стронг джуна, даже в минимуме можно потеряться изучая его слишком глубоко.

А що сіньор має знати, якщо ваш той джун знає мову, платформу, ріхтера читав, орієнтується в базових класах, фреймворк шарить, фронтенд трохи, сіквел запроси пише, про алгоритми і комплексіті чув ?
Воно йому то треба, ваш датаарт ? Подрочить кілька місяців лееткоде в гугль :)

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

Згоден, ІМХО автор трохи «перегнул палку». Я думаю, що краще навіть і не намагатися попасти в ДатаАрт (говорю за себе особисто :) )

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

А на интерна у Вас такие же требования? :) (они не выдуманы, взяты с реальной вакансии интерна одной компании — не, это не гуГль :))

Required skills
• Excellent C# and .NET Frameworks 4.6 skills
• Strong experience with RESTful services
• Solid knowledge of Web Api 2.0
• Strong knowledge of OOD, OOP and Domain Driven Design
• Strong analytical skills
• Good understanding of MicroServices
• Good knowledge of Git
• Experience with unit testing; practice of writing testable code
• Experience with writing integration test for REST services
• Good communication skills
• Good TDD skills

As a plus
• Experience with SSO(SAML) and IdentityServer
• Experience with OWIN
• MSSQL, MongoDb
• Basic knowledge of AWS services (S3, RDS, LB)
• RabbitMq, MassTransit
• Jira, Confluence, Jenkins — GitLab
• Release & Configuration management
• DevOps related experience
• Knowledge in financial/banking domain

Особенно доставляют отметки: Excellent, Strong и Experience. :) У интерна то? :))))
А венцом всего этого главная отметка: looking for intern .NET :)))))

уже лучше так писать в вакансии: strong++++++++++ intern (главное не в коем случае не джун (что бы денег вообще не платить и тем более не мидл:)) ;)

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

Ну, если это так — снимаю шапку :) Но знаете, когда я ходил на собеседование в одну из компаний, там так же стояли требования: basic C# and basic SQL. Когда мы углубились в ASP.NET MVC and Core я понял, что здесь что-то не то и меня эээ... обманули по требованиям:)

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

Я так и ответил.:) Хотя я немного работал с этими технологиями — учу еще просто их — мне очень нравится Web. Но результат собеседования я думаю Вы уже догадались какой был :)

вброс засчитан

jobs.dou.ua/...​oftserve/vacancies/38673

тут люди гуглить умеют, если что

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

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

Якщо linq запити транслюються один в один в SQL, не бачу тут проблем. Джуна звичайно на таке посадити, що дати неконтрольований всемогутор. Робота робиться, сервер лягає в ступор через пів року набивання даними.
Без знання SQL підпускати девелопера до баз даних — собі/їм дорожче.

Вам бы было интересно почитать подробный мануал, как правильно писать на Entity Framework, чтобы не ложить сервер и транслировать в SQL без излишеств ?

Я вважаю що EF придумали люди далекі від реальної роботи з базами даних і хотів би щоб це зрозуміли раніше ніж читали статейки про те що джуніку треба знати.
І я ні в якому разі не апелюю за EF — це зразу не правильно. Починаючи з Code First продовжуючи з Lazy Loading, умовно зручним Eager Loading і закінчуючи Change Tracker.

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

Я спрашиваю о том — если я напишу мануал как писать на EF так, чтобы не терялась скорость, например, был бы такой материал востребован?
Понимая как EF проводит сериализацию/кеширование запросов можно добиться повышения производительности.

От коли починають казати що EF дозволяє писати більш високорівневий код я плачу.
Так він це дозволяє але якими потім прогинами в самій роботі сервера:
1. Щоб щось апдейтнути — треба тягнути дані з сервера, дай боже сил тому серверу при нагрузці (так я знаю способи без цього)
2. Bulk операцій тупо немає. На кого ця х..нь розрахована?
3. Все завязано на Change Tracker — і його блін всюди прокидують і дуууже часто забувають що він існує, нічого памяті докупим.
4. Підтримується з коробки тільки SQL Server 2008 (дуже мило, це дійсно профіт) та SQLite, інші провайдери дані в опенсорс і дай боже вони ще живі і розробники мають необхідну кваліфікацію.
5. Без Code First з базою практично неможливо працювати, на реальних базах Scaffolding це біль між сідницями.

Мануал пишіть, це остужує мозок фонатів. Як приклад скину мою переписку в тому ж EF Core репозитрії github.com/...​15#issuecomment-396366301
Хомячки навіть не знають на що підписались, дуже знакова була реакція на client evaluation.

2. Есть дополнения для этого
3. Можно отключить
5. А больше и не надо

Вот тут начало
msdn.microsoft.com/...​y/hh949853(v=vs.113).aspx
Но эта тема куда шире.

По опыту — ну ок, EF не совсем для перфоманса, но я не представляю более простого инструмента для корпоративных приложений, где фактор скорости не решает, но все же есть разница 2 секунды или 10 для тяжелых запросов.

2 — так я бачив то Г. Zzz projects? Якщо б ви удосужились глянути на той код ви навідь би не заікались про ті розширення.
3 — можна, але то відключають коли пару сотень кілобаксів втратять.
5 — а от це дурня. Хоча, якщо ви пишете лише для дядьок в ентерпрайзі може проканати.

Людина яка не зрозуміла як писати SQL поза ентерпрайзом, просто немічна. І це основне в чому я притикаю EF — він вчить рішенням які далекі від оптимальних. За роки зявляються навики далекі від реальності і скіли програміста нівелюються до нуля.

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

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

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

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

Я спрашиваю о том — если я напишу мануал как писать на EF так, чтобы не терялась скорость, например, был бы такой материал востребован?

Владислав, предлагаю провести открытый вебинар по этой теме на YouTube канале ITVDN (125 тыс подписчиков). Там и с оппонентами можно будет пообщаться в прямом эфире )

А от я якраз часто думаю написати мануал чому не варто використовувати EF, точніше ORM з ченж трекером ;)
Будем думати далі ))

Святославе, і Вас запрошую на наш канал ) Мануали для слабаків ) виходьте в прямий ефір і переконайте аудиторію!

Фраза «устроится на сеньора/мидла легче, чем на джуна» повергла в легкий ступор. Но я пожалуй соглашусь. Не добавляет конечно оптимизма, но уже как есть :)

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

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

Но это не повод требовать от джуна все и сразу да еще и за 100-300 баксов. Как раз и возникает та проблема: нехватка сеньоров — избыток джунов. Замкнутый круг — Вы не находите? Так может стоит хоть немного обучить джунов (которые как минимум станут мидл через некоторое время), а не требовать от них с небольшим перебором при входе? Избавиться то «неправильного/ленивого/бесперспективного» джуна можно очень быстро — Вы же сами сказали :). Но дать шанс ему проявить себя в реальной работе (а не на всегда адекватном собеседовании) , в команде — было бы логичней в данной ситуации. ИМХО.

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

Владислав, давайте на чистоту: все то, что Вы здесь очертили, (с пометкой на будущее) Вы однозначно спросите на собеседовании. :)

Спрошу, если понадобится, почему бы и нет ? Вообще собеседования такая вещь, что невозможно определить как человек будет работать, можно только определить
1) набор теоретических знаний
2) что человек делал (опыт), можно проверить задавая наводящие вопроы
3) примеры тестовых заданий и проектов на гитхабе
4) общее субъективное впечатление о человеке, интуиция
5) Мотивация, готов ли человек развиваться или обманывает

Если бы я собеседовал — то шел по этим пяти направлениям. Мне кажется это был бы честный подход. Эти пять пунктов дадут некую вероятность сделать адекватный вывод о человеке как специалисте, далее из всех соискателей выбирается наиболее уместный/сильный под позицию. Но опять-таки на 100% выбрать человека и сказать что он будет идеальным работником на позиции нельзя.

если вам 65 — создайте скайп ForeverYoung и не парьтесь о возрасте — и все будет хорошо :))

Тогда не о чем париться :) Просто так вышло что рост рынка пришелся на года выпусков и наймов большого количества людей лет 5 назад, вот и имеем средний возраст 26-27 лет.

Спасибо:) Жаль, что Вы в Днепре :)

А вы к нам хотите работать ? Наши офисы везде есть))

Ну я нахожусь в поиске своего места под Солнцем :) Я (как это принято сейчас модно говорить) свичер/кандидат на джуна/интерна:) Хожу по собеседованиям — пытаюсь впарить пылес... :))))))))))....ээээ... трудоустроится и сменить профессию на то, что очень нравится.

Но судя по Вашим требованиям (даже с учетом на будущее), а так же отзывам о Вашей компании (на этом же сайте) шансов крайне мало:)))) Так что, Ваш вопрос скорее риторический:)

Развивайтесь, читайте, устроитесь вы или нет — это все равно неизбежно. Это все равно придется сделать, но сделая это сейчас вы повышаете шансы.

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

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

Джуниор не означает — не умеет программировать и не знает технологий, но тоже хочет зп в долларах.

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

Очень круто, было бы полезно статью по Front-end сделать в особенности с таким же документом вопросов

Что значит «Обязательно установите себе ReSharper»? Триал дается на месяц, а купить его джуну будет не по карману. Надеюсь Вы не пиратство пропагандируете? ;)

;) Нет конечно. Хотя мы прекрасно понимаем наш менталитет по отношению к покупке ПО)
Кстати, говорят в новой студии можно обойтись и без Решарпера

В 17-й студии конечно многое уже есть. Но вот простейшего Introduce variable так и не завезли :)

В Rider тоже можно без решарпера =) Если человек может написать код в блокноте и скомпилить его, а потом запустить — на джуна потянет

Джун это тот, кто уже в состоянии решать мелкие задачи, все равно знание IDE нужны.

Что значит "Обязательно установите себе ReSharper"?

Я относительно недавно узнал, что есть люди, которые не пользуются R#. Пользуйтесь by all means. А лучше Rider.

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

Ну то есть каждый джун реально считает, что без R# жизни нет, а потом как-то выясняется, что всё полезное есть в студии и так, а фокусы «мы сейчас foreach комбинацией клавиш»... ну да, это именно фокусы, основной практический смысл впечатлять неокрепшие умы юниорш. :)

Я совершенно не против Решарпера, но эти «обязательно и без него никак» отдают сектанством и приветом из какого-нибуть 2002 года

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

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

что всё полезное есть в студии и так

Отчасти правда для VS 2017 в которую добавиляют фичи, которые уже годами есть в R#.

сновной практический смысл впечатлять неокрепшие умы юниорш

Неокрепшие умы в моей команде вручную объявляют приватные поля для параметров конструктора и присваивают им значения из значений параметров. В R# - это одна команда чтобы сгенерить все поля и присвоить все значения. И таких примеров множество (непустое, очевидно 😉).

Я совершенно не против Решарпера

А пользовались им на достаточно профессиональном уровне?

ЗЫ: Одна значительная польза R# - он помогает изучать новые фичи языка и помогает учиться писать код оптимальнее.

а купить его джуну будет не по карману

Если рассматривать как инвестицию в себя сразу станет по карману.

Проходил курсы на Stepik, получил триал на 3-и месяца.

Есть помесячная подписка. $13 в месяц кажется.

jQuery тока выкинуть нах, и заменить на Angular

Увы, в мире .NET разработки очень много проектов, где на фронте JQuery, а джуну чтобы найти первую работу, достаточно будет и JQuery. А так я всеми душевными порывами с тобой, нах JQuery, Ангуляр рулит )

Angular тоже заменить 😊. Потестил компоненты немного и больше к нему возвращаться не хочется.

Ахах) Ну фронт-ендерам не угодишь) Вроде Vue сейчас тренд

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