Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
Подход мне нравится. В статье есть за что "зацепиться", надо будет еще перечитать. И таки да, писали Вы сами, это видно.
Вопрос на засыпку: а с какой стати понятие "сложности" стало вдруг объективным?
Простой пример: есть такая штука, называется функция Ламберта, обозначается буквой W. Определяется как решение уравнения z=W(z)×exp(W(z)). Насколько сложной является эта функция для программы? Если у Вас есть библиотека с такой функцией - это один вызов и всё. А если надо написать ее ручками? А если критична скорость счета (надо ее вычислить сто миллионов раз) - сложность будет та же самая или нет? А если важна точность до 15-го знака? А если баланс? И где здесь, простите, объективность?
Пример чуток в сторону. Представьте, что вы программируете, например, рисоварку. Для вас как для программиста здесь важны параметры, типа температура, время, масса, ток, естественно, всякие погрешности, и т.д. Но за всем этим стоит довольно сложная химия, о которой вы можете вообще не иметь никакого представления - ровно до тех пор, пока она вас не ударит по носу, в буквальном смысле - запашок появится... Чтобы это устранить, хорошо бы понимать кое-что за пределами программирования. Но может получиться и так, что вы с самого начала угадаете ключевые параметры, и проблема не возникнет - ввиду, опять же, правильной исходной догадки. И... насколько "сложной" является такая задача? разве это объективная категория?
На мой субъективный взгляд, "сложность" - столь же субъективная категория, как и "трудность". То, что сложно для одного (или в одной ситуации), просто для другого (или в другой ситуации). Различие в другом: сложность "лечится" новым знанием, а трудность - новым опытом. Вещи это малость разные: знания можно передать, а опыт - нет, его можно только приобрести самому, собственным трудом (отсюда и слово взялось: ТРУДность), наступив на те самые грабли.
Согласны? Если нет - какие возражения? Заранее спасибо.
Спасибо за фидбек.
Я использую определения, которые дал Рич Хикки — можно 10 минут отсюда глянуть. Всё, что зависит от субьективного восприятия — это про трудность. Например...
И... насколько "сложной" является такая задача?
если этот вопрос имеет отношение к кому-то, для кого задача “сложная”, то это про трудность. А если мы набираем список задач и пытаемся определить их сложность, нам нужно выделить критерии этой сложности. Это не всегда возможно сделать.
Если бы это были кодинговые задачи для алгоритмического интервью, то задача, где нужно знать 1 структуру данных, вроде хеш-мапы, и добавить 2 ветвления, — могла бы быть простой. А задача, где 30 ветвлений и нужно знать менее известный Краскал-алгоритм — средней по сложности. Если я этот алгоритм помню и решал подобную задачу, то для меня она легкая, а не трудная, но сама задача в нашей классификация остается средней.
сложность "лечится" новым знанием, а трудность - новым опытом.
По тем определениям, что я использовал, трудность лечится и новым знанием, и новым опытом. А то что сложно, остается сложным. Например, класс, имеющий 50 переменных в стейте и кучу функций, которые этот стейт меняют, и 10 иерархий наследования этого класса. Знания мне не помогут, потому что комбинаторный взрыв всё равно не уместится у меня в голове. Но знания и опыт сделают для меня работу с этим менее трудной.
А то что сложно, остается сложным. Например, класс, имеющий 50 переменных в стейте и кучу функций, которые этот стейт меняют, и 10 иерархий наследования этого класса.
А если этот класс запрятан во внешнюю библиотеку, из которой вызываются только функции? Класс - есть, а сложности - нет...
Аналогично, когда вы высыпаете в стиральную машину порошок,вы не задумываетесь о том, что его работа строится на сложнейших "нанотехнологических" процессах, которые, кстати говоря, до сих пор трудно моделировать ввиду, опять же, того, что современная наука не до конца изучила эти процессы. Система - реально сложнейшая. Но для вас она очень простая - ровно до тех пор, пока, например, в силу не той жесткости воды порошок перестанет делать то, что он делал.
Я бы уточнил: сложность СТАНОВИТСЯ объективной категорией ПОСЛЕ ТОГО, КАК опркделены все условия задачи, которые не всегда известны заранее. И вот это "после того как" - хорошо бы иметь в виду, оценивая "сложность" той или иной задачи.
А если этот класс запрятан во внешнюю библиотеку, из которой вызываются только функции? Класс - есть, а сложности - нет...
Тогда оно сложное, но для пользователя библиотеки это легко, потому что всю трудную работу забирает библиотека.
Тут видите, всё зависит от определений. Если сложность определить как объективное понятие — сколько раз ткань сложена (из этимологии слова), — то она будет объективной. А всё что меняет свойство — это про легкое и трудное.
Я бы уточнил: сложность СТАНОВИТСЯ объективной категорией ПОСЛЕ ТОГО, КАК опркделены все условия задачи
И вот тут если продолжать пользоваться определениями, как у Рича Хикки, то трудное становится объективной категорией для конкретного субъекта после того, как определеные условия.
Или вот еще пример — асимптотическая сложность алгоритма. Сколько вы ни занимались изучением алгоритмов и какие бы легкие они для вас ни были, и трудные для кого-то еще — сама сложность обхода массива остается O(n), а сортировки merge sort — NlogN.
Пошел читать другие статьи, заинтересовал раздел "Переход на микросервисы без нужды" в "Заговор разработчиков против корпораций: архитектура". Сейчас как раз размышляю и экспериментирую с модулями в монолите. И модули тоже оказываются проблемными.
Если каждый модуль имеет свою логическую подсистему обращения к БД и управлениями транзакциями, то вызов из одного модуля внутри транзакции другого модуля, который открывает свою транзакцию - становится проблемой. Физическая БД одна на все (монолит же), вложенные транзакции не поддерживает (еще и БД менять - слишком сложно и долго). И в итоге "SAGA, TCC, XA, Workflow, Outbox pattern, и т.д. и т.п." Как будто я микросервисы пишу, хотя не планировал.
Появились мысли сделать один контекст БД на все модули - но тогда модули перестают быть действительно модулями... Через общую базу можно залезть куда угодно...
R&D-команду SCRUM будет тормозить бесполезными церемониями и ограничениями. Если вы занимаетесь ресёрчем задачи, которую еще никто не делал, то последнее, что вам нужно — это стендапы, ретро, планирование и ограниченные по времени спринты.
Хы, что интересно - любая компания с продуктом - это по сути R&D, потому что они НЕ знают что делают и что реально будет приносить прибыль.
Но где бы я ни работал за последние 10 лет, всегда были проблемы со сроками и часто приходилось перерабатывать. Команды играли в оценки задач в story point (SP), где никто не знает, что такое SP, но все как бы приспосабливаются оценивать в SP (либо просто говорят, что 1SP — это час)
Да, да, вся проблема как раз в том, что время спринта - календарное, а оценка задачи - относительная. Если бы спринт заканчивался не по календарю, а тогда, когда все sp были выполнены - тогда всегда бы было 100% выполнения.
Скажу больше: если ваши задачи не "комсомольского" типа (в смысле, "мы все как один"), то ни вы, ни ваш заказчик не знают и не могут знать заранее, что конкретно там "нужно".
Но что реально нужно и помогает - это быстро созданный прототип. Не для того, чтобы оставить его как есть, а чтобы "пощупать" в реальной работе и, если понадобится (а надобится с вероятностью, близкой к 100 процентам), внести изменения в спецификацию и сделать нечто работающее. То самое R&D.
В работе с ИИ это, мне так каацца (по Райкину), тоже кое-что меняет...
Кстати, с ИИ появилась проблема с другой стороны — менеджеры вайбкодят и возмущаются, что до прода их фичи так долго идут.
У меня была другая ситуация, еще до вайбов. Фичи делались "менеджерами", которые не совсем понимали, как должна работать программа. Но - они не понимали, что они этого не понимают...
Результат - множество всяких фич, и почти ноль полезности. То самое R&D проводить никто и не думал. В итоге - 10 лет, потерянных в непрестанных поисках "волшебного ключика". Несколько тимлидов сменилось - бестолку. Пока, наконец, не пришел тот, кто имел реальный опыт работы в этой области, молодой парень, сказавший золотые слова: фичи сами не работают, с ними работают люди, вот у них-то и надо учиться, а не "спрашивать" их. И - чудесным образом новые фичи стали вдруг давать реальную пользу...
Роль первого лица - в эпоху ИИ, думаю,станет только еще важнее.
Да, для справки: парень пришел в 24-м году. Вайб тогда уже появлялся, но ИИ еще не умел толком программировать.
А что за сфера? Наука?
Она самая. Наука о материалах. Сейчас, кстати, модно расхваливать ИИ в части разработки новых материалов с всякими удивительными свойствами. Правда, 99 процентов таких публикаций - о сферических конях в вакууме. А реальные информационные системы по материалам - поле все еще непаханое. Систем - очень много, а вот реально помогающих в работе - не так много, как хотелось бы...
Опять же, сложность - которая происходит от недостатка прежде всего знания, а не опыта.
Оцениваешь в 8 и получаешь требование разбить задачу, потому что 8 — это слишком много.
Даже если задача действительно занимает 8 SP, придется делить на 3 и 5. То есть создавать ненужную работу
Госпадя, прям боль... после того как я разбил задачу на 3 и 5 и все равно не успел - меня спрашивают - "а почему нельзя задеплоить одну их них??" - покачену!!!11
Ретро может быть полезно, но только в одном случае — чтобы на нем решить, что надо отказаться от скрама.
🤣🤣🤣
Хы, что интересно - любая компания с продуктом - это по сути R&D, потому что они НЕ знают что делают и что реально будет приносить прибыль.
Сейчас в еще большей степени, все пытаются внедрять ИИ таким образом, каким до этого не делали, и это реально R&D. Я сейчас пытаюсь повлиять на управление разработкой у соседних команд — очень тяжело идет, SCRUM Cargo Cult прибит гвоздями.
Мне кажется, можно не разделять границы модулей и транзакций. Например, использовать один connection (пусть приходит на вход функциям), но модели у модулей будут разные. Детали зависят от того, какой у вас стек. При выделении модуля в микросервис боль все равно будет, но меньшая, чем если бы это был просто монолит без модулей.
На мой взгляд, чтобы избежать катастрофы, минимально нужно:
иметь опытных людей в команде, заинтересованных в проекте долгосрочно;
На мой тоже. И это именно то, что я пытался долгое время вбить в голову руковолителям одного проекта...
На что мне возражали: главное - чтобы проект мог поддерживаться независимо от конкретных разработчиков. То бишь, важна поддерживаемость при смене участников, а не долгая работа одних и тех же участников.
Итог плачевен: без тех, кто реально заинтересован САМ работать вдолгую, проект превращается в "работу", которую нужно спихнуть пораньше с минимальными усилиями. И в первую очередь это сказывается как раз на поддержке - ибо, даже если сам код написан и неплохо, он просто не делает того, что нужно. И следующим разработчикам приходится просто переписывать его с нуля, чтобы он таки делал то, что надо. А это, в том числе, касается и базовой архитектуры, которую решили сделать попроще...
Экономия на работниках всегда выходит боком, а если спецификации не вполне ясны заранее - тем более...
И вот тут-то мы приходим к еще одному моменту:
Естественный язык — не язык программирования: он неоднозначный и двусмысленный.
Я согласен с первыми двумяи последними тремя словами. Не совсем согласен с тем, что язык программирования сам по себе дает иное качество. Не дает! Однозначным он становится только тогда, когда точно реализует исходную, точно сформулированную модель "поведения" программы. А эта модель не всегда допускает такую формулировку и не всегда заранее известна.
Если исходная модель "дребезжит" (в силу, опять же, недостаточного знания о предмете) - то, каким бы однозначным и "правильным" ни был код, он все равно будет работать не совсем так, как нужно. А как нужно - икс зет...
И чем это, по существу, отличается от неоднозначности естественного языка?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поэзия агентной разработки или как теперь писать код