Рубрика «Совершенный код» - 40

Софт постоянно усложняется. Стабильность и простота расширения приложения напрямую зависят от качества кода.

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

  • Функции слишком длинные, и на них слишком много задач
  • Часто у функций есть побочные эффекты, которые сложно определить, а иногда даже сложно отлаживать
  • Непонятные имена у функций и переменных
  • Хрупкий код: небольшая модификация неожиданно ломает другие компоненты приложения
  • Плохое покрытие кода тестами или вообще его отсутствие

Всем знакомы высказывания «я не понимаю, как работает этот код», «бредовый код», «этот код сложно изменить» и другие.

Однажды мой коллега уволился, потому что пытался справиться с REST API на Ruby, который было трудно поддерживать. Он получил этот проект от предыдущей команды разработчиков.

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

Искусство написания простых и коротких функций - 1

Такие ситуации случаются часто, и это печально. Но что делать?Читать полностью »

Главные характеристики качественного кода - 1

Как часто вы поражаетесь, читая чужой код, и думаете «господи, ну и каша...». Скорее всего, достаточно часто. И можете ли вы быть уверенным, что никто не думал также когда читал ваш код? Другими словами, насколько вы уверены в чистоте своего кода? Можно быть уверенным только если полностью понимаешь, что значит чистый код.

Сложно дать точное определение чистому коду, и, скорее всего, сколько программистов — столько определений. Однако, некоторые принципы достаточно универсальны. Я собрал девять самых релевантных и описал ниже.

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

  • разработчикам принимающим аналогичное решение, чтобы взвесить за и против
  • менеджерам «непростых» проектов, чтобы лучше понять причины и следствия технических проблем
  • и, конечно, просто любопытствующим

Затрагиваемые в статье вопросы:

  • Низкая компетенция разработчиков, и что с этим можно поделать?
  • Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
  • Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

Читать полностью »

image

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.
Читать полностью »

Пилим монолит - 1

Перед этим опусом стоит крайне сложная задача — описать принципы перехода от монолита к микросервисам, при этом не рассказывать читателю то, что он и так знает. Микросервисная архитектура настолько популярна, что автор свято уверен, что каждый второй читатель работал с такой архитектурой или же ненавидит её всеми фибрами своей души. Также бытует мнение, что большая часть разработчиков, читающих эти строки присоединились к проекту, построенному на микросервисах, уже после того, как он стал микросервисным. А та малая часть ребят, которые самостоятельно проделывали путь от монолита к микросервисам уже достаточно опытны, чтобы работать на должностях старших разработчиков, архитекторов или менеджерами проекта.Читать полностью »

Роман Ивлиев

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

Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:

  1. Что такое фреймворк, и зачем их пишут.
  2. Почему для некоторых языков их десятки, а для некоторых — единицы.
  3. В чём плюсы и минусы применения.
  4. Наиболее распространённые мифы.
  5. Использовать или нет — примеры из жизни.
  6. Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

Читать полностью »

DIY DI в Ruby - 1

На Хабре уже была статья, посвящённая Dependency Injection в Ruby, но упор в ней был больше на использование паттерна IoC-container с помощью гемов dry-container и dry-auto_inject. А ведь для использования преимуществ внедрения зависимостей совершенно необязательно городить контейнеры или подключать библиотеки. Сегодня расскажу о том, как по-быстрому реализовать DI своими руками.

Читать полностью »

Введение

Если ты, дорогой читатель, являешься наемным сотрудником, то с недавних пор твой работодатель каждый месяц обязан сдавать за тебя отчет в Пенсионный фонд под названием СЗВ-М.

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

Зачем это нужно? Ну, по мнению Путина В. В., у нас в стране "слишком много бухгалтеров", поэтому вот и сделали еще один ежемесячный отчет.

Мера обсуждается в России уже более десяти лет: считается, что из-за сильных различий в двух видах учета в стране слишком много бухгалтеров (в России насчитывается три миллиона бухгалтеров, что в 2,5 раза больше, чем в США).

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

PVS-Studio and NASA World WindИногда полезно оглянуться и посмотреть, как мог помочь анализатор в старых проектах, и каких ошибок можно своевременно избежать, если использовать анализатор регулярно. В этот раз выбор пал на проект NASA World Wind, который до 2007 года разрабатывался на языке C#.

NASA World Wind — это интерактивный глобус, позволяющий увидеть любое место на Земле. Для работы проект использует базу публичных снимков со спутника Landsat и проект моделирования рельефа Shuttle Radar Topography Mission. Первые версии проекта создавались на языке С#. Позже проект продолжил своё развитие на языке Java. Последняя выпущенная на C# версия — 1.4. Хотя C# версия уже много лет как заброшена, это не помешает нам проверить проект и оценить качество кода, разработчиком которого является NASA Ames Research Center.

Зачем мы проверили старый проект? Нам давно предлагали проверить что-то из проектов NASA и вот мы случайно набрели на этот проект. Да, эта проверка не принесёт никакой пользы проекту. Но такой цели в этот раз мы и не ставили. Мы просто хотели в очередной раз продемонстрировать пользу, которую может приносить статический анализатор кода PVS-Studio при разработке, в том числе и компании NASA.

Читать полностью »

Переход от монолита к микросервисам - 1

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js