- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
burunduk, ну вот и приходим к постулату: "всё зависит от задачи и бюджета" :)
(перетирать одно и тоже и расписывать в 100500й раз лениво и непродуктивно :) )
Но я сосбно начал отвечать про возможность движков и костылей..
1) Программисты внедряют что-то на сайт - например новую категорию на сайте (или правки по старой категории).
2) Проверка внедряемого (собственно по поставленному ТЗ) не выявляет каких - либо проблем.
3) В местах, которые согласно ТЗ не были затрагиваемы проверяющим начинаются проблемы. Отвалилось что-то здесь, что-то там. Что-то еще появилось там где не должно было и так далее.
В результате получается, что задача проходит проверку, но полученный результат, если что-то слетело просто катастрофичен.
Хотелось бы увидеть какой-то реальный пример.
В принципе проблема может быть как и архитектурная так и в кривых руках программеров.
Если архитектурная - нанимать профи и потихоньку переписывать архитектуру.
Если в кривых руках прогеров - править им руки.
А может еще в чем-то.
1) После любой правки проверять все.
- Катастрофически нерентабельно с точки зрения ресурсов.
Неплохо помогают автотесты. Не надо все делать руками, даже сценарий "регистрация, пролистывание в такую-то категорию, поиск, добавление товара в корзину, .... покупка" очень даже автоматизируется.
Но проблема в том, что зачастую нет данных о том, переменная глобальная или нет (если касается веб-сайта).
Отчасти проблема архитектурная.
То есть нет понимания, что конкретно это меню выводится не только в этом разделе, но еще и в другом месте.
Если была задача "исправить меню на конкретно этой странице, а программер исправил меню так, что изменения вылезли еще где-то - это кривые руки программера. Неправильно в данном случае будет поменять выводимое меню, правильно - сдублировать это меню и поправить уже сдублированный код.
3) Сложный механизм учета всех глобальных переменных до начала работ. Требует полного понимания программистом проекта до начала каких-либо работ (или же системы, которая будет "светить" об изменениях в конкретных местах проекта для учета).
Глобальные переменные само по себе зло, но что бы избежать этого зла при правках - достаточно не трогать глобальные переменные. Новый код не должен вносить в глобальные изменения. И тут речь не только о глобальных переменных в прямом смысле, а вообще о любых глобальных вещах.
В общем проблема меня задолбала. Программисты, к которым я обращаюсь - разводят руками - "так все делают" - и либо одна правка вызывает 3 дополнительных косяка - либо тратят тонну ресурсов на перепроверку.
На форуме есть эксперты и опытные специалисты в боевых задачах - я взываю к вам, может быть вы нашли решение для избежания этой проблемы, когда программисты дай бог на 10 решение генерят 2 косяка и их надо исправлять. Но иногда программисты на 1 решении генерят 3 дополнительных проблемы. И это уже ну совсем плохо.
Есть ощущение, что проблема комплексная.
Т.е. вот на примере авто.
Если авто фигово сделан, то после замены лампочки может перегореть микросхема в центральном блоке управления отвечающая за печку. Как данность надо принять тот факт, что данная проблема у Вас есть. Решать ее надо на архитектурном уровне, избегая глобальных и делая максимально независимые зоны ответственности.
Однако даже если авто фигово сделан и задача стоит не "поменять лампочку", а "что бы вот тут светило", всегда можно прицепить эту лампочку напрямую к аккумулятору и вывести на панель управления выключатель. И если такие "вот тут вот светило" задачи будут делаться по единому гайдлайну с документацией, то весь этот процесс можно будет назвать рефакторингом кода и постепенно у Вас старый блок управления на "глобальных" вообще не будет нести в себе никаких функций и от него можно будет избавиться.
И все же - для нормального ответа хотелось бы пару конкретных примеров "что надо было сделать и что в результате навернулось". Иначе это обсуждение вкуса устриц которых еще не принесли.
---------- Добавлено 30.10.2018 в 18:14 ----------
Ну вот например простой и стандартный пример, без изысков. Интернет-магазин одежды. Два атрибута товара: цвет и размер. Я не знаю ни одного движка из коробки, в котором стандартными методами, без костылей, можно это нормально реализовать, чтобы работал корректно учет складских запасов и поиск по сайту. .