Ща дичь скажу, держитесь. А у кого-нибудь в команде практикуется "заказ"

сниппетов? Это когда участник команды говорит "мне нужна функция/класс/однострочник" , делающая что-то простое, Сниппет изолирован от логики приклада, он самодостаточен. На разработку сниппета отводится ограниченное количество времени. Предоставляется заказчику на страх и риск заказчика, ответственность за тестирование и отладку в рамках всего программного комплекса лежит на заказчике, либо в крайнем случае в запросе на разработку сниппета содержится просьба предоставить тесты.
Цели: разгрузить одних, занять других, сделать возможной разработку с прямой доставкой, без оверхеда пайплайнов CI/CD. То есть это просто способ делегирования, а не методология разработки как таковая

Это внутри разработчиков одной фирмы, или и для внешних заказчиков такое? Если внутри команды, то как раз фичи ЯВУ типа разделения интерфейса и реализации модулей/классов как раз разрабатывались/продвигались для того, что бы, условно, каждую функцию/процедуру большого продукта мог разрабатывать отдельный программист независимо. Особенно удобно такое делать в функциональных языках. И изредка приходится к такому прибегать, особенно когда приходится разрабатывать в исследовательском стиле (без достаточно проработаного кем-то ранее ТЗ)...

Звучит как дичь. Я вижу тут как минимум несколько проблем: 1) Это менеджмент всего этого и ответственность за ту часть которую ты делаешь. То есть тот кто делегирует должен уметь это делать. Это навыки декомпозиции задачи с учетом способностей людей, а не простая декомпозиция. Как результат любой программист, который имеет право заказывать эти сниппеты должен быть уровня сениора, а то и лида (то есть уметь ставить задачи и добиваться их выполнения). 2) Это обвязка этих сниппетов. Если хоть кто-то говорит о реиспользовании этого кода и вообще об эффективности, то возникает ествественное желание переиспользовать сниппеты и, как результат обвязка сниппета (подготовка данных для него и т.д.) вполне возможно будет стоить дороже чем сам сниппет, но так как сниппет является черным ящиком, причем за который несешь ответственность не ты, то у того кто заказывает или использует чужой сниппет с подходом черного ящика становится свободы еще меньше. Как результат это все может привести к тому, что те кому заказываю сниппеты будут "в шоколаде", а те кто их используют, мало того что должны быть выше классом чем исполнители, так еще и всегда виноваты. Это разделение может привести к проблемам в команде. 3) История с ответственностью на заказчике еще больше усугубляет ситуацию. Фактически в вашей парадигме умым быть не выгодно. Это или должно парироваться деньгами или может развалиться... Я-бы сказал что такой подход может работать в каких-то рамках но должен приводить к деградации команды и, как следствие, продукта.

Рассыпуха наше все, одобряю

Не практикуется, но сама идея нормальная, если есть чёткие критерии, что время на исполнение должно быть очень коротким

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

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

> а те кто их используют, мало того что должны быть выше классом чем исполнители, так еще и всегда виноваты. Это разделение может привести к проблемам в команде. 3) История с ответственностью на заказчике еще больше усугубляет ситуацию. Фактически в вашей парадигме умым быть не выгодно. каким макаром одно следует из другого? с чего умным быть невыгодно? тем более если команды разные.

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

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

Ага, только любое искусство это тоже про бабло. И без бабла сильно много не натворишь.

Бабло у нас из скважин течёт, в Германии - Сименсом зарабатывается. @Casus_Improvisus , Сименс же старается? Я не очень верю в то, что усилиями кода так сказать количество ликвидных материальных благ в нашей стране увеличится, поскольку это количество (благ) определяется количеством добытых нефти и газа, ну и конечно их стоимостью. Но к сниппетам всё это не имеет отношения ИМХО

Э-э-э... Я тогда вас не понимаю... С одной стороны хорошо что люди достаточно взрослые чтобы понимать что они не тянут, с другой... А почему они себя программистами называют?... Ну просто если это что-то маленькое, то больше связанно с базовой алгоритмикой. Если не умеешь в алгоритмы... Ну-у-у... Тогда иди в яндекс сходи на собес (нет, не иди туда работать). Если это что-то связанное с какой-то нишей, то вряд-ли это будет маленьким.

За одно собеседование научат алгоритмам? Ух ты

Зае... алгоритмами...

А у вас там не хуже требования к соискателям. )))

У нас каждый вопрос - это то с чем вы реально столкнетесь

А вы не думаете в сторону перехода с перла на новые языки?

Переодически...

И как? Выходит?)

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

Периодически только