Фреймворки, действительно ли важно?

Question

[gerasim_mumu]

Зачем нужны фреймворки мы и так с вами знаем.

1. Облегчить работу кодера
2. Иметь возможность заменить его на другого с теми же знаниями

Но, допустим я освоил язык и пользуюсь исключительно собственными наработками, шаблонами и т.д. Почему это не имеет ценности?

Comments

[WbICHA]

Почему это не имеет ценности?

Потому что в проектах используются фреймворки?

[Sub@ru]

У меня назрел встречный вопрос!!
А как вы видете свою работу в команде (в коллективе)!?

Answer 1

[Griboks]

Почему это не имеет ценности?

Это имеет ценность и является оптимизированным решением под конкретную задачу. В любой сфере за это с вас берут наценку +500% (одежда на заказ, персональный повар, тюнингованный автомобиль).

Нюанс заключается в том и только в том, что при модернизации вам потенциально придётся работать больше чем при использовании фреймворка.

Answer 2

[Александр Талалаев]

Самое важное это повторение уже сделанной работы.
Фреймворки для вас это уже сделанная работа, которую не нужно повторять. Более того, если фреймворк популярный - это качественная работа, с высокой насмотренностью, известными проблемами и тп.
И вот будет ли у вас такое же качество?
Почитайте ещё про фактор автобуса - вас сбил грузовик/автобус, вы погибли. Что делать с вашим наследием, копаться в нём? Делать новое? Кто этим займётся?
Отдельный вопрос что ваши штуки нужно будет другим людям специально изучать, если подключаться к проектам что вы ведёте или вели. И зачем это бизнесу? как найти людей которые знают ваши инструменты ваш подход?
К примеру даже у крупных компаний проблемы с подобным: например движок EA frostbite, который они мучают и при наёме новых людей их нужно прям обучать обучать всем фишкам, костылям и тп. С UE, Unity таких проблем нет.

Так что, если делаете лично для себя, само развитие и тп - это круто и праивльно, делать свои костыли, экспериментировать.
Если вы делаете для кого-то другого - вы подставляете заказчика, подкладываете бомбу под бизнес. Которая может потом сильно затруднить развитие.

Comments

[Griboks]

Если вы делаете для кого-то другого - вы подставляете заказчика, подкладываете бомбу под бизнес.

Скорее, это иголка на минном поле, которое заложил заказчик, не выдав техническое задание.

[Александр Талалаев]

Griboks, это уже другая проблема.И совсем не иголка. К чему профи будет городить свои костыли, если есть уже проверенные готовые решения - когда будет быстрее, безопаснее и надежнее в плане поддержки.
Конечно есть исключения, есть специфики, особые случаи и ид и тп. Я безусловно обобщил.
Но в общем случае, вся эта возня со своим всем своим кончается плохо, при прочих равных

[Griboks]

Александр Талалаев, наоборот. Возня со своим оригинальным кодом при прочих равных всегда, абсолютно всегда выигрывает. Например, мы решили написать телеграм-бота, который каждый час постит картину в группу. Как это делает самопис:

while (true) {
photo= google.get_random_photo_url('my_api_key');
http.get('https://telegram.api.org/bot123/sendPhoto?url='+photo);
sleep(3600*1000);
}

Да, это некрасиво, это не масштабируется и вообще, но эта штука будет работать 100% в любое время на любом сервере.

Как это делает люитель фреймворков:
1. Скачать шаблонизатор проектов
2. Создать проект, прописать конфиги
3. Зафиксировать зависимости
4. Раскидать 2 функции по 10 папкам/файлам маршрутов, представлений и т.п.
5. Настроить планировщик задач
А вот эта штука по всем канонам требует предварительной настройки окружения. При каждом обновлении требуется проводить ряд тестов. Некоторые модули могут оказаться несовместимыми. Баги и фичи придётся ждать по несколько месяцев. А если нет требуемой функциональности, то это становится невыполнимой задачей. Кроме того, видно сразу 5 точек отказа.
Ну и бонусов что-то вроде неактуальной документации у фреймворка, типа создавай приложения с помощью create-react-app.

[Александр Талалаев]

Griboks, вы не путайте конкретную задачу, где условный тяжёлый груз не нужно нести, и общий подход для сложных сервисов.
Понятное дело ко всему нужный здравый подход, логика и тп. Это рабочие моменты. Не вижу противоречий.

[Griboks]

Александр Талалаев, общий подход принадлежит домену управления. А вот выбор фреймворка - это как раз тот самый рабочий момент под конкретную задачу.

Я не говорю, что нужно писать новый фреймворк на каждый проект. Но если у автора уже есть готовый рабочий с покрывающей функциональностью, то лучше применять его.

[Александр Талалаев]

Griboks, о боже. Ну вы серьезно. Причем тут домену управления, это напрямую не связано с вопросом.
Вопрос сови костыли - рост издержек и подводных камней на будущее, готов вкладываться в команду внутри компании которая будет её поддерживать или нет? Ведь бизнес растёт, развивает, и маленькая фигня будет больше требовать всяких интеграций и вместо того чтобы развивать и растить самую базовую бизнес логику мы будем с правильными папочками пилить свое решение, а зарплатки откуда?
И естественно, важен здравый смысл, иногда полезно и нужно свой интструмент пилить, по причинам допустим критичности безопасности(но тут снова это часть ядра основного бизнеса тогда), либо это важно для бизнес/продаж, а может и в опенсурс потом самим выкатить и тоже определенные плюшки получить.
Вы даёте примеры, даже выше, которые легко разбить будет при росте и началу усложнения требваний/изменения апи стороннего сервиса и тд и тп. Это всё нужно поддерживать.
Вопрос а есть ли на это бюджеты? Не будем ли проедать относительно главной цели?
Не выстрелим ли себе в ногу просто проходя сами тот путь, который уже другие прошли отточили и тп.
И таких но много.
Каждый раз нужно принимать решения конкретно.
Если вам показалось что я за безумно бездумные фреймоворки везде и всегда, то абсолютно нет.
Но и из принципа "потому что бла бла" отказываться от них не буду.
А уж если прогер одиночка, фрилансер - то тут тупо подстава для маленького бизнеса. Он уйдёт, а его гениальные костыли никто не захочет поддерживать, либо возьмёт за это дополнительные деньги. Это уже все тысячи раз проходили. Но все равно эти вопросы возникают.
Поэтому ответ по умолчанию - изучить что сделано, возможно есть хорошие решения и их можно использовать, планирование, разработка.
Зачем тогда Яндекс использует Реакт и ко? Та ведь ещё костыльная технология. Но зато много чего на ней уже есть, много хороших(правда и не хороших тоже) спецов.
Так и живём.
Нужен здравый смысл и адекватное отношение к требованиям и реальным целям стейкхолдеров(и не важно кто это бизнес, общественная организация и тп). Лишний раз удорожать не стоит.

[Griboks]

Александр Талалаев, нет, вы не поняли моей мысли. Если кратко, то во всём виноваты менеджеры - это они подстовляют проекты, потому что не хотят работать.

spoiler

Перед непосредственным кодингом осуществляется планирование и проектирование. Этим занимаются другие люди, которые затем должны выдавать конкретное задание конкретному работнику. Это всё происходит в домене управления, потому что никак не приближает релиз продукта, а только ускоряет его (т.е. 0 х супер-пупер менеджерские советы = 0).

А вот когда работник/команда получает задачу "сделать api", то это совершенно отличная задача от "сделать api на api-framework-28". И эта задача далее является зоной ответственности исполнителей, которые самостоятельно выбирают необходимые инструменты. Однако все вопросы поддержки, развития, найма и прочего - зона ответственности управленцев, которые за эти риски, строго говоря, получают +500% к зарплате.

Вы правы, исполнителю действительно нужно здраво выбирать фреймворк, но свой собственный - это не есть плохо. Это просто одна из альтернатив, которая имеет выраженные достоинства и недостатки по сравнению с классическими фреймворками.

Answer 3

[Jacen11]

потому что с вами никто не сможет работать, если вы фрилансер, нет проблем. Вы говорите буквально "я придумал клингонский, почему меня за это не любят и не дают миллионы денег?". Ну потому что это никому не нужно.

особенно мне нравится ваша уверенность, что ваши методики лучше, чем у тысяч программистов за десятилетия лет практики и множество обсуждений

Comments

[Adamos]

Годы практики, километры обсуждений - и череда исправлений после потоков фидбека.
Долгий путь, который самопис еще даже не начинал.

[Griboks]

Adamos, На самом деле это действительно лучше чем очередной супермодный фреймворк от фейсбука.

Answer 4

[Сергей delphinpro]

Почему это не имеет ценности?

Для кого? Для вас или для заказчика?

Что нужно работодателю?
Ему нужен код, который будет выполнять его бизнес-задачи.

Как можно написать этот код?
1, Как вы - "я крут, я придумал свой фреймворк"
2, Взять уже готовый slim/laravel/symfony

Какая разница, спросите вы?
Для вас – никакой. ВЫ сделали проект и забыли про него. А Клиент потом захочент внедрить новые возможности.

У него опять будут варианты:

1, Искать вас для доработок, потому что вы делали систему, и хорошо ее знаете (а ваша доступность может быть неприемлема).
2, Нанять любого спеца по slim/laravel/symfony.

И вот тут становится очевидным преимущество использования популярных решений.

Comments

[Griboks]

Ему нужен код, который будет выполнять его бизнес-задачи.

Нет, ему нужно готовое решение, которое приносит деньги.

А Клиент потом захочент внедрить новые возможности.

Получается, он будет вынужден снова нам заплатить за модернизацию, а не голодному студенту.

Как видите, от самописа одни выгоды на фрилансе.

[gerasim_mumu]

Как и многим тут, отвечу:
1. Как и любой адекватный кодер, нужно комментировать свои действия что бы и самому в дальнейшем не запутаться в километрах кода, я уже не говорю о серьезности передачи информативности в следующие руки кодера.

По этому страхи бомбы можно исключить.. ведь, огромное количество самописных проектов до сих пор гуляет на просторах и отлично работают с изменениями разработчика или целой группы..

2. Да, фреймворки удобны в плане готовых решений, но отнюдь не все решения они могут предоставить, тогда кодер должен писать собственные костыли и придумывать велосипеды.

Как уже заметил Griboks, в плане повторных модернизаций, заказчик так же бы мог обратиться ко мне, это бы дало хлеб и воду мне, иметь проекты которые постоянно имеют развитие, а ты их создатель - дают тебе почву под ногами, даже когда ее нет у тех, кто фреймит.

[Сергей delphinpro]

. Как и любой адекватный кодер, нужно комментировать свои действия что бы и самому в дальнейшем не запутаться в километрах кода

ну да. И часто вы документируете свой код?

Как уже заметил Griboks, в плане повторных модернизаций, заказчик так же бы мог обратиться ко мне, это бы дало хлеб и воду мне, иметь проекты которые постоянно имеют развитие, а ты их создатель - дают тебе почву под ногами, даже когда ее нет у тех, кто фреймит.

Заказчика нужно ловить не на эту удочку. Качественно сделанная работа лучше его удержит.
К примеру мне удавалось убедить клиента переписать его самописный проект на популярное решение. Внимание вопрос: а почему он не обратился к тому, кто этот самопис писал?

[Сергей delphinpro]

Да, фреймворки удобны в плане готовых решений,

Не так. Это заготовки типовых решений. Плюс, бонусом, расширения (пакеты) от сообщества для реализации каких-то готовых решений. В остальном вам в любом случае нужно будет реализовывать бизнес-логику самостоятельно.

[jazzus]

он будет вынужден снова нам заплатить

Кроме паразитирования на тему "никто кроме меня в этом говне не разберется" плюсов больше не нашлось.

Answer 5

[Сергей Водаков]

Тут вчера женщина спрашивала, что такое библиотеки.
Мой ответ ей, подойдет и вам.
Вы можете собрать лен, спрясть нитки, соткать полотно, скроить и пошить рубаху, это займет у вас месяц.
А клиенту нужна рубаха, поэтому он пойдет к портному, который возьмет отрез ткани и сошьет её за несколько дней.
И даже если клиенту не важны сроки (хотя такого не бывает), кто оплатит вашу возню со льном?

Comments

[gerasim_mumu]

Как и любой адекватный кодер, нужно комментировать свои действия что бы и самому в дальнейшем не запутаться в километрах кода, я уже не говорю о серьезности передачи информативности в следующие руки кодера.

Взять за основу ваши метафоры, то:
У Портнова не окажется ниток, купить их негде, что он будет делать?

[Сергей Водаков]

gerasim_mumu, мне кажется вы разводите спор ради спора. Портной, который не умеет или не хочет пользоваться готовыми нитками в городе никому не нужен, на необитаемом острове будет незаменим.
Программист который принципиально не пользуется фреймворками, не справится с реальной бизнес-задачей в приемлемые сроки. Программист который умеет обходиться без фреймворков - сможет написать небольшую программу на компе без доступа к интернету, может быть когда-то ему это пригодится.
Только вот те кто пользуются фреймворками смогут, при необходимости написать нечто подобное, а те кто не хочет их учить, будут изобретать велосипеды, и не факт что качественные.

Answer 6

[mayton2019]

Я вот предложу пойти от происхождения слова. Что такое фреймворк если мы не знаем определения слова?
Фрейм - это рамка. Work - работа. Тоесть работа в рамках. Рамочная работа.

Безотносительно пользы или вреда от фреймворков уже можно предположить что это некое ужесточение
порядка процесса разработки. Разработчик ЯП - свободен. Разработчик фреймворка - менее свободен.
Фреймворк предполагает некоторую дисциплину в разработке user-stories. К примеру вы работаете
с акторным фреймворком (Akka) и вы не можеет просто так запускать вычислительные Threads
потому что это идеологически неверно. Вы должны декомпозировать задачу на набор функций-акторов
которые делают простое действие и передают результат другим акторам. Если вы вдруг резко вильнули
в сторону и затащили во фреймворк какую-то непонятную логику которая не ложиться на идеологию -
то синьоры-лиды сурово сдвинут брови и попросят вас немедленно откатить из feature branch все
что не соответсвтует. Такую ситуацию можно рассмотреть под разными углами. С одной стороны
хорошо что вы не виляете туда-сюда. Код получается гомогенный и понятный. Акторы. Сервлеты.
Bean-компоненты, SpringBeans, ApacheCamel компоненты e.t.c. С другой стороны если автор имеет
амбиции к использованию только своего кода - тут надо обсудить приемлемость такого подхода
в команде. Это - полюбому конфликт. А конфликты в корпоративной среде устраняются очень быстро.
С автором будет проведен разговор. И далее у него будут варианты - работать
в парадигме фреймворка или .. искать другие проекты. Здесь параллельно со фреймворком идут
техники управления людьми на проекте.

Еще одно лирическое отступление.

Недавно я читал комьюнити программистов языка Forth. Эти ребята - большие философы написания
кода. У них - практически нет не то что фреймворков но и даже библиотек. Просто такова специфика
языка. Чего-то нет - напиши сам. Скорее всего сама целевая платформа (микро-устройства) определяет
лимиты и фреймворки и либы просто не приживаются там.

Comments

[Griboks]

Похоже, вы забыли, что все эти идеологии, парадигмы, фреймворки, user-stories существуют лишь с одной целью - облегчить жизнь программиста и сделать его свободным, а не загнать в рамки. Как часто я вижу "идеологов", которые меняют место работы несколько раз в год, потому что где-то "данные в структурах дублируются", а где-то "функция принимает слишком много параметров". Вот они тратят месяц работы на идеализацию и рефакторинг, а потом их увольняют, потому что у птушника код просто работает.

[Сергей delphinpro]

Что такое фреймворк если мы не знаем определения слова?
Фрейм - это рамка. Work - работа. Тоесть работа в рамках. Рамочная работа.

Скорее каркас. Некая конструкция, на основе которой пилится кастомизированное решение.

[Wan-Derer]

Фрейм - это рамка. Work - работа. Тоесть работа в рамках. Рамочная работа.

Нет. У слова framework есть самостоятельные переводы. Фундамент, каркас.

Answer 7

[CityCat4]

я освоил язык и пользуюсь исключительно собственными наработками, шаблонами и т.д. Почему это не имеет ценности?

Потому что это завязка на персонально Вас. А для бизнеса это плохо как минимум по двум причинам:
- Звездная болезнь. Вот Вы весь такой из себя умный написали супер-программище, которая делает зашибись. Но Вас поразила звездная болезнь, Вы не пишете документацию, не обьясняете, как Ваша супер-мега-программа работает, всех других програмистов считаете за никого и не снисходите до общения.
- Фактор автобуса. Вы шли по улице и Вас сбил автобус. Насмерть. и Вы теперь в Лабиринте Синего Неба (привет, Aozora Meikyuu!). Как теперь поддерживать Ваше творение?

Бизнес старается таких вещей избегать, а если уж досталось "по наследству" - тупо отказываться и переписывать. Начисто. На более-менее стандартном инструменте.

(Про звездную болезнь - пример из жизни, увы. Сейчас как раз идет развод с таким вот звездуном)

Comments

[gerasim_mumu]

Это выпущено с дословным "допустим"...

1. Как и любой адекватный кодер, нужно комментировать свои действия что бы и самому в дальнейшем не запутаться в километрах кода, я уже не говорю о серьезности передачи информативности в следующие руки кодера.

2. Да, фреймворки удобны в плане готовых решений, но отнюдь не все решения они могут предоставить, тогда кодер должен писать собственные костыли и придумывать велосипеды.

Представим что кодер элементарно не знает кода, он хорошо разобрался во фреймворке, полностью изучил библиотеку с документацией, достойно пишет код на этом фрейме*, но сам код он не знает и не знает как изобрести то, что от него требуют, но этого нет во фрейме* что тогда?