В хороших книгах по программированию пишут, что код должен быть самодокументирующимся. А комментарии нужны там, где делается что-то нетривиальное. Наша команда разделяет это мнение, и недавно нам попался фрагмент кода, который отлично это демонстрирует.
Пользователи иногда спрашивают, как появляются новые диагностики в статическом анализаторе PVS-Studio. Мы отвечаем, что черпаем вдохновение из разнообразнейших источников: книг, стандартов кодирования, собственных ошибок, писем наших пользователей и так далее. Сегодня мы придумали новую интересную диагностику и решили рассказать историю, как это произошло.
Привет, меня зовут Григорий Бизюкин, я преподаватель Школы разработки интерфейсов и фронтенд-разработчик в Яндексе. Давайте поговорим о функциональном программировании в мире JavaScript. Мы все про ФП что-то слышали, нам всем оно интересно, но у меня, когда я искал полезные материалы для подготовки к лекциям, сложилось такое впечатление: есть куча статей, каждая из которых либо говорит об ФП общими словами, либо раскрывает отдельный маленький кусочек темы, чего, конечно, недостаточно.
Добавим функционального света
Впервые я попробовал обобщить в одном месте самые популярные и, как мне кажется, применимые приёмы функционального программирования в лекции для ШРИ. Потом захотелось расширить материал и рассмотреть ещё больше концепций. В результате получилась эта статья. В ней мы разберём всё самое сложное простым языком с понятными примерами. Надеюсь, вам будет интересно!
Если вы работаете с React или React Native и чувствуете, что у вас медленная скорость написания кода, вы тратите много времени на поиск ошибок, а не на добавление нового функционала, работаете с большими исходными файлами и вам сложно находить нужные части кода, а также многократно реализуете одну и ту же логику, то эта статья для вас. Вы удвоите скорость написания кода, если отрефакторите код в повторно используемые строительные блоки.
Мы рассмотрим React компонент, который можно хорошо разобрать. И мы будем шаг за шагом реорганизовывать его до хорошего уровня. Вы увидите большое количество идей, которые повысят вашу скорость написания кода.
Kotlin, созданный всего 5 лет назад, с 2019 года считается приоритетным языком программирования под Android. И все же этот язык достаточно молод и продолжает развиваться, поэтому иногда бывает непонятно, каким образом лучше написать код. У нас в команде часто бывают обсуждения на тему чистого Kotlin-кода, и на их основе мы составили свои best practices. Хотим поделиться этими рекомендациями и ждем ваших вопросов.
Ну что ж, приступим! В первую очередь, в Котлине много синтаксического сахара, и если им злоупотреблять, то читать такой код становится затруднительно. Следующие несколько пунктов можно отнести к борьбе между краткостью и читаемостью.
Задача состояла в подключении файлов: HTML, JS, CSS; без специальной подготовки. Так же неудобно подключать бинарные файлы (например картинки) конвертируя их в HEX. Так как не хотелось конвертировать в HEX или разделять на строки, искал способ подключения файла в адресное пространство программы.
Наверное, каждый программист рано или поздно начинает задумываться о качестве своего кода. И, скорее всего, я не ошибусь, если скажу, что добрая половина разработчиков им вечно недовольна. Мне мой код тоже нравился редко: функции, казалось, можно было бы делать и покороче, лишние вложенности было бы неплохо тоже убирать. Было бы здорово писать тесты и документацию, но на них времени не оставалось почти что никогда.
Естественно, что я потратил кучу времени на чтение книг и всевозможных статей, пытаясь понять, как же сделать свой код лучше. Но картинка не складывалась. То ли рекомендации в книгах или статьях были через чур общими и местами противоречивыми, то ли дело было во мне, но, несмотря на усилия, результата было мало.
Кардинальным образом ситуация изменилась после того, как я прошел курс HowToCode. В курсе описан системный и, как всё гениальное, простой и красивый подход к разработке, который сводит воедино анализ, проектирование, документацию, тестирование и разработку кода. Весь курс построен на использовании функциональной парадигмы и языка Scheme (диалекта Lisp), тем не менее, рекомендации вполне применимы и для других языков, а для JavaScript и TypeScript, к которым я постарался их адаптировать, так и вообще подходят отлично.
Хочу рассказать, как автор кода может упростить работу ревьюеру и увеличить тем самым как качество ревью, так и производительность ревьюера. Эта статья вполне может использоваться в качестве в вашей внутрикорпоративной документации как руководство для подготовки изменений к ревью. Она, собственно, и была скомпилирована из такого руководства.
Все знакомы с библиотеками логирования. Обычно они предлагают из коробки сразу много "уровней" важности, которым Вы можете записывать сообщения. Обычно в документации к ним можно найти рекомендации - как лучше этими уровнями - Info, Warning, Error, Fatal - пользоваться. Проблема в том, что это все не работает без некоторых дополнительных соглашений и уточнений - все равно возникает путаница и споры "какой уровень правильный". Именно об этих необходимых уточнениях я и хотел бы поговорить.
Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.
Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси? Попробуем разобраться.
Скорость разработки и производительность программистов могут отличаться в зависимости от их уровня и используемых в проектах технологиях. Для проектирования ПО нет стандартов и ГОСТов, только вы выбираете, как будете разрабатывать свою программу. Один из лучших способов повысить эффективность работы — применить шаблон проектирования CQRS.
Существует три вида паттерна CQRS: Regular, Progressive и Deluxe. В этой статье я расскажу о первом — классическом паттерне Regular CQRS, который мы используем в DD Planet в рамках разработки онлайн-сервиса «Выберу.ру». Progressive и Deluxe — более сложные архитектуры и влекут за собой использование обширного набора абстракций.
Я поделюсь опытом своей команды: как мы применили паттерн CQRS в наших бизнес-приложениях и беспроблемно внедрили его в существующие проекты, не переписывая тысячи строк кода.
Никогда такого не было, и вот опять! Опять на прошлой неделе на Хабре появился (и был очень активно комментирован) пост, ныне удалённый, о том, что такое хороший код и чем он отличается от плохого. Яндекс подсказывает, что публикаций о хорошем (вариант: отличном, идеальном, правильном, чистом, грязном, плохом и т.д.) коде здесь уже десятки и сотни, появляются они стабильно на протяжении многих лет, всегда активно обсуждаются, но к единому мнению на этот счёт так и не пришли.
Моё мнение - нет никакого "хорошего кода", потому что само понятие "хороший" крайне субъективно и неизмеримо. Так, может, нужна линейка для измерения хорошести качества кода? В общем, предлагаю вашему вниманию шкалу, которая самонадеянно претендует на исчерпывающий ответ. В шкале ровно 5 значений (ну или 6, начиная с нулевого - мыжпрограммисты), а для наглядности они обозначены звёздами. Впрочем, вы можете заменить звёзды на даны, школьные баллы, попугаи или любые другие единицы измерения - суть не изменится. Погнали!
Здравствуйте, меня зовут Дмитрий Карловский и (сколько себя помню) я борюсь со своим окружением. Ведь оно такое костное, дубовое, и никогда не понимает, что я от него хочу. Но в какой-то момент я понял, что хватит это терпеть и надо что-то менять. Поэтому теперь не окружение диктует мне, что я могу и не могу делать, а я диктую окружению каким ему быть.
Как вы уже поняли, далее речь пойдёт про инверсию контроля через "контекст окружения". Многим этот подход уже знаком по "переменным окружения" - они задаются при запуске программы и обычно наследуются для всех программ, которые та запускает. Мы же применим эту концепцию для организации нашего кода на TypeScript.
Итак, что мы хотим получить:
