Ну, если эта новость о хакерских атаках на Ф1 с сылкой на сайт пустить по всем новостным лентам всего мира, то вполне может быть, что сайт ляжет. И анонимусам даже ничего «ломать» не придется :)
Ой, эти ананимусы уже запарили каждую неделю что-нить новое выкидывать. Обещают пол интернета взломать и сделать недееспособным. А пока что ни один сайт толком из-за них не закрыли
>>Сейчас вижу следующее — многие большие монолитные энтерпрайзные проекты разбиваются на несколько частей и уже являются друг для друга сервисами.
Абсолютно верно. Те два примера, которые я привел — на самом деле модули одного большого проекта. Но я их назвал «системой» — из-за их независимости от общего проекта.
Это минус вашему менеджеру, если прям именно из-за ООП он переделывать продукт решил. Но скорее всего — это Вы неправильно поняли. Цель была не в ООП перевести, а сделать продукт лучше — добавить дополнительную функциональность, сделать более масштабируемым приложение, увеличить перфоманс и т.п.
Автор, статья пропитана неопытностью. Вы, видимо, мало в интерпрайзе работали или не работали вообще. Да, в большинсве случаев согласен с доводами — действительно, чем крупнее проект — тем меньше шансов его переписать как нужно. НО! очень часто это необходимо. И то, что вы перечислили — далеко не все случаи. Бывает так, что система в будущем может потребовать большей нагрузки (Например, к 2015му году 500000 реквестов в день, вместо текущих 70) и основная архитектура — ни коим образом не уложится в такие требования. К тому же написана индусами и по-индусски. В этом случае — проще уговорить заказчика, предоставить ему пруф оф концепт, что наша версия работает быстрее, более масштабируема + добавить бантиков (типа, мы добавим еще админку, точнее некий бекофис) и сделаем всё более конфигурабильно. Тогда получается, и выигрывает кастомер, получая более быстрое и скалабильное решение, и выигрывает вендор, т.к. 1) объем работ больше, селовательно и кастомер заплатит больше и 2) И разработчикам так легче, чем рыться в индусском коде.
Другой случай (тоже из реальной жизни). Система писалась одним человеком на протяжении 10 лет. Жутко связана с другими системами (итеграции по средствам файлов, БД и прочего булшита). Кастомер принял решение — переписать заново, т.к. 1) В этом 10тилетнем хламе сложно разобраться 2) ЕГо сложно поддерживать и 3) Его архитектура — УГ и связывает все остальные системы. Чтобы развязаться — нужно полностью пересмотреть весь подход. Также есть 4я цель — т.к. писал систему 1 человек, то слишком велики риски.
Я пишу всё это к тому, что во-первых, не всегда девелопер определяет, переписывать заново или нет. И во-вторых, это комплексное решение, зависящее от многих факторов (перфоманс, скалабильность текущего решениея и т.п.
Зря минусуете. Есть в этом правда. Мне тоже приходилось работать с ребятами по 12 и по 15 лет стажа. ИМХО, это непросто. Люди становятся абсолютно уверенны в своей точке зрения. Их оооочень сложно переубедить. Буквально только через архитектора или менеджера. Иначе — они мою точку зрения не принимали. И далеко не всегда эти люди были действительно гуру. Иногда да, а иногда — нет. И во втором случае не понятно, на чем основывалась их самоуверенность.
Абсолютно верно. Те два примера, которые я привел — на самом деле модули одного большого проекта. Но я их назвал «системой» — из-за их независимости от общего проекта.
Другой случай (тоже из реальной жизни). Система писалась одним человеком на протяжении 10 лет. Жутко связана с другими системами (итеграции по средствам файлов, БД и прочего булшита). Кастомер принял решение — переписать заново, т.к. 1) В этом 10тилетнем хламе сложно разобраться 2) ЕГо сложно поддерживать и 3) Его архитектура — УГ и связывает все остальные системы. Чтобы развязаться — нужно полностью пересмотреть весь подход. Также есть 4я цель — т.к. писал систему 1 человек, то слишком велики риски.
Я пишу всё это к тому, что во-первых, не всегда девелопер определяет, переписывать заново или нет. И во-вторых, это комплексное решение, зависящее от многих факторов (перфоманс, скалабильность текущего решениея и т.п.