Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».
Пришло время ответить на данный вопрос. Я немного затянул т.к. хотел рассказать доклад на одноименную тему на Я.Субботнике. Доклад был очень коротким многие важные моменты пришлось выкинуть. Статья — более-менее полная версия.
Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.
У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.
Так зачем же мы пишем этот плохой код, который изо дня в день замедляет нашу работу?
Потому, что мы тогда вынуждены были сделать что-то быстрее!
Я оставлю вас наедине с это логической несостыковкой… На одной из лекций Роберта Мартина
У нас на DevConf будет не самый обычный мастер-класс. Там не будут рассказывать о новых технологиях или хайлоаде. Будут говорить о коде. Хорошем, плохом. Называется он Принципы хорошего кода на реальных примерах. Расспросим немного автора.
Кто ты и чем занимаешься?
Меня зовут Адель. Я фрилансер. Обычно занимаюсь backend-разработкой. Еще иногда пишу и дописываю плагины для PhpStorm. Из популярных Laravel plugin и .env files support.
Что тебя побудило на такой мастер-класс?
Удрученность текущей ситуации в отрасли. Все одержимы технологиями. В последнее время облачными. Читаешь вакансию, перечисляют используемые технологии, необходимый опыт (который почти никогда, на самом деле, не нужен). Очень круто звучит на собеседованиях. Приходишь на проект. Смотришь на код… и он печально говорит тебе: «Пристрели меня». Смотришь глубже и понимаешь всю его печаль. Он смертельно болен. Как раковые опухоли разрослись классы, которые кто-то, словно в шутку, назвал контроллерами. Как метастазы везде расползлись копипасты. На психологию кода давит то, что он лишь жалкая обвязка для крутых облачных технологий. Но пристрелить дорого.
Инженеры очень любят измерения и числа. Поэтому нет ничего удивительного в том, что они пытаются измерять в численном виде такую нетривиальную штуку, как качество кода.
Метрик для оценки текстов программ придумали немало — от банального количества строк кода в проекте до не столь очевидного "индекса поддерживаемости" (Maintainability Index). Подробно про все существующие способы обмазывания кода всякими метриками можно почитать в этой статье.
В мире Python, конечно же, есть своя штука для оценки качества кода. Она называется radon. Она написана на этом же самом Python и работает исключительно с питонячими файлами.
Most of the processes that people use in their work lives can be represented as some object that goes through some flow. Each flow contains many stages, in each one of them the object can be manipulated by certain group of users.
In this article I want to suggest an approaches to effectively handle such flow based systems.
