Программирование как "Антибиотик" проекта: "Одно лечим - другое калечим"

SeVlad
На сайте с 03.11.2008
Offline
1474
#71

burunduk, ну вот и приходим к постулату: "всё зависит от задачи и бюджета" :)

(перетирать одно и тоже и расписывать в 100500й раз лениво и непродуктивно :) )

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

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Топики помощи с ⓌordPress (https://searchengines.guru/ru/forum/1032910 ) и основы безопасности сайтов ( https://searchengines.guru/ru/forum/774117 ). *** Помощь\консультации в топиках форума - БЕСПЛАТНО. Платные услуги ( https://wp.me/P3YHjQ-3 ) - с бюджетом от 150$ ***
edogs software
На сайте с 15.12.2005
Offline
743
#72
Shlackbaum:

1) Программисты внедряют что-то на сайт - например новую категорию на сайте (или правки по старой категории).
2) Проверка внедряемого (собственно по поставленному ТЗ) не выявляет каких - либо проблем.
3) В местах, которые согласно ТЗ не были затрагиваемы проверяющим начинаются проблемы. Отвалилось что-то здесь, что-то там. Что-то еще появилось там где не должно было и так далее.
В результате получается, что задача проходит проверку, но полученный результат, если что-то слетело просто катастрофичен.

Хотелось бы увидеть какой-то реальный пример.

В принципе проблема может быть как и архитектурная так и в кривых руках программеров.

Если архитектурная - нанимать профи и потихоньку переписывать архитектуру.

Если в кривых руках прогеров - править им руки.

А может еще в чем-то.

Shlackbaum:

1) После любой правки проверять все.
- Катастрофически нерентабельно с точки зрения ресурсов.

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

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

Отчасти проблема архитектурная.

Shlackbaum:
То есть нет понимания, что конкретно это меню выводится не только в этом разделе, но еще и в другом месте.

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

Shlackbaum:
3) Сложный механизм учета всех глобальных переменных до начала работ. Требует полного понимания программистом проекта до начала каких-либо работ (или же системы, которая будет "светить" об изменениях в конкретных местах проекта для учета).

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

Shlackbaum:
В общем проблема меня задолбала. Программисты, к которым я обращаюсь - разводят руками - "так все делают" - и либо одна правка вызывает 3 дополнительных косяка - либо тратят тонну ресурсов на перепроверку.
На форуме есть эксперты и опытные специалисты в боевых задачах - я взываю к вам, может быть вы нашли решение для избежания этой проблемы, когда программисты дай бог на 10 решение генерят 2 косяка и их надо исправлять. Но иногда программисты на 1 решении генерят 3 дополнительных проблемы. И это уже ну совсем плохо.

Есть ощущение, что проблема комплексная.

Т.е. вот на примере авто.

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

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

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

---------- Добавлено 30.10.2018 в 18:14 ----------

Solmyr:
Ну вот например простой и стандартный пример, без изысков. Интернет-магазин одежды. Два атрибута товара: цвет и размер. Я не знаю ни одного движка из коробки, в котором стандартными методами, без костылей, можно это нормально реализовать, чтобы работал корректно учет складских запасов и поиск по сайту. .
magento? правда в россии он не особо популярен и прогеры для него дорогие.
Разработка крупных и средних проектов. Можно с криптой. Разумные цены. Хорошее качество. Адекватный подход.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий