Программирование: искусство, наука, или ремесло?

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

Человек же, по своей природе, не любит неопределенности и пытается понять сложное путем упрощения. Так и программирование часто рассматривают только с какой-то одной стороны, сознательно или несознательно не замечая остальных его свойств.

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

Ремесло программирования: кажущаяся простота

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

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

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

Искусство программирования

Конечно, изредка встречались среди руководителей и специалисты по программированию, что было, то было. Компания, как видим, получается пестрая. Что из этого может получиться? Например, вам могут сказать:
— У нас есть программа в исходных кодах, но она немного не полная. Нужно изучить ее и сделать аналогичную или даже лучше, так как я точно знаю, что у этой программы есть недостатки.

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

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

Это, конечно, смешно, скажете вы, но это уж слишком частный случай! Хорошо, вот вам еще один пример, варианты которого я наблюдал неоднократно. Делать программы приятно вообще, а особенно, когда не несешь за них ответственность. Точнее, когда эту ответственность можно незаметно переложить на кого-то другого. Руководитель как никто другой переживает за успех проекта и поэтому имеет полное право, а может даже обязанность, особенно если у него это немного получается, внести свой скромный вклад в написание программы, которую поручено сделать вам.

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

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

Конечно, программисты видят и не сомневаются. Проект амбициозный, но не слишком долгий, где-то на три месяца. Задача, в общем, не очень сложная. Вам же все объяснили. Документацию писать нет большого смысла, потому что команда у нас небольшая. Тема описана в литературе. Программисты опытные. Да, эти изменения изначально не были предусмотрены, но они, по большому счету, несущественные. Слегка отклоняемся от графика. Ну что ж, всего не предусмотришь. Заказчик понимает, что проект сложный и согласен потерпеть.

Примерно через полгода, один из лучших программистов проекта, после перекура, тихо, но уверенно говорит вам:
— Я уже вообще не понимаю что мы делаем.

Программирование как наука или как измерить труд программиста

Помните как в школе на лабораторной работе по физике вычисляли на практике ускорение свободного падения. Точное значение почему-то не получалось. Когда у меня получилось 9.6 м/c2, и это сильно отличалось от истинного значения, я спросил учительницу что делать. Напишите 9.7, это больше похоже на правду, сказала она. Другими словами, мы верим в идеальную науку, но практика иногда подбрасывает сюрпризы.

Документация полезна, никто не спорит. Но, не во всех случаях. Например, для маленьких проектов она не нужна. Пока пишешь документацию, программа уже давно будет написана, так зачем тратить время. Пользовательский интерфейс самоочевиден. По исходникам легко понять что делает программа. Просто проект нужно сделать срочно. У нас нет технического писателя. Полная документация по стандартам разработки — это слишком сложно. Ее все равно никто не читает! Мы знаем как писать документацию, но для своих проектов мы ее не пишем.
— А если через год в программе обнаружится ошибка, или захотят внести доработки, а программист сменился или просто забыл что он там написал. Что делать без документации если, например, завтра один из заказчиков попросит что-то сделать в одном из проектов?
— Пока что не просили.

— Сколько строк кода в день вы обычно пишете? — эйчар пристально смотрит вам в глаза.
Вообще-то, лучшие алгоритмы часто бывают самыми короткими, думаете вы, мысленно перебирая варианты: двести, тысяча, две тысячи строк… А знаете сколько кода иногда приходится переписать чтобы получить одну небольшую функцию, думаете вы. Вспоминаете случай, когда вы оптимизировали недокументированный код на SQL, и он стал выполняться в несколько раз быстрее, но отчего-то молчите.