Необходимый минимум знаний у C# junior

Дисклеймер

Вообще, требования для Junior-разработчика имеют неплохой разброс. На это влияют:

• Компания, в которую вы попадете
• Команда, в которую вы попадете
• Проект, в который вы попадете

Требования могут выдвигаться как на уровне компании (например, высшее техническое образование или язык коммуникаций) на уровне команды (возможно, некий специфический опыт), так и на проектном уровне (его технологический стек). Это всё говорит о том, что само понятие Junior весьма субъективно и общих требований здесь быть не может. С одним и тем же техническим бакграундом вы запросто можете устроиться в компанию ASoftware и провалить собеседование в BSoftware. Поэтому, дальнейшие рассуждения о требованиях к Junor-разработчику я буду вести через призму своего опыта и опыта тех команд, в которых я работал (что никак не может являться истиной в последней инстанции. Пожалуйста, понимайте это перед тем, как брать текст ниже за руководство к действию)

Отделить мух от котлет

Мне кажется несколько ошибочным концентрироваться на знаниях конкретных технологий при собеседовании младшего разработчика. Под понятием «конкретные технологии» я имею ввиду знаний конкретных UI-фреймворков, ORM или IoС-контейнеров или ещё сотню библиотек и фреймворков. Мне кажется странным вопрос на собеседовании «Расскажите, как бы вы это сделали на EFramework?»

Мне было бы важнее понять не то, сколько технологий вы знаете сейчас, а то, как быстро вы можете осваивать новые технологии вообще. Поэтому, я бы больше сконцентрировался на знаниях C# и CLR и понимании проблем, которые решают конкретные технологии. Например, если вы в резюме напишете, что знаете, Ninject, то мы с вами, скорее всего, будем разговаривать про DIP в целом и проблемы DI в частности.

Книги по теме:

• Эндрю Троелсен. «Язык программирования C# 6.0 и платформа .NET 4.6»

Для повышения знаний:

• Братья Албахари. «С# 6.0 Справочник Языка»
• Джеффри Рихтер. «CLR via C#»
• Джон Скит. «C# in Depth»

Обеспечить внешнее качество

Минимум, на который рассчитывает среднестатистическая компания (спорный момент, кстати) это возможность продать результат вашего труда и заработать деньги. С этой точки зрения, вы обязаны обеспечивать внешнее качество вашего кода (он работает и решает задачу для которой был написан) для этого вам нужно понимать концепции тестирования и уметь их применять. Вы должны понимать для чего нужны различные типы тестов (модульные/интеграционные/приёмочные) и какое влияние оказывают модульные тесты на код. Одно из требований в нашей команде — код должен быть покрыт тестами. Без выполнения этого требования код не может пройти ревью.

Книги по теме:

• Рой Ошерув. «The Art Of Unit Testing»

Для повышения знаний

• Джерард Месарош. «xUnit Test Patterns: Refactoring Test Code»

Обеспечить внутреннее качество

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

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

Сконцентрируемся на первом пункте. Если вы поняли, то это про ООП и ООД в частности. Минимум, на который нужно рассчитывать — знание принципов ООП (инкапсуляция, наследование, полиморфизм). Особая важность в понимании полиморфизма и умении организовывать логичные и уместные иерархии наследования.

Особый навык, — умение решать проблемы дизайна кода и устранять различные code smells при помощи S.O.L.I.D. Где-то рядом тут пересекаются шаблоны проектирования. Было бы здорово если вы будете знакомы с GoF-паттернами, ну или как-минимум знать по паре самых распространенных на категорию. Но, наверное, это уже не про Junoir'a.

Книги по теме:

• Роберт Мартин. «Чистый код»
• Роберт Мартин. «Принципы, паттерны и методики гибкой разработки на языке C#»
• Сергей Тепляков. «Паттерны проектирования на платформе .NET»

Для повышения знаний

• GoF. «Приемы объектно-ориентированного проектирования»

Основные принципы ООП: инкапсуляция, наследование, полиморфизм http://gos-it.wikia.com/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D0%B5_%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF%D1%8B_%D0%9E%D0%9E%D0%9F:%D0%B8%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F,%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5,_%D0%BF%D0%BE%D0%BB%D0%B8%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC