мы с вероятностью в 80% перестанем ловить постоянные баги… время модернизации функционала (а мы его модернезируем постоянно) увеличится примерно на 40%
Честно говоря, больше похоже на речь ясновидящего, а не программиста) Не очень люблю давать такие громкие обещания менеджменту, потому что потом, чуть что, обязательно будут фразы «ну ты же говорил...», «уже два бага за неделю, а ты обещал...».
А если, действительно, сидеть и подробно анализировать, что время разработки увеличится именно на 40%, а не на 30, то как тут уже писали, на это времени может уйти как на сам рефакторинг :)
Я считаю, что лучший вариант — это когда бизнес и разработчики знают, как найти общий язык и хоть немного вникают в проблемы друг друга, а не живут в параллельных измерениях.
Первое что приходит в голову: у вас есть какой-нибудь класс FileSystemStorage, который используется для сохранения картинок в локальной файловой системе. Этот класс используется в 100500 местах в проекте. Потом поступает требование, чтобы для хранения использовался Amazon S3. Без интерфейса мы создаем класс AmazonS3Storage, и нам приходится менять код во всех 100500 местах, где использовался FileSystemStorage. Если бы мы делали зависимости от интерфейса, а не от класса, то нам бы понадобилось исправить всего 1 строку в конфигурации DI контейнера.
Могу сказать одно: я точно знаю, что детали приходят в негодность (так же, как и меняются бизнес-требования и технические требования в приложениях). И я не хочу из-за неисправного масляного фильтра менять весь двигатель, или покупать новую машину только из-за того, что хочу литые диски, а не железные.
Ваша проблема в том, что вы утрируете. Придумываете какие-то небылицы с превращением обычного двигателя в ядерный или бургеров в блинчики. В реальной жизни и в программировании великое благо, когда можно при необходимости легко заменять одни части другими (в разумных пределах), а не выкидывать все и писать/покупать с нуля.
И Вы же не ожидаете, заказав в макдоналдсе гамбургер подождать лишний час, что вам сделали такой бургер, который при желании может стать и блинчиком?
Какой-то не совсем удачный пример. Это вы представьте, что вы покупаете машину, а вам продают нечто, где нельзя заменить ни одну деталь, а можно только выкинуть всю машину и купить новую. Я сомневаюсь, что кто-то бы такое купил.
Под разработчиками я имею в виду именно пишущих код людей. А обязанность аналитика как раз заключается в сборе, анализе и структуризации требований от заказчика.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
За счет чего продукт станет менее полезным, если с заказчиком будет общаться только аналитик, структурировать хаотичную информацию, приводить ее в понятный вид и обсуждать это все с разработчиками в спокойной обстановке?
(ООП) Наличие огромного количества «....Manager» классов, которые содержат все методы манипуляции с объектами, которые, в свою очередь, совсем не содержат (или содержат мало) методов.
То есть, классы сервисного слоя в Java-приложениях, которые оперируют объектами anemic моделей — это признак плохого программиста?
Конечно, есть вакансии, ЗП по которым очень плавающая и определяется только в ходе собеседования. Но мне непонятно вот что: если есть конкретная вакансия с конкретным потолком ЗП, зачем на собеседовании опять выпытывать у соискателя информацию о желаемом размере ЗП, а затем еще многозначительно молчать, когда говоришь сумму, заявленную в вакансии?
Предположим, если на hh.ru есть вакансия «Веб-программист, такой-то опыт работы, ЗП 60-70к», то было бы, как минимум, глупо проходить по ней собеседование, если минимальный желаемый размер ЗП составляет 120к. И наоборот, если человек видит, что он подходит под требования данной вакансии, то, конечно, он скорее всего будет рассчитывать на заявленный максимум. Думаю, вряд ли он в здравом уме будет просить по данной вакансии 35к.
Если честно, сейчас больше интересует подход с сервисными слоями. Я уже применял принцип «всю логику помещать в модель» — модели очень сильно разрастались)
Насчет клонирования объекта — смысл понятен)
А что бы вы порекомендовали в случае сущностей и сервисов? Если не использовать DI контейнер, то оставлять их жестко зависимыми от других классов?
Где-нибудь есть хорошее описание таких вещей — для каких случаев контейнер предназначен/не предназначен, насколько правильно инжектить в сущности и т.д.?
Я немного другое имел в виду. Возьмем такой примитивный пример:
class BooksService {
public function booksMethod()
{
$book1 = new Book;
$book1->someAttr = 'val1';
$book1->someMethod();
// ...
$book5 = new Book;
$book5->someAttr = 'val5';
$book5->anotherAttr = 'anotherVal';
$book5->someMethod();
// ...
}
}
Как мне с помощью Dependency injection добиться того, чтобы класс BooksService не зависел жестко от класса Book, и также не был бы Container Aware классом? Такое возможно?
Еще такой вопрос: а если у нас в классе есть метод, в котором нужно использовать не один какой-то конкретный объект, который мы можем передать в аргументе, а нужно создать и использовать несколько объектов определенного класса? Как в таком случае поможет DI?
Однако на практике многие компании живут тем, что пишут платные модули и компоненты для бесплатных фреймворков и cms. Продается не фреймворк ведь, а тот код, который написала сама студия.
Не использовать никакие опенсорсные продукты и писать всё с нуля, боясь каких-то проблем с налоговой — имхо, что-то отдаленное от реальности. Если бы действительно была хоть в какой-то степени серьезная угроза со стороны налоговой, то фреймворки у нас бы использовали одни фрилансеры. Однако, это не так, если посмотреть хотя бы на требования в вакансиях на hh.
Спорить по этому поводу можно долго и упорно. Как пример — Yii достаточно быстр, и очень неплохо настраивается под highload. 2GIS, в частности, его использует для разработки своих сервисов.
Честно говоря, больше похоже на речь ясновидящего, а не программиста) Не очень люблю давать такие громкие обещания менеджменту, потому что потом, чуть что, обязательно будут фразы «ну ты же говорил...», «уже два бага за неделю, а ты обещал...».
А если, действительно, сидеть и подробно анализировать, что время разработки увеличится именно на 40%, а не на 30, то как тут уже писали, на это времени может уйти как на сам рефакторинг :)
Я считаю, что лучший вариант — это когда бизнес и разработчики знают, как найти общий язык и хоть немного вникают в проблемы друг друга, а не живут в параллельных измерениях.
Ваша проблема в том, что вы утрируете. Придумываете какие-то небылицы с превращением обычного двигателя в ядерный или бургеров в блинчики. В реальной жизни и в программировании великое благо, когда можно при необходимости легко заменять одни части другими (в разумных пределах), а не выкидывать все и писать/покупать с нуля.
Какой-то не совсем удачный пример. Это вы представьте, что вы покупаете машину, а вам продают нечто, где нельзя заменить ни одну деталь, а можно только выкинуть всю машину и купить новую. Я сомневаюсь, что кто-то бы такое купил.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
То есть, классы сервисного слоя в Java-приложениях, которые оперируют объектами anemic моделей — это признак плохого программиста?
Предположим, если на hh.ru есть вакансия «Веб-программист, такой-то опыт работы, ЗП 60-70к», то было бы, как минимум, глупо проходить по ней собеседование, если минимальный желаемый размер ЗП составляет 120к. И наоборот, если человек видит, что он подходит под требования данной вакансии, то, конечно, он скорее всего будет рассчитывать на заявленный максимум. Думаю, вряд ли он в здравом уме будет просить по данной вакансии 35к.
А что бы вы порекомендовали в случае сущностей и сервисов? Если не использовать DI контейнер, то оставлять их жестко зависимыми от других классов?
Где-нибудь есть хорошее описание таких вещей — для каких случаев контейнер предназначен/не предназначен, насколько правильно инжектить в сущности и т.д.?
Как мне с помощью Dependency injection добиться того, чтобы класс BooksService не зависел жестко от класса Book, и также не был бы Container Aware классом? Такое возможно?
Не использовать никакие опенсорсные продукты и писать всё с нуля, боясь каких-то проблем с налоговой — имхо, что-то отдаленное от реальности. Если бы действительно была хоть в какой-то степени серьезная угроза со стороны налоговой, то фреймворки у нас бы использовали одни фрилансеры. Однако, это не так, если посмотреть хотя бы на требования в вакансиях на hh.