Обобщенный паттерн Репозиторий Чтобы избежать недоразумений, давайте для начала проясним, что здесь имеется ввиду под понятием обобщенного репозитория. Видели ли вы когда-нибудь интерфейс вроде этого: Или может вы видели его брата-близнеца, который имеет иной вариант метода Get: Вдохновение для написания первого примера пришло из официальной документации Microsoft для ASP.NET MVC 4. Что же касательно второго примера, в Интернете вы можете найти бесконечное число блогов, описывающих именно этот вариант написания репозитория — иногда лишь с небольшими отличиями в виде возвращения IEnumerable<TEntity> вместо IQueryable<TEntity>. И в последнем случае часто еще и с дополнительным методом для генерации запросов. Что-то вроде этого: Так что плохого в них, вы можете спросить? Почти ничего, если не считать плохое именование методов из примера Microsoft (здесь лучше было бы использовать Find и FindAll вместо Get и GetAll). Но «почти ничего» - это далеко не то же самое, что «ничего». Первую проблему, которую я здесь вижу, так это нарушение Принципа Сегрегации Интерфейсов (Interface Segregation Principle). Они выражают полный набор CRUD-операций даже для тех сущностей, для которых операции удаления не имеют никакого смысла (к примеру, когда вы деактивируете пользователей вместо удаления их записей из базы данных). Но эта проблема может быть решена при помощи просто разбиения на три интерфейса — для чтения, обновления и удаления записей. Реальная проблема, которую мы здесь имеем, заключается в некорректном использовании. Оригинальная идея заключается в том, что интерфейсы должны быть использованы в качестве базовых для ваших пользовательских интерфейсов. Что-то вроде этого: Ваши обработчики событий и сервисы (клиенты пользовательских репозиториев) должны сами определять нужные методы и помещать их в пользовательские интерфейсы. Это в теории. К сожалению, за свою карьеру мне довольно часто приходилось видеть несколько иную картину: Кто-то создал рабочую реализацию IGenericRepository. Что хуже в этой реализации, так это то, что эта имплементация почти всегда регистрируется в IoC-контейнере и может быть внедрена в ваши обработчики команд и сервисы точно так же, как и любая другая зависимость. Код выглядит достаточно красиво и чисто. На самом деле — нет. Почему именно так — скажу немного позже. Теперь же я бы хотел поговорить об одном из решений неправильной интерпретации GenericRepository<T> многих разработчиков. Само решение выглядит примерно так (диалог на code-review): Джим Сеньор: вы когда-либо слышали, что NHibernate ISession или DbSet из Entity Framework на самом деле репозитории? А то, что вы только что создали — всего лишь небольшая обертка над ISession или DbSet? Де-факто, мы можем отказаться от этого обобщенного репозитория и просто использовать DbSet — результат будет аналогичным. Единственное, в чем IGenericRepository<T> действительно полезен — так это в том, что он скрывает большую часть ненужных для нас методов, которыми обладает DbSet. Джонни Джуниор: да, в этом действительно есть смысл. Я полагаю, использование обобщенного репозитория в нашем случае было лишним (счастливо возвращаемся к написанию программы…) Как по мне, что GenericRepository<T>, что DbSet – в большинстве ситуаций их использование лишнее (ну разве что вы пишите наиболее заCRUDженное приложение в своей жизни). Почему? Вот почему: Единственный способ убедиться, что все LINQ-запросы будут верно преобразованы в SQL — это протестировать их на том же типе базы данных, что находятся в продакшине. Кроме того, в таком случае задача написания интеграционных тестов становится достаточно затруднительной. К примеру, взглянем на код: Чтобы выполнить эти запросы, должны быть соблюдены два условия. За счет этого интеграционный тест становится менее читабельным. Теперь же давайте представим, что этот метод помещен в метод репозитория. Теперь в тесте нам нужно просто вызвать метод репозитория и проверить результат — просто, не так ли? Я уверен, вы согласитесь, что LINQ-предикаты внутри сервисов нельзя использовать повторно и они имеют плохую тенденцию повторяться на протяжении всего кода. Даже если программист желает извлечь запрос в свой собственный метод, обычно это будет приватный метод конкретного сервиса. Инкапсуляция запросов внутри методов репозитория приведет к большей читабельности кода и в значительной мере упростить его использование. LINQ-предикаты не именуются. Как правило, единственный способ узнать, что же, собственно говоря, делает наш запрос (без углубления в его логику), так это имя переменной-результата. К сожалению, искусство информативного именования переменных постигается с опытом, а поскольку в нашей индустрии полно начинающих программистов, мы имеем дело с переменными вроде result, ordersToProcess или просто — orders. Создавая обертку над запросами в виде метода репозитория, это автоматически обязывает разработчика дать этому самому методу конкретное имя. Даже если это имя не из лучших, в последствии провести небольшой рефакторинг не составит труда! Порой, по причине скорости, мы вынуждены доставать данные из базы посредством чистого SQL. Подумайте, вы действительно хотите в своей бизнес-логике работать с такими низкоуровневыми сущностями, как DbConnection или SqlException? Подобный код лучше прятать за методами репозиториями.   Никаких обобщений — только конкретные репозитории   Перед тем как начать разработку репозитория, необходимо определить его интерфейс. Интерфейс должен содержать только те методы, которые нужны конечным клиентам. Другими словами, если никому не нужно удалять сущности данного типа, нет никакого смысла в написании функционала для их удаления. Если вы боитесь закончить среди разных имен для базовых CRUD-операций — таких как Delete в одном репозитории и Remove в другом — вы можете создать полезные интерфейсы типа ICanDeleteEntity<TEntity>, ICanUpdateEntity<TEntity> и так далее. В таком случае конкретный репозиторий будет реализовывать только действительно нужные из них. Ни один из методов репозитория не должен возвращать IQueryable<T>. Также убедитесь, что репозиторий не возвращает IQueryable<T>, скрытые за IEnumerable<T>. Всегда вызывайте ToList() или ToArray() дабы «материализовать» значения, придав им более конкретный тип данных. Как только заходит речь о реализации репозитория, вы можете наследовать абстрактный класс GenericRepository<TEntity>. Если угодно — можно также использовать напрямую ISession и DbSet. Не важно, какой подход вы выбираете. Помните: любые «лишние» в данном контексте методы — по типу Delete из базового класса — будут скрыты за интерфейсом репозитория. Также не забывайте, что ваш репозиторий не несет ответственности за транзакции базы данных. Лучше всего эта концепция реализуется при помощи паттерна Unit Of Work. Этот паттерн уже реализован в рамках ISession и DatabaseContext. Все, что нам нужно — это хороший интерфейс над ними: Для большинства веб-приложений чтобы начать транзакцию через IUnitOfWork в виде начала запроса и Commit / Rollback в конце запроса — этого функционала вполне достаточно. Так же подобное может быть достигнуто при помощи фильтров действий или декораторов обработчиков / сервисов. Пример репозитория, созданного при соблюдении всех приведенных рекомендаций:   Сейчас все стало ясно, но давайте еще раз проясним. Каждый метод наших репозиториев должен быть учтен по крайней мере одним интеграционным тестом, который должен использовать тот же тип базы данных, что и продакшн. Всегда используйте интеграционные тесты для проверки своих репозиториев. Немного о недостатках Не существует роз без шипов, и представленный выше подход — не исключение. Некоторые из них можно решить, используя отличимую от трехуровневой архитектуру. Наиболее часто с конкретными репозиториями возникали следующие проблемы: За длительное время репозитории могут набрать большое количество Find-методов. Достаточно часто эти методы похожи друг на друга. Есть два способа это предотвратить. Один из них — это группировка нескольких Find-методов в один общий. Этот метод должен принимать object, что представляет собой критерий запроса. Пример: Чтобы создать запрос с критерием запроса, мы строим набор критериев шаг за шагом:   Зачастую слишком большие репозитории обрастают целой плеядой различных сервисов. Вы можете избежать этого при помощи чего-то, что я называю CQRS-light. Отличием от полной версии является использование тех же таблиц как для чтения, так и для записи. Используя эту технологию, мы можем использовать ту же самую ORM как для чтения, так и для записи. Обращаться же к CQRS только в тех случаях, когда приложение в этом действительно нуждается (например, при обработке 80+ колонок, с использованием 20+ join). Диаграмма ниже представляет типичную архитектуру CQRS-приложения: Ключевые принципы CQRS-light следующие: Деление всех действий пользователя на две категории. Первая категория — действия, изменяющие систему. К примеру, оформление заказа в интернет-магазине. Вторая категория — действия, систему не трогающие. К примеру, просмотр списка товаров. Первая категория пишет — это команды, другая — читает, это запросы. Обработчики запросов для доступа к данным могут использовать только репозитории. Доступ к данным может осуществяться посредством любой технологии. Обычная конфигурация включает в себя ORM для чтения-записи, ORM для записи и микро-ORM для чтения (вроде Dapper) или же ORM для записи и чистый SQL для чтения. Обработчики команд для доступа и изменения данных могут использовать только репозитории. Для получения данных из базы обработчики команд не должны использовать обработчики запросов. Если обработчик команд должен выполнить комплексный запрос и этот запрос должен получить ответ от обработчика запроса, вы должны продублировать логику этого обработчика запроса и поместить его как в обработчик запроса, так и в метод репозитория (операции чтения и записи должны быть разделены). Обработчики запросов тестируются только в интеграционных тестах. Для обработчиков команд существуют юнит и — опционально — также интеграционные тесты. CQRS даже в своей легкой форме — сама по себе объемная тема и заслуживает отдельного блога. Теперь же давайте вернемся к теме недостатков паттерна конкретного репозитория. Другой недостаток, о котором я бы хотел упомянуть, заключается в нежелательной миграции бизнес-логики в определение запросов. К примеру, даже такой простой запрос:   содержит часть бизнес-логики, описывающей необходимые параметры, дабы заказ стал активным. Как правило, ORM не позволяет нам инкапсулировать такие части логики в отдельные свойства, как IsActive. Что нам здесь нужно, так это паттерн спецификации. Теперь наш запрос в форме паттерна спецификации будет выглядеть так: Автор перевода: Евгений Лукашук Источник

В этой статье вы найдёте несколько полезных советов для тех, кто хочет стать программистом. Совет 1. Определитесь с языком программирования Выбор языка программирования — первая трудность, с которой встречаются новички. Сколько программистов — столько и мнений о языках, поэтому выделить «лучший» среди них нельзя. Почему? Каждый язык создан для определённой области разработки и решения определённых задач. Для выбора языка программирования, ориентируйтесь на ваши желания. Какие программы и сервисы вы хотите создавать? Делать игры на Unity? Сайты на HTML, CSS и JavaScript? Или, может быть, бизнес-приложения на С# или Java? Python широко используется в науке для быстрых вычислений. При выборе учитывайте порог вхождения языка (Python, например, изучается быстрее и легче С++) и ваши предрасположенности. Кроме того, перед изучением любого языка стоит изучить основы программирования. Разберитесь, что такое двоичный код, компилятор, познакомьтесь с алгоритмами и шаблонами проектирования. Совет 2. Применяйте метод дробления материала Если вы решили стать программистом, вам нужно будет очень мнрогое изучить и запомнить. Сделать это «с наскока» будет трудно. Не хваатайтесь за все сразу. Ставьте перед собой небольшие реальные, достижимые цели. Например, изучайте одну тему за 1 день. При изучении любого языка начинайте с самых основ, постепенно продвигаясь вперёд. Закрепляйте пройденный материал практикой, если есть какие-то небольшие пробелы в знаниях — двигайтесь дальше, возможно, вы заполните их потом. Но не оставляйте слишком много «белых пятен», иначе запутаетесь. На помощь в структурировании информации вам придут различные техники запоминания (ассоциации, карточки) и ваш собственный дневник обучения, в котором вы можете записывать усвоенный материал, как говорят, «своими словами», и затем проверять его на практике. Совет 3.  Не стесняйтесь использовать детские обучающие программы и курсы. В детских программах часто подают упрощенные знания, основы основ. Не стесняйтесь пробовать детские игры и курсы, в которых материал усваивается значительно легче. Кроме того, это бываает весело! Прослушав материал в упрощенном виде, вы сможете понять его, и дальнейшее изучение программирования будет даваться вам значительно легче. Кроме того, к временной помощи детских курсов можно прибегнуть, если какой-то участок материала даётся вам с трудом, и понять его вы никак не можете. Прослушав упрощенный материал, вы получите взгляд со стороны и, возможно, наконец сможете понять материал. Совет 4. Разбирайте чужой код Это больше относится к практике. Разбирая чужой код, вы начнёте понимать, почему программа работает или не работает. Перенимая чужой опыт, вы получаете новые знания и фишки, которые помогут вам в будущем. Читая код другого программиста, вы улучшите своё общее понимание программирования и убережете себя от ошибок. Кроме того, разбор чужого кода также может помочь вам сдвинуться с мёртвой точки. Если вам что-то не понятно, то вы можете просмотреть чей-то код и получить его советы. Таким образом, вы сможете понять, как сделать правильно и почему часть программы у другого человека работает правильно, а у вас — нет. Совет 5. Читайте полезную литературу Не смотря на то, что сейчас больше людей предпочитают литературе курсы, статьи и видео, чтение актуальных книг по программированию поможет вам глубже изучить программирование. Некоторые книги вообще являются признанной классикой, например книга Роберта Мартина «Чистый Код» детально описывает процесс создания чистого кода, и указывает на ошибки, которые могут возникнуть при написании красивого кода. Фактически, эта книга — «библия» для тех, кто стремится писать чистый код. Поискав в Гугле другие книги по вашему направлению, вы можете скомбинировать их со справочниками, и получить «универсальный набор» программиста, в котором вы найдёте ответы на большинство своих вопросов. Общепризнанную литературу можно читать в переводе, но большинство актуальной литературы выходит в мир на английском, и переводится на русский с опозданием в год-два, когда уже всё поменялось. Поэтому дополнительный совет: уделите внимание изучению английского языка! С английским вы всегда сможете получать актуальную информацию, общаться с зарубежными программистами, английский облегчит вам изучение программирования в несколько раз, и, возможно, в будущем вы найдете работу в зарубежной компании. Совет 6. Запишитесь на курсы Для некоторых людей самостоятельное изучение программирование может даваться с трудом, ведь рядом нет никого, кто мог бы в любой момент ответить на их вопросы. Многим не понятно, с чего начинать обучение и как структурировать информацию.С наставником и одногруппниками вы будете продвигаться в обучении быстрее. Если вы хотите начать изучать программирование, вам будет интересно посмотреть записи вебинаров ITVDN из серии «С чего начать?», и «Как стать программистом?» . Ваши вопросы вы можете задать, обратившись в службу поддержки ITVDN. Консультанты нашего образовательного ресурса будут рады помочь вам.

Сейчас трудно представить себе любого девелопера без использования фреймворков. Здесь вы найдёте 5 лучших и наиболее признанных фреймворков для Python-разработчиков. Что такое framework? Говоря простым языком, фреймворк — набор инструментов для программиста. Фреймворк существенно упрощает разработку за счёт готовых решений и чётко выделенной структуры разработки приложений, сайтов. При использовании фреймворка вы значительно сэкономите себе время, ведь вам не придётся тратить его на решение рутинных задач программирования. Вместо этого вы сможете уделить внимание непосредственно разработке, сократив потраченное время с нескольких недель до пары дней. При использовании framework’a вы будете совершать меньше ошибок из-за невнимательности, и ваш синтаксис станет лучше. Кроме того, каждый framework оснащён собственной системой безопасности, которая защитит вас от случайной поломки программы. Большинство фреймворков являются бесплатными и имеют открытый код, хотя некоторые придётся покупать. Представляем вашему вниманию 5 лучших фреймворков для разработки на Python. Django «Классический» Python-framework, Django серьезно упрощает разработку за счёт большого количества доступных функций и паттернов. Имеет открытый код и предлагает большое количество возможных решений. Django относится к так называемым full-stack фреймворкам, которые универсальны и содержат все стандартные функции и шаблоны. К ним относится: аутентификация, маршрутизация, миграция баз данных, ORM и прочие. Django можно использовать для администрирования содержимого сайтов, аутентификации, RSS. Он отлично подойдёт для создания сайтов. Фреймворк работает с основными БД: MySQL, SQLite, PostgreSQ, Oracle. При необходимости можно установить специальные драйверы для подключения других баз данных. В целом этот фреймворк можно считать универсальным для Python-разработчиков. Он имеет большую базу шаблонов и на ура справляется со стандартными задачами, а также может помочь в решении нестандартных. Имеет полностью переведённую на русский язык техническую документацию. С хорошим переводом. Flask Платный мини-фреймворк, который предоставляет прочную основу для создания веб-приложений. Вмещается в один файл и легко устанавливается, пригодится в создании мелких и средних проектов, но не подойдёт для крупных из-за недостатка шаблонов и готовых решений. Предоставляет готовые шаблоны для маршрутизации, поддержку безопасных кукисов, WSGI 1.0. Имеет встроенный дебаггер и сервер для HTTP-разработки. Сервер поддерживает fapws3, GAEM, CherryPy, BJoem. Pyramid Бесплатный фреймворк типа «всё включено», разработан для приложений на основе Питона. Универсален и подойдёт как для создания небольших, так и больших проектов. Легок в установке, понятен, не тормозит. Имеет минималистичный дизайн. Имеет большое количество готовых шаблонов, в основном рассчитанных на разработчиков API. Умеет генерировать URL, помогает при аутентификации и авторизации пользователей, удобен для создания однофайловых приложений. Отлично подходит для тестирования и отладки. Twisted Создан для решения специальных задач сетевых разработчиков.  Быстр, бесплатен, сокращает время разработки сервисов в несколько раз. Создан на базе Deferred, которая упрощает обслуживание сетевых запросов и обработку ошибок.  Одно из главных оружий сетевого разработчика. Не подойдёт для разработки типичных веб-приложений из-за своих шаблонов и структуры. Twisted используется для разработки небольших асинхронных программ. Поддерживает большинство сетевых форматов: TCP, UDP, SSL/TLS, Domain sockets; умеет работать с сетевыми протоколами: HTTP, NNTP, XMPP, IMAP, IRC, FTP, SSH и прочими. Ещё больше модулей и форматов можно подключить с помощью драйверов. Имеет дополнительные структуры: Unit test (с поддержкой системы Deferred), Processor pools и т.д. Tornado Асинхронный фреймворк и одновременно сетевая библиотека по типу Twisted. Справляется с классической проблемой С10k (то есть может обрабатывать свыше 10 000 поступающих сетевых запросов). Представляет из себя солянку из Django, Flask и Twisted, но при этом быстрее их. Имеет встроенные шаблоны для аутентификации и авторизации, с поддержкой внедрения других шаблонов (например, Google), не блокирующийся HTTP-клиент.  Справляется с длинными запросами (long polling’ами), имеет поддержку web-сокетов. Используется разработчиками, которые создают масштабные сетевые приложения с большой нагрузкой и высокими требованиями к производительности. Каждый год количество новых фреймворков постоянно растёт, но некоторые из них уже несколько лет держатся на плаву, периодически изменяясь. Эти пять уже признаны чуть ли не классикой, и начать изучение мира фреймворков стоит именно с них. Потом вы сможете перейти на более специфические, предназначенные для решения определённых задач. Если вы изучаете программирование на Python и хотите освоить самые популярные фреймворки, смотрите видеоуроки ITVDN для Python-разработчиков, а также смотрите записи вебинаров на YouTube канале ITVDN.

Хотя внимание разработчиков приковано сейчас к таким глобальным вещам, как дефолтная реализация методов интерфейсов, мы хотим поговорить с вами о нюансах новой версии популярного языка программирования С#. Новые операторы присвоения: &&= и ||= Начиная с самой первой версии, C# поддерживал комбинирования операторов присвоения с другими операторами. Существует поддержка всех бинарных операторов (а именно - +, -, & и так далее), кроме булевских && и ||. Теперь комбинации типа &&= и ||= дополнят этот список. Дословно-интерполируемые строки Дословные строки начинаются на @”. Интерполируемые строки используют $”. Но что, если нам нужно создать дословно-интерполируемую строку? Что нам писать - @$” или  $@”? Сейчас первый вариант работает, но второй выдает ошибку уровня компиляции, что может вызывать некоторые неудобства у многих разработчиков, так как обычно такие нюансы часто забывают. Суть нововведения заключается в том, что в новой версии можно использовать как первый вариант конструкции, так и второй. Впрочем, некоторые все равно находят это изменение лишним, так как оно может привести к некоторой фривольности кода и проблемам с единым стилем. Выражение using структурно соответствует IDisposable У компилятора C# интересное отношение к интерфейсам. Довольно часто вам не нужно на самом деле реализовывать абстрактный интерфейс для определенных фичей языка. Все, что вам нужно, так это просто реализовать в классе определенный публичный API, что по своей структуре повторяет абстрактный интерфейс. Классическим примером этого является foreach и IEnumerable. Если класс обладает методом GetEnumerator, возвращающим значение свойства Current и методом MoveNext, тогда вы можете использовать foreach. Сами типы возвращаемых данных не имеют значения, что позволяет таким классам, как List<T>, реализовывать более быстрые перечисления. Этот подход достаточно часто называется структурным соответствием. В рамках новой версии языка using также будет поддерживать структурное соответствие. На первый взгляд, это нововведение кажется лишенным смысла, так как мы вряд ли ожидаем увидеть класс для использования с using без реализации интерфейса IDisposable. Впрочем, мы упускаем такое нововведение как ref struct. Реализация интерфейса в данном случае невозможна, поэтому здесь нам на помощь приходит структурное соответствие. Методы расширения с foreach и using Как дополнение к предыдущему посту, теперь мы можем добавить GetEnumerator и Dispose в качестве методов расширения для работы с foreach и using соответственно. Опять же, здесь мы говорим об особенности, которая станет полезной в частном случае. К примеру, вы хотите добавить Dispose-расширение в COM-объект сторонней библиотеки (к примеру, дабы вызвать Marshal.ReleaseComObject). Впрочем, информация об этом еще неполная и мы можем упустить некоторые случаи использования данной фичи. Using неявной области видимости На данный момент выражение using может быть использовано только в рамках явной области видимости (в скобках). Если данное нововведение будет принято на вооружение, теперь вы можете писать конструкции следующего вида: Каждая из этих переменных будет автоматически очищена в конце текущей области видимости в реверсивном порядке. Функционально написанное выше эквивалентно этому, но гораздо более элегантно: Подобное может быть полезно в тех случая, когда в одно и то же время создается множество dispose-объектов. Теперь вы можете создавать подобные объекты даже внутри выражений в полной уверенности в безопасности данного типа объявлений. Возможный минус данного нововведения в том, что оно не совместимо с оператором goto. Автор перевода: Евгений Лукашук Источник

Красивый код — не просто абстрактное понятие, а вполне реально существующая вещь в среде программистов. Научившись писать красивый код, вы значительно сэкономите своё (и чужое) время, а ваши программы станут работать быстрее и стабильнее. Как научиться писать красивый код и каким нюансам стоит уделить внимание — узнаете в этой статье. Почему так важно писать красивый код? Код — штука тонкая, в которой эстетика и полезность тесно связаны, как в архитектуре. Полезный, но не эстетично выглядящий код будет трудночитаемым и в результате менее эффективным, чем мог бы быть. Каким образом? Трудночитаемый код сложно корректировать и тестировать возможные решения, поэтому он отнимает больше времени на корректировку, чем обычный код. Чистый код создан для людей, поэтому другие программисты, которые будут читать его, будут вам очень благодарны за красивый код. Благодаря чистому коду поиски одного бага могут сократиться с нескольких часов до нескольких минут, а программа будет работать стабильнее и не выдавать сюрпризов. Однако овладеть мастерством написания чистого кода с наскока не получится — до момента написания первого элегантного кода, вызывающего восхищение коллег, вы напишите ещё десяток не самых красивых кодов, от которых будут плеваться. Впрочем, если вы немного измените мышление и овладеете несколькими навыками, то успехи у вас будут значительно лучше, и к написанию красивого кода вы придёте значительно быстрее. Для начала определимся, как вообще научиться писать красивый код, и какие знания нужны для этого, а затем — с навыками, которые необходимо будет развить. Как научиться писать чистый код?  Прежде чем приступить к написанию красивого кода, запомните два основных принципа, которые вытекают из прошлой части статьи: Красивый код должен быть легко читаемым и понятным для других программистов. Красивый код должен работать, а если он не работает — легко фикситься. Для того, чтобы соответствовал этим требованиям, он должен быть коротким, а функции — линейными. Таким образом, при написании чистого кода вы должны ориентироваться на эти принципы. И постоянно практиковаться: пишите код каждый день, и каждый раз пытайтесь написать наиболее лучший вариант. Со временем у вас начнёт получаться. Не забудьте почитать книгу Clean Code под авторством Роберта Мартина. Эта книга — настольная библия для программистов, которые стремятся к совершенному коду. На 900 страницах расписано всё, что следует знать программисту, который стремится к чистому коду. Во время чтения книги можете также зайти на Хабру или другие сайты с полезными для прогеров статьями. Так вы сможете узнать ещё больше о чистом коде и позже закрепить свои знания практикой. Также вы можете пройти обучение по видео курсам ITVDN. Авторы видео курсов – сертифицированные разработчики. Они помогут вам научиться писать хороший код. Нужно ли изучать алгоритмы и паттерны? Изучение алгоритмов — дело ваше, но запоминание паттернов является обязательным для программистов, как изучение таблицы умножения для детей. Без паттернов найти решение типичной проблемы будет трудно, поскольку не будет готового решения. Впрочем, это не значит, что вы всегда должны использовать паттерны в каждой непонятной ситуации, иногда они не смогут помочь и вам придётся продумывать самостоятельное нестандартное решение, или обращаться за помощью к старшим коллегам. Но само изучение паттернов существенно упростит вам жизнь. Для желающих начать изучение паттернов рекомендуем великолепный курс Александра Шевчука. Изучение алгоритмов — чуть более глубокая сторона программирования. Сам алгоритм — это записанные в определённой последовательности команды, которые должны решить стоящую перед ними задачу. Если вы решили взяться за их изучение, то вам нужно не только знать сами алгоритмы, но и уметь их выводить, иначе от знаний не будет толку. Если вы решили изучать алгоритмы, то рекомендуем обратиться к школьному курсу информатики и статьям для программистов, где подробно рассказывают об алгоритмах. Если в статье вы встретили упоминания как минимум трёх основных видов алгоритмов (линейный, разветвлённый и циклический) — то вы на верном пути. Хорошим вариантом для старта будет статья Ворожцова А. В. «Что такое алгоритм?», затем знания можно углубить изучив курс Алгоритмы и структуры данных. С общими требованиями к красивому коду и необходимыми знаниями определились, теперь перейдём к навыкам. Какие полезные привычки необходимо завести? Для написания чистого кода необходимо развить следующие навыки: 1) Уделять внимание форматированию кода и стараться делать его как можно более линейным. Это сделает код более понятным и элегантным. Не стоит гнаться только за производительностью, если не хотите получить знаменитый «индусский код»: 2) Короткие методы и функции. Чем короче — тем понятнее, чем понятнее — тем лучше. Слишком длинные функции запутают любого программиста и он потратит кучу времени, пытаясь разобраться в функциях. Запомните золотое правило: одна функция — одно действие. 3) Удобные названия для функций. Это кажется нелепым, но придумать действительно хорошее название для функции — та ещё задачка, по сложности сравнимая с придумыванием имени для вашего персонажа в MMORPG. Совет, который может помочь, — при наименовании классов используйте существительные, а для методов используйте глаголы. Это сильно упростит понимание кода. Для примера можете взглянуть на два кода ниже и сказать, какой из них выглядит более понятно: первый (до переделывания) или второй (после).   До После Как видно на примере, в первом варианте код не так плох, но из-за непонятных названий труден для понимания. Во втором варианте он разбит на более мелкие блоки, а правильно придуманные названия («sendTOmAILsERVER, Client, Message) помогают понять его с первого взгляда.   4) Грамотная обработка ошибок. Даже если вы по каким-либо причинам не можете написать короткие функции и красивый код, вы всё ещё можете исправить ошибки. Ни одна программа не застрахована от сбоев, поэтому создать идеально работающую прогу не получится. Однако вы можете воспользоваться методом try-catch-finally. Сущность этого метода заключается в эдакой «страховке» от ошибок. При использовании этого метода, вы должны будете создать 3 блока: try, catch и finally. Затем, при запуске команды, она будет выполняться в блоке Try. Если что-то пойдёт не так, то она попадёт в блок catch, где вы сможете поймать ошибку и исправить её. Если же ошибки не было, или вы её исправили, то команда продолжит выполнение в блоке Finally, где и будет завершена. Такой метод является универсальным для поиска и исправления ошибок и его может написать даже джун. Это, кстати, будет лучше и элегантнее, чем грузить код лишними функциями и превращать его в лапшу. Написание красивого кода — дело непростое и требующее практики, но освоив эту методику, вы станете ещё на один шаг ближе к совершенству и завоюете больше уважения от коллег, а также сможете считаться уже более опытным программистом. Если вы хотите овладеть искусством написания красивого кода, изучайте программирование на ITVDN. Опытные наставники разложат всё по полочкам и после окончания обучения вы научитесь писать красивый чистый код. При условии конечно, если будете прикладывать и свои усилия.

Мы уже знаем особенности работы с памятью и доступные структуры данных в .NET приложениях, в этом посте мы разберем упаковку и распаковку, а также рассмотрим, как эти две операции влияют на производительность приложения.   Что такое упаковка и распаковка? Зачем нам задумываться об упаковке и распаковке? Разве это не обязанность .NET-среды, которая следит за управлением данных и, соответственно, сама "выбирает" наиболее оптимальный способ их хранения? На самом деле - нет. Что очень важно знать и понимать -  так это механизм перемещения данных из области стека в кучу - и наоборот. Помните: Когда любой значимый тип присваивается к ссылочному типу данных, значение перемещается из области стека в кучу. Эта операция называется упаковкой. Когда любой ссылочный тип присваивается к значимому типу данных, значение перемещается из области кучи в стек. Это называется распаковкой. К примеру, здесь мы имеем следующий пример упаковки: А вот состояние памяти в момент произведения операции: Чтобы сохранить значение "123" в виде объекта, в куче создается "упаковка", куда впоследствии и перемещаются данные. Когда же производится распаковка: Вот что происходит с памятью: Значение "123" было изъято из упаковки и помещено назад в область стека. Заметьте, что когда тип данных i упаковывается внутри объекта o, в стеке хранится лишь ссылка, в то время как само значение хранится в куче. Как только производиться распаковка, данные в куче обязаны быть скопированы в стек (переменная j). В обоих случаях наша цель - это работать с тем самым значением (123). Как вы можете себе представить, сии операции могут быть достаточно ресурсоемкими.   Давайте рассмотрим IL Когда мы производим подобный анализ производительности, часто бывает полезно заглянуть непосредственно в Intermediate Language (IL). Мы еще не рассматривали эту концепцию, но, как вы наверняка знаете, когда мы производим компиляцию в DLL или EXE, выходной файл на самом деле содержит IL - промежуточный код, который в последствии исполняется JIT и впоследствии - виртуальной машиной. Среда выполнения .NET обязана как-то знать, нужно ли упаковывать или распаковывать определенные переменные. Поэтому для обозначения этих операций также требуются дополнительные затраты памяти. Давайте создадим несложное .NET консольное приложение: Теперь скомпилируем приложение и при помощи утилитки ILSpy посмотрим его код внутри EXE. Как только EXE-файл будет открыт в ILSpy, пронавигируемся к методу Main, выбрав "IL with C#". Заметьте, что операция box выполняется только после присвоение ссылочному типу значения значимого. И наоборот: unbox.any - только после попытки присвоить ссылочному типу данных значимой переменной. Это де-факто способ, которым операции упаковки и распаковки представлены в IL.   Когда стоит производить упаковку и распаковку? Код в примере выше скорее всего вам покажется наивным, и вы можете подумать: "Эй, что за вздор! Я никогда не буду такого делать". Что же, в большинстве случаев это действительно так. Но данные в нашем приложении часто упаковываются и распаковываются, когда мы об этом даже не догадываемся.   Гетерогенные коллекции К примеру, старая школа до сих пор может похвастаться ArrayList. Метод добавления элемента здесь, как можно отметить, принимает object-параметр. Таким образом, и здесь производится наша излюбленная упаковка. Впрочем, подобное кануло в лету с приходом обобщений и обобщенных коллекций.   Конкатенация строк Другой интересный пример в виде конкатенации строк. Эта операция требует наличия метода String.Concat, который принимает два object-параметра. Дабы избежать подобных ситуаций, нам достаточно просто немного изменить код, используя на переменной типа int метод ToString (и здесь стоит проигнорировать сообщение ReSharper о том, что операция бессмысленна:) ). И все! Никакой упаковки больше нет. Вообще, это далеко не единичные примеры для демонстрации. Но цель нашей статьи - донести четкое представление о том, что такое упаковка и распаковка и когда они применяются.   Производительность Как мы уже говорили, упаковка и распаковка требуют определенных затрат производительности. В случае с конкатенацией строк, выигрыш от применения ToString весьма незначителен. Именно потому, как я упомянул выше, даже ReSharper не советовал нам делать подобное: В этом случае гораздо лучше сохранить читабельность кода без ToString. Целесообразность оптимизации появляется, как правило, тогда, когда операции упаковки и распаковки предстоит производить в цикле сотни и тысячи раз. В этом случае время выполнения кода с упаковкой может составлять порядка 150 процентов от времени исполнения кода без нее (вы можете сами создать тестовое приложение и сравнить требуемый промежуток времени). Упакованные значения могут также требовать больше памяти, чем значения в стеке. Копирование значений в/из стека также требует своих затрат. Согласно MSDN, упаковка может занимать порядка 20 раз больше времени, нежели простое присвоение. В то время как распаковка примерно в 4 раза медленней простого присвоения.   Итак... зачем же тогда вообще нужно использовать упаковку и распаковку? Несмотря на все недостатки в плане падения производительности .NET -приложения, концепции упаковки и распаковки были внедрены в .NET не просто так. И вот причины: .NET-стандарт обладает общей системой типов, что позволяет представлять и ссылочные. и значимые типы схожим образом - и все это благодаря упаковке. Коллекции можно было использовать для хранения значимых типов до появления обобщений. Упрощения кода, вроде конкатенации строк и так далее. Упаковка и распаковка настолько распространены, что мы не может избежать их полностью. Мы должны знать принцип их работы, чтобы минимизировать их использование, но к этому нужно подходить разумно. Не тратьте свое время на постоянную оптимизацию кода, частую проверку через IL, чтобы убедиться, дабы ни одна лишняя операция упаковки не была использована. Помните, что чистота и простота чтения кода иногда значительно более важна, нежели незаметное, мельчайшее ускорение работы программы.   Подведем итоги В сегодняшнем уроке мы рассмотрели, что такое упаковка и распаковка, как она представлена в IL-коде, и какое влияние на производительность они имеют. Искренне надеюсь, моя статья сумела прояснить некоторые общие концепции, хотя бы чуть-чуть. :) В грядущих статьях мы рассмотрим механизм сборки мусора. Если у вас есть идеи или пожелания касательно материала новых статьей - милости просим в комментарии!   Автор перевода: Евгений Лукашук Источник

10 полезных фич в Angular, о которых вы могли не знать Angular - это объемный фреймворк, и наверняка большинство из нас использует лишь небольшую его часть. Но за этим мы можем упускать некоторые весьма полезные его возможности, которые сделали бы нашу жизнь значительно проще. В этой статье я собираюсь разобрать около 12 полезных фич в Angular, о которых вы могли и не слышать. Одна из вещей, о которой часто забывают, но которая таит в себе множество полезностей, является Pipe. Итак, давайте поговорим о них. KeyValuePipe Это одна из ключевых особенностей Angular 6.1. До этого все, что позволяла директива *ngFor, так это проитерировать массив или другую счисляемую конструкцию. Что же в случае со свойствами объектов или элементов Map - перебрать их было задачей отнюдь нетривиальной. Это как раз тот случай, когда может пригодиться директива KeyValuePipe! Мы просто ставим pipe по отношению к объекту, который желаем проитерировать, и все остальное за нас совершает ngFor. К примеру:   Slice Pipe Отображение списка предметов и манипуляция большим объемом DOM-элементов - задача достаточно затратная, потому порой могут возникать ситуации, когда мы захотим уменьшить количество отображаемых элементов. Выполнить это можно многими способами, но Angular обладает прекрасным SlicePipe, который позволяет нам выполнить все это всего лишь как часть нашего ngFor - выражения. К примеру, давайте представим, что мы хотим отобразить только первые 10 элементов массива:   Decimal Pipe Этот pipe предназначен для форматирования чисел. Он может быть весьма полезен, когда мы желаем ограничить число цифр, которые будут показаны после точки. Впрочем, он также может быть использован, когда мы просто желаем представить определенное число в более "презентабельном" виде, с запятыми после каждой тысячи. Так, 1000 у нас станет 1,000. Кроме того, стоит также упомянуть еще об одной полезной фиче здесь. А именно, функции formatNumber, которая является частью @angular/common, что позволяет применять то же самое форматирование на программном уровне.   JSON Pipe Крайне полезный инструмент, особенно при отладке. Позволяет вам отобразить объект в виде строки в представлении. Подобный подход может стать неплохой альтернативой точкам остановки и командам отладчика в некоторых случаях. Просто добавьте JSON pipe объекту, который вы желаете отобразить:   Заголовок и мета-сервисы Становятся особенно полезными, когда мы работаем с поисковиками или соц. сетями (по типу Google, Twitter, Facebook и т.д.). Эти платформы для формирования контента, названия, его описания используют теги <meta>. К примеру, в нашем блоге для каждой статьи существуют свои заголовки, описания, картинки и так далее. Дабы убедиться в достоверности предоставляемой информации, мы можем поместить все необходимое в специальные мета-теги, как показано на примере ниже: Плюс у нас есть сервис Title, который, как вы понимаете, обновляет заголовок, отображаемый в окне браузера. Достичь этого можно просто и незамысловато: просто добавить значение тегу <title> в заголовке документа. Впрочем, здесь, увы, мы не сможем использовать стандартную Angular-привязку: <title>{{ myTitle }}</title>, так как <head> не находится внутри Angular-компонента. Поэтому здесь мы должны использовать сервис Title. Использовать его очень просто: Дабы позволить социальным сетям обнаружить эти мета-теги, они должны быть представлены на странице в момент ее загрузки (без использования JavaScript).   ng-container Пытались ли вы когда-либо поместить две структурные команды на один и тот же элемент, впоследствии обнаружив, что вы не можете это сделать? Или, возможно, вы применяете при этом ngTemplateOutlet, отмечая, что сие не позволяет в качестве дочернего, а лишь как родственный? Согласны, это может быть весьма утомительно, особенно если единственный способ решить сей ребус - добавить обертку в виде <div>, что, безусловно, может "замусорить" существующую DOM-структуру. К счастью, существует ng-container, что позволит вам избежать подобных проблем. Этот элемент, доступный при разработке, на самом деле не создает никаких новых элементов в структуре DOM-дерева и может быть прекрасным решением для обеих вышеназванных ошибок и даже более! К примеру, дабы использовать несколько структурных деректив, мы может просто сделать следующее: После чего просто применить существующий темплейт в качестве дочернего: Это лишь малая часть возможных применений сего инструмента, уверяю вас, при желании ng-container можно использовать и для более широкого круга задач. Декоратор атрибутов Все мы знаем, что свойства-декораторы @Input и @Output используются для привязки и порождения событий. Впрочем, существует другой, менее известный декоратор, @Attribute. Этот декоратор чем-то похож на @Input-декоратор, так как он может быть использован для передачи значения компоненту. Привязка атрибута чем-то похожа на scope-привязку AngularJS: Для начала, давайте изучим ограничения декоратора!             - Любые значения должны быть представлены строковым типом данных             - Значения статические и не изменяются, в отличие от привязок             - Мы не можем использовать синтаксис привязки [attribute] В то время, как существуют определенные незначительные ограничения, выигрыш от повышенной производительности будет более значимым. Они могут быть использованы точно так же, как и @Input-декоратор:   Мониторинг изменений профиля Я уверен, все мы знаем о функции enableProdMode, что будет вызвана в main.ts-файле любого проекта Angular CLI. Впрочем, здесь также существует функция enableDebugMode. Конечно, мы можем думать, что, мол, если я не работаю в прод-режиме, значит, я работаю в режиме отладки, но, кхм, все не совсем так. Вызывая эту функцию, мы получаем дополнительный инструмент - window.ng объект, что называют профилировщиком. Профилировщик имеет в своем арсенале функцию timeChangeDetection, при вызове которой выводится консольная информация о том, сколько произошло change-detection - циклов (а также о том, сколько времени они заняли). Может быть очень полезно при профилировании приложений с низкой производительностью. Для вызова функции добавьте следующее в коде bootstrap: Для запуска профилирования, введите в DevConsole следующее:   NgPlural Во многих приложениях бывают случаи, когда необходимо описать определенное число элементов, и в рамках нашего приложения нам нужно предусматривать различные ситуации. К примеру, рассмотрим следующие варианты:             - Предметов нет вообще             - Есть только один предмет             - Есть только два предмета Директива же ngPlural очень проста в использовании, и предназначена она для обработки подобных случаев:   ngPreserverWhitespaces & NgNonBindable Я решил сгруппировать две эти директивы, так как используются они в принципе в схожих условиях. В Angular 5 существовала опция preserveWhitespaces, добавленная в angularCompilerOptions. Если бы ее значение было равно false, оно бы позволило компилятору избавиться от пробелов, которые не считались существенными. Конечно, читабельность могла бы пострадать, но, с другой стороны, это позволило бы уменьшить размер пакета. Впрочем, бывают случаи, когда мы желаем сохранить пробелы. Если мы хотим оставить целый компонент нетронутым, нам необходимо просто использовать опцию в декораторе компонента: Впрочем, мы также можем желать оставить нетронутым пробел в определенном DOM-элементе. В таком случае мы можем использовать директиву ngPreserveWhitespaces. Также мы можем использовать {{ }} в нашем документе, впрочем, в любом случае Angular сочтет это за использование интерполяции и попытается оценить, что находится внутри ее. В таком случае нам придется кстати ngNonBindable.   Ну, вот и все! Здесь были описаны 10 вещей, которые вы могли не знать об Angular. Надеюсь, вы найдете их полезными! Автор перевода: Евгений Лукашук Источник

Дмитрий Охрименко – один из создателей ITVDN, автор видео курсов, консультант по построению распределенных и веб-ориентированных приложений, сертифицированный специалист Microsoft (MCTS, MCPD, MCT). Более 10 лет Дмитрий проводит корпоративные тренинги для IT специалистов в таких компаниях как 3Shape, GlobaLogic, Ciklum, Terrasoft, Simcorp и других. Мы попросили Дмитрия ответить на ряд вопросов, связанных с обучением IT специалистов и о том, в какой мере ITVDN может помочь в решении этих задач.   Как HR-специалисту узнать, какие новые технологии нужно изучить разработчику? Для этого есть много инструментов, которыми можно воспользоваться для определения действительно важных для разработчика тем. Так как бизнес должен зарабатывать деньги, то неправильно будет идти только на поводу у разработчика. Если говорить о мотивации, то все люди любят платить деньги за то, что приносит пользу, либо за то, что приносит удовольствие. Если брать разработчиков, то пользу им приносит все то, что может помочь в решении их повседневных задач. Если компания, например, разрабатывает какие-то веб-приложения, то, возможно, стоит обратить внимание на изучение их популярных библиотек, которые используются в проектах, на изучение разработки BackEnd-части. Это то, что можно отнести к пользе, которую получит разработчик. Если говорить об удовольствии, то все разработчики любят говорить, что они знают все самые последние технологии, что они имели опыт с последними версиями: C#, JavaScript, C++ и т.д.  Поэтому мотивация может заключаться в том, чтобы проводить обучение, может, не совсем полезное для проекта, но зато - это новые технологии, и разработчик будет чувствовать себя частью передовых технологий. Также необходимо проводить обучение для поднятия общего уровня знаний специалистов в проекте. По сути, как узнать, что нужно разработчикам? Лучше всего на этот вопрос ответит не сам разработчик, а тимлид или человек, который занимается организацией всей команды. Потому что четко понятно, что у этих ребят не хватает опыта работы с таким-то языком, инструментом и необходимо подтянуть именно эти навыки. Можно сделать, например, общий опросник для всех разработчиков и узнать, что они хотят. Как показывает практика, это обычно разбросанные требования: хочу учить С#, хотя человек пишет на Java, или хочу учить Python, хотя в проекте он не будет вообще использоваться. Для того, чтобы обучение мотивировало разработчиков и было полезно для самой компании, то HR-специалисту нужно собрать информацию не только от конкретных разработчиков, а еще и уточнить, что действительно необходимо для реализации тех задач, которые стоят перед командой в целом. Чтобы команда смогла поставить действительно качественный продукт.   Как происходит процесс построения корпоративного тренинга? Чаще всего компания понимает, что ей не хватает каких-то знаний в определенных направлениях. По своему опыту, если возникает какая-то задача у HR-специалиста или у тимлида, что команду нужно подтянуть по знаниям, например, по JavaScript, то мы просто приезжаем от Учебного центра CyberBionic Systematics и предоставляем перечень тех курсов и материалов, которые уже существуют. Если компании необходимо подготовить, допустим, Frontend-разработчиков, то мы приезжаем с теми наработками, которые уже есть. Также предварительно готовим конкретное предложение, если от компании уже поступили рекомендации, что, например, нужно сделать больший акцент на объектно-ориентированное программирование, на библиотеку, на определенные инструменты. То есть, мы подготавливаем предложение таким образом, чтобы высветлить те проблемы, которые возникают перед разработчиками и дополнительно добавляем какие-то материалы, которые могут поспособствовать дальнейшему росту специалистов. Мы проводим встречу с компетентными лицами. Собираемся с тимлидерами, с senior-разработчиками, они высказывают свои пожелания, они корректируют эту программу, и мы берем время на доработку дополнительных материалов. У нас очень много опыта по работе с киевскими компаниями. Очень часто компания Terrasoft заказывала именно абсолютно новую, индивидуальную программу. Они смотрели на то, что у нас есть, но вносили корректировки, которые требовали разработки 30-40 часов, под свои проекты. Чтобы обучение было действительно качественным и эффективным, чтобы компания получила из этого выгоду, специалистам компании необходимо озвучить, какие проблемы есть и в каком направлении нужно учить команду. В большинстве случаев тимлид и senior-разработчик понимают, что у его 10-ти мидлов, джуниоров и других специалистов не хватает опыта в определенных заданиях. Обычно это знания выборочные и их нужно подтянуть, или их просто нет, тогда нужно донести до слушателей. Наша задача понять, чего не хватает для того, чтобы специалисты были действительно продуктивными, и их работа была результативная. Для этого нужно подготовить программу, которая принесет пользу компании и специалисты будут удовлетворены. Мы расскажем им, что нужно знать и как нужно работать. Задачи компании будут решатся, а рабочих проблем должно стать меньше после того, как тренинг успешно закончится.   Какие формы обучения наиболее подходят для IT-специалиста? Чтобы обучение было максимально эффективным, я думаю, его необходимо комбинировать. Использовать обучение вместе с тренером, когда он будет своим примером мотивировать разработчика, заставлять что-то новое учить и двигаться дальше. Также комбинировать обучение необходимо с добавлением онлайн-составляющих, дополнительной литературы. Если брать корпоративное обучение, то максимально эффективное будет очное и онлайн, когда приезжает тренер или обучает через скайп и подобные ресурсы. Непосредственно взаимодействуют все группы слушателей и дополнительно к этому добавляется обучение в видеоформате. Для большинства проектов не всегда есть возможность оторвать людей от производственного процесса, есть определенные часы, в которые тренеру можно пообщаться с коллективом, рассказать теоретическую часть, но не всегда у разработчиков есть возможность полностью переключиться на подобного рода обучение. Обучения, когда в течение 5 дней в неделю по 5 часов учат определенную технологию, я считаю не очень эффективным, потому что информации очень много, не хватает времени, чтобы её освоить и закрепить. Я считаю, что обучение должно быть постоянным, интенсивным, но при этом в меру, чтобы была возможность переварить саму информацию. Чтобы был максимальный эффект, необходимо комбинировать очное и онлайн-обучение, когда тренер рассказывает материал и добавлять видеоформат обучения. Конечно, в идеале было бы перевести все на видеоформат и сделать так, чтобы слушатели только смотрели видеоматериалы, но у многих часто возникают вопросы. Если брать, например, проект ITVDN, то корпоративное обучение подразумевает еще и консультации, то есть команда может взять себе набор видеоуроков. Создатели и авторы курсов ITVDN хорошо понимают, что именно и в какой последовательности учить и какой эффект будет максимально достигнут. Мы можем составить индивидуальную программу, сделать временные метки и консультировать команду уже по ходу обучения, чтобы они смотрели все в видеоформате и не отрывались от рабочего процесса, при этом мы будем проверять результаты тестирования и отвечать на возникшие вопросы в ходе обучения. Мы открыты для диалога с компаниями, которые хотят мотивировать своих разработчиков и организовывать для них обучение. Наша команда готова разрабатывать индивидуальные программы, создавать индивидуальный график и подход к каждой компании в отдельности. У каждой компании свои собственные бизнес-процессы, своя корпоративная культура и всех под одну гребенку поставить не выйдет, поэтому мы готовы свои процессы подстроить под график конкретной организации.   Как ты посоветуешь "расшаривать" знания, делиться опытом внутри команды? Я считаю, что лучшего всего организовывать мастер-классы, когда сама команда для себя что-то полезное рассказывает. В команде всегда есть разработчики, у которых больше опыта. Неплохо было бы организовать день мастер-классов, составить график, где каждый разработчик должен выступить в течение 10-20-ти минут, рассказать о чем-то новом, показать технологию, сделать минимальную презентацию и просто поделиться знаниями, которые он получил на последнем проекте или вычитал, например, в статье. Польза в этом всем в том, что все понимают, над чем они работают, с какими сталкиваются задачами и технологиями, поэтому такие мастер-классы могут быть максимально эффективными для команды. Если компания пишет, например, используя Angular, то все мастер-классы нужно заточить под Angular и культивировать освоение тех частей этой библиотеки, которые необходимы для работы в проекте. Тимлидер может составить список докладов, и каждый сможет их проводить, будет общая копилка тех тем, по которым разработчик может провести мастер-класс и сделать расписание – это будет наиболее эффективный способ поделиться знаниями в команде. Также как способ - экстремальное программирование, вместе работать с одной задачей. Кто-то один знает процесс и диктует, а второй набирает код. Экстремальное программирование никто не отменял, но не в каждом проекте оно может примениться, чтобы более опытный специалист смог передать свои знания.

Вопросы, которые беспокоят каждого начинающего разработчика – смогу ли я найти работу после того, как пройду обучение? Какую специальность лучше выбрать, чтобы наверняка быть нужным? Есть, много субъективных факторов, которые влияют на возможность получить ту работу, о которой вы мечтаете. Это настойчивость, готовность рискнуть, черты характера, навыки представления себя потенциальному работодателю, умение правильно выбрать компанию и вакансию, соответствующие вашему уровню, умение проходить собеседование. При равных знаниях в программировании шансы кандидатов не равны. Однако, есть и объективные факторы, которые вы можете  (и должны!) учитывать. Один из них – конкуренция среди программистов, желающих занять определенную вакансию в IT компании. Самый простой способ взвесить свои шансы – посмотреть на количество вакансий, опубликованных в течение месяца и количество откликов на эти вакансии. Такая информация всегда в свободном доступе на сайте  сообщества программистов Украины DOU.UA.   Мы сделали небольшую выборку по десяти специальностям. Это информация за май 2018 года. Информация, представленная в этой таблице, говорит о том, сколько специалистов откликнулись на вакансии и какие специальности в нынешние время самые популярные. Из таблицы явно видно, что у начинающего C#/.NET разработчика шансы получить работу намного выше, чем у Java или FrontEnd разработчика. Смотрите, думайте. Желаем Вам стать профессионалом и работать в компании Вашей мечты! С более подробной информацией Вы можете ознакомиться на сайте DOU.UA.

Об авторе Юрий Думов работает архитектором программного обеспечения в SAP, имеет более 10 лет опыта в разработке веб и мобильных приложений. Прежде всего, давайте введем некоторые сокращения. Internationalization - достаточно длинное слово, поэтому предлагаю его заменить в нашем контексте на “intl”. Интернационализация в общем плане может быть разделена на следующие подпункты: Определение пользовательской локали Перевод UI-элементов, заголовков, подсказок и прочего Поддержка местных специфических сервисов, таких как даты, валюты и числа На заметку: в этой статье я заострю ваше внимание лишь на front-end части. Мы разработаем несложное универсальное React-приложение с полной поддержкой интернационализации. Для начала предлагаю воспользоваться моим репозиторием. Здесь у нас есть веб-сервер Express для серверного рендеринга, вебпак для построения клиентского JS, Babel для конвертации современного JavaScript в ES5. Также мы будем использовать npm-run, nodemon для запуска веб-сервера под средой разработчика и webpak-dev-server для ассетов. Нашей точкой входа в серверное приложение будет служить server.js. Здесь мы загружаем Babel и babel-polyfill для создания прочего серверного кода в современном стандарте JavaScript. В качестве бизнес-логики сервера мы используем src/server.jsx. Тут мы устанавливаем Express-сервер для прослушки порта 3001. Для рендеринга мы используем очень простой компонент components/App.jsx, который также является частью точки входа в универсальное приложение. Точкой входа в клиентский JS нам служит src/client.jsx. Тут мы фиксируем корневой компонент - component/App.jsx - для placeholder'а react-view в HTML-разметке, предоставляемой Express-сервером. Таким образом, сейчас мы склонируем репозиторий, запустим npm-install и выполним nodemon и webpack-dev-server одновременно в двух консолях. В первой консоли: И во второй: Наш веб-сервер должен быть доступен по localhost:3001. Откройте предпочитаемый вами браузер и убедитесь в этом сами! Итак, мы готовы начать. Определение пользовательской локали Существует два возможных решения этого вопроса. По какой-то причине большинство популярных веб-сайтов, включая Skype и NBA, используют гео-IP для определения местоположения пользователя, таким образом определяя его родной язык. Подобный подход не только является дорогим в плане реализации, но и еще не совсем точным. Сейчас очень много людей путешествует, по этой причине местоположение пользователя не является надежным ориентиром при выборе подходящего языка приложения. Вместо этого мы предпочтем второй способ решить данную проблему при помощи обработки на стороне сервера заголовка Accept-Language. Этот заголовок отправляется любым более-менее современным браузером.   -Language Этот заголовок предоставляет информацию о возможных вариантах языка, принятого в качестве ответа. Каждый язык обладает своим «приоритетом», показывая, как часто пользователь может его использовать. По умолчанию уровень «приоритетности» равен 1. К примеру, «Accept-Language: da, en-gb;q=0.8, en;q=0.7» означает «я предпочитаю датский, но могу также принять британский или другие виды английского».   (Также стоит упомянуть, что сей подход так же несовершенен. К примеру, пользователь может посетить ваш веб-сайт из интернет-кафе или публичного ПК. Лучше всего разработать виджет, при помощи которого пользователь на интуитивном уровне сможет поменять язык сайта.)   Реализация определения локали пользователя Вот пример кода веб-сервера Node.js. Мы используем пакет accept-language, что извлекает локали из http-заголовков и находит наиболее предпочтительные, исходя из поддерживаемых вашим веб-сайтом. Если таковые не были найдены, тогда сайт будет использовать свою дефолтную локаль.   Приступим к установке пакетов: После чего в src/server.jsx у нас будет следующее: Здесь мы импортируем accept-language и устанавливаем поддержку английских и русских локалей. Также мы реализовываем функцию detectLocale, что извлекает значение локали из куки. Если ни одна не была обнаружена, начинается обработка Accept-Language. Наконец, мы выбираем дефолтную локаль. После обработки запроса мы добавим заголовок Set-Cookie для обнаруженной локали в ответ. Это значение будет использовано для всех последующих запросов.   Перевод UI-элементов, заголовков, подсказок и прочего Здесь я собираюсь использовать React Intl-пакет. Это наиболее популярная и, так сказать, проверенная боем реализация интернационализации для React-приложений. Впрочем все библиотеки так или иначе строятся по одному принципу: они обеспечивают нас компонентами высшего порядка, что внедряют уже готовые функции интернационализации для обработки сообщений, дат, номеров, валют посредством специальных фич React.   Во-первых, мы должны установить провайдер интернационализации. Для этого мы немного изменим src/server.jsx и src/client.jsx. src/server.jsx:          здесь src/client.jsx: Так, теперь IntlProvider-дочерний компонент получит доступ к функциям интернационализации. Давайте добавим переведенный текст в наше приложение и клавишу для изменения локали. У нас есть два способа, как это можно сделать: через FormattedMessage или через formatMessage – функцию. Разница в том, что компонент будет обернут в span-тэг, что хорошо для текстовых данных, но не хорошо для значений HTML-атрибутов, таких как alt и title. Давайте опробуем и их!   Вот src/components/App.jsx: Отметьте, что атрибут id должен быть всегда уникальным для всего приложения в целом, так что было бы не лишним установить для себя некоторые правила именования сообщений. Я предпочитаю следовать формату «имяКомпонента.некийУникальныйИдентификатор». В качестве некой дефолтной локали будет использовано сообщение defaultMessage. Атрибут description предоставит некую информацию для переводчика.   Перезапустите nodemon и обновите страницу в браузере. Вы должны увидеть «Hello World». Но если вы открываете статью при помощи инструментов разработчика, вы увидите, что текст теперь внутри тэга span. В этом случае это не ошибка, но иногда мы предпочитаем просто получить текст, без никаких дополнительных тэгов. Для этого нам нужен прямой доступ к объекту интернационализации React Intl.   Давайте вернемся назад к src/components/App.jsx: Нам нужно написать гораздо больше кода, чем раньше. Во-первых, мы используем injectIntl, который «упаковывает» наш компонент приложения и внедряет intl-объект. Чтобы получить переведенное сообщение, нам нужно вызвать formatMessage и передать в качестве параметра message. Этот message должен иметь свой уникальный идентификатор и атрибуты defineMesasges из React Intl.   Лучшее, что есть в React Intl, так это его экосистема. Давайте добавим babel-plugin-react-intl к нашему приложению и построим словарь трансляции. Мы передадим этот словарь переводчикам, которым не нужно никаких задатков программирования для выполнения своей работы. .babelrc: Перезапустите nodemon, и вы увидите, что папка build/messages была успешно создана в корневой директории проекта, вместе с некоторыми другими папками и файлами внутри. Теперь нам необходимо собрать эти файлы в один JSON. Для этого вы можете использовать мой скрипт. Сохраните его как scripts/translate.js.   Теперь нам нужно добавить новый скрипт в package.json: Что же, попробуем! В конце вы должны увидеть файл en.json в build/lang. И все работает! Теперь пришло время для кое-чего поинтересней. На стороне сервера мы можем загрузить все переводы в память и, соответственно, выдавать их в зависимости от характера запроса. Однако на клиентской стороне этот подход неприемлем. Потому вместо этого мы будем один раз принимать json-файл со всеми переводами, а клиент автоматически определит, какой из текстов ему нужен.   Скопируем результирующий файл в public/assets. На заметку: если вы пользуетесь Windows, симлинки для вас недоступны. Таким образом, вам нужно будет вручную копировать команды каждый раз, как только вы будете перестраивать ваши переводы. public/assets/ru.json применим следующее: Теперь нам нужно повязать серверный и клиентский коды. Для сервера наш src/server.jsx должен выглядеть так: Здесь мы делаем следующее: Кэшируем сообщения и специфичный для данной локали JS для валют, DateTime, Number во время запуска приложения. Расширяем метод renderHTML так, что мы можем вставить специфичный для данной локали JS прямо в разметку. Предоставляем переведенные сообщения IntlProvider (все те сообщения теперь доступны в качестве дочерних компонентов). Что же касается стороны сервера, во-первых, нам нужно установить библиотеку для выполнения AJAX-запросов. Я предпочитаю использовать изоморфное обновление, так как, скорее всего, нам предстоит запрашивать данные из сторонних API, и изоморфное обновление очень хорошо с этим справляется. Вот src/client.jsx: Также мы должны затронуть src/server.jsx, чтобы Express предоставлял json с переводом на сторону клиента. Заметьте, что на продакшине вы, скорее всего, будете использовать что-то вроде nginx. После инициализации JavaScript, client.jsx возьмет локаль из куки и запросит JSON с переводом. Во всем остальном наше приложение будет работать, как и раньше. Пришло время проверить, как все будет работать в браузере. Откройте вкладку «Network» в панели разработчика и удостоверьтесь, что JSON с переводом был успешно получен нашим клиентом. Подведя итог, давайте добавим небольшой виджет для изменения локали в src/components/LocaleButton.jsx: И так же в src/components/App.jsx: Заметьте, как только пользователь меняет свою локаль, мы перезагружаем страницу, чтобы убедиться, что новый JSON-файл с переводом был успешно извлечен. Теперь же время протестировать! Окей, мы изучили, как определять локаль пользователя и как отображать переведенные сообщения. Перед тем, как двигаться в направлении заключительной части, давайте обсудим пару также немаловажных нюансов. Плюрализация и шаблоны В английском большинство слов могут принимать одну или две возможные формы: «одно яблоко», «много яблок». В других языках все намного сложнее. К примеру, русский имеет 4 различные формы. Надеемся, React сумеет справиться и с этим. Он также поддерживает шаблоны, так что вы можете предоставить переменные, которые могут быть подставлены в шаблон во время рендеринга. Вот как это работает. В src/components/App.jsx у нас есть: Тут мы определяем шаблон с переменной count. Мы напечатаем или «одно яблоко», если значение переменной равно 1, 21 и так далее, или «два яблока» в противном случае. Нам нужно передать все переменные в formatMessage. Давайте перестроим наш файл переводов и добавим русский перевод для теста. Вот наш public/assets/ru.json файл: Теперь все случаи предусмотрены! Поддержка местных специфических сервисов, таких как даты, валюты и числа Ваша информация будет представляться по-разному в зависимости от локали. К примеру, русская локаль нам покажет $500.00 и 12/10/2016.   Intl предоставляет React-компоненты для такого типа данных, которые автоматически обновляются каждые 10 секунд, если вы за это время не перезаписывали значения. это в src/components/App.jsx: Обновите браузер и проверьте страницу. Вам необходимо будет подождать 10 секунд, чтобы увидеть, как обновится FormattedRelative.   Круто, не правда ли? Что же, теперь мы можем столкнуться еще с одной проблемой – универсального рендеринга.   В среднем между формированием разметки и инициализацией JS проходит порядка 2-х секунд. Это значит, что все DateTime`сы, сгенерированные на странице, могут иметь разные значения на стороне клиента и сервера. Что, как следствие, разрушает универсальный рендеринг.   Вот src/server.jsx: вот src/client.jsx: Перезапустите nodemon и проблема почти исчезнет! Она может, правда, остаться в случае, если вы используете Date.now() вместо показаний, записанных в базе. Чтобы сделать пример более «жизненным», заменим в app.jsx Date.now() на последний таймштамп, что-то вроде 1480187019228.   (Впрочем, вы можете столкнутся с другой проблемой – когда сервер не в состоянии отрендерить DateTime в нормальном формате. Это потому, что 4 версия Node.js по умолчанию не поддерживала Intl.) Звучит слишком хорошо, чтобы быть правдой, не так ли? Мы как истинные фронт-енд разработчики всегда были на стороже того, что касается браузеров и платформ. React Intl использует нативный браузерный API для обработки форматов DateTime и Number. И, несмотря на тот факт, что подобная функциональность была представлена в 2012 году, до сих пор есть современные браузеры, которые ее все еще не поддерживают. Даже Safari поддерживает ее только частично. Вот таблица с детальной информацией: ​ Это значит, что если вы желаете покрыть большинство браузеров, которые не поддерживают Intl API на нативном уровне, polyfill для вас просто незаменим. Хвала Всевышнему, существует Intl.js. С одной стороны, кажется, вот оно – идеальное решение, но, как показывает мой опыт, всегда существуют свои недостатки. Во-первых, вам нужно добавить Js-bundle, что несколько ресурсоемко. Также для уменьшения размера вам нужно будет передавать ваш Intl.Js только для браузеров, у которых нет своей нативной поддержки. Конечно, все эти техники уже давным-давно известны, и существует великое множество статей, посвященных им. Но все равно, Intl.js – не абсолютное решение, так как все же представления DateTime и Number на стороне сервера и на стороне клиента могут несколько отличаться, что, разумеется, влечет за собой ошибки при серверном рендеринге.   Наконец, я пришел к своему собственному решению, которое хоть и имеет свои недостатки, но мои запросы в большинстве случаев оно устраивает. Я реализовал очень поверхностный polyfill, что имеет лишь небольшую часть из требуемой функциональности. В то время, как в большинстве случаев подобное решение непригодное, оно лишь добавляет лишние 2 КБ к размеру JS-файла, так что даже нет необходимости реализовывать динамическую загрузку кода для устаревших браузеров, что значительно упрощает решение в целом.   И в заключение Возможно, сейчас вас не покидает чувство, как будто здесь написано слишком сложное решение. Также, возможно, сейчас вы подумываете о том, чтобы реализовать все самим. Я бы не советовал этого делать. В конце концов, вы все равно придете к выводам, представленным в данной статье. Или, что хуже, зайдете в тупик одного решения и не сможете увидеть остальные. Вы можете подумать, что можно легко решить проблему с Intl API, используя вместо него Moment.js (я специально не рассматривал другие библиотеки, так как они либо неподдерживаемые, либо неиспользуемые). К счастью, я уже опробовал это, так что я могу сохранить вам много времени. Moment.js монолитен и очень тяжел, так что если для кого-то он и подойдет, то остальная масса пользователей будет неудовлетворенной результатом. Разработка собственного polyfill не звучит интригующе, так как вам наверняка придется выделить определенное время для борьбы с возникающими при этом багами. Подведя итог, могу лишь сказать, что не существует идеального решения касательно проблемы на данный момент: просто выберите то, что вам подойдет лучше всего.   Надеюсь, эта статья дала вам все, что нужно знать для создания интернационализируемого React front-end приложения. Теперь вы выучили, как определять локаль пользователя, сохранять ее в куки, писать виджет для изменения локали и многое другое! Также вы ознакомились с некоторыми возможными проблема и ловушками, в которые вы можете попасть в процессе написания приложения.   Удачи в разработке! Автор перевода: Евгений Лукашук Источник