![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Mar. 11th, 2018
Задумался о вечном, пока вчера вечером отвечал на комментарии о программировании, а на другом экране тётя в онлайн курсе разбирала мозг и рассказывала что, почему и где отключается при инсульте, ударе и других неприятностях. (Вечером смотрю, потому что после просмотра весёлой дамы со скальпелем аппетит совершенно пропадает.)
Что-то странное происходит с коммуникацией. Вроде, просто констатирую банальности.
Например, полезно называть вещи своими именами.
Если вместо слова "баг" использовать "ошибка кодирования", то вместо ловли блох можно составлять классификацию ошибок, устранять их причины, использовать стратегии поиска и профилактики...
Если вместо слова "рефакторинг" использовать термин "ошибка на уровне дизайна", можно вместо дурацких рассказов про запах кода (Кстати, чем он пахнет? Потной футболкой программиста?) говорить об ошибочных предположениях, отвергнутых гипотезах, оптимизации на основе лучшего понимания и, конечно, о способах устранения этих ошибок до начала бессмысленного сжигания бюджета на кодировании.
Также программисты прекрасно помнят, что в зависимости от задач и выбора алгоритмов затраты ресурсов в зависимости от объёма данных могут расти линейно, экспоненциально, квадратично или сублинейно.
Почему-то при этом удивление, граничащее со священным ужасом, вызывают вполне очевидные слова о том, что совершенно также в зависимости от задачи и выбранного решения линейно, экспоненциально, квадратично, сублинейно... от объёма кода может зависеть его когнитивная сложность (то есть те же затраты ресурсов на его обработку).
Ещё я писал, что есть задачи, где результаты однозначно зависят от входных данных, и проще решать их процессом преобразования в структурном подходе. Есть задачи, решаемые операциями над множествами, и лучше реляционных баз данных для них ничего не придумали. Есть задачи, раскладываемые на иерархию модулей. Если добавить к этому немного психологии восприятия, очевидным решением будет использование объектно-ориентированного подхода. Есть задачи, где можно прямо набивать в коде решение по образцу. Есть те, где надо сначала понять структуру и найти оптимальные пути решения, а потом переходить к частностям, спускаясь сверху вниз по уровням моделей. (И при правильном подходе сами модели напрямую в код преобразовывать.)
Так нет же. "Давайте представим, что весь мир состоит из математических абстракций, и применим современные модные методы, не взирая на мелкие отклонения реальности от идеала".
Мне кажется, что я пишу достаточно элементарные вещи. Но они почему-то вызывают странные реакции.
Конечно, это приводит к интересным разговорам. Например, про немецких программистов, или явлсяется ли кодирование главным этапом в процессе производства софта, или можно сначала думать. Но всё-таки ощущение, что я использую какой-то загадочный, не понятный для большинства язык.
Что-то странное происходит с коммуникацией. Вроде, просто констатирую банальности.
Например, полезно называть вещи своими именами.
Если вместо слова "баг" использовать "ошибка кодирования", то вместо ловли блох можно составлять классификацию ошибок, устранять их причины, использовать стратегии поиска и профилактики...
Если вместо слова "рефакторинг" использовать термин "ошибка на уровне дизайна", можно вместо дурацких рассказов про запах кода (Кстати, чем он пахнет? Потной футболкой программиста?) говорить об ошибочных предположениях, отвергнутых гипотезах, оптимизации на основе лучшего понимания и, конечно, о способах устранения этих ошибок до начала бессмысленного сжигания бюджета на кодировании.
Также программисты прекрасно помнят, что в зависимости от задач и выбора алгоритмов затраты ресурсов в зависимости от объёма данных могут расти линейно, экспоненциально, квадратично или сублинейно.
Почему-то при этом удивление, граничащее со священным ужасом, вызывают вполне очевидные слова о том, что совершенно также в зависимости от задачи и выбранного решения линейно, экспоненциально, квадратично, сублинейно... от объёма кода может зависеть его когнитивная сложность (то есть те же затраты ресурсов на его обработку).
Ещё я писал, что есть задачи, где результаты однозначно зависят от входных данных, и проще решать их процессом преобразования в структурном подходе. Есть задачи, решаемые операциями над множествами, и лучше реляционных баз данных для них ничего не придумали. Есть задачи, раскладываемые на иерархию модулей. Если добавить к этому немного психологии восприятия, очевидным решением будет использование объектно-ориентированного подхода. Есть задачи, где можно прямо набивать в коде решение по образцу. Есть те, где надо сначала понять структуру и найти оптимальные пути решения, а потом переходить к частностям, спускаясь сверху вниз по уровням моделей. (И при правильном подходе сами модели напрямую в код преобразовывать.)
Так нет же. "Давайте представим, что весь мир состоит из математических абстракций, и применим современные модные методы, не взирая на мелкие отклонения реальности от идеала".
Мне кажется, что я пишу достаточно элементарные вещи. Но они почему-то вызывают странные реакции.
Конечно, это приводит к интересным разговорам. Например, про немецких программистов, или явлсяется ли кодирование главным этапом в процессе производства софта, или можно сначала думать. Но всё-таки ощущение, что я использую какой-то загадочный, не понятный для большинства язык.
Я долго сдерживался, но всё-таки напишу.
Разговоры с IT-специалистами всё больше и больше напоминают мне беседу с папуасами, которые утверждают, что небоскрёбов не бывает, потому что солома постройку выше трёх этажей не выдержит.
Разговоры с IT-специалистами всё больше и больше напоминают мне беседу с папуасами, которые утверждают, что небоскрёбов не бывает, потому что солома постройку выше трёх этажей не выдержит.