Разработка программного обеспечения с самого своего начала и по сей день существует на стыке науки, искусства и ремесла. Постоянно балансируя на границе этих трех сущностей, она, тем не менее, не желает стать ни одной из них. Строгие законы логики с одной стороны, широта выбора алгоритмов с другой, и шаблонные методы решения типовых задач с третьей стороны позволяют рассматривать разработку ПО с совершенно разных точек зрения и делать выводы, иногда противоречащие друг другу.
Человек же, по своей природе, не любит неопределенности и пытается понять сложное путем упрощения. Так и программирование часто рассматривают только с какой-то одной стороны, сознательно или несознательно не замечая остальных его свойств.
В разработке ПО странным образом переплетаются кажущаяся простота и невероятная сложность, жесткие правила и полная свобода, необходимость и необязательность. По опыту работы приходилось не раз наблюдать как сложность и простота в разработке ПО причудливо менялись местами, приводя к совершенно непредсказуемым, хотя и не всегда отрицательным, результатам.
Ремесло программирования: кажущаяся простота
Если хотите получать удовольствие от программирования, оно должно показаться простым. В конце концов, как учил нас основоположник кибернетики Норберт Винер, ничто не мешает представить любой алгоритм как «черный ящик» с данными на входе и результатами на выходе, и если противоречий в этом не замечено, то, вуаля, осталось отдать этот ящик кодерам, выступающим здесь в качестве ремесленников, которые за умеренную плату изготовят продукт, и дело в шляпе.
В самом деле, типов операторов всего-то три: безусловный, условный и циклический. И с помощью этих трех можно запрограммировать без преувеличения что угодно. Куда уж проще. Примерно такую логику берут на вооружение сторонники рассматривать программирование как ремесло. Из этой логики, например, также следует и то, что руководить разработкой ПО может любой здравомыслящий, как он сам в этом уверен, человек. При этом, само собой разумеется, он не обязан быть специалистом в программировании.
Думаете это не так? На моей долгой памяти, не только у меня но и у моих знакомых, программистами руководили специалисты из следующих областей, как говорится, извините, если кого забыл: инженер по трубопроводам, физик, геолог, электронщик, дипломированный фотограф, специалист по английской литературе, и даже романтик с большой дороги без высшего образования.
Искусство программирования
Конечно, изредка встречались среди руководителей и специалисты по программированию, что было, то было. Компания, как видим, получается пестрая. Что из этого может получиться? Например, вам могут сказать:
— У нас есть программа в исходных кодах, но она немного не полная. Нужно изучить ее и сделать аналогичную или даже лучше, так как я точно знаю, что у этой программы есть недостатки.
Вы смотрите на исходники и понимаете, что не хватает модуля с ключевой функциональностью, которую и надо «улучшить». Говорите об этом руководителю, то есть специалисту по чему-угодно-только-не-программированию, и он удивленно и слегка недоверчиво глядя на вас отвечает, что он точно знает что программа, которую он вам дал и есть то что вам нужно, потому что так сказал программист, который и передал ему эту не совсем полную программу.
После чего вы начинаете пояснять свою точку зрения и ненароком вставляете ненужные математические термины из предметной области задачи. И тут наступает момент истины. Ваш руководитель, слегка выпрямив спину, с металлическим блеском в глазах, заявляет, что у него гуманитарное образование, он никогда не любил математику, а точнее, ее просто ненавидит. Занавес. В сознании проносятся видения взрывов звезд и камни, рушащиеся в бездонный разлом земной коры, и мысли о том, что добиться внятных сроков решения задачи не получится в принципе, равно как и оценить предложенный вами способ решения задачи. Даже просто понять что на самом деле хочет ваш руководитель можно будет только после того, как вы несколько раз покажете ему готовое решение, но это будет не-то-что-он-хотел.
Это, конечно, смешно, скажете вы, но это уж слишком частный случай! Хорошо, вот вам еще один пример, варианты которого я наблюдал неоднократно. Делать программы приятно вообще, а особенно, когда не несешь за них ответственность. Точнее, когда эту ответственность можно незаметно переложить на кого-то другого. Руководитель как никто другой переживает за успех проекта и поэтому имеет полное право, а может даже обязанность, особенно если у него это немного получается, внести свой скромный вклад в написание программы, которую поручено сделать вам.
Итак, вам поручено написать программу. Задание более или менее понятно. Сроки… в общем, согласованы. Вы собрались с мыслями, представили в целом что и как будете делать и принялись за работу. И тут получаете письмо от шефа, понятное дело, лично не может, занятой человек, где он сообщает, что сделал на днях библиотеку DLL, которая решает один вопрос для вашей программы, в котором он очень хорошо разбирается. Естественно, эта библиотека пригодится компании и в других проектах.
Вот ведь, талантливый человек талантлив во всем! Интересно, как он эту библиотеку отлаживал, мысленно чертыхаясь думаете вы, понимая, что с этим придется что-то делать. И с видимым энтузиазмом подключаете библиотеку к своему проекту, уже представляя глупое выражение своего лица, когда будете говорить шефу, что после многих тестов, по вашему мнению, глючит именно его библиотека.
В другом варианте, шеф прибегает в комнату программистов и с невинным детским видом подсаживается к одному из них, глядя на процесс написания программы. Затем на шефа, в который уже раз, снисходит гениальное просветление, в котором он понимает, что на самом деле в пользовательский интерфейс, далее по выбору: в базу данных, структуру класса, функцию и т.д., нужно внести изменение, которое будет окончательным и… ну вы же сами видите что так и надо было сделать!
Конечно, программисты видят и не сомневаются. Проект амбициозный, но не слишком долгий, где-то на три месяца. Задача, в общем, не очень сложная. Вам же все объяснили. Документацию писать нет большого смысла, потому что команда у нас небольшая. Тема описана в литературе. Программисты опытные. Да, эти изменения изначально не были предусмотрены, но они, по большому счету, несущественные. Слегка отклоняемся от графика. Ну что ж, всего не предусмотришь. Заказчик понимает, что проект сложный и согласен потерпеть.
Примерно через полгода, один из лучших программистов проекта, после перекура, тихо, но уверенно говорит вам:
— Я уже вообще не понимаю что мы делаем.
Программирование как наука или как измерить труд программиста
Помните как в школе на лабораторной работе по физике вычисляли на практике ускорение свободного падения. Точное значение почему-то не получалось. Когда у меня получилось 9.6 м/c2, и это сильно отличалось от истинного значения, я спросил учительницу что делать. Напишите 9.7, это больше похоже на правду, сказала она. Другими словами, мы верим в идеальную науку, но практика иногда подбрасывает сюрпризы.
Документация полезна, никто не спорит. Но, не во всех случаях. Например, для маленьких проектов она не нужна. Пока пишешь документацию, программа уже давно будет написана, так зачем тратить время. Пользовательский интерфейс самоочевиден. По исходникам легко понять что делает программа. Просто проект нужно сделать срочно. У нас нет технического писателя. Полная документация по стандартам разработки — это слишком сложно. Ее все равно никто не читает! Мы прошли обучающие курсы по официальным методикам разработки проектов. Мы можем создавать документацию, но для своих проектов мы ее не пишем.
— Но вы же разрабатываете программы на заказ. Вашими программами пользуются клиенты, перед которыми вы имеете какие-то обязательства, по крайней мере по поддержке ваших программ. А если через год они найдут в вашей программе ошибку? Или захотят внести доработки, а программист сменился или просто забыл что он там написал? У вас ведь уже не один десяток проектов. Что вы будете делать без документации если завтра один из ваших заказчиков позвонит и попросит что-то сделать с одним из ваших проектов?
— Пока еще никто не звонил.
— Сколько строк кода в день вы обычно пишете? — эйчар пристально смотрит вам в глаза.
Вообще-то, лучшие алгоритмы часто бывают самыми короткими, думаете вы, мысленно перебирая варианты. Двести. Тысяча. Две тысячи строк… А вы знаете сколько кода иногда приходится переписать чтобы получить одну небольшую функцию, думаете вы. А еще вспоминаете случай, когда вы укоротили в 4 раза недокументированный код на SQL, и он стал выполняться в 9 раз быстрее, но отчего-то молчите.
Комментарии (22)
Indemsys
05.09.2022 00:09+2Не понял пункт про искусство.
По моему в данном пункте у автора идет путаница с soft skills или с психологией.
Тут нужно было бы добавить пункт, что программирование - это психоаналитика.Искусство я бы усмотрел в архитектуре софта, в используемых образах при построении классов, в механистических моделях или в антропоморфических, в применяемых аналогиях и т.п.
dkuzminov
05.09.2022 00:12+2Я бы не разделял науку и искусство: в программировании они идут рука об руку. Но вот то, что в статье описано как "наука" -- это скорее менеджмент и технология, ничего общего с наукой не имеющие.
Indemsys
05.09.2022 00:25+1Забавно.
А мне казалось что наука и искусство диаметрально противоположные вещи.
Если не считать научным искусством танцы с бубном в ситуациях неопределенности или незнания. Но такие танцы я бы уж скорее отнес к ремеслу.dkuzminov
05.09.2022 01:14И то, и другое -- выход за рамки известного и попытка открытия чего-то нового. И там, и там много творчества.
boopiz
05.09.2022 09:31+1был такой чувак. Пифагор. Так вот. Он не наукой занимался, а основной целью его было дрстичь гармонии. Стремление к прекрасному. А науку и ее методы он разрабатывал как инструментарий.
Indemsys
05.09.2022 09:41Скорее он был мистик. Его сочинений никто не видел из ныне живущих.
Тогда надо добавить что программирование - это мистицизм.
Я сам такое практикую. Иногда кажется если вид текста, его дизайн и пропорции в окне редактора мне нравятся, то в таком тексте нет ошибок. И это работает!
AlexCzech01
05.09.2022 00:54+2Архитектура (которая дома строит из дерева, камня, стекла и бетона) - искусство, наука или ремесло?
Написание битов на продажу - искусства, наука (ну это вряд ли конечно, но там тоже есть свои закономерности, которые если уловить, то будешь успешнее) или ремесло?
Анализатор крови создать, который будет делать анализы в 2 раза быстрее и/или в 2 раза точнее - искусство, наука или ремесло?
Ну и так далее
Любая классификация придумывается для упрощения. Когда что-то не лезет в классификацию - надо просто спокойно признать, что для этого "что-то" эта классификация не годится и не надо её использовать, а не впихивать невпихуемое. Потому что это не даст в данном случае никакого упрощения, следовательно непонятно, зачем на это тратить силы и время
dkuzminov
05.09.2022 01:34+3Напрашивается сравнение с Cynefin Framework: https://en.wikipedia.org/wiki/Cynefin_framework
Есть задачи простые (когда знаешь, как их решать и известен наилучший способ решения), усложненные (когда наилучших способов нет, но есть хорошие, и выбор метода доступен аналитически), сложные (когда неизвестны хорошие методы, и надо пробовать разные, чтобы понять, что именно сработает), а также запутанные (когда вообще непонятно, с чего начать). Так вот простое -- это ремесло. Усложненное -- инжиниринг. Сложное -- наука. Запутанные -- искусство. Они сосуществуют вместе, и самое важное -- не их путать, понимать границы между ними и по возможности вовремя переводить задачи из более сложных классов в менее сложные.
JackKatch
05.09.2022 08:59Как то в контору, где я когда то работал, пришел парень, устраиваться на работу сварщиком. Директор его спрашивает: "Компьютер знаешь?". Тот отвечает: "Ну.. Да". Директор: "Так ты программист!".
qrdl
05.09.2022 09:16Мне кажется, русское слово "ремесло" имеет для многих какой-то уничижительный оттенок, и даже в этой статье проскальзывает, что это что-то низкое. Если использовать вместо ремесла слово "craft", не имеющее таких коннотаций, то уже вполне не стыдно считать то, чем мы занимаемся, ремеслом. То есть мы не ремесленники, а craftsmen, если это больше ласкает слух (и эго).
Мы можем восхищаться произведениями резчиков по дереву, или, например, стеклодувов - людей, которые занимаются ремеслом, но достигли в нем вершин. То есть ремесло вовсе не значит, что это просто. Конечно, не все стеклодувы, даже на острове Мурано, мастера высшего класса - кто-то должен делать и простые штуки. Так и среди программистов хватает формошлепов.
s_f1
05.09.2022 09:58+1Потому что русское слово «ремесло» вообще не имеет того смысла, который в него вкладывет автор статьи.
Профессиональное занятие — изготовление изделий ручным, кустарным способом
То есть ремесло – это противоположность фабричному производству. Получается, FAANG и прочее – по определению не ремесло.Indemsys
05.09.2022 10:41А как же тот факт, что программисты сидят и ручками набивают код, кто бы они ни были и где бы не работали?
Т.е. FAANG по сути просто сильно масштабированное ремесло. Потому и платят программистам дорого поскольку ручной труд. А кустарно или не кустарно - секрет фирмы. Об этом судить не можем, особенно по отношению к фрилансерам.
Навороченность станков у кустаря же не делают его фабрикой.s_f1
05.09.2022 12:40Промышленное производство отличается от ремесла и кустарного производства значительно большей механизацией и автоматизацией, что ликвидирует зависимость свойств конечного продукта от мастерства рабочих, непосредственно занятых на производстве
Автоматизация присутствует? И Windows всё так же выпускается, хотя из её создателей вряд ли кто сейчас занят непосредственно в разработке. Так что все признаки конвейера налицо )
Дело не в «навороченности» станков, а в количестве людей и организации процесса.
PS то есть вы на полном серьезе можете назвать Windows «кустарным изделием»?
s_f1
05.09.2022 10:04Статьи с подобным вопросом появляются регулярно, и кажется мне, что дело тут в чрезмерном обобщении словом «программирование».
Вот медицина – это ремесло, искусство или наука? Для стоматолога XIX века из небольшого города, который только зубы лишние рвал всю карьеру – вероятно ремесло. Для Кристиана Барнарда – вероятно искусство. Ну наука, вроде как, вне сомнений )
thevlad
05.09.2022 10:57Разве computer science не наука? Понятно, что обычные программисты в основном просто пользуются ее плодами, но так и во всех других областях. Если спускаться дальше получаем software engineering, инженерное дело это ремесло или искусство? Наверное зависит от того, что делаешь.
akazant Автор
05.09.2022 11:14Признаки науки это в первую очередь четкая классификация терминов и понятий, а также логические доказательства утверждений, если они нужны в ходе построения теории или исследований. Computer science - наука о компьютерах - все же не более широкое понятие чем программирование. Computer science, к тому же имеет довольно размытые границы. Например, разработка микропроцессоров и разработка баз данных все же разные области, хотя к Computer Science относятся.
thevlad
05.09.2022 11:55+2Основной признак науки это построение моделей/создание знаний, которые можно проверить(фальсифицировать). Для построения моделей чаще всего используется "язык науки" - математика. На каком-то уровне, математика это "логические доказательства утверждений", но для большинства тех кто ее использует это скорее "знаковая система" имеющая некоторый прикладной характер.
Размытость областей присутствует в любой науке, будь то физика, медицина или биология.
Программирование это software engineering + некоторые области computer science, какие конкретные области computer science будут использоваться зависит от области применения.
akazant Автор
05.09.2022 15:31Замечание: в предложении ...все же не более широкое понятие.. "не" это опечатка, т.к. Computer Science включает в себя программирование.
Про модели и язык науки математику, вряд ли можно найти убедительные примеры где она используется, скажем, в таких науках как философия, биология, история и т.п.
thevlad
05.09.2022 16:27Философия и история, довольно странные гуманитарные "науки", где то на крайнем спектре "hard-soft" science, и ключевое слово было "чаще всего".
В современной биологии, математика повсюду, так как на на нижнем уровне она основана на химии, плюсом еще сюда биоинформатика, всякие генные сигнальные сети основанные на теории графов и прочее, прочее, думаю что специалист бы привел еще больше примеров.
Вот к слову линк: https://en.wikipedia.org/wiki/Mathematical_and_theoretical_biology
Это даже если мы не берем в расчет, что экспериментальные методы тоже зависят от технологий развитых в других областях (физике, химии и т.д.) А так же, что результаты экспериментов требуют статистической обработки. Еще бы я добавил, что в областях, где нет подходящих white-box моделей, вовсю используются статистические методы.
kosmonavt76
05.09.2022 23:34"Вторая грамотность. Первая грамотность даёт знания, вторая позволяет реализовать свои знания в действии" (с) кто то.
beeptec
Крутится на уме вопрос, не в абстракциях ли интерфейса среды разработки зарыта собака?
На что больше всего палит времени программист в поиске искомого результата, когда прямая линия между 2-я точками есть прямая линия, но по условию не есть истина?
Sergeant101
Скажу иносказательно: беря абстракции добавляешь готовые решения, оптимизированные, отлаженные и обкатанные годами.
Беря велосипед на обкатку ты берешь себе на голову кучу проблем.