Previous Entry Share Next Entry
photo25

Как изъять фан из программирования? (репост c комментарием)

Хехе, таки да.

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

"Just let me code" - ну да. Когда весь мир в голове у самого программиста, пишется легко и непринуждённо, когда приходится думать про окружающее, становится сложно и тяжело. Там время, сбои, ошибки, причинность и неопределенность, вот это всё.

Второе, подвижки в среде CI/CD таки есть. Да и сами билдсистемы постепенно, хоть и медленно, но становятся лучше. Другой вопрос, что сделать хорошую билдсистему действительно очень сложно, т.к. предметная область крайне широкая.
Из более-менее любопытных примеров последнего времени есть NixOS, конечно же, ну и если "на поржать", то gulp.

Оригинал взят у metaclass в Как изъять фан из программирования?
Ответ прост: сделать его промышленно-надежным. Вкинуть корявые баг-трекеры, инопланетные системы контроля версий, системы управления зависимостями и сборки, юнит-тесты и CI и даже самая маленькая интересная задача превращается в гребаного монстра, на который нужно 20 страниц документации только для того, чтобы можно было поправить мелкий баг.

http://www.reddit.com/r/programming/comments/2bi4yz/just_let_me_code/

PS: там в комментариях еще есть интересно про CI/CD системы.

CD/CI is a good case in point. I've had quite some experience with a lot of difference systems by now, and all of them without exception are a pain to maintain and cost lots of time to use well. I've setup, used & maintained systems based on CC.NET, Hudson+Jenkins, Travis CI & Circle CI. Getting a CI system to really work well costs a lot of time. It's worth it - no question - but it's a huge investment nevertheless. And lots of that investment is ultimately just working around bugs+limitations. Passing around build artifacts is a pain. Managing differing configurations is a pain. This is a solved problem: we have these things called methods that have parameters and even higher-order functions in most programming languages, yet in a CI you tend to need to do lots of messy hackery just to pass around parameters cleanly.


Если бы вы знали, КАК вот это все бесит - это слов нет. Сидишь пишешь на нормальном языке высокого уровня, с нормальными правилами видимости переменных, с всякими проверками компилятора на тему пропущенных переменных и прочим таким.
И тут ХЕРАК, надо делать билд и тесты - переключаешься например на MSBuild или CC.Net - и там нет даже тех мелочей, которые есть в самых наираздинамических из динамических языков - ошибся в одной букве, переменная стала другой - похер, работаем, только с пустым значением. Методов нет, объектов нет, функций нет, переменные все глобальные, причем одна часть из них взята из системного окружения, вторая создается на ходу, третья создается где-то в проекте, импортированном из проекта, импортированном из проекта, импортированном из проекта, импортированном из проекта.
Более ad-hoc говна, чем сборочные системы, сложно себе представить, ибо они все выросли из всякого уебища вроде make-файлов, косоручных бат-sh-cmd-файлов и несут на себе их родовой грех.


  • 1
sorcerer_ December 9th, 2014
Каждый раз, когда вижу какого-нибудь "абстрактного программиста", хочется его застрелить.
Мы живем в реальном мире и программировать нужно всегда зная, что код будет работать на реальных ЦПУ, с реальными данными, и собираться реальными мейкфайлами (в лучшем случае).

wizzard0 December 9th, 2014
Фиг с ними с абстрактными программистами, а вот если в орхетекторы и ПМы идут люди, которые вообще не знакомы* с понятием "системная инженерия" - вот тогда убивать-убивать-убивать

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

sorcerer_ December 9th, 2014
Есть термин: architecture astronaut.
Народная примета: 99% их всегда идут в архитекторы и ПМы.
Следствие: архитектура приложения - это автоматом то, что астронавт придумал. Если астронавтов нет - архитектура нахуй не нужна.

sorcerer_ December 9th, 2014
Вторая примета, т.к. астронавт привык играть логическими построениями и теориями, он может аргументированно доказать как соответствие так и несоответствие архитектуре для любой конкретной имплементации. :)
А если не может, так он еще и дурак. :)

wizzard0 December 9th, 2014
Ну, хм, я астронавтю постоянно :-) Надо же пробовать.

Но иногда выходит нормально, тогда это можно и в продакшен %))

sorcerer_ December 9th, 2014
Дык, лемма: архитектором может быть только астронавт, мало того, если в группе есть астронавт и нет архитектуры, он не может работать, т.е. ценность его как боевой единицы нулевая.
Поэтому оторванная от реальности архитектура всегда присутствует в любом достаточно большом проекте.

insanegigolo December 9th, 2014
Как же тогда с такой архитектурой большие проекты релизяться?

sorcerer_ December 9th, 2014
Так же, как обычно. Архитектура только структурирует знания о проекте для астронавтов.

insanegigolo December 9th, 2014
А для не астронавтов она что делает?

sorcerer_ December 9th, 2014
Думаю по-разному, для меня: смешной слайд-дек про отвлеченную хуйню.

insanegigolo December 9th, 2014
Архитектура программ не нужна?

sorcerer_ December 9th, 2014
Конечно нужна, в команде всегда будут астронавты.

wizzard0 December 9th, 2014
Кстати, 90% астронавтизма мгновенно сдувается, если ввести понятие "бюджет по ресурсам" (как времени/денег девелоперов, так и runtime budget)

sorcerer_ December 9th, 2014
Не вижу как оно поможет. Ибо скорость имплементации может отличаться на порядки у одного и того же человека в зависимости от кучи параметров. :)

wizzard0 December 9th, 2014
Как минимум, оно помогает от "давайте портанём на новые принципы всё, а также всё, с чем этот код взаимодействует".

sorcerer_ December 9th, 2014
Не знаю, не знаю, мне кажется, что единственный способ: этим кодом будут пользоваться люди уже завтра.
И на любое возражение: а ты когда хочешь, чтобы им пользоваться начали?

wizzard0 December 9th, 2014
Хммм, а это не бюджет времени разве? %)

Хотя вообще да, это более мягкий вариант, сдвиг стимулов, все дела.

unknown_orient December 9th, 2014
>>> но вообще есть нормальная литература

Например?

potan December 9th, 2014
Лучше разбомбить "реальный мир".

wizzard0 December 9th, 2014
:) Люди разные важны, и ситуации тоже бывают разные.

udpn December 9th, 2014
Но лучше всё же разбомбить.

sorcerer_ December 9th, 2014
Бесполезно, он все равно найдет как надавать оплеух любителю абстракций. Причем у некоторых оно реально прямо в частной жизни все так (одни оплеухи).

udpn December 9th, 2014
А зачем нужны билд-системы вообще? Набор комбинаторов для работы с ФС и процессами, нормальный статически типизированный ЯП в руки, и вот вам "билд-система" стандартными средствами. sbt и gulp как сырые варианты вполне ок.

wizzard0 December 9th, 2014
не надо тут упоминать sbt, да еще как хороший пример. его надо выжечь напалмом и показывать в назидание - как проабьюзить выразительные способности языка и получить неюзабельное гавно. и еще, де-факто, он динамически типизирован.

sorcerer_ December 9th, 2014
Лемма: любая билд/ci-система, написанная программистами, не уважающими реальный мир, будет over-engineered unusable crap (maven, например, или puppet).

udpn December 10th, 2014
Ну будто бы gulp сильно лучше :)

wizzard0 December 10th, 2014
Гульп, в отличие от sbt, не пытается вносить кучу магии.

Вот jake говно, да.

udpn December 10th, 2014
Это файловые-потоки-с-именем-файла-которые-возможно-запишутся-на-диск-а-может-нет не куча магии?

(Deleted comment)
  • 1
?

Log in

No account? Create an account