Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
«фреймворки не нужны поэтому мы используем in-house аналог»
«У нас был собственный вебсервер, CGI, взаимодействие с базой данных, авторизация, и формирование клиентских страниц, а еще это было написано на си. Не то, чтоб это был необходимый запас для всех нужных нам фич, но включив NIH-синдром, остановиться уже трудно. Единственное, что у меня вызывало опасения — это сторонние фреймворки. Я знал, что рано или поздно мы перейдем и на эту дрянь...»
Непонятна мотивация минусования, автор же честно рассказал о том, к чему пришла его компания, которая судя по всему работает не первый год и даже не два.
Если их собственный фреймворк помогает им вести разработку быстрее и дешевле и при соблюдении требований к проектам, то «почему бы и нет»?
За мои 15 лет в разработке бекендов, были кучи примеров таких «инхаус» перед глазами, причем иногда все начиналось с популярных фреймворков, которые потом допиливались/перепиливались до нужной функциональности и уже становились теми же самыми «инхаус». Но в конечном итоге, после жизненного цикла в 5 лет, становилось очевидно, что дешевле было сразу создать свое, нежели чем адаптировать что-то стороннее.
Сей рецепт не универсален, и есть тысячи случаев, когда именно не надо пилить свое, но это же не означает, что инхаус это всегда плохо?
Если их собственный фреймворк помогает им вести разработку быстрее и дешевле и при соблюдении требований к проектам, то «почему бы и нет»?
За мои 15 лет в разработке бекендов, были кучи примеров таких «инхаус» перед глазами, причем иногда все начиналось с популярных фреймворков, которые потом допиливались/перепиливались до нужной функциональности и уже становились теми же самыми «инхаус». Но в конечном итоге, после жизненного цикла в 5 лет, становилось очевидно, что дешевле было сразу создать свое, нежели чем адаптировать что-то стороннее.
Сей рецепт не универсален, и есть тысячи случаев, когда именно не надо пилить свое, но это же не означает, что инхаус это всегда плохо?
Проблема подобных инхаус фреймворков в том что какой-либо функционал пишется один раз, в тот момент когда он потребовался, и потом практически никогда не модернизируется, не улучшается, зачастую очень сильно отставая в развитии от технологий. Нет поддержки комьюнити, которое помогает выявить баги.
Ну а про тесты, документацию и скорость исправления багов я вообще молчу.
Насчет не модернизируется вот не соглашусь. Если отдел разработки «пилит какое-нибудь и-коммерц ядро системы» для своей компании, то как раз ситуация может быть прямо противоположной. У нас как раз такая ситуация, выкатываем по 3..4 апдейта прода в неделю, из них как минимум 1 достаточно существенный. Приблизительно половина апдейтов случаются после обнаружения/устранения багов и по результатам профайлинга, а вторая половина — новые фичи или очередное А\Б тестирование.
У любого подхода есть минусы и плюсы. Если плюсы в частном случае перевешивают, то почему бы и не пойти таким путем? В нашем случае, мы получаем приличную производительность (по нашей предметной области). Никакой коробочный софт или фреймворк даже близко не сможет такое дать. И естественно продать на сторону этот свой «инхаус фреймворк» как коробочное решение (или фреймворк) мы не сможем. Но у нас и задачи такой не стоит.
У любого подхода есть минусы и плюсы. Если плюсы в частном случае перевешивают, то почему бы и не пойти таким путем? В нашем случае, мы получаем приличную производительность (по нашей предметной области). Никакой коробочный софт или фреймворк даже близко не сможет такое дать. И естественно продать на сторону этот свой «инхаус фреймворк» как коробочное решение (или фреймворк) мы не сможем. Но у нас и задачи такой не стоит.
Про апдейты — у нас практически аналогичная ситуация И про производительность — полностью согласен Причем для нас это главный приоритет.
У кода не может быть проблем априори. Он написан и работает ровно так, как его написали. И у вас судя по всему нет проблем на вашем рабочем месте. И «движок» ваш крут. Проблемы возникают, когда программист либо уходит из вашего проекта или приходит к вам. В первом случае с большой долей вероятности знания о вашем «движке» можно оставить у дверей на выходе. С такой же вероятностью у вас при смене работы станет важным знать и уметь в «Симфони»(в кавычках). А нового коллегу придется учить вашему «подходу» и всем оптимальным ходам.
«То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.
«То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.
Да в какой-то степени Вы правы. Если к нам приходит новый человек он какое-то время учится. Но знайте, что самое интересное? Когда-то у нас была попытка написать проект на рельсах. Взяли человека который утверждал, что рельсы он знает очень хорошо. Проект был достаточно сложный, как в общем и все наших проекты. Это был маркетплейс по покупке с доставкой сыпучих строительных материалов. Там было более 2к в водил которые размещали свои предложения и, когда заходил покупатель, для него нужно было автоматически сформировать наилучшее предложение на основании имеющихся прайсов (порядка 60к) расстояния доставки и еще некоторых факторов.
Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )
Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )
Под узкоспециальные задачи или ресурсоемкие процессы легко написать микросервис, отдельного «демона» или «воркер» хоть на вашем хоть на С. При этом обвязка будет написана любым из 1000 без дополнительного обучения.
Иными словами написать тот самый костыль о котором писал tuxi чуть выше ) Может сразу использовать то что этих костылей не требует?
Вот тут позволю себе не согласиться. Весь функционал постоянно дорабатывается и улучшается. У нас часть наших программистов работает над проектами заказчиков, а часть над инструментом для них и это процесс постоянный.
«Приходите к нам, у нас вы за месяц научитесь пилить на НЕфреймворке, и наберетесь ценного костыльного опыта, который вам нигде не пригодится, потому что на этом НЕфреймворке больше никто не пишет»
Какой программист в здравом уме пойдёт к вам закапывать себе карьеру?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размер имеет значение