caxapa.ru :: Понятно. Всё как всегда, примтивно. А я то уж думал.... На самом деле проблема не в том что код программ стремятся набрать блочно-кусковым методом. Реальная, истинная проблема заключается в методе написания программ на PC. А он такой: У девелопера/ов в распоряжении находится машина, утрированно, с бесконечной мощностью. И вот он/они пишут софт, для которого никаких границ, тестов и требований не поставлено.

RxTx (25.12.2021 02:06, просмотров: 301) ответил Kceния на В программировании МК это чаще всего I2C и USB-device. Если АЦП, то и для него обычно ищут готовый код, который оформлен в виде функций, т.к. разбираться с чужим кодом мало кто может. Если это вычислительная процедура, то и тут тоже обычно ищут для нее готовый код. Т.е. фактически получается ситуация, как с Ардуино - на все типичные случаи есть функции, а на нетипичные голову сломишь, чтобы под Ардуино написать. Тем самым, ситуация складывается, как конструкторе "Лего" -

Понятно. Всё как всегда, примтивно. А я то уж думал.... На самом деле проблема не в том что код программ стремятся набрать блочно-кусковым методом. Реальная, истинная проблема заключается в методе написания программ на PC. А он такой: У девелопера/ов в распоряжении находится машина, утрированно, с бесконечной мощностью. И вот он/они пишут софт, для которого никаких границ, тестов и требований не поставлено.

Запускается? Ура! Всё, пакуйте в дистриб, деплоим.

Никто не смотрит ни на потребление памяти, ни на время старта, а уж на время работы тем более.

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

Как только были бы поставлены границы/требования (по совместимости, времени запуска, по времени, потреблению памяти) и их жестко требовали бы выполнять - они бы выполнялись.

А в противном случае происходит именно то, что происходит. Как только железо умощняется в N раз, программеры продолжают ваять по методу:

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

Вот именно этот подход и создает то, на что жалуется статья.

Спасибо, князь. Вы настоящий дворянин. И программист.

Ответить

- Да, такое тоже бывает, только видится вне в несколько иной ипостаси, когда требования техзадания удовлетворятся приблизительно и не особо старательно, а уповают на стадию тестирования, когда тестировщик находит ошибки (или расхождения с ТЗ), а программист накладывает на код заплаты. При этом предполагается, что если наложить на код достаточно много заплат, то получится именно то, что требовалось :). А поскольку Kceния(118 знак., 25.12.2021 02:20)
  - Ну, поправить багу и коммитнуть (и закрыть тикет) — это совершенно отдельный уровень разработки. Отдельный метод надмозгов. Вся надежда именно на то что девочка-тестировщица скомпилит, запустит, проверит и откатит Jira-тикет: "нет, бага не поправилась, работай еще". Я такое видел. Дураки они есть всегда, к сожалению постоянный приток баксов позволял и позволяет этому д..му плавать... - RxTx(25.12.2021 02:35)
    - Мне встречался противоположный случай, когда тестировщик был мужик с головой, досконально знающий во всех подробностях всё то, что должна делать программа, тогда как программистами были девочки :), которые "исправляли" глюки добавлением очередных if-ов. - Kceния(25.12.2021 02:38)
      - Повезло. Так это и работало. А если бы девочки были бы мудры :), досконально добавляли бы мудреные if-ы, а мужик был бы дурён и метался бы как обезьяна в клетке - это бы уже не сработало. Потому что один дурак может задать столько вопросов, на которые и сто мудрецов не ответят :) - RxTx(25.12.2021 02:43)

Средства и методы разработки