Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Задумался о вечном, пока вчера вечером отвечал на комментарии о программировании, а на другом экране тётя в онлайн курсе разбирала мозг и рассказывала что, почему и где отключается при инсульте, ударе и других неприятностях. (Вечером смотрю, потому что после просмотра весёлой дамы со скальпелем аппетит совершенно пропадает.)

Что-то странное происходит с коммуникацией. Вроде, просто констатирую банальности.

Например, полезно называть вещи своими именами.

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

Если вместо слова "рефакторинг" использовать термин "ошибка на уровне дизайна", можно вместо дурацких рассказов про запах кода (Кстати, чем он пахнет? Потной футболкой программиста?) говорить об ошибочных предположениях, отвергнутых гипотезах, оптимизации на основе лучшего понимания и, конечно, о способах устранения этих ошибок до начала бессмысленного сжигания бюджета на кодировании.

Также программисты прекрасно помнят, что в зависимости от задач и выбора алгоритмов затраты ресурсов в зависимости от объёма данных могут расти линейно, экспоненциально, квадратично или сублинейно.

Почему-то при этом удивление, граничащее со священным ужасом, вызывают вполне очевидные слова о том, что совершенно также в зависимости от задачи и выбранного решения линейно, экспоненциально, квадратично, сублинейно... от объёма кода может зависеть его когнитивная сложность (то есть те же затраты ресурсов на его обработку).

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

Так нет же. "Давайте представим, что весь мир состоит из математических абстракций, и применим современные модные методы, не взирая на мелкие отклонения реальности от идеала".

Мне кажется, что я пишу достаточно элементарные вещи. Но они почему-то вызывают странные реакции.

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

Comments

[(Anonymous)]

У математиков есть готовые решения, у них проблемы с поиском задач. Если в руках молоток - то везде монады мерещится.

[juan_gandhi]

Давно уже на монады не наезжали.

А лемма Ионеды вам тоже не по душе? А законы де Моргана?

[(Anonymous)]

Когда их именем начнут называть програмистские конструкции,
и расказывать что "онежевизде" и "тот кто этого не понимает -- ну, тупоо-о-ой"
Дойдет дело и до них. ;)

[sab123]

Не, "рефакторинг" - это не "ошибка на уровне дизайна". Дизайн - вещь не статическая, а динамическая.

Во-первых, требования к программе не фксированны, а меняются со временем.

Во-вторых, невозможно вот так сесть и написать идеальные требования до написания программы. Эти требования будут содержать различные предположения, сделанные без наличия опыта использования. Когда появится опыт, многие из этих предположений окажутся неверными.

В-третьих, программу сколько-нибудь заметных размеров невозможно вот так сесть и написать целиком. Она так или иначе пишется частями. Если пытаться имитировать "написать целиком" и писать все части и потом их ждруг с другом соединять, то работать ничего не будет (чему есть множество примеров). Части эти придется очень сильно именять, чтобы подогнать друг к другу. Более разумный вариант - начинать с минимальной функциональности и постепенно выращивать оттуда, чтобы все время была работающая программа, но ее функиональность постепенно росла.

[vit_r]

Во-первых, требования к программе не фиксированы, а меняются со временем.

Ох.

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

Очень странно будет, если отправят его в полёт с не до конца зафиксированными требованиями.

Не то, чтобы патч нельзя было поставить, но это дело рискованное. Истории спасения космических миссий, тем более дальних, читаются как хороший детектив.

Когда появится опыт, многие из этих предположений окажутся неверными.

Хорошие требования содержат большой раздел "риски", куда входит описание всего, что известно только в виде предположений, и способы действий в этой ситуации. И возможность внесения необходимых изменений закладывается в дизайн изначально.

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

Не то, чтобы это было стандартом в нашей дикой и бардачной индустрии, но я видел и правильные процессы, и результаты с невебовским качеством.

[sab123]

> Ну, скажем, летит зонд к Юпитеру.

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

> Хорошие требования содержат большой раздел "риски", куда входит описание всего, что известно только в виде предположений, и способы действий в этой ситуации.

И этот раздел обычно оказывается бессмыссленным по сути, и способы дейтсвий в нем - неверными.

> И возможность внесения необходимых изменений закладывается в дизайн изначально.

О! То есть, все-таки рефакторинг.

> Легенда о том, что из самоката небольшими наращиваниями можно сделать Мерседес, очень привлекательна, но неправдоподобна.

Тут надо вспомнить о том, из чего сделали настоящий Мерседес в реальности. И окажется, что это не легенда, а реальность.

[vit_r]

Программы для зонда рефакторят для _следующего_ зонда с учетом знаний, полученных от первого зонда.

Нет, конечно.

Во-первых, слово "рефакторинг" - это дрянь, которую надо выбросить и забыть. Всё надо называть правильными терминами.

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

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

И этот раздел обычно оказывается бессмысленным по сути, и способы действий в нем - неверными.

"Обычно" толпа остолопов пытается сляпать на коленке жуткую хрень.

Я писал не про "обычно", а про "правильно". В IT индустрии это очень сильно отличается.

[sab123]

> Даже, если это одна платформа, на следующем зонде будут другие приборы, системы с другими параметрами, другие массово-габаритные характеристики и прочее.

Во-от. Другие. Созданные с использованием полученного опыта.

> Я писал не про "обычно", а про "правильно".

Думать, что можно все предусмотреть заранее - неправильно.

[vit_r]

Во-от. Другие. Созданные с использованием полученного опыта.

Полученного где? :-)

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

Будущее - это вероятностная характеристика. Не нужно предусматривать всё возможное, достаточно оценить и правильно подготовиться к вероятному.

[alexott]

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

я думаю что есть компании где это все делается, но скорее всего это что-то около-государственное/военное, где время особо не считают...

[vit_r]

и у верхнего менеджмента все время меняются приоритеты...

Тогда они занимаются не своим делом.

но скорее всего это что-то около-государственное/военное, где время особо не считают...

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

Если, конечно, важен конечный результат, а не обман заказчика демонстрацией результата "готового на 90%".

[sab123]

Полученного от предыдущих миссий. Все идет итеративно.

[vit_r]

Они не "предыдущие", они "независимые".

[sab123]

С чего бы им быть независимыми?

[vit_r]

Например, их производят другие фирмы в других странах для других целей.

[sab123]

Даже те, которые в других странах, полагаются на найденную информацию о рабочей среде.

[vit_r]

Это не называется "итерация".

[sab123]

Имея готовый код, конечно, легче его отрефакторить. Но не имея его, знания об области задач тоже очень важны, и составляют собой центр всего проектирования.

[vit_r]

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

[juan_gandhi]

Я уверен, что трехколесный мерседес еще можно где-нибудь встретить в реале.

[bowhill]

Сколько зондов летит к Юпитеру?

[anonim_legion]

>Легенда о том, что из самоката небольшими наращиваниями можно сделать Мерседес, очень привлекательна, но неправдоподобна.

Это же про Линукс! Мерседес и вправду не получился, но работать с ним всё равно приходится.

[vit_r]

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

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

[smugastyi_kit]

Проблема в том, что мы все (ну или бОльшая наша часть) разучились общаться.
Мы все неплохо умеем отстаивать свою правоту, приводить аргументы, передергивать, уводить темы в другую плоскость, в общем — заниматься демагогией.
А вот общаться — увы. :(

[xoxlobandera]

Ага.

[vit_r]

Мы все неплохо умеем отстаивать свою правоту, приводить аргументы, передергивать, уводить темы в другую плоскость, в общем — заниматься демагогией.

Кстати, единственная область, где специалисты женского пола проигрывают мужикам. Просто в силу разницы гормонального фона.

[rdia.livejournal.com]

Рефакторинг - это не ошибка архитектуры. Это ИСПРАВЛЕНИЕ ошибки архитектуры.

Баг - это да, ошибка кодирования. Но кодирование может быть на языках совершенно разного уровня.

[vit_r]

Рефакторинг - это не ошибка архитектуры. Это ИСПРАВЛЕНИЕ ошибки архитектуры.

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

[juan_gandhi]

Это мы тут должны были догадаться пять лет назад, что ваши выдумают GDPR.

(впрочем, как раз лет пять назад я таки что-то такое сдизайнил в этом смысле, по заказу дойчтелекома - но если б не они, в жизни бы не догадался, до чего немецкая мысль дойдет.)

[vit_r]

Кто "наши"? General Data Protection Regulation - это общеевропейский ответ на актуальный запрос времени. Иначе получится как в Китае.

Что получилось не очень - так это результат не сильно больших талантов и коллегиального процесса разработки.

[juan_gandhi]

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

[vit_r]

Просто почему-то этот общеевропейский ответ даже европейцам не был заранее известен.

Вообще-то это было известно давно и заранее обсуждалось. Борцы за приватность требовали ещё добавить строгостей, представители индустрии просили убрать особо неудобные места.

Практически, законодательно определили не саму необходимость уважать частные данные, а меру ответственности и способы обеспечения этого уважения.

Как и Y2K.

Это тут не в тему.

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

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

[(Anonymous)]

Казнить, нельзя помиловать.
Казнить нельзя, помиловать.

Какой из двух вариантов -- ошибочный? ;) (надеюсь вы и так поймете, на что тут намек, вы же умный, али разжевывать нужно?)