Мощь и немощь языков программирования

На волне последних споров из разряда «Go заставляет всех писать в едином стиле» или «ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.» решил попробовать привести в порядок собственные мысли на этот счёт.

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

Всем этим я наслаждаюсь, когда пишу на C#, Котлине, Эрланге. Но всего этого нет у меня в 1С. И если раньше я как-то страдал и печалился по этому поводу, то попав по иную сторону разработки, я немножко приоткрыл глаза.

Другая сторона состоит в том, что иногда программы пишу не я, а для меня. Точнее, для заказчика, который в итоге получает требуемый продукт, но составные части для этого продукта — это мой заказ на сторону. Что тут стоит отметить?

Первое — это род получаемого мной продукта. Это может быть либо чёрный ящик с некоторым соглашением на взаимодействие. В данном случае код меня мало волнует: я либо не смогу его получить, либо не буду его исполнять на своих мощностях, либо ответственность за его работоспособность целиком лежит на исполнителе. Это редкий случай.
Второго рода программные продукты — это именно код. Код, который не обязательно являет собой законченный продукт для пользователя, но который я могу взять и подключить в кодовую базу разрабатываемого целикового продукта. Этакий кирпичик для дома, который строит моя бригада.
И вот, что важно для меня: мне важны габариты кирпича, его правильная форма, его заявленная устойчивость к нагрузкам. Сколько при этом выпито литров смузи, сколько порвано свитров с оленями — это не моё дело. Я получил кирпич, один из десятков, из сотен. Унылый, красный или белый, параллелограммовидный кирпич.

К чему весь этот бред про кирпичи? Бред этот к предстоящему разговору про «творческую профессию». Разработка программного продукта — это, безусловно, творческое дело. Как построить дом — архитекторы, дизайнеры, маркетологи (чтоб они сгорели!). Но, ё-моё, не должно быть творчества у того, кто кладёт кирпичи или кто подвозит брёвна! Можно слушать музыку и закладывать кирпич тройным броском в двойном прыжке, но как итог: кирпич воооон из той груды должен лечь воооот в ту вот стенку.
На каком-то уровне нашего строительства творчество заканчивается и превращается в механическую работу. Вот здесь нужен чёткий водораздел.

Представим себе конструктор!

Говорю исполнителю «хочу конструктор». Что должен сделать исполнитель? Конструктор? Нет! Он либо должен спросить «А какой??», либо идти и пилить своё «творчество».
Потому если я знаю, какой конструктор я хочу получить, то буду ставить задачу чётко: «вот столько-то болтов по такому чертежу, вот столько деталей выпилить и высверлить вот по этому чертежу».
Всё. Чертежи, спецификации, строгие техзадания — никакого творчества на стороне исполнителя. Это дополнительная нагрузка для меня, как для архитектора программного продукта, — строго прописывать и обозначать характеристики получаемых деталей, но получаемая выгода гораздо выше.

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

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

  • Они говорят на одном языке
  • Работают по одним спецификациям, стандартам, ГОСТам
  • Имеют примерно одинаковый уровень технических компетенций
  • И не выходят за рамки этого уровня в своей работе

Первое разумеется само собой: я буду отдавать работы на 1С тем, кто работает на 1С. Их много, можно выбирать.
Второе прописывается при постановке заданий, проверяется при приёме работ.
Третье достигается постановкой задач: какие библиотеки выбрать, какие механизмы платформы задействовать.
А вот четвёртое достигается только ограничениями языка.

Если в 1С появятся объектное программирование, лямбды с замыканиями, каррирование, функции первого порядка, то формально я не смогу запретить всё это использовать. Но мне придётся более тщательно подходить к выбору исполнителей. Если в одном куске кода задан уровень входа для разработчика выше, чем в среднем по рынку, я теряю в гибкости. Однако если даже у самых крутых и мозговитых разрабов просто-напросто НЕТ возможности написать так, чтобы не понял студент после года работы во франче, то я буду спокоен за работу.

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


Comments are closed.