Как можно продать идею типа «мы должны использовать jQuery, потому что он высоко оптимизирован и совместим с разными браузерами», или «инфраструктура сущностей - это круто, потому что она аккуратна и автоматически заботится о нашей модели», когда общим ответом является закрытое утверждение, такое как «jquery». плохо работает "или" сущности приносят в таблицу 12 столбцов, когда нам нужно только 10 "?
Я - прагматичный парень, который склонен доверять аксиомам, которые я развил через опыт (это не проблема с производительностью, пока нет видимого замедления). Я не знаю, есть ли конкретная «категория», в которую вписывается другая крайность, в то время как все является проблемой производительности, пока не доказано обратное ... или даже с чего начать общение здесь.
источник
Ответы:
Принесите им убедительные факты!
Например, существуют тесты производительности для сред ORM и JS. Кроме того, у всех фреймворков и ORM есть хорошие аргументы по продажам на их домашней странице.
Прочитав ваш комментарий, я считаю, что в вашем случае проблема не в правильной технологии. Это люди, которые отказываются изучать новые технологии.
источник
Я сталкивался с этой проблемой раньше, люди, желающие изобрести велосипед. Я обычно объясняю им, что мы можем сделать продукт лучше и лучше, если потратим время на совершенствование того, что важно, а не того, что лежит под ним. Плюс ... Я имею в виду рамки для REASON, и производительность на самом деле не так важна в наши дни. Надежность важнее, и если у фреймворков хорошие отзывы / рейтинги, то они, вероятно, более надежны, чем что-либо, что кто-либо может создать на лету.
источник
Кажется, что все не согласны с вашим коллегой, но я думаю, что вы должны относиться к его аргументам серьезно, если только для того, чтобы понять его точку зрения. Я твердо верю в фреймворки, когда они вам нужны или когда они действительно обеспечивают оптимизацию, но я также считаю, что чрезмерная зависимость от фреймворка может привести к слабому развитию в некоторых случаях.
Я думаю, что вам следует меньше подходить к проблеме с точки зрения того, что ваш коллега неправ, и больше с точки зрения того, что использование платформ, о которых вы думаете, улучшит время разработки, производительность, обслуживание и т. Д.
Я всегда стараюсь использовать правильный инструмент для правильной работы. Мне не нужны сани весом 12 фунтов (jQuery), чтобы забить гвоздь, чтобы повесить картину (обмен изображениями). Но если я столкнусь с ситуацией, когда я вешаю картину, которая требует, чтобы железнодорожный шип удерживал ее на стене, мне лучше подготовить эти сани.
источник
он прав, есть накладные расходы
но предположение о том, что служебная информация структуры представляет собой нечто большее, чем решение с ручным кодированием, может быть неверным, и даже если оно является правильным, служебные данные могут быть несущественными.
предложить тест:
Скорее всего, с фреймворком будут небольшие накладные расходы - очень маленькие - но огромная разница в том, сколько времени потребуется, чтобы закодировать [и отладить!] решение
тогда твой друг может поспорить с фактами, а не с тобой
примечание: будьте готовы к продолжению сопротивления; во многих случаях откат против фреймворков выражается в технических терминах, но на самом деле это дымовая завеса для «не изобретено здесь» или «я не хочу изучать другой инструмент»
источник
Напомните своему коллеге, заново изобретающему колесо, что он делает различные преждевременные оптимизации. Как он может знать, что эти платформы представляют недопустимый удар по производительности, пока не будет продемонстрировано, что они вызывают проблему. Между тем, ваша взаимная продуктивность, безусловно, снизится со всей дополнительной работой, которую вы должны были выполнить.
источник
Как насчет того, чтобы объяснить снижение производительности временем выполнения проекта, когда вы не используете некоторые из этих огромных, экономящих время и проверенных в бою фреймворков?
источник
Один из вариантов - сказать ему, что он отвечает за настройку производительности - если можно показать, что есть проблема с производительностью! Или, если у вас есть ресурсы, создайте два Proof-of-concept: вы создаете свой с помощью jQuery и всего остального, что вам нужно. Он может построить его с помощью своей собственной суперскоростной системы. Не позволяйте этому продолжаться более пары дней (это является проверкой концепции) и посмотрите, кто в итоге выступит лучше.
И, конечно, как уже упоминали другие, получите некоторые точные цифры и характеристики производительности для обеих сторон аргумента.
источник
Во-первых, он может быть правильным для вашей конкретной ситуации.
Поскольку кажется, что у вас проблемы с тем, чтобы заставить его взглянуть на вашу точку зрения, вам нужно лучше убедить его.
Вы двое находитесь в двух разных точках вдоль линии между "Build" и "Buy". Это довольно длинная очередь. Слева, в «Build» у вас есть SpaceX, который должен был построить целую индустрию. Справа в разделе «Купить» вы получаете полный аутсорсинг всех ИТ-функций IBM, HP и т. П., А бизнес вообще не занимается кодированием. В середине, на расстоянии около 2 мм, вы двое. Вам обоим нужно убедить руководство в том, что ваш подход «построить против покупки» на основе и в нормальных условиях и тому подобное - и под словом «купить», я имею в виду «не построенный собственными силами» - в интересах компании, долго -срок. Твиттер умер бы, если бы они были переданы в IBM. Они катились самостоятельно. Подумай об этом.
В любом случае, руководство должно сойти с поля для гольфа, попасть туда и выполнять свою работу.
источник
Для ORM ответ - «Только если вы напишите свой запрос таким же образом, то же самое можно сказать и о SQL». Как уже говорили другие, вам нужны неопровержимые факты.
Кроме того, задайте конкретные вопросы, чтобы разобраться в том, что он говорит: «Можете ли вы привести пример того, как JQuery не работает, потому что это не мой опыт».
Третий вариант, и старый мудрый разработчик предложил мне это, просто включить «вещь» в любом случае (при условии, что у нее нет плохих проблем).
Поиск одобрения приводит только к ответу «нет». Получите это там, тогда вы можете попросить их указать на конкретные области и попросить их рассказать вам, в чем проблема.
«Эй, этот код EF возвращает только 2 необходимых элемента данных из этой таблицы, в чем проблема» и т. Д.
Очевидно, что вы должны быть достаточно уверенными в себе и в своем инструменте, прежде чем продолжить работу с этим подходом! :-)
источник
Ну, отвергать такие библиотеки из-под контроля глупо и иногда высокомерно. Часы продукта, вложенные в них, и мысль, лежащая в их основе, делают отказ от них просто смешным.
Может случиться так, что ваш коллега прав, хотя вам нужно сравнить и перевесить требования к программному обеспечению, которое является частью дизайна. Может случиться так, что решение ORM или ActiveRecord слишком излишне или наоборот, что программное обеспечение нуждается в действительно связанном решении для БД, а ORM просто не будет его сокращать.
Принятие во внимание этих вещей важно каждый раз, когда вы разрабатываете программное обеспечение.
Для библиотек на стороне клиента я бы сказал, что это глупо, поскольку вы всегда можете найти подходящую среду для ваших нужд. И, как некоторые говорили до меня, что может быть лучше, чем проверенные в бою рамки?
Пусть он возьмет дерьмо из всех кросс-браузерных проблем, он охотно придет к вам по поводу того, как использовать фреймворк.
Кстати, у меня был босс, который не учитывал фреймворки. Я просто показал ему, как легко делать ajax-запросы вместо того, чтобы копировать функции снова и снова (что изначально было глупой идеей), ну, он не знал, как так кодировать ...
источник