Зачем использовать такие странные решения, когда есть Automator с поддержкой AppleScript? Тем более Power Automate Desktop никогда не публиковался ни под OSX ни даже под Linux.
Техдолг можно и нужно планировать уже на этапе архитектуры. Это не исключение из процесса - это часть процесса.
Принятые на старте проектные и архитектурные решения и есть первоисточник техдолга. Именно здесь определяется: какова будет стоимость изменений завтра и послезавтра,будет ли возможна компонентная замена элементов без риска для всей системы, где будут пролегать технологические границы и насколько они поддаются пересмотру.
Искусство архитектора (или менеджера - зависит от проекта) - не избегать техдолга, а управлять им. Балансировать между скоростью, устойчивостью и стоимостью. Создавать систему, где возможна эволюция без остановки сервиса.
Дальше - да, культура важна. Код-ревью, рефакторинг, документация, «почини по ходу» - всё это обязательно. И это тоже требуется планировать. Но если в основании проекта нет миграционной стратегии, если не заданы устойчивые интерфейсы, если всё строится на слоёной каше из фреймворков - никакая «гигиена» не спасёт.
Проблема не в том, что техдолг не чинят - проблема в том, что о нём не думают, пока не стало поздно.
В раннем киберпанке нет особой борьбы верхов и низов - социализация вопроса произошла позднее, и скорее характерна для того же Гибсона, который конечно про киберпанк стилистически, но не совсем про него филосовски. Если посмотреть на работы Стивенсона (который Нил) - там социальная проблематика это просто один из слоев, подчеркивающих эстетику, А если обратиться к тому же Варли - у него значимой (то есть той, которую нельзя выкинуть не потеряв смысл) социалки в текстах кажется вообще нет.
(Советский и Российский киберпанк рассматривать надо вообще отдельно - он не так плохо пахнет)
у вас странно опущена структура бд... и запрос типа 'SELECT * FROM users' начиннающим лучше не показывать... wildcard в таких запросах в принципе не рационально ни с какой точки зрения...
Из-за этого на практике получается, например, что в систему маркировки товары отправляются по FIFO/LIFO, а реально отгружается то, что стояло ближе в выходу.
Это тоже решается специальным оборудованием и софтом для простых сотрудников, которые по роду своей работы не могут сидеть у компа.
Еще одна проблема — это попытка “натянуть сову на глобус” и втащить коды маркировки во все стандартные документы ERP, чтобы там их видел бухгалтер, логист или ответственный менеджер.
То есть сломать (работающие) процессы и внедрить «инновацию» за счет бизнеса — норм.
Не кажется ли вам, что если ценность автоматизации в выполнении требований регулирующих органов — то ничего особо полезного в ней нет. Так, доп. налог.
Поведение нормальной СУБД от потоков клиента не зависит (в общем то она и не знает есть ли они), для изоляции есть a — транзакции и b — явные блокировки, что и описано в статье.
Зачем использовать такие странные решения, когда есть Automator с поддержкой AppleScript? Тем более Power Automate Desktop никогда не публиковался ни под OSX ни даже под Linux.
-
Техдолг можно и нужно планировать уже на этапе архитектуры.
Это не исключение из процесса - это часть процесса.
Принятые на старте проектные и архитектурные решения и есть первоисточник техдолга.
Именно здесь определяется: какова будет стоимость изменений завтра и послезавтра,будет ли возможна компонентная замена элементов без риска для всей системы, где будут пролегать технологические границы и насколько они поддаются пересмотру.
Искусство архитектора (или менеджера - зависит от проекта) - не избегать техдолга, а управлять им.
Балансировать между скоростью, устойчивостью и стоимостью.
Создавать систему, где возможна эволюция без остановки сервиса.
Дальше - да, культура важна. Код-ревью, рефакторинг, документация, «почини по ходу» - всё это обязательно. И это тоже требуется планировать.
Но если в основании проекта нет миграционной стратегии, если не заданы устойчивые интерфейсы, если всё строится на слоёной каше из фреймворков -
никакая «гигиена» не спасёт.
Проблема не в том, что техдолг не чинят - проблема в том, что о нём не думают, пока не стало поздно.
В раннем киберпанке нет особой борьбы верхов и низов - социализация вопроса произошла позднее, и скорее характерна для того же Гибсона, который конечно про киберпанк стилистически, но не совсем про него филосовски. Если посмотреть на работы Стивенсона (который Нил) - там социальная проблематика это просто один из слоев, подчеркивающих эстетику, А если обратиться к тому же Варли - у него значимой (то есть той, которую нельзя выкинуть не потеряв смысл) социалки в текстах кажется вообще нет.
(Советский и Российский киберпанк рассматривать надо вообще отдельно - он не так плохо пахнет)
Вы пишете об этом так, как будто видите в этом что-то плохое...
Ерунду говорите. Никаких проблем построить интерфейс в рантайме ни там, ни там - нет.
Гуртовщик. А правильнее конечно «Привод»
у вас странно опущена структура бд... и запрос типа 'SELECT * FROM users' начиннающим лучше не показывать... wildcard в таких запросах в принципе не рационально ни с какой точки зрения...
Вкусно )
Посмотрите на Сербский - прекрасно сочетаются две азбуки в реальной жизни. А ваш вариант, к сожалению, искуственный.
CTO который забыл как писать код - так себе CTO в софтверных компаниях. Как минимум не надо забывать навыки чтения)
https://habr.com/ru/articles/113165/
Спасибо за два минуса, еще отсыпьте пожалуйста.
Казалось, что такой поход к рекламе давно в прошлом, но внезапно)
Так а что нового то?
Можно убрать титульный лист? Не всегда.
Можно печатать в цвете? Не всегда.
Ура, можно подумать и спроектировать отчет ДО его использования? Поздравляю.
О чем статья - не понял.
глобальный стандартный идентификатор с понятным для человека значением - утопия)
То есть сломать (работающие) процессы и внедрить «инновацию» за счет бизнеса — норм.
Не кажется ли вам, что если ценность автоматизации в выполнении требований регулирующих органов — то ничего особо полезного в ней нет. Так, доп. налог.
или linux )
Достаточно иллюзии свободы )