Монолитный Perl и виртуальные машины по 700 Гб оперативной памяти

Теории не бред, их надо знать и уметь применять.

вот кто-то в реальности видел работающую БД с 5NF или хотя бы 4NF? я не видел, и точно знаю что таких не встречается в дикой природе, c 3NF история несколько загадочная, потому что у кого-то работает, у кого-то уже не работает (ну тут всегда есть возможность на косорукость разработчика списать, хотя дело отнюдь не в этом), а вот первая и вторая формы - это никакая не реляционная теория уже, а просто некая сложившаяся практика: вы же наверняка ходите в туалет по нужде не имея при этом медицинского образования?

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

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

Пока оверрайдов было мало, всё работало хорошо. Как только оверрайдов стало больше, MySQL стала захлебываться, ибо в ней нет нормальных типов для ip адресов и ip сетей, быстрый поиск возможен только через очень ограниченные хаки.

Что за хаки? Хранишь IP-адрес, как 32-битное число. Хранишь сетевую маску, как два 32-битных числа (начало и конец). С индексом поиск будет O(1). Или для тебя это хак? С IPv6 чуть посложней будет, придётся хранить, как два 64-битных числа, но в целом всё тоже тривиально. Из-за такой мелочи переходить на другую базу глупо (хотя я постгрес тоже люблю).

скажи мне, друг, а зачем ты позволяешь хоть 1 проклятью к тебе прилететь, тем более всем последующим? ты куколд?

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

Во-первых, были IPv6 адреса. Во-вторых, ну не работало оно. Поверь, я испробовал все варианты хранения данных, индексов и запросов. Слишком медленно начинает работать, когда адресов становится больше 10,000.

Я сейчас уже не стану раскапывать эту историю, и пытаться показать, почему не работает. Времени нет вообще.

Из-за такой мелочи переходить на другую базу глупо (хотя я постгрес тоже люблю).

Перехода, конечно же, не было. Это была бы огромная задача сама по себе. Был добавлен ещё один драйвер БД, и ещё одно соединение к БД, которые использовались в паре мест кода.

Я это воспринимаю как своеобразный крик о помощи. Человек наступил в какашку. Рядом нет даже лужи, чтобы отмыться.

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

Но в этой ситуации подход «а давай-ка возьмём пилу, распилим отложения мамонта на кусочки» выглядит вообще глупо. По крайней мере без дополнительной информации, а ТС ещё и хочет, чтобы мы помогли убедить владельца.

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

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

Ну, то есть, не видя кода, вы способны точно определить, что ТС неправ, и архитектура - зашибись, а он тупой неуч?

Но в этой ситуации подход «а давай-ка возьмём пилу, распилим отложения мамонта на кусочки» выглядит вообще глупо. По крайней мере без дополнительной информации, а ТС ещё и хочет, чтобы мы помогли убедить владельца.

Да всё здесь гадание на кофейной гуще. Информации почти нет.

Про распиливание - просто очевидно, что декомпозируя большую кучу говна на маленькие, её проще убрать.

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

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

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

Изначально у них приложение работало частично в докере, частично на хосте. Около десятка сервисов, вручную скрафченные docker-compose-ы, вручную выпускаемся letsencrypt сертификаты раз в месяц, ибо на автоматизацию всей этой лапши уже скилла не хватило. Бэкапы были в теории, на практике они уже полтора года не делались и никто даже не догадывался. Система падала несколько раз в месяц, постоянно вручную «поднималась». Сервер не обновляли 7 лет (какая-то древняя убунта была, то ли 12, то ли 14, не помню). В системе было несколько десятков юзеров (каждому разработчику заводили юзера). Обновления собирались вручную. В общем всё работало на честном слове. Сломавшийся жёсткий диск означал бы банкротство компании.

Я сначала всё перенёс в контейнеры, полностью настроил CI/CD пайплайн. И параллельно начал изучать Kubernetes. Через два года мигрировал всю систему в Kubernetes, попутно переписав несколько сервисов.

По итогу за последние годы все даунтаймы были только по вине хостера. Хостера в итоге поменяли, за последние полгода даунтаймов не было. Я сплю спокойно, база ежедневно бэкапится, бэкап это на самом деле ещё слабое место, ещё буду над этим работать, чтобы была возможность восстановления на любой момент, а не только на последний день. При переносе системы на другой хостинг проблем вообще не было, я просто создал kubernetes кластер, настроил туда flux и подождал полчаса, пока он всё поднимет (ну упрощаю, конечно, но не особо).

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

Конечно это всё работа не только административная, всё это время и приложения постоянно дорабатывались, я всё же в первую очередь программист.

Во-вторых, ну не работало оно. Поверь, я испробовал все варианты хранения данных, индексов и запросов. Слишком медленно начинает работать, когда адресов становится больше 10,000.

Не поверю. Оно не может медленно работать. Индекс по целому числу это самое простое, что может быть. И оно будет работать моментально хоть с 10 тыс., хоть с 10 триллионами. Логарифм, однако.

В целом я доволен результатами своего девопсинга.

ТС вас нужно к себе перетянуть …

Авгеевы конюшни не всякий осилит …

У ТС проблема в руководстве. Не думаю, что я там что-то смогу поменять, я языком болтать не мастер. Мне руководство изначально доверяло и поддерживало изменения, т.к. все понимали, что всё плохо.

Мне руководство изначально доверяло и поддерживало изменения, т.к. все понимали, что всё плохо.

Вы молодец!
Блог на ЛОР не помешал бы …

Ну, то есть, не видя кода, вы способны точно определить, что ТС неправ, и архитектура - зашибись, а он тупой неуч?

конкретно в этом случае - да: я свою позицию довольно четко обозначил здесь

а для поклонников докера и иже с ним предлагаю задаться следующим вопросом: если случилось так, что вас начали пенетрировать в задний проход, насколько для вас важно делают ли это с презервативом и смазкой, или нет? Вот для операционной системы и СУБД совершенно не важно, через докер их насилуют или нет.

Не поверю. Оно не может медленно работать. Индекс по целому числу это самое простое, что может быть. И оно будет работать моментально хоть с 10 тыс., хоть с 10 триллионами. Логарифм, однако.

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

При чём тут рандомные значения от 1 до 5? Мы обсуждаем IP-адреса. Там значения от 0 до 2^32 или от 0 до 2^128.

Проблем с «уговорить mysql использовать индекс» нет, force index для этого и сделан. Если значения распределены равномерно от 1 до 5, то выигрыша в производительности такой индекс не даст, но это уже другая ситуация.

Мы обсуждаем IP-адреса. Там значения от 0 до 2^32 или от 0 до 2^128

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

Нет, не всё так просто. У нас override вида:

ip_addr/net | country | comment
-------------------------------

Если нам надо найти просто вхождение в таблицу - то это просто и это да, логарифм. Но оно нам ничего не даёт.

Если нам надо найти конкретное вхождение в конкретную строку для получения country/comment - то тут уже так просто не получится, потому что все адреса и сети всех стран в одной таблице.

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

Самое удивительное, что PostgreSQL ищет соответствия молниеносно, в отличие от MySQL. В clickhouse есть например специальная trie подобная структура данных для таких случаев, я бенчмаркал postgres с cidr и clickhouse, ожидая, что clickhouse окажется быстрее. Так вот postgres уделал clickhouse одной левой.

Разговаривать с любым человеком нужно на его языке. Если это человек бизнеса, то ты ничего не докажешь и не объянишь используя слова докер, легаси и тех долг. Это все пустое. Хочешь объяснить бизнесу показывай расчеты в деньгах.

Забавляют меня такие советы. Откуда простому программисту уметь это делать? Это же всё филькина грамота будет. Откуда ты знаешь, что переписывание системы будет стоить столько-то? Это вообще никто не знает. Как ты посчитаешь шанс того, что переписывание вылетит в трубу? Сплошь и рядом такое - начали переписывать, не смогли, уволились, старая система продолжает работать. Попытки такое делать это в чистом виде попытки в инфоцыганщину, которые смотрятся убого, если человек в инфоцыганщину не умеет. Причём эти попытки легко будут опровергнуты тем, кто с этой системой уже давно работает.

Завидую. Потому что нередко подобные предложения наталкиваются на стену непонимания. «Некогда думать, давай работать», «тебе сложно сделать 5 ручных действий перед раскаткой? Не надо автоматизировать, ты просто ленивый», «деды не пользовались докером, и мы не будем», «если сможешь за 2 часа переделать весь код во всей компании, то делай. А иначе у нас времени нет, занимайся другими задачами» и т.д. и т.п.

Если компания изначально не-IT, то там это почти всегда.

Авгеевы

Авгиевы. Персонажа звали «Авгий»

Забавляют меня такие советы. Откуда простому программисту уметь это делать?

Это зависит от квалификации программиста. Зачем программисту уметь компилировать программу есть же devops, зачем писать тесты есть же QA отдел. Если человек метит в «манагеры/директор it отдела» он должен уметь общаться с людьми, которые ему ставят задачи.

Это же всё филькина грамота будет. Откуда ты знаешь, что переписывание системы будет стоить столько-то?

Это называется делать оценки исходя из своего опыта. К тебе приходят и спрашивают сколько будет стоить реализовать фичу А, ты говоришь ХХ часов. Откуда ты взял эту филькину грамоту? Из своего опыта. Сделаешь ли ты ТОЧНО за ХХ часов, врятли. Зависит от множества факторов. Предсказать сложно, но это базовая опорная точка от которой стоит отталкиваться.

про 16 тыщ либо ТС откровенно привирает и там их на порядок-два меньше, либо в консерватории что-то совсем не так.

да запросто. на крупных серверах в ДЦ я видела даже 256 тысяч процессов. и это было довольно давно. тогда и железо было слабее, чем сейчас. правда, я подозреваю, что это не от хорошего планирования архитектуры софта, но не вникала, нафига им столько. это были серверы Сбера, на которых крутились какие-то внутренние задачи. трогать такие монстрозные софтины я бы не решилась. я предпочитаю использовать машины состояний и пул обработчиков, по количеству ядер, а не дикое размножение процессов, если есть много контекстов. но тупо проще плодить процессы - вот и плодят, если железо позволяет. там была жаба, кстати говоря.

есть ещё ЯП, которые плодят потоки на каждый пук, типа Эрланга. там чуть ли не каждая операция - отдельный поток. в итоге, когда такой софт работает (его используют в телекоме, например), - это выглядит просто устрашающе с точки зрения админов и девопсов. я не думаю, что такая конкуренция потоков - это что-то нормальное для производительности железа. но такова селяви.

Авгиевы. Персонажа звали «Авгий»

Спасибо!

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

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

Так я же написал. Маска (если не брать теорию, а общеупотребительные вроде a.b.c.d/e) это просто промежуток адресов. Для 192.168.0.0/16 это от 192.168.0.0 до 192.168.255.255, например. Или, в десятичной форме, от 3232235520 до 3232301055. В любую сторону это делается по индексу настолько быстро, насколько возможно. И смена базы тут ничего не даст. Такие примитивные запросы хоть postgres, хоть mysql, хоть sqlite выполняют одинаково быстро, везде одни и те же B-деревья.

… там просто неприличные накрутки, зачастую.

Поясню тем кто не в курсе - откаты.

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

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

Это называется делать оценки исходя из своего опыта. К тебе приходят и спрашивают сколько будет стоить реализовать фичу А, ты говоришь ХХ часов. Откуда ты взял эту филькину грамоту? Из своего опыта. Сделаешь ли ты ТОЧНО за ХХ часов, врятли. Зависит от множества факторов. Предсказать сложно, но это базовая опорная точка от которой стоит отталкиваться.

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

Реально что можно делать в таком случае - просто сидеть и делать новую систему рядом со старой, постепенно заменяя её куски. Начинать внедрять её на максимально раннем этапе. В идеале вообще на уровне роутинга запросов - переписали эндпоинт, направили туда 1% запросов. Если всё хорошо, постепенно доводим до 100%. И так работать год за годом, параллельно поддерживая старую систему, и постепенно заменяя её новой системой. Это очень сложно, очень замедляет развитие всей системы, но по крайней мере это путь, который приведёт к результату, причём результат этот можно объективно измерить хоть в каких-то попугаях (перенесено 156 из 942 эндпоинтов). Но когда - неизвестно. Через год скорость разработки и перспективы может быть станут понятными.

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

Бывает так, что для выполняют работу несколько человек и …

Да, я уже вообще не берусь оценивать. Как-то меня попросили прикинуть аппаратные ресурсы, для переписывания старой системы. У них был древний HP Superdome (итаниум, прикольная штука). Я с этой системой работал, знал, что мой ноутбук работает быстрей этого супердома, сказал им, что одного сервера современного хватит с головой, короче 5 000 долларов максимум. Для дублирования 10 (у них дублирования не было, но когда хотят переписывать системы, сразу аппетиты растут). В итоге они решили, что у меня какие-то несерьёзные цифры и им впарили какие-то дикие системы за 200к. Может откатили, я хз. Но реально вся их система прекрасно работала на современном ноутбуке и я не преувеличиваю, я её поддерживал и запускал у себя с дампом прод базы.

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

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

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

что переписывать надо всё сразу, по частям не получится. и дело не только во внутренней архитектуре софта, а ещё и в совместимости разных реализаций на уровне системы.

Мой начльник раз пять рассказывал как он переписал код без наличия исходников.
Разработчик их утерял.
Так он реверсил, разоборался и сделал код раз в три меньшего размера.
Для M6000 у которой раздел был всего лишь 32KB это было весьма существенно.
Говорит, что показал код разработчику и он был весьма удивлён.

Вот поэтому мне импонирует подход к архитектуре без монолита. Система становится сложней, но каждый отдельный компонент можно окинуть взглядом. И переписать, если надо. С точки зрения деплоймента это просто образ, который работает с какими-то базами, отдаёт какой-то HTTP API, т.е. это кирпичик, а не завод. Понятно, что системы, разбитой на сервисы, куча проблем, такую систему писать сложней, но все их примерно понятно, как решать.

я думала, что итаниумы неудачно пролетели между 32-битными и 64-битными системами и не вписались ни туда, ни сюда. очень редко их можно увидеть в рабочих конфигурациях. я их живьём не встречала. хотя было бы занятно посмотреть на такое.

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

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

Я не утверждал, что это можно сделать просто и быстро. Да это процесс может быть сложный, а иногда даже долгий.

Реально что можно делать в таком случае - просто сидеть и делать новую систему рядом со старой, постепенно заменяя её куски.

Да, вполне хорошие решение(одно из). Еще могу заметить, что если мы «переписываем» очень старую систему, то часто бывает что от 1 до 80% старой системы оказывается не нужна(требования менялись за 15 лет), а выбрасывать что то либо никто не хочет либо не может, так как зависимости. Так что в реальности, нужно переписывать сильно меньше. И да, делаем MVP, дальше лепим нужную функциональность.

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

Ты никогда не работала на фрилансе, видимо. В разработке всё время встречаются непредвиденные ситуации. Думал, что разработка фичи займёт день, а она заняла две недели.

Заказчик фрилансеру заплатил за один день (он ведь на один день оценил), 13 дней работаешь бесплатно.

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

Например для линукса, если привести отвлечённый пример, это было бы микроядро и куча модулей-драйверов. Каждый драйвер можно было бы переписать. Да и микроядро можно переписать. Значение имеют лишь интерфейсы между ними. Можно написать слой совместимости. Но - в линуксе так не принято, поэтому и возникают странные драмы вроде недавней драмы с bcachefs, которую не берут в апстрим. Линукс уже не переписать никак. И линуксовые драйверы в BSD вряд ли засунешь, можно взять какой-то слепок кода и попытаться врапперы написать, но через год этот слепок кода устареет, а обновлять его будет непрактично, не угонишься. Потому, что изначально у линукса внутренняя архитектура монолитная. Хотя ZFS пытаются, конечно, но всё же они идут против течения.

А вот заменить в каком-нибудь Debian ядро на другое - можно. Потому, что стабильный интерфейс это системные вызовы. Вон даже в винде захотели и реализовали слой совместимости и теперь могут запускать кучу линуксовых бинарников с виндовым ядром (WSL1).

Типа create table ip_override(net_start int, net_end int, country text). И запросы вида select country from ip_override where :ip >= net_start and :ip <= net_end

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

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

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

если мы «переписываем» очень старую систему, то часто бывает что от 1 до 80% старой системы оказывается не нужна(требования менялись за 15 лет), а выбрасывать что то либо никто не хочет либо не может, так как зависимости. Так что в реальности, нужно переписывать сильно меньше.

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

Обычно, в таких древних системах, ответа на этот вопрос нет нигде.

Да, именно так, поэтому я и удивился, что тут пришлось аж целую новую БД добавлять, ибо в такой формулировке это решается несложно.

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

А вдруг какая-то функциональность используется раз в месяц? А вдруг раз в полгода?

Согласен, точного ответа никто ни даст. Узнаешь со временем. Но в этом и соль. Ты делаешь MVP которое решает основную задачу(MVP - меньше всей старой системы), и если нужно наращиваешь функциональность сколько нужно.

Тут даже можно все не реализовывать. Пусть MVP делает 90-95% всей работы, остальное делает старая система.

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

Надеюсь, что всё же были и другие соображения. )

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

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

чем больше у тебя опыта, тем точнее ты можешь оценить объём работ. но иногда и с опытом можно ошибиться в оценке. в моём случае фриланс маловероятен, потому что софт на Си для серверов - ни разу не фрилансерская штука. но когда работаешь лет 20+ и видел всё, можно прикинуть не только написание фичи, но и разработку целого проекта с нуля.

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

да вот нет.

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

допустим что у нас есть поле да/нет, в реальных системах какое-то одно из значений всегда превалирует, т.е. active/inactive, live/deleted и все в таком духе, условно тот же int 0/1, СУБД может за счет сбора статистики понять каких значений в БД больше и насколько и исходя из этого решить будет ли доступ по индексу оптимальным или нет - звучит гладко все хорошо. Проблема: половина интернета завалена мнениями откровенных профанов, которые вещают, что вот, мол, в SQL запросах нужно всегда использовать bind-переменные - это круто, защищает от пришельцев из космоса, все дела. Вот нет, для битовых (включая размерность byte на самом деле) полей bind-переменные использовать в запросах нельзя - БД должна четко понимать что происходит и что от нее хотят (у оракла решение этой проблемы заняло где-то лет 5: сначала они начали с bind peeking (т.е. подсмотра того, что реально в запросе приходит) и признания того, что у одного и того же запроса может быть несколько планов, а потом придумали adaptive cursor sharing, который приходилось выключать и в 11g и в 12c, сейчас оно вроде более-менее адекватно работает).

давайте чуть усложним ситуацию и у нас в БД будет разброс значений в пределах int, а еще у нас есть плохиши, вызывающие определенные всплески/отклонения в данных, вот что нужно сделать на уровне СУБД, чтобы эти всплески хотя бы разметить, ну вот есть статистика, так какая-то частотность значений присутствует, но размеры стастики нифига не безграничны и обычно там записей от силы порядка 256. Т.е. если всплесков в действительности куда больше, то для большинства СУБД оно будет происходить примерно так: если утром первым пришел толстый клиент, то весь день всем остальным будет плохо, а если наооборот - будет наоборот.

на поле long, вполне очевидно, что какую-либо статистику построить уже нельзя, т.е. нужно свято верить в индексы B*Tree (никакими логарифмами там и не пахнет на самом деле, потому что высота вполне себе ограничена), но вот тупые СУБД (PostgreSQL точно, на счет остальных не в курсе) все равно пытаются там какую-то статистику придумать