«Мы, методологи, проектируем сложные системы, но не принимаем во внимание рабочие характеристики активного компонента этих систем, компонента, который известен своей нелинейностью и изменчивостью – человека».
Алистэр Коуберн

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете».
Стив Макконнелл «Совершенный код»

Совершенность кода

Идеальный код существует – и это не шутка. Нет, космически спутники, безошибочная система управления «ядерным щитом», программное обеспечение АЭС тут совершенно не причём. Идеальный код – это программа, выводящая на экран «Hello world».

Фраза «Здравствуй, мир!» известна каждому программисту. Появилась она в 1978 году, как пример использования языка С, и до сих пор остаётся первым шагом в освоении языков программирования для тысяч студентов по всему миру.

Перейдя по ссылке вы увидите пример «Hello World» на трёхстах языках программирования. Каждый вариант программы является примером идеального, безошибочного, совершенного кода.

На Бейсике программа состоит из 21-го символа. На BIT, Redcode, инопланетном Credits – нескольких сотен. Разница в методологии между этими языками – колоссальна. Результат выполнения работы один и тот же.

Идеальный код не самый короткий, не самый быстрый, не самый удобный для программиста. ИК – наиболее простой вариант исполнения заданной функции. Надо вывести фразу на экран – выведет. Пристыковать Shuttle к Орбитальной Космической Станции – пристыкует. Функция не требует выводить «Hello World» в зелёном неоне, не заставляет Shuttle варить нам кофе. Мы должны сделать лишь то, что должны, так просто, как сможем.

И слепой увидит – код, который пишите лично вы, с точки зрения математики, ужасен.

Идентификация кода

Софт, которым мы пользуемся ежедневно, разрабатывали от одного до нескольких сотен программистов, на протяжении пары часов или нескольких лет. Кто-то из них сидел на кофе и сигаретах, кто-то работал по ночам, нашлись и те, кто программировал по несчастной случайности; были наркоманы, трудоголики, лентяи, гении, посредственности. Финансовый кризис, грязная посуда, сбитая собака – всё отражалась в их головах и в том, что они делали.

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

По некоторым критериям выделяют «японский код» (идеально сформулированная задача – заказ для американских программистов – заказ выполняют нанятые программисты из Пакистана – отладка американскими программистами – мутант, живущий вопреки всем законам природы), «русский код» (код без всяких комментариев и пояснений, если считается 2х2=4, то в программе будет отображено: 2х3 ≠4, 2х4≠4, 2х5≠4 и т.д.), «китайский код» (создан простым и надёжным методом copy-paste, на основе готовых примеров; создатели подобного кода часто не представляют, как программа работает «изнутри», на аппаратном уровне) и др.

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

Современное программное обеспечение ненадёжно, непонятно, а часто – опасно. Если вы купите велосипед, вы сядете на него и поедете. С программным обеспечением всё гораздо сложнее. Конечно, времена когда софт требовалось дополнительно «оттачивать напильником», остались в прошлом. Но и сейчас вы можете быть уверенным, когда-нибудь он откажет. Каждый компьютер и фактически каждая программа рано или поздно зависнут, вылетят или сделают недопустимую операцию. Хорошо, что речь идёт не о ваших внутренних органах, не так ли?

Уязвимость кода

Если бы программы писали программы – мир был бы похож на постный пирожок без сахарной пудры. К счастью или к ужасу пока мир не может обойтись без программистов, которые пишут идеальный код лишь однажды в жизни – переписывая из учебника пример программы «Hello World».

Всё, что будет написано программистом после этих сладких мгновений, это «кофеварка в неоновом свечении» - код, одновременно выполняющий несколько функций с десятком дополнительных бонусов. Заглянув в исходники всего программного обеспечения, созданного человечеством, от NetBSD до mail агента, вы увидите признаки этого странного явления. Дайте двум, не знакомым друг с другом программистам, простую задачу, подкиньте незатейливую идею, и вы увидите, насколько по-разному они подойдут к её реализации. В итоге вы получите две программы, к примеру, на PHP и Perl, которые будут делать не то, что вам хотелось бы.

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

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

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

Эффективность кода

Хоторнский эффект – «Hawthorne effect – это условия, в которых новизна, интерес к эксперименту или повышенное внимание к данному вопросу приводят к искажённому, зачастую слишком благоприятному результату».

В нашем случае каждый новый проект, стартап, неминуемо ведёт к повышению эффективности работы программистов. Потому что проект новый! Однако как только проходит «новизна», интерес к работе у сотрудников резко снижается. Более того, если группе менеджеров дать задачу разработать методологию роста производительности труда – они её разработают и успешно внедрят! Введут пятиминутные перерывы, переставят кактусы, повесят в нужном месте кондиционер, а в другом – усилят освещение. Все эти меры неминуемо дадут положительный эффект. Но лишь на короткий промежуток времени. С тем же результатом вы – как руководитель проекта – можете самостоятельно повышать производительность вашего коллектива. Графики сдачи проектов, зелёные фишки, ползущие по настенному календарю, бесплатный квас (non-alcoholic summer drink), описание угроз мирового кризиса, разосланное по корпоративной почте – всё это даёт положительный результат в течение одного дня. Максимум – недели.

Попытка внедрения любой методологии воспринимается сотрудниками как неудовлетворённость результатами их деятельности. Забросьте в стан программистов двух-трёх менеджеров с блокнотами, а затем послушайте в курилке зубодробящие истории «о грядущем сокращении».

Заглядывая глубже, как оценить работу программиста: по скорости набора и сдачи проекта, по эффективности исполняемого кода? Или индусский метод – «не понятно как, но всё работает прекрасно» - мы можем считать удовлетворяющим результатом? Ответы на эти вопросы пока находятся за гранью современной теории разработки ПО. Но каждый из заданных вопросов говорит нам: правильная оценка эффективности кода даст ключ к совершенной безопасности. Внедрение методологий работы на крупных проектах даёт лишь непродолжительный результат, который можно добиться и другими способами. Мы не можем понять в начале проекта – идеальный ли перед нами код или страшный монстр. Мы не можем понять это и после сдачи проекта заказчику. Некоторые организации, не понимая этого, живут и процветают годами, усложняя жизнь другим.

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

Превосходство кода

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

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

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

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

Не следует тратить на отладку программы 80% времени разработки – всех ошибок не устранить никогда. 80% времени потратьте на создание эффективного кода, 20% - на отладку и вы увидите, как резко сократится количество ошибок.

Развитие софтостроения привело к тому что, пользователь использует 5% от заявленной функциональности. Кажется, перед нами иллюстрация теории «прогресс – маркетинговый миф». В 70-е годы пользователь использовал две-три возможности программы. Потому что больше не было. Сорок лет спустя я включаю Nero 9 и не понимаю, где здесь кнопка прожига диска. Людям по-прежнему хочется использовать две три функции, чтобы не перегружать утомлённый мозг. Откройте список программ на компьютере и проверьте, какие из них были выпущены в этом году. Большинство пользователей в мире используют Windows XP, который вышел в 2001 году. Потому что больше им не надо ничего. Не пытайтесь делать неоновую кофеварку. Вы удивитесь, но большинство хочет просто кофе.

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