Именно разработчик решает реализовать бизнес-требования через костыль, и именно он вносит этот костыль в код и берет тем самым на себя ответственность и за этот костыль
У вас сроки реализации тоже разработчик сам себе ставит? Я обычно видел ситуации, когда есть срок, к которому нужно реализовать фичи, к которому ее реализовать нормально нельзя и происходит стандартный диалог на тему "ну мы же потом перепишем — конечно", а потом чуда не происходит.
А еще это мы не затрагивает ситуацию, когда какой-то топ-менеджер по 6 раз кардинально меняет требования к задаче в течении времени ее реализации. И каждый раз давит на разработчиков с тем, что бы ее реализовали быстрее. В итоге код будет просто отвратительный и тоже разработчики будут виноваты?
Эти утверждения же не опровергают ложного вывода статьи в том, что "источник технического долга — разработчики". Разумеется, проблемы IT отдела (как и любого другого) в итоге будут проблемами бизнеса, но в том числе важно понимать, что очень часто именно бизнес-решения порождают технический долг, а не "неидеальность" разработчиков.
Я могу переформулировать это как "очень часто технический долг не возникает сам по себе, а бизнес намеренно увеличивает технический долг зная или игнорируя риски с ним связанные, дабы получить выгоду для себя".
Если без лишних сложностей, давайте думать о нашей кодовой базе как о замкнутой системе. Отбросим внешние зависимости и всё, что живет за пределами нашей кодовой базы. В этих условиях — неизменное количество разработчиков, разработка фич в стабильно высоком темпе — количество энтропии (мера беспорядка и случайности в системе) в нашей кодовой базе остается постоянной.
Из неправильного предположения вытекает неправильное следствие — в итоге, так или иначе в техническом долге виноваты только разработчики, пусть это можно списать на сущность человеческой природы.
На практике, кодовая база это не закрытая система. Она катастрофически часто претерпает проблемы со стороны заказчика (аутсорс) или бизнеса (продуктовая разработка). И обычно все проблемы бизнеса в духе кривых бизнес-процессов или "сделай как-то так, там же все понятно" в первую очередь отображаются в ней, потому что плохо продуманные бизнес-процессы как-то людьми залепить можно, а с кодом так не сработает.
Я, конечно, все понимаю, но зачем натягивать сову на глобус? Уже есть правильный термин — эксклюзив, зачем еще притягивать другие термины, которые не имеют к этом отношения?
Наконец, все мы знаем, что сегодня программисту сложно найти хорошую работу без знания Elasticsearch, RabbitMQ, Kafka и других технологий, которые в моей повседневной работе появляются не часто.
И я не писал, что Rust реализация будет медленнее. Я писал, что в лучшем случае она будет не медленнее.
Вы же понимаете, что это так вообще не работает? Вам нужно написать две крупные большие одинаковые программы на разных языках. У вас никогда не будет таких условий, что бы они соревновались в одинаковых условиях.
Поэтому выражение "программа на rust не будет быстрее С++" сильно похоже на софистику, так как вы никто не будет дословно переписывать написанное на С++ на Rust.
Возможно, этому виной плохие примеры. Одна продуктовая фирма, где я работал, использовала C# 2.0. ДВА НОЛЬ. Аргументировали они просто: проект большой, если переносить его на новую версию, наплодим кучу багов. И я принимаю этот аргумент — это аргумент бизнеса, для которого прибыль важней технологичности. Я понимаю бизнес, но я не могу понять разработчиков, которых это устраивает.
Я в таких случаях наоборот, не понимаю бизнес. Консервативных разработчиков очень легко понять, так как эта платформа, которую они знаю и им проще с ней работать. А бизнес, который игнорирует потенциальные проблемы в духе "у вас тут уязвимости, которые никто не закроет, так как продукт не поддерживается" и потенциальное удорожание рабочей силы мне очень сложно понять.
Если они будут запущены в пределах одной group, они будут на одной ноде и смогут общатся. Правда если вы укажите им сети, так как автоматически номад сети не делает.
Есть много инструментов, которые вы можете интегрировать для облегчения разработки. Кроме того, все действия выполняются с одним каталогом, что упрощает развертывание. Благодаря монолитному ядру разработчикам не нужно развертывать изменения или обновления по отдельности, поскольку они могут сделать это сразу и сэкономить много времени.
Разумеется. А потом для развертывание монолита локально нужно писать сложные многостраничные инструкции или даже раздавать готовые виртуалки, потому что поднять это чудо самостоятельно уже год никто не может.
Вот это новость. Тысячи людей по всему миру вполне неплохо защищаются от государственного и банквоского произвола, а оказывается, защитится он него нельзя (!).
От первого можно защищаться через разные ончейн механизмы типа мультисиг кошельков
Как там история с дырами в популярных криптах и ХАРДФОРКАМИ для того, что бы октатить транзакции? А между прочим, это сказывается на всех пользователях крипты, потому что их реальная стоимость обычно после такого сильно падает.
Мне кажется, вы не понимаете, что система, которая хочет быть массово используемой должна содержать в себе механизмы отмены проведенных операций в любом случае. Если этого нет, то любая ошибка система, ваша ошибка или же злонамеренные действия третьих лиц являются необратимыми, что очень плохо.
И если вы думаете, что вы умный и всегда сможете избежать "злонамеренных действий третьих лиц", то это так не работает.
Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.
Очень мало, даже опытных специалистов, может взять и написать к условному проекту код, который бы придерижвался стиля разработки в проекте (в том числе и не описанного), а еще что бы решение совпадало с тем, как его видит автор проекта .
Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.
Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.
У вас сроки реализации тоже разработчик сам себе ставит? Я обычно видел ситуации, когда есть срок, к которому нужно реализовать фичи, к которому ее реализовать нормально нельзя и происходит стандартный диалог на тему "ну мы же потом перепишем — конечно", а потом чуда не происходит.
А еще это мы не затрагивает ситуацию, когда какой-то топ-менеджер по 6 раз кардинально меняет требования к задаче в течении времени ее реализации. И каждый раз давит на разработчиков с тем, что бы ее реализовали быстрее. В итоге код будет просто отвратительный и тоже разработчики будут виноваты?
Эти утверждения же не опровергают ложного вывода статьи в том, что "источник технического долга — разработчики". Разумеется, проблемы IT отдела (как и любого другого) в итоге будут проблемами бизнеса, но в том числе важно понимать, что очень часто именно бизнес-решения порождают технический долг, а не "неидеальность" разработчиков.
Я могу переформулировать это как "очень часто технический долг не возникает сам по себе, а бизнес намеренно увеличивает технический долг зная или игнорируя риски с ним связанные, дабы получить выгоду для себя".
Из неправильного предположения вытекает неправильное следствие — в итоге, так или иначе в техническом долге виноваты только разработчики, пусть это можно списать на сущность человеческой природы.
На практике, кодовая база это не закрытая система. Она катастрофически часто претерпает проблемы со стороны заказчика (аутсорс) или бизнеса (продуктовая разработка). И обычно все проблемы бизнеса в духе кривых бизнес-процессов или "сделай как-то так, там же все понятно" в первую очередь отображаются в ней, потому что плохо продуманные бизнес-процессы как-то людьми залепить можно, а с кодом так не сработает.
На самом деле, просто нет. Особенно на Benchmarks Game
Эх, а ведь там в комментариях все так возмущаются о том, что "вот как так можно!". А теперь вот оно как :(
Я, конечно, все понимаю, но зачем натягивать сову на глобус? Уже есть правильный термин — эксклюзив, зачем еще притягивать другие термины, которые не имеют к этом отношения?
Но ведь понятия монополии обычно используют для определения доли рынка, а не конкретного продукта на этом рынке.
Мне казалось, что в дистрибуции на ПК игр сейчас однозначный монополист — steam.
Эм… разве?
Ну да, если бы.
Вы же понимаете, что это так вообще не работает? Вам нужно написать две крупные большие одинаковые программы на разных языках. У вас никогда не будет таких условий, что бы они соревновались в одинаковых условиях.
Поэтому выражение "программа на rust не будет быстрее С++" сильно похоже на софистику, так как вы никто не будет дословно переписывать написанное на С++ на Rust.
Уже даже в Go догадались до
go modЯ в таких случаях наоборот, не понимаю бизнес. Консервативных разработчиков очень легко понять, так как эта платформа, которую они знаю и им проще с ней работать. А бизнес, который игнорирует потенциальные проблемы в духе "у вас тут уязвимости, которые никто не закроет, так как продукт не поддерживается" и потенциальное удорожание рабочей силы мне очень сложно понять.
Если они будут запущены в пределах одной group, они будут на одной ноде и смогут общатся. Правда если вы укажите им сети, так как автоматически номад сети не делает.
Разумеется. А потом для развертывание монолита локально нужно писать сложные многостраничные инструкции или даже раздавать готовые виртуалки, потому что поднять это чудо самостоятельно уже год никто не может.
Вот только это два разных термина, по идее ....
Зачем все переходят с celery на rq? Мне кажется, это странная тенденция :(
Вот это новость. Тысячи людей по всему миру вполне неплохо защищаются от государственного и банквоского произвола, а оказывается, защитится он него нельзя (!).
Как там история с дырами в популярных криптах и ХАРДФОРКАМИ для того, что бы октатить транзакции? А между прочим, это сказывается на всех пользователях крипты, потому что их реальная стоимость обычно после такого сильно падает.
Мне кажется, вы не понимаете, что система, которая хочет быть массово используемой должна содержать в себе механизмы отмены проведенных операций в любом случае. Если этого нет, то любая ошибка система, ваша ошибка или же злонамеренные действия третьих лиц являются необратимыми, что очень плохо.
И если вы думаете, что вы умный и всегда сможете избежать "злонамеренных действий третьих лиц", то это так не работает.
21 век, а спринг все еще не умеет в конфигурацию из разных источником сливать? То есть настройки в классе нельзя перебить переменными окружения?
Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.
Очень мало, даже опытных специалистов, может взять и написать к условному проекту код, который бы придерижвался стиля разработки в проекте (в том числе и не описанного), а еще что бы решение совпадало с тем, как его видит автор проекта .
Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.