Программисту о качестве
Оригинал взят у pavel_koryagin в Программисту о качестве
Дорогие программисты, давайте определим качество и пути его достижения.
Во-первых, всё что мы делаем - это дизайн. Во-вторых, мало кто понимает, что такое дизайн. Даже те, кто уже слышал правильный ответ.
Что такое дизайн
Слово дизайн облипло довольно чуждым ему смыслом: броский внешний вид - в массовом сознании это и есть дизайн. Или процесс его изготовления. Или вообще внешний вид. Для внешнего вида я использую слово «декор», чтобы отличать его от дизайна.
Если же вы попадёте на проповеди матёрых профессионалов в области дизайна (А. Лебедев, А. Горбунов, Стив Круг, Тим Браун, много их), то, с 10-го захода, придёте к выводу, что дизайн - это решение проблем.
Именно так, в самом общем виде. Ок, устойчивое и изобретательное решение проблем. Если вы приехали на стрелку и порешали проблемы - это ещё не дизайн. Если использовали бельевую прищепку, чтобы повесить бельё - тоже. А если приклеили на шкаф клейкий лист с одним словом, сократив потери времени кладовщика на, скажем, 3% - это уже дизайн.
Вы можете сказать, а не инженерия ли это? В общих смыслах это, кажется, синонимы. А узких смыслов у обоих слов несколько. Пресловутый декор тоже можно признать одним из узких смыслов слова дизайн.
Правильный смысл может понять знание английского. Существительное design означает проектирование.
Зачем это нам
Ок, определение дано. Хотя я не верю, что оно уже усвоено, но таки продолжим. Какое отношение это имеет к качеству?
Мы решаем проблемы наших клиентов. Очевидно же? Причём мы передаём им готовые решения. Мы всегда что-то изобретаем, часто по-мелочи, но именно изобретаем. Всё, что полагается работой кодера, постепенно всасывается в используемые инструменты: библиотеки, IDE, инструменты проектирования.
Кодер не нужен. Кодер - это кассир в супермаркете. Кассир не делает никакой принципиально человеческой работы. Это просто устройство ввода-вывода, ожидающее, когда его вытеснит с работы дозревший алгоритм распознавания образов. Кодер ждёт, когда инструменты разработки разовьются до прямой трансляции идей дизайнера/инженера/разработчика/аналитика в работающую программу.
Прямая трансляция - это не обязательно подключение компьютера к мозгу. Нет, достаточно всего лишь языка или UI, не создающих так много рутинной работы, чтобы нанимать для неё низкоквалифицированного помощника.
Итак, мы решаем проблемы наших клиентов. Устойчиво и изобретательски. А это и есть дизайн. А значит, нам полезны те знания о дизайне, которые есть у профессиональных дизайнеров.
Грааль
Есть ли в дизайне краеугольный камень? Такая вещь, вокруг которой всё крутится и без которой рассыпается? Есть. Вещь эта, а точнее понятие - смысл.
Возьмём слово у Артемия: http://www.artlebedev.ru/kovodstvo/sections/148/ в тексте бросается в глаза, что автор работает с дизайном в области того, что я чуть выше обозначил декором (вы же не подумали, что для меня дизайн и декор исключают друг друга?), однако всё то же самое справедливо и в гораздо более широком контексте. В тексте параграфа тоже можно заметить «остроумный способ крепления куба к конусу» - это уже вовсе не декор.
Итак, Грааль дизайна - это смысл.
Где добывают смысл
Известные тезисы (отобранные мной и приводимые тут от моего имени, разумеется):
Единица смысла должна быть интеллектуально калорийной (чтобы пойти в зачёт - прим. ПК). © А. Лебедев, § 148.
Смысл всякой деятельности лежит вне её пределов. © В. Тарасов.
То есть:
Идея - это ещё не единица смысла.
Смысл всегда приходит извне. Помните про решение проблем? Проблема всегда внешняя по отношению к своему решению. Другими словами она всегда возникает в среде, не содержащей решения. Не обозначена среда = не может быть проблемы = твоё нечто не является решением ни для чего.
Следствия:
Копирование чужих идей без понимания их смысла (т.е. среды и пользы) ведёт к отсутствию смысла.
Пример 1. Вы спроектировали что-то также, как авторы Yii. У них получилось гениально, а у вас глупо. Почему? Вы не озадачились причиной их решения. В итоге применили не туда.
Пример 2. Вы спроектировали что-то также, как авторы Yii. У вас получилось глупо, но и у них тоже было глупо. Почему? Все мы люди, и даже у величайших из нас есть свое кладбище начинаний. Смотри, что берёшь.
Пример 3. Вы пообещали клиенту, что замена фреймворка на Yii, конечно, будет чего-то стоить, зато потом позволит решать многие задачи гораздо быстрее. Получили добро. Расходы на внедрение превышены в 5 раз. По окончании эпопеи скорость разработки не улучилась, а продолжила деградировать. Почему? Вы не умеете пользоваться Yii. Причина та же, что в примере 1. Умение сказать «давайте сейчас вложимся и получим экономию в будущем» не наделяет тебя умением приносить экономию в будущем.
Изоляция от смежных обязанностей ведёт к провалу в исполнении собственных обязанностей.
Пример 4. Ты проектируешь архитектуру, но не общаешься со стейкхолдерами, как положено аналитику. Ты же не на должности аналитика, зачем тебе общаться? Итог: команда срывает все сроки, а продукт всё ещё не запускается. Как из первого получилось второе? Следим за руками:
Архитектура ПО - это такая невидимая материя, которая будет направлять всех программистов (включая её автора). Она будет подбрасывать интуитивные решения проблем.
Если архитектура не релевантна задаче, то получаем двойной удар: 1) она подталкивает нас решать задачи, которые вообще не должны были возникать и 2) у нас нет архитектуры на те задачи, которые приходят от клиента. Как нет, делали же? Ну вот так: не покрывает она ту область знания, в которой создаётся смысл (ещё не забыли, что смысл приходит извне?). Поэтому каждую задачу приходится решать, как в первый раз.
А обязательно ли выполнять работу аналитика? Почему бы её не выполнить аналитику? Выбирайте:
Получить неполное описание задачи.
Получить подробное описание задачи в таком объёме (50 листов), который никто из живущих не удержит в голове.
Кстати, в обоих случаях, скажем, ⅔ описанных требований вредны клиенту и будут отменены в ходе работ. Либо не будут отменены и поставят работу колом на этапе пилотного внедрения. Вы же в курсе, что больше половины ИТ-проектов заканчиваются «не получилось»?
Выбрали? Нравится? Дело в том, что знание одного принципа заменяет знание тысячи фактов (ок, десятков фактов в данном контексте).
А что же делает профессиональный аналитик? Зависит от того, какие ещё он роли несёт. Чистый аналитик может быть только кем-то вроде тьютора, который помогает всей команде выполнить работу аналитика. Но его продукт не может быть документом. Да, его продукт может включать всевозможные конспекты и документацию, оформленную по стандартам, но не может быть полностью сведён к ним.
Пример 5. Тебе поручили нанести разметку на дороге. Достаточно подробно описали все неоднозначные моменты: длина и ширина линий, количество мест, расстояние между полосами. Ты сделал:
[Нажмите, чтобы увидеть]
Молодец! Выполнил писаное ТЗ на 100%!
Пример 6. Тебе поручили разработать переносимый компонент Excel-подобной сетки для просмотра таблиц. Для примера привели конкретную таблицу из БД, и посоветовали вынести в отдельный проект.
Ты создал пустой проект, добавил в него миграцию на создание таблицы из примера. Прописал для неё модель. Настроил конфиги, создал контроллер. Всё пучком, 80% усилий потрачено. Последним шагом ты сделал вьюшку с вёрсткой в , захардкженным списком столбцов и стандартной формой редактирования.
Принимающий твоё изделие спросил: «Какую ты вообще задачу решал?», в смысле нахуа это всё вообще было нужно и где то, что с тебя требовалось?
(Пример вымышленный, но написан иносказательно к нескольким реальным инцидентам. Я стесняюсь их описывать без купюр, раны ещё не затянулись)
Стейкхолдеры знают принципы лучшей архитектуры для порученного тебе проекта. Только не спрашивай их словами.
Представь грампластинку. На ней есть слова, но это не то, ради чего она существует. Музыка на ней тоже есть, но ты не можешь ещё просто взять и прочитать. Тебе нужен специальный прибор.
Также и с внешними смыслами. Всё это уже есть в людях и предметах, в среде которых возникла та проблема, решение которой поручено тебе. Но нужен инструмент для их извлечения. Вот мой тулбокс навскидку:
Дизайн-мышление (см. выше).
Умение задавать вопросы.
Умение получать ответы. Это комбинация предыдущего пункта со скиллом психолога на горячей линии. Ок, если горячая линия пугает, то пусть будет хороший воспитатель детсада.
Критическое мышление. Относись к своим идеям, как гипотезам. И к чужим тоже. То есть:
Сомневайся в них.
Проверяй факты.
Умение отличать важное от неважного.
Тут должны быть несколько абзацев текста о том, что часто цепочка смыслов не разматывается логикой и опросами, а недостающий элемент находится в момент приступа любопытства. Но я уже порядком подзадолбался, чтобы писать подробно.
Пример. Раскапывал я, на что же в Yii2 на самом деле обращает внимание алгоритм функции ActiveRecord::__get(), и случайно выяснил, как в Yii2 спроектированы реляции. А по учебнику они мне казались глупыми - я упустил одного очень важное звено, которое случайно мной прочиталось в исходниках Yii2 по совершенно другому поводу. Это также иллюстрация на темы: а) не делай поспешных выводов, б) будь готов пересматривать свои убеждения.
Резюме
Смысл твоей работы вне её.
Выяснить внешний смысл - твоя работа. Даже если на то есть другой человек - он, конечно, поможет, но за тебя не сделает.
Всегда выстраивай цепочку смыслов от первоисточника до того элемента, на который сейчас смотришь. Держись за неё, как за путеводную нить.
Не можешь сформулировать решаемую проблему и обозначить среду, в которой она возникает - не владеешь смыслом.
Сомневайся во всём на свете! Проверяй факты.
Хорошая архитектура - в голове клиента, а не в твоих идеях. Инструмент для её оттуда извлечения - в спинном мозге* хорошего разработчика. Стань хорошим разработчиком, снарядись полезными привычками.
Не делаешь этого - становишься просто кодером. А кодеры (в перспективе) не нужны.
Есть такое искусство - отличать важное от неважного. Надо овладеть. Не задолбай клиента выяснением смыслов, внешних, по отношению к тебе. У него ментальный бюджет на общение с тобой тоже не резиновый.
Я обещал определить качество? Пожалуйста:
Решение ключевых проблем клиента, вне зависимости от степени их осознанности.
Решение проблем клиента, осознаваемых им. Быстро.
Решение остальных проблем клиента. Больше - лучше.
Не решать задачи, которые не должны возникать в проекте. Держитесь за цепочки смыслов. Расплата за ненужную работу - гораздо больше, чем ресурсы, прямо потраченные на решение ненужных задач. От таких решений потом шлейф эффектов, влекущий новые потери.
Сноски
*) В физиологическом плане соврал, конечно. Речь про attitude (жизненную позицию) и набор привычек. Во владении, скажем, лыжами - это точно спинной мозг. А тут считайте метафорой.