И Вы же не ожидаете, заказав в макдоналдсе гамбургер подождать лишний час, что вам сделали такой бургер, который при желании может стать и блинчиком?
Какой-то не совсем удачный пример. Это вы представьте, что вы покупаете машину, а вам продают нечто, где нельзя заменить ни одну деталь, а можно только выкинуть всю машину и купить новую. Я сомневаюсь, что кто-то бы такое купил.
Под разработчиками я имею в виду именно пишущих код людей. А обязанность аналитика как раз заключается в сборе, анализе и структуризации требований от заказчика.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 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, в частности, его использует для разработки своих сервисов.
Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!».
Мне, наоборот, кажется, что джуниоры в большинстве своем вообще мало что комментируют и просто не хотят тратить на это время. Несколько раз сталкивался с унаследованными проектами без единого комментария, с кодом уровня явно не умудренного опытом сеньора. Не знаю, может, это только мне так попадается.
Насчет инлайновых комментариев сложно сказать однозначно, а вот по поводу докстрингов к методам и классам — никогда бы не сказал, что они что-то ухудшают. Во-первых, они сильно улучшают автокомплит в IDE, во-вторых, часто помогают быстро понять основное назначение и принцип работы класса/метода, в-третьих, по ним можно автоматически сгенерировать документацию, ну, и в-четвертых, IDE позволяет их сворачивать, если для кого-то они ухудшают читаемость.
Какой-то не совсем удачный пример. Это вы представьте, что вы покупаете машину, а вам продают нечто, где нельзя заменить ни одну деталь, а можно только выкинуть всю машину и купить новую. Я сомневаюсь, что кто-то бы такое купил.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
То есть, классы сервисного слоя в Java-приложениях, которые оперируют объектами anemic моделей — это признак плохого программиста?
Предположим, если на hh.ru есть вакансия «Веб-программист, такой-то опыт работы, ЗП 60-70к», то было бы, как минимум, глупо проходить по ней собеседование, если минимальный желаемый размер ЗП составляет 120к. И наоборот, если человек видит, что он подходит под требования данной вакансии, то, конечно, он скорее всего будет рассчитывать на заявленный максимум. Думаю, вряд ли он в здравом уме будет просить по данной вакансии 35к.
А что бы вы порекомендовали в случае сущностей и сервисов? Если не использовать DI контейнер, то оставлять их жестко зависимыми от других классов?
Где-нибудь есть хорошее описание таких вещей — для каких случаев контейнер предназначен/не предназначен, насколько правильно инжектить в сущности и т.д.?
Как мне с помощью Dependency injection добиться того, чтобы класс BooksService не зависел жестко от класса Book, и также не был бы Container Aware классом? Такое возможно?
Не использовать никакие опенсорсные продукты и писать всё с нуля, боясь каких-то проблем с налоговой — имхо, что-то отдаленное от реальности. Если бы действительно была хоть в какой-то степени серьезная угроза со стороны налоговой, то фреймворки у нас бы использовали одни фрилансеры. Однако, это не так, если посмотреть хотя бы на требования в вакансиях на hh.
Мне, наоборот, кажется, что джуниоры в большинстве своем вообще мало что комментируют и просто не хотят тратить на это время. Несколько раз сталкивался с унаследованными проектами без единого комментария, с кодом уровня явно не умудренного опытом сеньора. Не знаю, может, это только мне так попадается.
Насчет инлайновых комментариев сложно сказать однозначно, а вот по поводу докстрингов к методам и классам — никогда бы не сказал, что они что-то ухудшают. Во-первых, они сильно улучшают автокомплит в IDE, во-вторых, часто помогают быстро понять основное назначение и принцип работы класса/метода, в-третьих, по ним можно автоматически сгенерировать документацию, ну, и в-четвертых, IDE позволяет их сворачивать, если для кого-то они ухудшают читаемость.