Вхід і реєстрація
×
Розробка · 23 серпня 2019, 21:26 2257
Peter Blacksmith

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем привет!

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

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Vadim Kopanev 24.08.2019 01:23

Пм может помочь команде выполнять работу лучше двумя способами:
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
Сергей Устенко Marketing manager в Idealsoft 22.10.2019 15:22

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

Відповісти
Підтримати
Blitz .net Developer 29.08.2019 14:10

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

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

Відповісти
Підтримати
Peter Blacksmith 19.09.2019 08:59

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

Відповісти
Підтримати
Blitz
anonymus ps 19.09.2019 09:38

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

Відповісти
Підтримати
Peter Blacksmith
Sеrgejs Bоrуsson Senior Tractorist 29.08.2019 13:49

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

Відповісти
Підтримати
Peter Blacksmith 19.09.2019 09:02

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

Відповісти
Підтримати
Sеrgejs Bоrуsson
Sеrgejs Bоrуsson Senior Tractorist 19.09.2019 11:05

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

Відповісти
Підтримати
Peter Blacksmith
Peter Blacksmith 25.11.2019 18:14

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

Відповісти
Підтримати
Sеrgejs Bоrуsson
Sеrgejs Bоrуsson Senior Tractorist 19.09.2019 11:13

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

Відповісти
Підтримати
Peter Blacksmith
Gennady Dogaev full-stack web developer (freelance) 29.08.2019 01:09
Каждый раз они будут тебе продавливать все самые топовые новинки с которыми они захотят поиграться, самые последние хайпанутые тулзы и технологии, а давайте заменим реляционку на носкл+граф базу+что-то оперативное для кеша

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

Відповісти
Підтримати
anonymous
Bot Bot 29.08.2019 11:58

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

Відповісти
Підтримати
Gennady Dogaev
Gennady Dogaev full-stack web developer (freelance) 29.08.2019 12:06

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

Відповісти
Підтримати
Bot Bot
Bot Bot 29.08.2019 13:30

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

Відповісти
Підтримати
Gennady Dogaev
Peter Blacksmith 19.09.2019 09:06

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

Відповісти
Підтримати
Bot Bot
Peter Blacksmith 19.09.2019 09:05

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

Відповісти
Підтримати
Bot Bot
anonymus ps 19.09.2019 10:37

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

Відповісти
Підтримати
anonymous
anonymus ps 19.09.2019 10:52

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

Відповісти
Підтримати
anonymous
Sergius von Bielersee Schweizergarde в Ziemer Ophthalmic Systems AG 27.08.2019 09:28

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

Відповісти
Підтримати
Peter Blacksmith 19.09.2019 09:08

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

Відповісти
Підтримати
anonymous
Peter Blacksmith 19.09.2019 09:07

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

Відповісти
Підтримати
Sergius von Bielersee
VO 25.08.2019 03:14

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

Відповісти
Підтримати
anonymous
Blitz .net Developer 29.08.2019 14:11

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

Відповісти
Підтримати
anonymous
Yegor Chumakov founder в startup 29.08.2019 14:16
гигов этак 50 данных

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

Відповісти
Підтримати
Blitz
Blitz .net Developer 31.08.2019 14:22

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

Відповісти
Підтримати
anonymous
Gennady Dogaev full-stack web developer (freelance) 01.09.2019 21:30
скриптом по ночам перегоняем данные со старой на новую

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

Відповісти
Підтримати
anonymous
Blitz .net Developer 07.09.2019 02:03

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

Відповісти
Підтримати
anonymous
Gennady Dogaev full-stack web developer (freelance) 31.08.2019 14:39
Объясняю как делается. Пишется абстрактный слой для работы с данными. Делается имплементация его для работы с текущей базой.

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

Відповісти
Підтримати
anonymous
Sergey Lysak T/T Lead 31.08.2019 14:49
Пишется абстрактный слой для работы с данными.

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

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

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

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

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

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

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

и

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

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

Відповісти
Підтримати
anonymous
Sergey Lysak T/T Lead 01.09.2019 15:24
индусокод и хуяк-хуяк и в продакшен ваше всё.

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

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

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

Відповісти
Підтримати
anonymous
Sergey Lysak T/T Lead 01.09.2019 15:50
Выше я просто в 3-х строках изложил то, о чем в куче книжек много раза написано и рассказано.

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

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

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

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

Відповісти
Підтримати
anonymous
Sergey Lysak T/T Lead 01.09.2019 16:43

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

Відповісти
Підтримати
anonymous
Gennady Dogaev full-stack web developer (freelance) 01.09.2019 15:49

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

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

Відповісти
Підтримати
anonymous
Blitz .net Developer 07.09.2019 02:05

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

Відповісти
Підтримати
anonymous
Peter Blacksmith 19.09.2019 09:09

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

Відповісти
Підтримати
anonymous
Vadim Kopanev Architect 24.08.2019 01:23

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

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

Відповісти
Підтримати
Yuriy Pitometsu Оглаголиватель существительных 24.08.2019 15:07

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

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

Відповісти
Підтримати
Vadim Kopanev
Yuriy Pitometsu Оглаголиватель существительных 24.08.2019 19:39

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

Відповісти
Підтримати
Vadim Kopanev
Vadim Kopanev Architect 24.08.2019 20:02

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

Відповісти
Підтримати
Yuriy Pitometsu
Yuriy Pitometsu Оглаголиватель существительных 24.08.2019 20:10

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

Відповісти
Підтримати
Vadim Kopanev
Vadim Kopanev Architect 24.08.2019 20:14

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

Відповісти
Підтримати
Yuriy Pitometsu
Yuriy Pitometsu Оглаголиватель существительных 24.08.2019 20:21

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

Відповісти
Підтримати
Vadim Kopanev
Pavel Yakimovich PHP Developer в G5 25.08.2019 02:18

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

Відповісти
Підтримати
Yuriy Pitometsu
Yuriy Pitometsu Оглаголиватель существительных 25.08.2019 02:41

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

Відповісти
Підтримати
Pavel Yakimovich
Gennady Dogaev full-stack web developer (freelance) 25.08.2019 02:54

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

Відповісти
Підтримати
Yuriy Pitometsu
Олексій Пєніє 23.08.2019 23:37

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

Відповісти
Підтримати
Vadim Kopanev Architect 24.08.2019 13:58

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

Відповісти
Підтримати
anonymous
Євген Лесько Competency manager в ELEKS 25.08.2019 00:50

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

Відповісти
Підтримати
Олексій Пєніє
anonymus ps 23.08.2019 23:32

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

Відповісти
Підтримати
Bot Bot 23.08.2019 23:24

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

Відповісти
Підтримати
Gennady Dogaev full-stack web developer (freelance) 24.08.2019 13:52

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

Відповісти
Підтримати
Bot Bot
Gennady Dogaev full-stack web developer (freelance) 24.08.2019 14:05

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

Відповісти
Підтримати
anonymous
Aleksey Bober I am not looking for a new position в the moment 23.08.2019 22:40

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

Відповісти
Підтримати
Peter Blacksmith 25.11.2019 18:10
«Когда» — это когда выбрали не подумав и что потом делать?
Відповісти
Підтримати
Aleksey Bober

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.