Доброго времени суток всем.

«Как лодку назовешь, так она и поплывет» — довольная известная фраза, которая вполне подходит к функциям, переменным, классам.

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

Например

enum Dates{
  GET_FIRST,
  GET_SECOND,
  GET_BOTH,
  None
}



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

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

Даже если код тривиален, вы всё равно должны его тестировать.
Пару дней назад, Роберт Мартин опубликовал пост «Прагматичность TDD», (здесь лежит перевод — прим.переводчика) где он рассказал о том, что не тестируют абсолютно весь код. Среди исключительных ситуаций, когда не стоит применять TDD, дядя Боб упоминает написание GUI-кода, и я вижу смысл в таких утверждениях, но среди исключений есть парочка, на мой взгляд, нелогичных.

Я люблю две вещи: Intellij IDEA и чистый код (Clean Code).
IDEA создана для чистого кода. Многие настройки по умолчанию уже стимулируют вас писать как надо.


Но она всё ещё не идеальна.
Когда я устанавливаю новую копию IDEA, я пробегаю по настройкам и выставляю свои любимые галочки.
Хочу ими с вами поделиться в надежде, что когда-нибудь и они станут стандартом.

Привет, коллеги!

Совсем недавно мы провели конференцию, посвященную ASP.NET технологиям и всему что с ними связанно. Она имела успех, о чем можно судить по полному залу и звонкам с вопросами: «Может еще билетик будет все же?». Более подробно мы расскажем позже, но можно посмотреть фотоотчет, а сейчас хочется рассказать о двух новых конференциях, которые мы планируем провести в апреле.

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



Первая конференция UI Desktop & Business Application (11 апреля) посвящается «невидимым» с облаков разработчикам настольных корпоративных приложений и в целом всем, кто занимается разработкой и поддержкой бэкенда или разработкой сложного корпоративного интерфейса.

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

Тематика докладов:

• разработка системы обновлений
• системы плагинов — MEF
• интересные бизнес-кейсы связанные со стационарной разработкой
• фреймворки для UI, тестирование UI
• встраивание в систему
• особенности или какие-то интересные возможности связанные с EF
• и так далее, все что специфично для Windows программ

Регистрация уже началась. Воспользуйтесь возможностью приобрести билет по начальной цене.

До того, как я пришел в HeadHunter, я не знал, что такое code review. Я знал, что такое code approval — так было в одной американской компании, где я начинал свою карьеру, и где весь код в проекте проходил перед мудрыми глазами профессора Фортрана за столиком в глубине офиса. Он с отеческой улыбкой смотрел на мои первые шаги в разработке и говорил: «Вот тут поправь, пожалуйста, и можешь выпускать».

От переводчика: оценка процесса и результата разработки — достаточно субъективная вещь, если не используется какая-либо мера весов. Можно долго спорить: табы или пробелы, git или mercurial, maven или gradle, но такие споры все равно скатываются к вкусовщине и каким-то частным случаям. Другое дело — соблюдение однородности проекта, вот это уже вполне себе измеримая величина.

Плохая методология лучше её отсутствия.

Помимо общих вещей, найдутся и специфические, присуще только мобильной разработке, только под Android. Pedro Vicente Gómez Sánchez из Karumi в своей работе разобрал по косточкам основные технические области и задал меткие вопросы для правильной, объективной оценки разработки для платформы Android. Если появится задача: оценить чужой проект, то рекомендую воспользоваться его методологией. Я воспользовался этой методологией, как чек листом. На выходе получился вполне понятный не профессионалу документ, где напротив каждой категории — конкретная величина соответствия правильности от 0 до 1.

Год назад мой друг Roberto Ciatti познакомил меня с концепцией, которую Роберт Мартин называет чистой архитектурой. Дядя Боб много говорит об этой концепции на конференциях и пишет о ней очень интересные статьи. «Чистая архитектура» представляет собой способ структурирования системы программного обеспечения, набор соглашений о различных слоях и ролях их участников, нечто большее, чем строгие правила.

Как он уже говорил в своей статье «Чистая архитектура» (перевод на хабре), идея самого подхода не нова, она строится на множестве концепций, которые продвигались многими разработчиками программного обеспечения в течение последних 3-х десяти лет.

Доменные модели

Git tag: Step02

Начнем с простого определения модели StorageRoom. Как было сказано ранее, модели в чистой архитектуре очень легкие, по крайней мере, легче, чем их ORM-аналоги в фреймворках.

Раз мы следуем методологии TDD, то первое, что мы напишем, это тесты. Создадим файл tests/domain/test_storageroom.py и поместим внутри него этот код:

Сценарии (часть 2)

Git tag: Step06

Теперь, когда мы реализовали объекты запроса и ответа, добавляем их. Помещаем в файл tests/use_cases/test_storageroom_list_use_case.py следующий код:

Сценарии (часть 3)

Git tag: Step09

Наша реализация ответов и запросов, наконец, завершена. И теперь мы можем реализовать последнюю версию нашего сценария. Сценарий корректно возвращает объект ResponseSuccess, но до сих пор не проверяет корректность входящего запроса.

Давайте изменим тест в файле tests/use_cases/test_storageroom_list_use_case.py и добавим ещё 2 теста. Полученный набор тестов (после фикстуры domain_storagerooms) выглядит следующим образом:

REST-слой (часть1)

Git tag: Step12

Наступил завершающий этап нашего приключения в поисках чистой архитектуры. Мы создали модели предметной области, сериализаторы, сценарии и хранилище. Но пока отсутствует интерфейс, который склеивает все вместе: получает параметры вызова от пользователя, инициализирует сценарий с хранилищем, выполняет сценарий, который получает модели предметной области из хранилища, и преобразует их в стандартный формат. Этот слой может быть представлен с помощью множества интерфейсов и технологий. Например, с помощью интерфейса командной строки (CLI): получать параметры с помощью ключей командной строки и возвращать результат в виде текста на консоли. Но та же базовая система может быть использована и для web-страницы, которая получает параметры вызова из набора виджетов, выполняет описанные выше шаги, и разбирает возвращенные данные в формате JSON для отображения результата на той же странице.

Вне зависимости от выбранной технологии, для взаимодействия с пользователем, сбора входных данных и предоставления выходных результатов, нам необходимо взаимодействовать с недавно созданной чистой архитектурой. Поэтому сейчас мы создадим слой для вынесения наружу API для работы с HTTP. Реализовано это будет при помощи сервера, который предоставляет набор HTTP-адресов (конечных точек API), при обращении к которым возвращаются некоторые данные. Такой слой обычно называют REST-слой, потому что, как правило, семантика адресов схожа с рекомендациями REST.

­­ 

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

Это принципы разработки ПО, взятые из книги Clean Code Роберта Мартина и адаптированные для PHP. Это руководство не по стилям программирования, а по созданию читабельного, многократно используемого и пригодного для рефакторинга кода на PHP.

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

Статья вдохновлена clean-code-javascript.

Всем привет!

В последнее время стало модным делать разоблачения на задачи. В посте решил привести свои соображения по задачам Одноклассников. Задачи понравились, но уж больно получились неоднозначными, а в отведённое на листочке место всё не уместить. Обсудим?

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

В качестве вступления хотелось бы вспомнить цитату дядюшки Боба

Вы читаете эту статью по двум причинам. Первая — Вы программист, вторая — Вы хотите быть лучшим программистом.

Всем привет!

Предваряя сегодняшнюю переводную публикацию, сразу отметим, что этот текст задуман как follow-up недавнему дискуссионному материалу "Прекратите усердствовать с комментариями в коде". Нас настолько впечатлила развернувшаяся там дискуссия и 189 комментариев по состоянию на 19.07.2019, что мы решили дать здесь слово и другому автору с портала Medium (Кристоферу Лейну), который практически по всем принципиальным вопросам полемизирует с тезисами Брайана Норлендера, автора первой статьи. Отметим, что в оригинале данная статья вышла на месяц позже предыдущей (16 мая и 16 июня), но собрала практически вдвое меньше аплодисментов (706 против 1,5K на момент публикации перевода). Посмотрим, что будет на Хабре…



Снимок взят с сайта rawpixels.com от автора Pexels

Всё больше и больше проектов и команд используют TypeScript. Однако просто применять TypeScript и выжимать из него максимум пользы — это очень разные вещи.

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

В статье, перевод которой предложен ниже, Роберт Мартин вроде как начинает с мыслей, очень похожих на те, что можно увидеть в рассуждениях Егора Бугаенко про ORM, но выводы делает другие. Лично мне подход Егора импонирует, но я считаю, что Мартин подробнее раскрывает тему. Мне кажется, с его мнением стоит познакомиться всем, кто когда-либо задумывался о том, какое место должен занимать ORM и вообще, зачем нужны объекты у которых все поля открыты. Статья написана в жанре "Диалог", где более опытный программист обсуждает проблему с тем, у кого опыта меньше.

Что такое класс

Класс это спецификация множества сходных объектов

Что такое объект?

Объект это набор функций которые производят действия с инкапсулированными данными.

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

В смысле "подразумевается"?

^{«Чистый код» и чистый кот}

Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».

Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.

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

В апреле Дядюшка Боб прилетит в Петербург выступить на трёх наших конференциях, и они как раз по трём разным направлениям (про .NET-разработку, про тестирование и про JavaScript). Поэтому мы спросили нескольких спикеров этих конференций, что такое чистый код для них, чтобы сравнить мнения экспертов индустрии в 2020-м.

А поскольку тема холиварная, наверняка кто-то из вас окажется не согласен с какими-то из мнений. В таком случае айда спорить в комментариях, это тоже весело!

UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.