Обновить
128K+

Качество кода *

Как Макконнелл завещал

61,45
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Почему я предпочитаю исключения, а не значения ошибок

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели44K

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

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

Давайте рассмотрим пример, в котором применено защищённое от ошибок целочисленное деление:

int safeDiv(int a, int b) {
   if (b == 0)
      throw Div0(); // Исключения передаются особым образом
   return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}

Новые языки программирования склонны применять сообщения об ошибках в функциональном стиле и кодировать ошибки в возвращаемый тип. Например, Go кодирует ошибку в возвращаемый тип при помощи кортежа (res, err), а Rust возвращает Result<T, E> — тип-сумму результата и ошибки.
Читать дальше →

Чистый код: Принцип разделения интерфейса (ISP)

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели13K

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

Этот принцип пожалуй самый простой для понимания, но важный при реализации. С разделением интерфейсов мы встречаемся постоянно, правительство любой страны имеет интерфейсы, которые называются министерствами, компании - интерфейсы в виде отделов, материнская плата - интерфейсы для подключения памяти, процессоров и другой периферии. Тоже самое логично делать и в программировании.

В чем суть принципа разделения интерфейсов. Если перефразировать простыми словами, не нужно делать два дела сразу. Сознание человека так и построено, вспомните детскую задачку, когда просят одновременной дотянуться пальцем до кончика носа и гладить живот по часовой стрелке.

Прежде чем создавать свой пример, давайте рассмотрим пару участков кода из интернета. Из кода удалены приватные части классов, а так же конструкторы и параметры методов. Исключительно для экономии места.

Первый пример, выдержка из огромного класса интерфейса API, весь класс содержит около 30 методов и не представляет интереса, но показанный участок, иллюстрирует проблемы которые возникли у автора кода при модификации.

Читать далее

Функциональные опции в Go

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели15K

Сегодня я хочу поделиться своими знаниями о паттерне, который может значительно упростить работу, если ты пишешь на Go. Речь пойдет о функциональных опциях. Поверь, как только ты разберешься c этим, твой код станет немного гибче и проще.

Читать далее

Проект «Статистика дрифта». Часть 2. Базовые сущности

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели1.5K

Первая часть серии - Проект «Статистика дрифта». Часть 1. Настройка
Паблик во ВКонтакте с новыми сериями без задержек выпуска на habr - Пихта DEV

Читать далее

Чистый код: Принцип подстановки Барбары Лисков (LSP)

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели14K

Принцип подстановки Лисков гласит, что если метод использует базовый класс, то он должен иметь возможность использовать любой из его производных классов без необходимости иметь информацию о производном классе.

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

Рассмотрим тонкости соблюдения этого принципа, на довольно сложном примере. Начнем с класса хранения данных.

Читать далее

Проект «Статистика дрифта». Часть 1. Настройка

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели2.8K

Разработка PHP/VueJS пет-проекта "Статистика дрифта" в формате лайф-тайм блога.
Первая часть лфай-тайм блога написана про базовую настройку будущего приложения.

Читать далее

Грепабельность — важная метрика кода

Уровень сложностиПростой
Время на прочтение3 мин
Охват и читатели16K

При работе над поддержкой незнакомой мне кодовой базы я трачу кучу времени на поиск строк при помощи grep. Даже в проектах, полностью написанных мной, мне нужно много искать: имена функций, сообщения об ошибках, имена классов и тому подобное. Если я не могу найти нужное, то я буду как минимум расстроен, а как максимум могу создать опасную ситуацию, если предположу, что какой-то элемент больше не нужен, ведь я не могу найти ссылок на него в кодовой базе. На основании этих ситуаций я выработал правила, которые позволяют повысить греппабельность кода.

Читать далее

Чистый код: Принцип открытости закрытости (OCP)

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели11K

Принцип открытости/закрытости гласит, что программные объекты (классы, методы, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации.

Идеальной реализацией данного принципа является интерфейс. Ничего лишнего, нечего модифицировать, можно только расширять.

Читать далее

Чистый код — дар или проклятие? Акт I. Конфронтация

Уровень сложностиСредний
Время на прочтение24 мин
Охват и читатели16K

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

Читать далее

Чистый код: Принцип единственной ответственности (SRP)

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели12K

Принцип единой ответственности гласит, что программный модуль должен иметь единственную ответственность, то есть у него должна быть одна и только одна причина для изменения.

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

Читать далее

Methodcentipede

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели3K

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

Читать далее

Деградация кода — это результат неправильной организации процессов

Время на прочтение7 мин
Охват и читатели30K

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

На своей должности руководителя разработки я стал непосредственным свидетелем разницы между командой, которой предоставили мощь и… какой антоним у мощи? Они были не слабыми, а, скорее, немощными.

Силу команды постоянно нужно подстёгивать и стимулировать, сама по себе она не развивается.

Что я под этим подразумеваю? Давайте поговорим о том, как немощные организации влияют на техническую работу.

Здесь есть большой выбор тем, от неэффективного использования ресурсов и плохой документации до отсутствия возможностей улучшения процессов «снизу».

Я руководитель разработки, поэтому смотрю на это с точки зрения технаря. Немногие книги о совершенствовании процессов рассматривают углублённо рассматривают улучшение процессов разработки.

Давайте изучим это на примере деградации кода.
Читать дальше →

Как улучшить время сборки в iOS с помощью модуляризации

Время на прочтение9 мин
Охват и читатели1.7K
image


Большинство команд мобило понимают и ценят преимущества быстрой сборки. Возможность быстро компилировать и тестировать код означает ускорение разработки и итераций, что, в свою очередь, позволяет команде осуществлять доставку новых версий более регулярно и эффективно. Но на самом деле бывает сложно добиться стабильно быстрой сборки и внедрить долгосрочное решение, позволяющее поддерживать высокую скорость сборки по мере роста кодовой базы. Существует множество различных тактик, и если некоторые из них относительно тривиальны — например, уменьшение размера доставляемых ресурсов, — то другие могут быть гораздо более сложными и даже опасными (вспомните сомнительные трюки с компилятором)!
Читать дальше →

Ближайшие события

Почему комментарии в коде — базовый инструмент, упрощающий поддержку и развитие проекта

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели5.3K

Привет, Хабр! На связи C#-разработчик компании SimbirSoft Георгий. В этой статье поговорим о том, как с помощью комментариев кода можно ускорить погружение новых разработчиков в проект, упростить написание документации и найти общий язык с коллегами-разработчиками.

Материал будет интересен как начинающим IT-специалистам, кто только учится писать чистый и красивый код, так и тем, кто отвечает за формирование кодстайла проектов. Подкреплять свои рассуждения буду примерами из личного опыта и опыта коллег. Сначала быстро пройдемся по основам, а потом откроем этот ящик Пандоры и уйдем в рассуждения.

Читать далее

Формат описания идентификатора зависимости в JS DI

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели1.5K

Эта статья для тех, кто знает, что такое “внедрение зависимостей” и имеет практический опыт его использования. Меня зовут Алекс Гусев и я являюсь автором библиотеки “@teqfw/di”. Цель моей библиотеки - дать возможность использовать функционал “внедрение зависимостей через конструктор” в проектах на JS (фронт и бэк) и TS (бэк). Минимальной единицей внедрения является отдельный экспорт es6-модуля. Поэтому библиотека не может использоваться с модулями CJS или UMD.

В основу внедрения зависимостей заложена идея о том, что вместо статического связывания исходного кода на этапе написания (через import) применяется динамическое связывание объектов программы в режиме выполнения. В моей библиотеке это достигается за счёт размещения в коде конструкторов (или фабричных функций) инструкций по созданию нужных им зависимостей, которые интерпретируются Контейнером Объектов при работе программы и на основании которых загружаются нужные исходники и создаются нужные зависимости.

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

Читать далее

Реализация сапёра в 100 строках чистого Ruby

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели10K

Ruby — весьма экспрессивный язык, в котором очень многое зачастую можно реализовать буквально в ста строках кода. Именно поэтому мне так нравится искать способ создать то же самое, но в более сжатом виде.1

Сразу внесу ясность: я не говорю о код-гольфинге, хотя это занятие тоже бывает интересным. Я имею в виду сокращение количества строк кода без потери его читаемости. По факту одним из самых приятных аспектов Ruby является то, что уменьшение количества строк кода зачастую может повысить его читаемость.

В нашем случае мы проделаем это на примере старого доброго «Сапёра». Помню, как играл в него на Windows XP ещё пацаном. Если и вы разделяете аналогичные воспоминания, то приветствую вас, мои друзья-миллениалы!
Читать дальше →

Мои взгляды на программирование на июль 2024 года

Время на прочтение5 мин
Охват и читатели14K
Эта статья – собрание убеждений о разработке ПО, которые выработались у меня на сегодняшний день. Всё основано на личном опыте.

Подход к задачам


Основная часть моей работы – разбираться с тикетами, и я до сих пор продолжаю совершенствоваться в этом деле. Вот несколько вещей, которые я открыл для себя в процессе.
  • Разные задачи, проекты и команды требуют разных подходов. Например, сделать пейсмейкер без автоматических тестов было бы безответственным решением – кто-то может от этого пострадать. И вместе с тем, глупо изводиться по поводу автоматических тестов на геймджеме, куда вы отправились на выходных. Содержание понятия «хороший код» меняется в зависимости от контекста, и нужно адаптировать свой подход под конкретную ситуацию.
  • Делайте марш-броски. Бывает, что я ставлю себе цель довести какую-то функциональность до готовности в кратчайшие сроки, пусть даже срезая углы где только можно, с кодом ужасного качества и TODO на каждом шагу. Когда у меня появится что-то рабочее, тогда и буду приводить всё в должный вид. Я пришел к выводу, что это хороший способ обозначить для себя проблемные зоны, а также неплохой путь к ускорению процесса разработки. На эту тему есть статья «Выбросьте первый набросок кода».
  • Если я бьюсь головой об задачу и никак не могу сдвинуться с мертвой точки, значит, необходимо оторваться от нее на какое-то время.
  • Прежде чем начать работу над сложной задачей, я задаю себе вопрос: «А что если вообще этого не делать?» Как правило, вопрос оказывается глупым и выполнять задачу все-таки приходится. Но примерно в пяти процентах случаев я осознаю, что определенную часть работы можно спокойно пропустить.

Читать дальше →

Работает — не трожь: зачем обновлять Python в долгоживущих проектах

Время на прочтение15 мин
Охват и читатели35K

Всем привет! Меня зовут Сергей Яхницкий. Я пишу на Python уже больше шести лет, техлид в Яндекс Такси, Python-евангелист и член Python-комитета Яндекса (аналог Python Steering Council).

Человек я простой, звёзд с Гитхаба не хватал: до того, как я устроился в Такси, я мирно писал маленькие бэкенды на Python. А потом меня прорвало: кодогенерации, CI/CD, кучи тестов, монорепа и прочее. Вот тут-то моя питоничья душа и воспряла. Решил я всё автоматизировать, обновить всё, что движется, а что не движется — подвигать и обновить. Из этого вышел мой рассказ.

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

Читать далее

Программисты не должны доверять никому, даже себе

Время на прочтение7 мин
Охват и читатели3.3K
Программисты должны быть параноиками.

  • “Я дважды проверил код”
  • “Код прошел тесты”
  • “Ревьюер одобрил мой код”
“Мой код верен?”

Писать правильный код сложно, а проверить его корректность невозможно. Вот несколько причин, почему:

  • Универсальность: Даже если ваш код работает правильно один раз, будет ли он работать так во всех случаях, на всех машинах, во всех ситуациях?
  • Ложноположительные результаты: Неудачные тесты указывают на наличие ошибок, но пройденные тесты не обещают их отсутствия.
  • Отсутствие уверенности: Вы могли бы написать формальное доказательство корректности вашего кода, но теперь вы должны задаться вопросом, верно ли это доказательство. Вам нужно будет подтвердить доказательство. Эта цепочка проверки доказательств никогда не закончится.
Глупо добиваться абсолютной уверенности в правильности своего кода. Ошибка может скрываться в зависимостях, которые вы никогда не найдете. Тем не менее, не стоит отчаиваться. Мы все еще можем снизить риск возникновения ошибок, добиваясь глубокого понимания кода и добросовестно работая с ним.
Читать дальше →

Четыре принципа разработки ПО, которым я научился на горьком опыте

Время на прочтение4 мин
Охват и читатели44K
Недавно я спроектировал и написал огромный сервис, и в прошлом месяце (наконец-то) состоялся его запуск. В процессе проектирования и имплементации я обнаружил, что ряд закономерностей, которые я приведу ниже, раз за разом всплывает в самых разных сценариях.

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

Хотелось бы отметить здесь одну вещь: разумеется, для каждого из принципов есть свое место и время. Как и во всех прочих случаях, важно учитывать нюансы. Я склонен держаться этих заключений в общем случае, по той причине что, как я вижу по опыту инспекции кода и документации, люди часто принимают противоположный образ действия как вариант по умолчанию.
Читать дальше →