Борьба за качество в веб-приложениях, депрессия, драконы и Вестерос

Веб-разработку никто, изначально, не планировал. Даже в страшном сне. В генеральном плане, при поддержке крупных корпораций и науки, люди воспринимали создание дорогостоящих IT-систем как близконаучный процесс, доступный избранным, в котором очень важно знать не только быстро забывающиеся большинством алгоритмы (я 5 раз заучивал с листочком принцип обхода красно-черного дерева — взгляд на покачивающиеся бедра ранней весной полностью стирает полученную информацию), но и внутренности железа. Это священнодействие, разумеется, нужно было правильно (слава великому Демингу) контролировать, измерять и тестировать и тестировать и во веки веков, аминь. Но что-то сразу пошло не туда и не так…

Борьба за свободу самовыражения

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

На эти искажения здравого смысла оперативно отреагировало движение свободного программного обеспечения, благодаря которому мы имеем сейчас бесплатные, качественные и очень полезные и на досуге и в бизнесе инструменты, к которым мы очень привыкли: Linux, MySQL, PHP и многие, многие другие.

Очень хорошо ценность свободного ПО видна в контексте запрета на использование Android в устройствах Huawei. А активное развитие современных криптовалют добавляет масло в огонь — криптопанки всерьез взялись за дело и вытягивают почву из-под ног традиционных институтов и технологий.

Панки в разработке — скриптинг

Нельзя сказать, что программное обеспечение получалось плохим. Просто его создавали долго, потом долго тестировали, а потом получали то, что уже устарело. Процесс, все же, рабочий. Эволюция: за миллионы человеко-часов тестирования баги уйдут и вместо динозавров останутся ящерицы и тараканы, зато… живучие. Люди тратили много времени на решение низкоуровневых системных задач, забывая про бизнес-цели. Ситуацию усугубляло поверие, что чем больше программистов, тем быстрее можно написать систему. Желание избавиться от служения коду во славу его использования для дела породило вначале дикую жажду, а потом и реализацию целого класса языков программирования, целями которых стали безопасность, скорость разработки, простота и лаконичность: Python, PHP, Ruby, Lua, JavaScript. Несмотря на теоретические ограничения: отсутствие статической типизации, наличие runtime и сборщика мусора, откровенную лень и семантическое раздолбайство, технологии активно развиваются и приносят гораздо больше пользы, чем вреда.

Дырявые концепции

Довольно быстро стало понятно, что программировать научить палкой можно, а вот писать простой и понятный другим представителям Homo Sapiens код, решающий бизнес-задачу — на порядки труднее и нужно этого самому сильно захотеть. За озвучивание этой простой идеи чуть заживо не сожгли святого Дейкстру. Это примерно как писать книги (нужно большое желание учиться и идти к цели = талант) и писать посты в фейсбук (нужна учетка). Но понять это дано далеко не всем, ведь проще выучить грамматику языка, чем научиться писать на нем захватывающие вещи и поэтому до сих пор продолжаются ожесточенные споры:

1. какой язык программирования лучше
2. какая операционная система правильнее
3. писать тесты до, во время или после супружеской близости
4. с какой ноги утром вставать и т.д.

Традиционное противостояние писателей и библиотекарей, музыкальных критиков и звезд сцены, создателей компаний и менеджмента среднего звена :-)

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

Оказалось, что жизнь настолько разнообразна и задачи, которые решаются с помощью программирования, иногда до такой степени оригинальны, что какая-то одна традиционная концепция в лоб просто не работает или рождает ломающие сознание «дырявые концепции»:

1. Объектно-ориентированное программирование хорошо работает в играх и графических системах, но в Python его сильно недолюбливают как ограничивающую свободу концепцию. Помню, как в PHP увидел класс Tools, расширяющий класс Utils
2. Функциональное программирование прекрасно справляется с обработкой потоков данных и бигдаты (Apache Spark), но Haskell так и не «взлетел», ведь жизнь это не математическая абстракция, а, часто, набор разбегающихся и хохочущих костылей
3. Скрипты на PHP, Python, Ruby отлично связывают между собой разные технологии и компоненты приложения, на Lua описывают сценарии в играх, но писать на них высоконагруженные сетевые сервисы — лучше застрелиться сразу и в голову. В Python даже не думают о добавлении многопоточности.

В общем, получилось так, что решать все задачи одним инструментом (Java Spring), мягко говоря, неэффективно и лучше подобрать правильный инструмент к задаче, чем забивать микроскопом гвозди. Но, к сожалению, учиться не любят…

Сложность — главный враг

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

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

Люди — прекрасны

Сколько десятилетий развивались языки программирования и технологии в одном и том же направлении:

1. Эффективный и быстрый код, близкий к железу. Дырявый, непродуманный, компилятор, подставляющий разработчика. C/C++.
2. Сборщик мусора, безопасный язык. Мощные концепции. Довольно строгая типизация. Но теряем скорость и расходуем оперативную память. Иногда пишем под сборщик мусора. Java, C#, Swift (да я в курсе про RC).
3. Совсем простой язык, быстрый вход, быстрая разработка. Но отсутствие типизации (риски) и сборщик мусора. PHP, Python, Ruby.

И тут появляется отличная идея: «ребята, мы идем не туда от слова совсем; а давайте сделаем компилятор умнее?». Рождается Rust, который удовлетворил практически все запросы:

• Эффективный и быстрый код, zero-абстракции
• Умный компилятор, защищающий разработчика от ужасных ошибок при работе с памятью
• Нет сборщика мусора, Карл. ЕГО НЕТ!

Слава уму и красоте!

Веб-разработка — как такое вообще могло случиться?

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

1. Отрисовывать эффективные интерфейсы с помощью HTML/CSS. Да, они не всегда были идеальными, но они эффективны и, особенно сейчас, чрезвычайно мощны
2. Надежно хранить данные приложения в MySQL
3. Лазать в сеть через Linux
4. Передавать сообщения между компонентами с помощью взрослых архитектурных шаблонов, таких как очереди

Никто, на самом деле, не понимает, почему произошла эта революция, но факт остается фактом — синергия простых технологий породила ядерную бомбу. И пусть PHP продолжает с удивлением заимствовать из других языков давно отшлифованные концепции, и пусть Python никогда не внедрит многопоточность — именно скриптинг, именно простота, лаконичность и высокий уровень абстракций позволили совершить переворот в программировании и решать бизнес-задачи быстро, просто и эффективно в 3-5 строк кода.

Синергия продолжается — BigData и Machine Learning

Именно по вышеописанным причинам и взлетел Python для задач обработки и анализа данных. Сидели математики, писали на своем «ужасном», слаботипизированном, Duck typing инструменте, который и в руки взять страшно — нет компилятора, вау, какая же беда! Писали, писали и… написали комплекс библиотек высочайшего класса:

1. Numpy — высокоскоростная обработка многомерных массивов, такого в PHP нет и не предвидится
2. Pandas — мощная реляционная обработка данных в памяти
3. Matplotlib, Seaborn — великолепные инструменты визуализации данных

Скачал свободно распространяемый дистрибутив Anaconda, установил пакеты и все, твори бигдату, запускай нейронки и предсказывай будущее! Бесплатно.

Однако это еще цветочки. Ягодки — это очень популярная стандартизированная интерактивная среда разработки и коммуникаций — Jupiter Notebook. Первое впечатление — регресс. Ну как, есть же мощные IDE? Но потом приходит понимание — это большой шаг вперед. Роль Jupiter примерно сейчас такая же, как у веб-разработки в момент ее появления: быстрый результат, быстрые коммуникации, критичные для бизнес-задач возможности и открытые стандарты.

Веб-студия и веб-программист — атмосфера

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

1. В отличии от мира С, C++, где принято выпускать 1-2 релиза в год, тут выпускают релиз раз в неделю, т.е. разработка происходит на сверх-световых скоростях
2. В отличии от мира C# и Java, где принято увлекаться объектно-ориентированным программированием и все покрывать юнит и интеграционными тестами, тут часто бывают настолько сложные и нестандартные концепции и задачи, что скрипт из 10 строк может решить задачу быстрее и красивее фреймворка из 10 классов. Тестировать верстку и скрипты, увы, автоматически очень сложно и дорого, поэтому часто тестируют глазами и на пользователях :-)
3. В отличии от мира функционального программирования и красоты функционального выражения задачи, тут подходы к решению выражаются через, в прямом, но хорошем смысле, зад, и это оправданно — экономическая целесообразность ужасного процедурного скрипта, который можно выбросить и написать новый (и так 10 раз)
4. В отличии от традиционного софта тут идеи быстро реализуются в коде, проверяются, отбрасываются и лучше отбираются. 90% кода — умирает, 10% — живут и радуют клиентов. Лучше иметь надежно работающие и понятные 10 строк, здесь и сейчас, чем 1000 академичных строк где-то в функциях и классах с неопределенной дырявостью и покрытостью автотестами.

Но главное — это люди. В среде веб-разработчиков они особенные. Они не то, что не любят писать код, скорее — ненавидят. Объект преклонения веб-разработчика — скорость решения задачи. Если будет выбор между 2 строками кода на PHP и фреймворком из 20 классов, выбор будет в сторону более сексуального своей лаконичностью решения. Именно поэтому, если можно выбрать писать или не писать код, профессиональный веб-программист выберет первое и проведет больше времени с девушкой, например, в читальном зале библиотеки, изучая древнеиндийский эпос, а новичок — второе, пока не осознает, что чем больше кода, тем больше в нем может быть ошибок, а в автотестах к коду ошибок будет еще больше и поэтому лучше написать 5 строк и быстро проверить их глазами, чем создать видимость качества и исправлять любую ошибку неделями :-)

Как управлять качеством веб-проектов

К этому моменту Вы, скорее всего, уже усвоили, что веб-разработка — это особая, новая и очень бурная область программирования, наполненная очень непохожими на коллег инженерами, ненавидящими код и горящими желанием решать задачи как можно быстрее и с помощью готовых и простых инструментов. Именно поэтому веб-разработчики нередко вырастают в системных администраторов, которые больше любят зарабатывать, чем работать. И да, еще ассоциация, веб-разработчик это скорее ботан с пистолетом, чем самурай 8 дана с мечом, растяжками и набитыми костяшками. Сделаем ставки, кто победит в уличном бою, БЕЗ правил?

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

1. Скорость обхода конкурента важнее качества. Если веб-проект все-таки взлетит и раскрутится (1 из 10 или меньше), то можно его переписать «правильно», но, как ни странно, никто их не переписывает и они живут, причем нередко успешно и безбедно, годами.
2. Проект делается для акции, одноразовый и о внутреннем качестве можно с чистой совестью забыть. Вероятность, что кто-то полезет в код потом, равна 0.00001% (я лазил в такие проекты; под Новый Год они могут стать снова популярными).
3. Заказчики не хотят писать автотесты, увеличивающие стоимость разработки в 2 раза и раздувающие архитектуру классов в наборы абстрактных и торчащих наружу концепций. Но иногда, для библиотек и, с большой вероятностью, повторного использования, соглашаются.
4. Заказчики готовы помогать в тестировании веб-системы, часто понимая (к сожалению, бывают исключения), что при таких сроках разработки (4 месяца на весь проект под ключ) и борьбы с автотестированием и раздуванием кода на уровне договора добиться одинакового качества всех компонентов системы нельзя.
5. ТЗ не нужно, ибо оно постоянно меняется, устаревает и нужно держать отдел документирования для его актуализации. Проще креативить на лету, смотреть результаты и крутить штурвал Agile.
6. Дурака работа любит

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

1. Используемые подходы в проектировании, разработке и тестировании не должны приниматься на веру, религиозно. Важно стать Фомой. Вот нужно писать автотесты, значит нужно. Кому нужно, э? До-ка-за-ть экономическую целесообразность. Зачем автотесты к сайту-визитке, если быстрее все проверить глазами? Зачем писать мок-объекты к используемому фреймворку, если это порождает тонны кода, который может содержать ошибки и который нужно сопровождать. Не проще написать 10 строк ясного кода без DI?
2. Оценить срок разработки веб-проекта, с 3-5 днями на проектирование, строго говоря, нельзя, поэтому оценка берется с наиболее похожего веб-проекта и умножается на 666
3. Иногда, когда это экономически целесообразно, нужно снять критичные риски на прототипе, провести превентивное нагрузочное тестирование
4. Важно проконтролировать, что используются готовые инструменты, фреймворки, технологии и есть четкое понимание, что чем больше кода, тем больше ошибок придется исправлять
5. Важно, очень важно, обеспечить максимально интенсивные коммуникации, позволяющие полностью погрузиться в веб-систему, ощутить ее движение и архитектуру и создать эффект «много глаз смотрят на код». Вспомним, что в Linux, успешной операционной системе, долгое время не существовало автоматизированного тестирования, а если бы там сразу был Test-Driven Design, то ее, скорее всего, до сих пор бы запускали. Но зато в Linux сразу был глубокий аудит кода и централизованная система принятия изменений. Нужно это хорошенько прочувствовать.
6. В подобных проектах можно значительно снизить риски, если подключить опытных инженеров для планирования низкоуровневой архитектуры и принятии решения о необходимости создания прототипа. Как только есть ощущение, что идет раздувание требований и бюджета, быть беде — нужно совершить пару-тройку суицидальных выходок, забрызгать кровью несколько стен и Agile-досок. Жертва во славу успеха проекта — что может быть круче?

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

Но самое сложное, к сожалению, мы оставили за кадром. Самое сложное — научиться балансировать на бритве выбора акцентов. Вы, веб-разработчик, стоите без доспехов, в облегающих плавках семейниках и майке с надписью «Agile», с крутящейся пращой в руках, перед великаном. И если попадете ему в лоб — проект ваш. А промажете несколько раз подряд — вас затопчут отряды самураев 8 дана с хорошей растяжкой и набитыми костяшками, которые, поедая ваш труп, будут плеваться косточками и смеяться: «хотел на PHP в 50 строк кода решить задачу на 50 классов и 7 фреймворков, сумасшедший». В общем, не промахивайтесь, носите огнестрельное оружие, изучайте веб-разработку и… удачи Вам!