Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

Когда для проекта выбирается неподходящий инструмент

Всем привет!

Я проект менеджер и недавно задался вопросом о том, когда для проекта выбирается неподходящий инструмент: вроде redis вместо sql db. Наверняка у каждого из опытных разработчиков есть примеры.

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

Главное это то, что меня интересуют тулзы для организации работы, а не инструменты программирования — SharedPreferences или ngrok.

Если у кого-то есть релевантный опыт — буду рад узнать о нем!

LinkedIn

Лучшие комментарии пропустить

Пм может помочь команде выполнять работу лучше двумя способами:
1) если раньше был программистом — писать код под командованием программиста из команды, иначе помогать тестировщикам тестировать
2) не мешать, при чем настолько чтобы про твое существование забыли

Любые другие способы помочь будут только отрицательно влиять

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не в обиду специалистам — сталкивался не один раз с разработчиками, которые работают, что называется, «на коленках» :) Не знают какие есть инструменты управления проектами, для совместной работы, отладки... В связи с этим возникает вопрос — может имеет смысл создать нечто типа «группы товарисчей гуру» и написать мануал? А то и устроить что-то типа он-лайн обучения?

Что касается тулов для организации работа — то связка джира/гит/слака работает отлично.

Что касается инструментов — не лезь в это. Лучше найди архитектора без мании на все новое и тяги к демократии.

о да, мания на все новое — это зло. НО! иногда же ведь и толк от этого может быть. вот меня кстати такие фейлы и интересуют: было когда-то такое, что архитектор не то что-то выбрал и понеслась?

был на проекте где архитект ***овый неподдерживаемый фреймворк выбрал — 2 года не признавал фейла, а потом сказал что нашел новый (действительно был намного лучше), но по прежнему не признавал что то был фейл

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

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

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

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

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

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

значит так, я тебя сейчас научу.
Если структура построена так что ты имеешь весомое слово в выборе технологий (нет тех лида например) то команда — твой наизлейший враг, archenemy в вопросе выбора инструментов.
почему?!
Каждый раз они будут тебе продавливать все самые топовые новинки с которыми они захотят поиграться, самые последние хайпанутые тулзы и технологии, а давайте заменим реляционку на носкл+граф базу+что-то оперативное для кеша
а ты кто?!
Ты гребаный ПМ которому потом эти все технологии-годоваси поддерживать, искать персонал, переплачивать за 2.5 калеки на рынке по этой очумело модной сырой технологии

Поэтому
Каждый раз когда принимается КЛЮЧЕВОЕ решение по выбору технологии — попроси потратить топ дева пару часов и показать плюсы и минусы того что они хотят и классической обкатаной технологии — а там читай, либо покажи техно-соседу что бы он оценил и помог.

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

Хз, я как-то наоборот предпочитаю писать на том что знаю. Не без нового, но по необходимости, а не потому что это модно

Они ищут аты уже нашел © несмешной анекдот

Ну я тоже так думаю, но было время когда таки присунул парочку решений...которые дали опыт :-)

Опыт это хорошо, крайности — плохо :)

Зато плохие крайности дают хороший опыт ))))

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

что за решения? поделишься опытом?

Поэтому
Каждый раз когда принимается КЛЮЧЕВОЕ решение по выбору технологии — попроси потратить топ дева пару часов и показать плюсы и минусы того что они хотят и классической обкатаной технологии — а там читай, либо покажи техно-соседу что бы он оценил и помог.

Есть простой и действенный метод для оного.
Тому кто предлагает обычно поручается провести анализ и других инструментов, технологий. Подготовить развернутый документ и провести презентацию и обсуждение. После еще 2-6 недель на принятие решения.
В итоге. если действительно что-то разумное предлагают и предлагающий делает всё выше, то новая технология или инструмент принимается, иначе не принимается.

В общем использование принципа — инициатива наказуема.

такие обычно покажут как альтернативы не вписываются — не потому что они не вписываются а потому что он субъективен. я так одного чувака знаю, который типо архитект — предлагал технологию которая из другой «экосистемы» (в которой он раньше работал), и не решает поставленную проблему, так вот его анализ показал что те которые решают обладают кучей минусов (в то время как его вариант только одним мелким по его словам, то что не решает задачу это он не считал минусом), хотя все эти минусы были более чем решаемы о чем я ему сказал, но он их все равно оставил (что в целом норм)... и его решение выглядело наилучшим, если исходить из его анализа

И все остальные идиоты? Бывает...

ну я ему сказал о его недоработках (и это было весьма конкретно по пунктам), на что он мне ответил что я ничего не понимаю и так будет лучше, остальные кивают

Я вижу два варианта причин:
1. Антипаттерн «золотой молоток» — что умеем, в то и пляшем.
2. Желание за счёт заказчика освоить что-то новенькое, не просчитав плюсы, минусы и ограничения.

И то и то нормальный рабочий процесс.
1. Используя то, что умеем быстрее сделать ожидаемое и не тратить время на изучение чего-то другого.
2. Без изучения нового быстро сольешь конкурентам.

аналогичной вопрос, есть опыт, когда за счет заказчика попытались изучить что-то новое, а по итогу просто жестко нафейлили?

Это утверждение или вопрос?

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

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

а вот было когда-то такое, что вбахали время и деньги во что-то новое, а потом все пошло ****?

А про такое в инете море историй с конторами разной величины. Те же мелкомягкие отличный пример и успехов и фейлов такого плана.

Когда для проекта выбирается неподходящий инструмент

То он по необходимости меняется на подходящий.

Не интересный подход. Тут же требуется , что то радикальнее ...

О. Тогда выбор срам в сраме и на сраме.

Легко говорить. Поди смени бд, когда в ней гигов этак 50 данных на работающем приложении.

гигов этак 50 данных

Это почти ничто.

И в чем проблема?

Объясняю как делается. Пишется абстрактный слой для работы с данными. Делается имплементация его для работы с текущей базой. Затем пишется работа с новой базе по этим интерфейсам. Прогоняются тесты.
А да возможно нужно будет написать тулзовину (скрипт, можно и на васике), что данные из одной базу в другую переложит.
Но да, это сложно если у вас спагетти код, но для такого кода необходим рефакторинг, иначе все одно в ближайшие полгода всё работать перестанет.

Заменяется одно другим.

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

Зачем отключать? Поднимается новая база, к которой проект пока еще не обращается, скриптом по ночам перегоняем данные со старой на новую, по завершении в конфигах меняем строку подключения и деплоим. Если все сделать грамотно (а это таки займет время, да), клиент ничего даже не почувствует.

скриптом по ночам перегоняем данные со старой на новую

Тут проблема что старая база в процессе растет. Так что даунтайм хотя бы на пару минут необходим. И в скрипте нужно продумать как «докачать» последню порцию данных. В-общем всё в-принципе возможно, но лучше сразу выбрать удачно СУБД и больше не трогать

Тут проблема что старая база в процессе растет. Так что даунтайм хотя бы на пару минут необходим.

Можно создать триггер, который при добавлении данных в текущую базу будет копировать в новую. Однако, если СУБД разные, то можно, например, создавать промежуточный файл и записывать данный в него. Файл будет трекаться утилиткой и все изменения будут переноситься из старой базы в новую. Как вариант: не ипать себе голову триггерами, а создать сразу утилитку, которая будет отслеживать изменения в старой СУБД переносить их на новую, а заодно мониторить процент синхронизированности. Потом, на самых низовых нагрузках (например, в ночь с субботы на воскресенье), когда синхронизация достигнет 100%, переподключить софт со старой базы на новую.

но лучше сразу выбрать удачно СУБД

Так с этого и надо начинать. Обсеры всегда дорого обходятся.

Если бы приложение можно было отключить на ночь — проблемы бы не было.

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

Объясняю как делается. Пишется абстрактный слой для работы с данными. Делается имплементация его для работы с текущей базой.

Не, так не делается, если только изначально разработчики не озабочены переключением баз и не с ООП головного мозга. Любая СУБД имеет свои особенности, которые нужно учитывать для нормальной производительности и задействования ресурсов.

Пишется абстрактный слой для работы с данными.

Если его не было — то это считай переписать половину проекта, если не 2/3

Прогоняются тесты.

эм, какие тесты — если не было абстрактного слоя?
значит — их вначале написать нужно
а чтобы их написать, надо пролопатить функционал, алгоритмы, домен чтобы написать тестовые данные

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

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

ну и уже сказали до меня про

Любая СУБД имеет свои особенности

и

если только изначально разработчики не озабочены переключением баз

добавлю только, что когда и озабочены были на старте, тюнинг запросов что генерит ORM под особенности БД приводит к тому что — а шишь сменишь вот так бытенько
даже когда у тебя «абстрактный слой» и ORM аля Hibernate/Doctrine

Отвечу всем выше вам и сразу. Наверное вы правы, индусокод и хуяк-хуяк и в продакшен ваше всё.

индусокод и хуяк-хуяк и в продакшен ваше всё.

вам же не 20+ — чтобы прибегать к аргументу — я такой весь правильный, теорию знаю, а вы говнокодеры
;)

... недавно на тему проектирования бизнес ПО, «абстрактных слоев» доступов к БД и прочего похоливарил с одним многолетним преподом, айти курсов
ну чё, по его оценке я и до джуна не дотягиваю :D

оно так всегда, чем дальше от практики, тем больше рассуждений перфекциониских, до упоротости.

Так приходится писать так, чтобы вы понимать могли.

Выше я просто в 3-х строках изложил то, о чем в куче книжек много раза написано и рассказано. Но вот что удивляет — читать их погромисты не любят

Выше я просто в 3-х строках изложил то, о чем в куче книжек много раза написано и рассказано.

это да, неграмотны, не читали...

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

Но вот что удивляет — читать их погромисты не любят

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

это да, вы то все по книгам читанным делаете :)

Да. Предварительно проанализировав написанное и оценив применимость.

подисаться забыли
«Ваш кэп»

Хуяк-хуяк — это как раз лепить ОРМ в любой проект, потому что так учат и по-другому чел не умеет. Когда тебе нужен многоэтажный запрос к БД с аггрегациями, то ты берешь и ручками пишешь этот запрос с учетом тех возможностей, которые дает твоя СУБД (потому что готовые обертки поддерживают только ту часть SQL, которая реализована во всех популярных СУБД). И потом ты уже не переключишь базу, этот кусок кода не переписав. И неважно во сколько абстракций ты его обернул. А когда у тебя весь проект завязан на таких запросах, то поменять СУБД = переписать половину.

И «переложить данные» легко только в теории. Переложи их на живой базе, которую бизнес не хочет остановить на пару часов.

Когда тебе нужен многоэтажный запрос к БД с аггрегациями, то ты берешь и ручками пишешь этот запрос с учетом тех возможностей, которые дает твоя СУБД

Проблема в том, что в основном люди эти ОРМ-ы не умеют готовить. Но да, даже если этот многоэтажный запрос написан в ОРМ-е, при миграции все равно надо его переписывать. И тут уже приходится ответить на вопрос — что быстрее и выгоднее: переписать запрос ОРМ или сразу написать запрос в СУБД, а потом уже обращаться к результатам?

Ты говоришь так, будто это мы неправильно базу выбрали, лол. Обычно приходишь уже на готовое расхлёбывать.

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

Не возможно, а всегда. Иначе как ты себе представляешь миграцию данных? :)

Ну может тут байтики на дискетах носить собираются.

есть пример, что заменили на что?

Я и не вспомню такого, чтобы уж очень знаменательного. Это обычный процесс любой разработки: замена одних инструментов другими.
Главное, с точки зрения архитектора, проектировать архитектуру так чтобы замены производились с минимальными затратами.
Тех же БД, например, стадо. И соответственно желание ее заменить в какой-то момент возникнет однозначно. Следовательно архитектуру делать так, чтобы заменить было не сильно дорого.

Пм может помочь команде выполнять работу лучше двумя способами:
1) если раньше был программистом — писать код под командованием программиста из команды, иначе помогать тестировщикам тестировать
2) не мешать, при чем настолько чтобы про твое существование забыли

Любые другие способы помочь будут только отрицательно влиять

Вообще не так. Если разработчиков больше одного, и часть из них асоциальные интроверты, или «rock star», или же просто джуны, то проект очень быстро превращается в спагетти в погоне за юзер-фичами.
Грамотный ПМ:
— поможет тебе с эстимейтом
— поможет BA с переводом хотелок в ТЗ, ТЗ в юзер-стори, а последине — в тикеты с нормальным описанием
— поставит процессы, разделит обязанности, обеспечит вменяемую коммуникацию
— обеспечит комфортный для продуктивности уровень нагрузки
— позаботится о документации, и отчётности
— прикроет твою задницу, если облажался
— по дефолту в наших реалиях является нередко еще и скрам-мастером, и продукт овнером, и бизнес-аналитиком, т.е. приоритезирует задачи, и объём реализации, или помагает с этим.
Ты проклянёшь проект, если никто этим не будет заниматься, или будет делать это плохо.

Что же касается сабжа, то redis vs db — это архитектурное решение, в этом должен быть компетентен лид и/или архитектор (тех-лид), с ним и обсуждать на этапе планирования. А тулзовины и утилиты разработчиков для непосредственно разработки — чисто вкусовщина, кому что удобно.

Значит, мне пару раз очень повезло. Естественно, если ПМ прикрывает только свою задницу, работает прокладкой и испорченным телефоном, не знает бизнес-логику и риски проекта, и компетенции команды, не берёт на себя никаких ответственностей и обязанностей, не облегчая жизнь команде, а осложняя её, то да, зачем он такой нужен. И без ПМ лучше, чем с плохим ПМ. Но с хорошим ПМ сильно лучше, чем без оного.

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

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

А куда кастомер денется? К тому же ему не говорят что пм ничего полезного не делает. В аутстафе обычно пм со стороны заказчика и выступает в качестве представителя заказчика

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

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

Разве ПМ не должен сначала у тебя спросить, а не брать свой эстимейт с потолка? А в идеале держать ПМа в курсе архитектуры, рисуя схемы, может и не UML но некий mind map в общих чертах: data flow, сервисы, базы, кеши, слои приложения, бизнес-модели. Тогда и отчетность будет, и процесс прозрачнее, и объяснять работу проще, и результат предсказуемее.

Он-то должен, но...

Воспользуйся методом Иисуса: закажи в офис вместо воды 20л бутыль вина

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

І тести писати під бухлом. А кодити під травою. Можна навпаки.

Разрешение на всё подряд можно и не спрашивать...

времена не те: все равно водой разведут :((

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

Да как как, sql db это не модно, и нудно, а вот redis это круто, начитал хипстерщины и убедил кастомера и играешься с ней на проде, а через год другой ушел в другую компанию на +500 и забыл этот головняк :-)))

В одном проекте можно (и часто даже нужно) использовать и то, и другое. SQL — для постоянного хранения данных и сложных запросов, redis — для кеша

Редиска теж може зберігати дані. Я туди джобси закинув. Якраз нормуль. Не буде основну базу з важливими даними навантажувати.

Может, но это простое хранилище со всеми вытекающими ограничениями. Для джобсов есть rabbitmq кстати, правда он вначале не сильно понятный. Но когда настроишь — работает отлично

Так и не понял вопрос. «Когда» — это когда выбрали не подумав и что потом делать? Или «когда» — это когда целенаправлено выбирается с понимание тогдо что инструмент неподходящий? Или это вообще не вопрос был?

«Когда» — это когда выбрали не подумав и что потом делать?

Подписаться на комментарии