Hello World, должно быть, самая часто создаваемая компьютерная программа. Уже десятилетия это первая программа, которую пишут люди, когда начинают изучение нового языка программирования.
Конечно же эта простая программа не должна иметь баги. Верно?
Привет Хабр! Пятничного тру ФП хардкора с Free Monad, Таглес Финал, Монад трансформерами, Refined Types, Smart Constructors и прочим таким вам в ленту. Хардкор сам себя в ленту не принесет так что погнали.
Гексагональная архитектура делит наш код на три основные части.
1) Primary Adapters,
2) Secondary Adapter
3) Logic aka Domain.
Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».
Вы создаете новую систему, и два члена вашей команды предлагают альтернативные архитектуры для отправки уведомлений. Какая из них правильная?
Первый разработчик предлагает модель push: ограниченный контекст должен дать указание Notifications отправить уведомление. Notifications должен просто подчиняться командам и отправлять указанные уведомления.
Второму разработчику не нравится модель push-уведомлений, и он предлагает решение на основе хореографии: когда ограниченные контексты создают события, Notifications должен подписаться на эти события и определять, когда отправлять уведомление.
Как бы вы спроектировали решение? Что еще более важно, как бы вы приняли это решение в команде? Как вы будете разрабатывать наиболее эффективную архитектуру, которая поддерживает краткосрочные цели и долгосрочное развитие?
Программисты читают код намного чаще, чем пишут его, поэтому важно писать понятный, последовательный, однозначный код. Автор книги С++17 in detail написал о способах избегать путаницы. Делимся его материалом к старту курса по разработке на С++.
С появлением подсказок типов (type hints) в Python 3.5+ добавилась опциональная статическая типизация – поэтому эти подсказки так мне нравятся. Теперь я аннотирую ими все мои проекты.
Кажется, все сейчас стремятся к «чистому» коду. Нет почти ни одной статьи в блогах, где автор не скажет о том, насколько «чист» его подход. Команды собираются обсудить, какое из возможных решений самое чистое. Разработчики вокруг заверяют, что практикуют «чистый код».
Тем не менее, я осознал: нет такого понятия — чистый код.
Если ваша задача — не просто научиться писать код, а понять, как стать тем, без кого поддержка и развитие проекта просто немыслимы, то этот текст для вас. Заодно поговорим о том, как помочь коллегам постичь дзен и досконально изучить структуру разрабатываемого приложения.
Всем привет, меня зовут Макс Кравец, я CEO IT-компании Holyweb, и сегодня хочу поделиться вредными советами о том, как стать незаменимым React-разработчиком. Поехали!
Зачем нужен статический анализ кода, кажется, никому объяснять сегодня уже не нужно. Но одно дело — поддерживать код «чистым» с первого коммита, и совсем другое — встраивать новый инструмент в проект, который за несколько лет успел разрастись и пережить несколько итераций глобального рефакторинга. Мы работаем с большим количеством плохо документированных источников данных, а статический анализ кода помогает учитывать самые разные граничные случаи.
И ещё один момент: Rusprofile почти целиком написан на PHP, языке со слабой динамической типизацией. Статический анализ кода на PHP уже несколько лет набирает популярность, сказывается здесь и движение самого языка в сторону более строгой типизации. Но мы опасались, что без предварительной подготовки кода пользы от него мало. Аннотировать типами весь код в реальных бизнес-условиях тоже нереально. Сильно медлить с внедрением в рабочий процесс тоже нельзя: чем дальше, тем сложнее что-то кардинально улучшать. Поэтому нужно было оперативно запускаться, чем-то пожертвовав.
Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче
Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?
Ситуация получилась следующая.
Компания переделывала сайт и сказал, что необходимо сделать его максимально гибким, чтобы, во-первых, можно было дизайн обновлять просто, во-вторых, сделать ещё несколько подразделов на базе готового функционала (вроде как SaaS фишка для заказчиков).
"Разработчик – это человек, который переводит мысли заказчика на язык машины"
@mikita_du
Идея статьи появилась год назад, думал назвать «Вёрстка в 2021», но как-то затянулось… Весной 2021 года Microsoft объявила, что с 15 июня 2022 года прекращается поддержка IE11 (да, не для всех версий Win 10, но всё же), а значит, к выходу статьи уже останется менее полугода до знаменательного события, когда не придётся верстать под IE.
Для меня же это значит, что можно будет по полной использовать новые стандарты браузеров, в частности – css-variables, grid layout.
В то время как космические корабли бороздят просторы вселенной, а для разработчика код-ревью – обыденное явление, системные администраторы, инженеры эксплуатации и даже прокачанные DevOps-инженеры чуть ли не впервые с этим сталкиваются, будучи уже опытными специалистами.
В этом году команда Слёрма внедрила код-ревью практических заданий на курсе «Python для инженеров», чему и посвящён материал: кто делает ревью, какие наши принципы, а также как это сравнить с настоящим код-ревью на работе и кто может помочь инженеру.
Казалось бы, совершенно непонятно, зачем живым людям в 2021 году решать задачу под названием «печатаем обычное вещественное число». Вроде бы это должно быть уже решено — причём примерно в тот момент, когда эти вещественные числа изобрели. Но оказывается, что нет.
Привет, меня зовут Андрей, я занимаюсь инфраструктурой поиска в Авито и сегодня расскажу, зачем это вообще нужно — печатать вещественные числа. Какие есть методы (один) решения этой боевой задачи и как это получилось у нас в проекте, в рамках наших очень странных требований. А также, зачем таки подобное, хм, умеренно эзотерическое знание, может когда-то понадобиться и вам. На каком бы вы языке не писали. Read on!
Облачные технологии открыли путь к множеству новых практических областей, среди которых есть и такие, которые ранее были совершенно невозможны. Среди них выделяется бессерверная парадигма:
Бессерверные вычисления – это модель выполнения вычислений в облаке, при которой облачный провайдер предоставляет машинные ресурсы по требованию и берет на себя всю работу с серверами, на что его уполномочивает клиент. При бессерверных вычислениях ресурсы не содержатся в энергозависимой памяти; напротив, вычисления выполняются краткими всплесками, после которых результаты сбрасываются в долговременное хранилище. Когда приложение не используется, никаких ресурсов на него не выделяется.
По Википедии
Проверка кода (code review) — отличный инструмент для повышения качества кода, но он не учитывает один факт: отправляют и просматривают код люди, а они устают, теряют сосредоточенность, ленятся, да и просто испытывают эмоции в самые неожиданные моменты.
Поэтому хочу представить свое видение хороших и плохих практик код ревью с учётом человеческих особенностей.
Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.
Многие при этом не задумываются, правильно ли они пилят микросервисы. Как в синдроме утенка: увиденное самым первым становится единственно верным решением.
Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.
