«Если не уметь думать, то может показаться, что программирование — это просто печатание команд на клавиатуре».
Уорд Каннингем, из предисловия к The Pragmatic Programmer
Разработка ПО — проектирование, решение проблем, изобретение оптимальных новых алгоритмов, изучение нового языка программирования, рефакторинг путаного кода и превращение его во что-то более легкое и красивое — все это сложная умственная работа.
Например, вам может потребоваться решить задачу, которую еще ни разу не решали — или никто до вас не решал. Либо раньше вам уже приходилось решать такую задачу, но вы ни в коем случае не хотите повторять собственных ошибок и собираетесь продумать более оптимальный вариант решения. Порой вам требуется понять написанный кем-то код, чтобы изменить его или отловить какой-то вредный баг. На все это может уйти немало времени, но в конце концов окажется, что для всего этого понадобилось написать не так много кода.
Но при разработке ПО приходится решать и иные задачи, требующие не столько умственного напряжения, сколько набора целых простыней кода. Когда уже ясно, что надо сделать и как это сделать, остается руками набрать массу кода, необходимого для выполнения задачи. Вы уже делали это раньше и просто должны сделать снова: еще скрипт, еще экран, еще отчет и т.д. В то же время большую часть умственной работы кто-то уже выполнил за вас: подготовлены каркасные модели, вам в точности известно, как должно выглядеть и работать приложение, как в нем организуется поток задач, API подробно описаны в спецификациях. От вас требуется просто все это написать и по возможности допустить поменьше ошибок.
Отладка — это мышление. Исправление бага и обеспечение того, чтобы правка была протестирована и выдана в готовом виде — это в основном набор текста. Проектирование и ранние этапы разработки, техническое зондирование для проверки качества технологии, разработка архитектуры — это напряженная умственная работа. Подготовка третьего, четвертого или сотого экрана, а также любого отчета — это написание кода. Проектирование пользовательских взаимодействий (UX) и прототипирование: мышление. Планирование поддержки CRUD-операций и конфигурационных экранов: набор кода. Зарождение классной идеи для нового мобильного приложения: мышление. Ее реализация — набор кода. При решении распространенных бизнес-проблем требуется писать очень много кода. При оптимизации бизнес-процессов на уровне кода необходимо много и напряженно думать.
Среди наших коллег есть и те, кто много думает, и те, кто в основном пишет код. Все дело в том, что они заняты принципиально разной работой и, следовательно, управлять ими нужно тоже по-разному.
Иногда программирование — это просто печатание кода
«В первую очередь мы наборщики текста и лишь потом — программисты».
Джефф Этвуд, Programming Horror
Многие бизнес-приложения, в сущности, неглубокие. В них есть множество таблиц баз данных, файлы с множеством информационных элементов, масса экранов и отчетов, исключительно похожих на другие такие же экраны и отчеты, огромное количество интеграционной работы с кучей полей, которые должны отображаться между различными точками программы. Наконец, есть определенные ограничения, необходимые для соответствия правилам, а также эксплуатационные зависимости, о которых необходимо позаботиться. Длинные списки функциональных требований, куча вопросов, на которые нужно ответить и убедиться, что все правильно понимают поставленные требования, масса деталей, которые нужно запомнить и отслеживать.
Банковское дело, страхование, учет, финансовая отчетность и биллинг, управление материально-техническими ресурсами и ERP-системы (планирование ресурсов предприятия), CRM-системы (управление взаимоотношениями с клиентами), приложения для операционных отделов (back office), а также другие бухгалтерские и учетные системы — вот как разнообразен этот бизнес-софт. Таковы же многие веб-порталы и интернет-магазины. Не следует забывать и о техподдержке; обновления платформы и работа по интеграции системы, изменения в правилах и налоговые изменения — все это рутинная кропотливая работа.
Допустим, вы строите дом, или мост, или торговые ряды, а может быть, ремонтируете такое сооружение. Это большие, зачастую нарастающие проблемы, решение которых порой обходится недешево. Приходится готовить множество документации (набирать текст). Но такие задачи уже многократно выполнялись ранее; как правило, подобная работа заключается в решении проблем с применением хорошо проработанных паттернов, известных инструментов и методологий.
Когда проектирование закончено, основная работа сводится к пониманию всех деталей и умению обращаться с ними, а также к управлению людьми и координации усилий — то есть к написанию готового кода. Это классический пример проект-менеджмента: бюджетирование, планирование, отслеживание расходов и изменений, а также эффективное делегирование задач. Основными аспектами работы являются логистика, масштабирование, согласованность и эффективность — так, чтобы весь проект не «сошел с рельсов».
Думай, думай, думай
Существуют и иные задачи: проектирование игрового движка, торгового алгоритма, логистической схемы, системы онлайнового управления рисками или, например, оптимизация систем контроля, работающих в реальном времени. В таких случаях программист занимается не столько набором кода, сколько умственной работой. К подобным системам предъявляются очень высокие нетехнические требования (масштабируемость, производительность в реальном времени, надежность, целостность и точность данных), в них действует сложная логика. Тем не менее, такие программы применяются для решения ограниченного круга проблем. Несколько умных людей могут осмыслить такие задачи и найти решения для большинства из них. В таких случаях также требуется набирать определенное количество кода. В частности, это касается обрамляющего кода, служебного и связующего кода, но основная часть работы обычно выполняется в удивительно небольшом количестве кода. Чтобы в этом убедиться, достаточно отбросить все неудавшиеся эксперименты и прототипы.
Здесь мы затрагиваем самые волшебные аспекты программирования — проприетарные или патентованные алгоритмы и дизайнерские озарения, лежащие в основе успешной системы. Для выполнения такой работы требуется проводить массу исследований, заниматься прототипированием, уметь решать проблемы, а также обладать настоящей технической хваткой, глубокими знаниями предметной области или и тем, и другим одновременно.
Печатание и мышление — это разные виды работы
Необходимо сразу определить, какая работа будет наиболее важна в будущем проекте — набор большого количества кода или мышление. Исходя из этого, принимаются решения о том, сколько человек должно быть в команде и каким людям вы готовы поручить такую работу. Разумеется, будут отличаться и способы управления такими командами, и принципы взаимодействия в них. Набор кода можно организовать методом аутсорсинга. Мышление — нет. Вам придется определить, для решения каких проблем достаточно просто уметь набирать код, а в каких случаях этого недостаточно. Также важно уловить момент, в который мыслительная работа в основном заканчивается и начинается кропотливый набор кода.
Умственная работа хорошо протекает в небольших командах тесно взаимодействующих специалистов — и должна выполняться именно ими. Может быть, достаточно будет всего одного гения, работающего самостоятельно. На этапе подготовки проекта или в поиске решения для сложной проблемы, экспериментирования вам не требуется большой команды (и правильно). Кто бы ни работал над проблемой на этом этапе, он должен полностью погрузиться в решение задачи, уделить время на исследование альтернатив, иметь право на ошибку и научиться чему-то на ней, либо просто отойти и посмотреть в окно, когда возникнет дефицит идей.
Вот где иногда допускаются фундаментальные ошибки, порой чреватые разрушением архитектуры, завалом проекта, крахом карьеры. Достаточно неверно выбрать технологическую платформу. Неверно оценить допустимые отклонения в реальном времени. Потратить слишком много времени, чтобы устранить трудноразрешимые проблемы (а то и вообще не решить их). Набрать в команду не тех людей или неверно поставить задачи, которые требуется решить. Пропустить финиш.
При управлении работой такого рода необходимо привлечь к ней самых лучших людей, которых вы в состоянии найти, убедиться, что у них есть вся необходимая информация и инструменты, постоянно поддерживать их концентрацию на работе, определять возможные внешние риски и заблаговременно устранять проблемы, мешающие решению задачи.
Мышление непредсказуемо. В нас не встроена функция «копировать-вставить», так как информацию неоткуда копировать и некуда сравнить. Невозможно учесть все, так как вы никогда не можете точно очертить объемы того, что вам неизвестно. Просто старайтесь выдать наилучшее решение, которое можно подготовить за имеющееся время.
Набор кода — предсказуемая работа. Ее объемы можно и нужно оценивать. Самое важное — учесть весь код, который должен быть написан, сделать поправку на все мелкие ошибки и отклонения от курса, которые могут возникнуть по ходу работы, так как подобные огрехи будут накапливаться очень быстро. Неаккуратность и срезание углов, непонимание требований, пренебрежение тестированием, копипаста — за все это вам придется понести дополнительные расходы как сегодня, так и в будущем.
Набор кода — довольно неквалифицированная работа. Для этого нужны не эксперты, а просто такие люди, которые вполне компетентны, разбираются в основах языка и инструментах, те, кто будет аккуратно следовать указаниям и терпеливо напишет весь нужный код. Конечно, несколько senior-разработчиков могут делать такую работу быстрее толпы простых кодеров, но только пока эта работа им не наскучит. Управление толпой кодеров требует определенного набора навыков, иного подхода и иных навыков. Вы должны быть и политиком, и дипломатом, и логистом, и законодателем стандартов, а также администратором и экономистом. Вы управляете рисками, связанными с проектом и с людьми, а не техническими рисками.
Со временем проект переходит из фазы умственной работы в фазу набора кода. Рано или поздно оказываются решены почти все сложные проблемы вроде «Не знаю, что еще мы должны сделать и как это нужно сделать». Большинство неизвестных моментов проясняется. Приходит время прорабатывать детали и обеспечивать работу системы.
Объем работы по набору кода увеличивается по мере того, как растет ваша клиентская аудитория, приходится иметь дело с все новыми интерфейсами, разворачивать систему в новых местах и обеспечивать кастомизацию, заниматься административными делами, поддержкой и проблемами соответствия правилам. Система растет, но большинство проблем уже известны и решаемы. Предстоит изучить массу чужого кода, чему-то из него научиться, а что-то скопировать. Для этого нужны люди, которые умеют быстро схватывать суть работы, а также быстро печатать.
Мышление и печатание
Итак, и умственная работа, и набор кода — равнозначные части разработки ПО.
В статье «Программирование — не просто набор текста» Брендан Энрик объясняет, почему парное программирование действительно работает. Дело в том, что такая методология помогает людям одновременно заниматься и мышлением, и печатанием кода.
Оба напарника при этом думают, но о разных вещах. У одного из разработчиков все время есть под рукой клавиатура, и он сосредоточен на том, как выразить в коде все необходимые идеи (и достаточно быстро). Он набирает код, и размышляет именно об этом коде, а не о структуре приложения.
Второй напарник, не занятый набором кода, все это время также мыслит. Он прослеживает в уме тот путь, который у него на глазах проходит наборщик, не задумываясь при этом о синтаксической стороне кода. Правильность синтаксиса должен обеспечить как раз его партнер. Программиста, работающего без клавиатуры, в данном случае можно сравнить со штурманом. Он следит за тем, чтобы программа оставалась на правильном пути и шла по оптимальному пути к решению задачи».
Мастерство разработчика не сводится к умению набирать код, равно как мастерство наборщика не ограничивается скоростью нажатия на клавиши. Разумеется, программист должен в совершенстве владеть фундаментальными навыками программирования: хорошо знать язык, разбираться в инструментах и уметь ими пользоваться, уметь ориентироваться в коде и хорошо его писать — и, конечно, быстро управляться с клавиатурой. Нельзя недооценивать важность быстрого набора. И при этом не следует писать код чрезмерно быстро — скорость набора не должна мешать мышлению.
Джим Бёрд
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.