В начале я обозначу некоторые проблемы и особенности при работе с БД, покажу дыры в абстракциях. Далее мы разберем более простую абстракцию, основанную на иммутабельности.
Предполагается, что читатель немного знаком с паттернами Active Record, Data Maper, Identity Map и Unit of Work.
Проблемы и решения рассматриваются в контексте достаточно больших проектов, которые нельзя выкинуть и быстро переписать.
Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.
Во второй части статьи рассмотрим некоторые новые диагностики в go-critic, которые позволяют находить код, который с высокой степенью вероятности содержит ошибку.
Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта
Хабр, это доклад инженера-программиста Алексея Старкова на конференции Moscow Python Conf++ 2018 в Москве. Видео в конце поста.Всем привет! Меня зовут Алексей Старков — это я, в свои лучшие годы, работаю на заводе.
Если вы считаете консистентность важной составляющей качественного кода — эта статья для вас.
Вас ждут:
type EmailContactInfo = String
type PostalContactInfo = String
data ContactInfo = EmailOnly EmailContactInfo |
PostOnly PostalContactInfo |
EmailAndPost (EmailContactInfo, PostalContactInfo)
data Person = Person
{ pName :: String,
, pContactInfo :: ContactInfo,
}
data Person = Person
{ pName :: String
, pAge :: Int
}
D3.js произвело на меня сильное впечатление.«Результат визуализации — это
За время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.
Разумеется, часто главной проблемой было низкое качество программного обеспечения (отсутствие модульных тестов, отказ от использования принципов чистого кода…), но были также и трудности, чьим источником являлись архитектурные решения, принятые в начале работы над проектом или даже в период зарождения корпоративной системы. На мой взгляд, этот класс проблем является причиной наибольшей боли для многих проектов.
В сущности, улучшение кода — дело довольно простое, особенно сейчас, когда движение за мастерство разработки ПО (software craftsmanship) продвигает хорошие практики в командах. Однако изменение стержневых частей систем, ограничений, введенных в самом начале их жизненного цикла, является чрезвычайно сложной задачей.
Расскажу о нескольких типах встречавшихся мне архитектурных решений, которые могут стать реальным бременем для команд, занимающихся поддержкой подобных систем.
Я написал книгу, предварительный релиз, о создании веб-приложений с нуля.
Я прочитал много книг по программированию, но, часто, после прочтения у меня оставался только один вопрос — Как мне применить эти знания на практике?
Предположим, вы разработчик системы автоматизации, портала или интернет-магазина.
Добавление новой функциональности осложняется наслоениями кода. Запуск тестов занимает полчаса, а релиз — час. Идея о переходе на новую версию фреймворка вызывает нервные подергивания. Вы узнаёте, что PostgreSQL имеет поддержку массивов, jsonb, полнотекстового поиска и lateral join, но ORM не позволяет использовать их в полную силу. Вы прочитали про TDD, но как писать в таком стиле, когда аналитик описывает сценарии, а фреймворк требует создания модели, контроллера и представления?
Как применить SOLID, если сущности наследуют от ORM?
Как избавиться от боли?
Постепенно, по мере изучения Clojure, и, наконец после прочтения Clean Architecture, я понял, как без боли написать приложение, где на первом месте стоит предметная область, а не фреймворк, где я принимаю решения, а не создатели фреймворков навязывают свои.
В какой-то степени книгу можно рассматривать как практический самоучитель по Clojure,
так что знание этого языка не требуется.
