Это всего лишь отсылка к Запрещённым Барабанщикам. В далеком 2007 году, когда я уже работал программистом - у начальника из колонок на компе звучала эта песня периодически. Въелась в память)
Играл в киберпанк с генератором одного кадра на 4080 - если базовый фпс 40-50 или выше - играется вполне нормально, незаметно. Улучшился ли игровой опыт? Мне показалось да. Оптимальное сочетание - картинка чуть плавнее, а негативные эффекты незаметны.
А вот если 40 фпс и меньше, то желе проявляется все сильнее.
Кстати лично по моим ощущениям - нормальный фпс где то 100-120 на мониторе 144 гц. Край 75-80 фпс. Если ниже - то уже начинает чувствоваться что-то не то.
Это все конечно хорошо, но в реальности некогда задумываться об этом, так как есть еще 100500 вещей о которых надо подумать и вспомнить. Только если целенаправленно не занимаешься низкоуровневой оптимизацией.
Да и в целом - структура по доке рекомендуется 16 байт (на хабре была статья с тестами, где выяснилось 64 байта). То есть структуры - это для чисел. Но при этом, когда например пишешь бизнес приложения, то в 80% случаях в dto будет id и name как строка, в которой может быть и 5 символов и 500.
Ничего страшного, зато меньше вызовов по сети, меньше компонентов, не нужен кэш, нет проблем с шардированием, бд потребуется только для статистики и то, если она была упомянута в требованиях. Стабильней, надежней. Масштабирование - без проблем.
Я имел ввиду какие либо принципиально новые алгоритмы или подходы, может быть даже новое железо, типа квантовых компьютеров.
Азбука Морзе не может увеличивать в три раза. Там все буквы кодируются точкой тире (это по сути бит). Каждая буква от 1 до 4 или 5 «битов». Код символа ASCII - 1 байт или 8 бит. То есть сокращается на 50% и больше. Но в азбуке Морзе есть аналоговые паузы, которые сообщают о начале буквы. Возможно, если это подружить с нейросеткой - она научится выдергивать правильные буквы из непрерывного потока 0 и 1.
У урл ссылок тоже есть алфавит - это буквы англ алфавита и спецсимволы. Всего порядка 50-60 штук, лень точно считать.
Если даже взять 64 штуки то их можно закодировать 6 битами а не 8. Это уже сокращение на 25%. Разумеется это не совсем то, что требуется по условию задачи.
У нас сейчас скрам срам и 1sp по мнению руководства - это пара часов. Лет 10 назад я участвовал в проекте, где мы оценивали задачи в SP и я все же потом поделил сумму SP на сумму часов. Получилось 1sp = 8ч. А знаете что говорит сам изобретатель стори поинтов? 1sp = 3дня 😅 (пруф https://ronjeffries.com/articles/019-01ff/story-points/Index.html# - третий абзац).
Вот вы говорите, что нельзя конвертировать sp в часы. Но спринт имеет длительность в неделях (днях/часах), а не в стори поинтах. И клиентам обещают фичу через N кол-во дней/недель, а не через N стори поинтов.
Еще момент, вроде как sp - это сложность задачи, да? Вот я сейчас пишу авто тесты, у меня есть уже подход, архитектура тестов, их просто надо фигачить один за одним, по накатанной, чуть меняя тестовые данные (потому что у меня даже проверки переиспользуются, я их пишу на группы тестов). Это простая задача? Да это простая задача. Я бы ее оценил в 1sp именно по сложности. Но я ее буду делать весь спринт, потому что это крайне нудная, кропотливая и долгая задача. И получится моя скорость - 1sp, вместо 10-12-15 в предыдущих. После этого ко мне будут вопросы - а че так мало сделал? Поэтому я в уме конвертирую в дни и ставлю 13.
Идем дальше. Я тут недавно детализировано записал несколько своих рабочих дней, что я делал, с точностью до минут. У меня получилось, что я пол дня занимаюсь не пойми чем - ко мне приходят куча народу и задают вопросы, не понимают, задают уточняющие. Я помогаю в саппорте, я помогаю другим программистам, в некоторых случаях я за них делаю их работу, потому что они не-умеют/не-могут/не-хотят, делаю код ревью.
И это все отражается на моей скорости и опять ко мне возникают вопросы. Но при этом не учитывается в этих сторипоинтах. Серьезно, надо создавать задачу "ответы на вопросы и помощь команде" - и всегда закладывать туда 5 или даже 8 sp.
Следующий пункт
Просто потому, что для такой оценки нужна детальная информация: готовый DoD, аналитика, чёткое понимание, что именно вы собираетесь делать
Так и в сторях этого нет. В сторях написано "я как {роль} хочу {сделать} чтобы получить {результат}". Короче, то что вы рассказываете - это для команд в 15 человек, из которых 3 аналитика, 5 программистов и 3 тестировщика, остальные - всякий менеджмент.
Но у нас например - 1.5 программиста и 0.33 тестировщика. И когда мне приходит стори, вот как я выше описал - я сначала должен надеть шляпу аналитика и пойти анализировать. Только никто с меня других задач по программированию в рамках спринта - не снимает. Так что лучше было начать с ограничений, типа "я буду рассказывать про скрам в командах от 10-15 человек"
Самый смак будет - когда удастся реализовать вообще без хранилища БД. По сути это некий алгоритм сжатия и распаковки, когда в самом коротком урл будет содержаться все что надо. Как пример - азбука Морзе.
Реальность такова - что нельзя четко посчитать сколько сэкономили. И всегда, даже с командой лютых сениоров, можно сказать, что вы выкладываете фичи слишком медленно.
Я искренне хочу услышать эти истории успеха в комментариях
Расскажу про свой опыт, но не в хронологическом порядке.
Я для себя определился с двумя определениям ООП:
Это объекты, наследования, интерфейсы, полиморфизм, инкапсуляция
Это объекты + инкапсуляция + обмен сообщениями
Первой попыткой осознать ООП был пет проект - кодирование настольной игры. Я начал с объектов доска, кубики, каточки, фишки игроков и так далее. Я не завершил его. Но в целом, думаю, что ООП хорошо бы помог описать все объекты и правила взаимодействия в этом конкретном случае.
Вторая попытка - UI-движок-генератор. Я подсмотрел идею на одном из реальных бизнес-проектов и захотел сделать такое же сам. Суть - берем классы с атрибутами (модели и контроллеры из MVC) и генерим view на vue / react / angular. Я использовал ООП, у меня вышла развесистая структура объектов с наследованиями, инкапсуляцией и интерфейсам - по сути полная модель М* и C* в памяти компьютера, с необходимыми мне свойствами. Поверх этого я наложил генератор, который проходился по этой модели от общего к частному и на выходе генерировал js / vue файлы.
По итогу - это были попытки использовать ООП согласно первому определению. И в целом неплохо получилось.
Что же насчет бизнес-приложений? Собственно весь мой рабочий опыт относится к ним.
В самом начале у меня были очень простые бизнес-приложения. По сути CRUD с отчетами. Я тогда писал на WinForms и у меня весь код был размещен в обработчиках button1_Click и в конструкторах форм. Тут был чистый процедурный подход - взять строку данных из БД, показать на UI, сохранить. Не было никакой бизнес-логики. Никаких domain / DI / слоеных архитектур - я тогда об этом еще не знал.
Так продолжалось довольно долго, лет 10. Я узнал про паттерны / DI / DDD / слои и так далее и стал все (ну кроме DDD) это применять. Мне казалось, что все шло гладко. Видимо позволяла сложность проектов. Они все еще по прежнему были CRUD, только теперь перекладывали json из БД во внешнюю систему и обратно. Хорошо лег паттерн адаптер (для взаимодействия с внешними системами). Иногда были очереди и местами кое-какая нагрузка. В какой-то момент я даже сделал микросервисы. Только тогда, я еще не знал что это так называется и, как выяснилось позже, я применил "анти-паттерн" - одна БД на всех. Зато с транзакциями у меня был полный порядок. Бизнес-логика если и была - то довольно простая и укладывалась в пределах IMyService.
Вспомнил... Глотком свежего воздуха был один проект с алгоритмом. Там надо было считать покрытие фондовых инструментов на основе корреляции цен. Я там тоже применил ООП по первому определению. И паттерн стратегия - три варианта расчета. Все легло хорошо.
И вот наступает примерно 2020 год я устраиваюсь в компанию в сфере логистики. Мне дают проект в сложной предметной области с кучей исключительных и уникальных случаев. И вот тут начинаются проблемы.
Все эти фичи, опции, и уникальные обработчики размазываются тонким слоем по всей кодовой базе. Это просто ад. Тут я начинаю думать, что процедурный подход с анемичной моделью дал сбой. Пытался как-то реорганизовывать код. Но по сути все это было просто перекладыванием проблем из одного места в другое. Попробовать кардинально другое (полноценное DDD / функциональные языки) я не решался, потому что это долго почти с нуля туда заходить. А для DDD, к тому же, нужны были ресурсы на нормальный бизнес-анализ, которых не было.
Ну допустим. А что если действительно было бы лучше DDD / ООП? Тем более, что к тому моменту я прошел Route 256 в озоне и там дали какие-то базовые вещи о том, как проектировать предметную область и затем перекладывать это в программный код.
И вот однажды, у нас появилась новая фича, которая должна была выбирать оптимальный склад, с учетом остатков и собственно обновлять остатки на складах, чтобы не продать то, чего уже нет. И хорошо бы пару серверов, чтобы понадежней. А раз у нас больше одного сервера - то запрос может попасть на любой их них. Получаем параллельную обработку.
А как вы параллельно обработаете обновление остатков на складе? Никак. Там по любому где-то должно быть в один поток или откат лишнего резерва на границе перехода от "еще есть" и "уже закончилось". То есть нужны транзакции / блокировки. И что в этом случае предлагает ООП / DDD? Самому на коленке закодить распределенный ACID? Нет спасибо. Давайте лучше по старинке - например БД + хранимка + read committed (на крайняк serializable) + встроенные средства блокировок на строку в таблице - это точно работает, до определенной нагрузки и пока можем поднимать мощность сервера в условном AWS Cloud.
Но ведь хранимка в БД - это уже не ООП, правда ведь?
---
В итоге:
Когда ты делаешь CPU bound - алгоритмы, расчеты, моделирование - ООП тут работает четко
Когда ты делаешь простой I/O bound - процедурный поход позволяет с этим жить, при наличии нормального бизнес/системного анализа немного дольше
Когда делаешь сложный, но локальный / малонагруженный, I/O data bound - пожалуй это можно осилить с помощью ООП / DDD. Ну будешь из IRepository на каждый запрос доставать полную модель, валидировать по ее правилам и потом сохранять обратно. В данном случае не страшно, пусть весь мир подождет
Но вот как делать сложный облачный / распределенный / высоконагруженный I/O data bound - я пока не представляю. Совокупность требований и возможных оптимизаций начинают выводить из контекста ООП / DDD, которые могли бы помочь не размазывать фичи по всей кодовой базе.
Было бы интересно еще узнать - а что пошло не так или стало хуже с новой архитектурой.
Ну то есть никого не смутило падение с 200 тыс до 100 тыс до появления чат гпт? Но об этом заговорили только с появлением нейронок.
То есть график тоже сгенерирован нейронкой?
Это всего лишь отсылка к Запрещённым Барабанщикам. В далеком 2007 году, когда я уже работал программистом - у начальника из колонок на компе звучала эта песня периодически. Въелась в память)
DLSS (масштабирование разрешения) у меня отключен, разрешение нативное.
Но генерация кадров включена, у меня 4080 super, на ней генерит один дополнительный кадр, а на 50хх серии до трех кадров.
Миллион долларов сша и жизнь будет хороша (с)
Играл в киберпанк с генератором одного кадра на 4080 - если базовый фпс 40-50 или выше - играется вполне нормально, незаметно. Улучшился ли игровой опыт? Мне показалось да. Оптимальное сочетание - картинка чуть плавнее, а негативные эффекты незаметны.
А вот если 40 фпс и меньше, то желе проявляется все сильнее.
Кстати лично по моим ощущениям - нормальный фпс где то 100-120 на мониторе 144 гц. Край 75-80 фпс. Если ниже - то уже начинает чувствоваться что-то не то.
Что-то вспомнилось выступление Петросяна про шпингалеты из нижнего тагила, только тут про тг канал.
Это все конечно хорошо, но в реальности некогда задумываться об этом, так как есть еще 100500 вещей о которых надо подумать и вспомнить. Только если целенаправленно не занимаешься низкоуровневой оптимизацией.
Да и в целом - структура по доке рекомендуется 16 байт (на хабре была статья с тестами, где выяснилось 64 байта). То есть структуры - это для чисел. Но при этом, когда например пишешь бизнес приложения, то в 80% случаях в dto будет id и name как строка, в которой может быть и 5 символов и 500.
Мда, 3 и 6 сервера отожгли)
Хорошо, что выбрали графический редактор - на нем можно показать плюсы ооп, вместо бизнес приложения, где центром являются данные и их согласованность
Меня теперь другой вопрос интересует - а какая СУБД справляется лучше?
Ничего страшного, зато меньше вызовов по сети, меньше компонентов, не нужен кэш, нет проблем с шардированием, бд потребуется только для статистики и то, если она была упомянута в требованиях. Стабильней, надежней. Масштабирование - без проблем.
Я имел ввиду какие либо принципиально новые алгоритмы или подходы, может быть даже новое железо, типа квантовых компьютеров.
Азбука Морзе не может увеличивать в три раза. Там все буквы кодируются точкой тире (это по сути бит). Каждая буква от 1 до 4 или 5 «битов». Код символа ASCII - 1 байт или 8 бит. То есть сокращается на 50% и больше. Но в азбуке Морзе есть аналоговые паузы, которые сообщают о начале буквы. Возможно, если это подружить с нейросеткой - она научится выдергивать правильные буквы из непрерывного потока 0 и 1.
У урл ссылок тоже есть алфавит - это буквы англ алфавита и спецсимволы. Всего порядка 50-60 штук, лень точно считать.
Если даже взять 64 штуки то их можно закодировать 6 битами а не 8. Это уже сокращение на 25%. Разумеется это не совсем то, что требуется по условию задачи.
Самая ржака была знаете когда?
У нас сейчас
скрамсрам и 1sp по мнению руководства - это пара часов. Лет 10 назад я участвовал в проекте, где мы оценивали задачи в SP и я все же потом поделил сумму SP на сумму часов. Получилось 1sp = 8ч. А знаете что говорит сам изобретатель стори поинтов? 1sp = 3дня 😅 (пруф https://ronjeffries.com/articles/019-01ff/story-points/Index.html# - третий абзац).Вот вы говорите, что нельзя конвертировать sp в часы. Но спринт имеет длительность в неделях (днях/часах), а не в стори поинтах. И клиентам обещают фичу через N кол-во дней/недель, а не через N стори поинтов.
Еще момент, вроде как sp - это сложность задачи, да? Вот я сейчас пишу авто тесты, у меня есть уже подход, архитектура тестов, их просто надо фигачить один за одним, по накатанной, чуть меняя тестовые данные (потому что у меня даже проверки переиспользуются, я их пишу на группы тестов). Это простая задача? Да это простая задача. Я бы ее оценил в 1sp именно по сложности. Но я ее буду делать весь спринт, потому что это крайне нудная, кропотливая и долгая задача. И получится моя скорость - 1sp, вместо 10-12-15 в предыдущих. После этого ко мне будут вопросы - а че так мало сделал? Поэтому я в уме конвертирую в дни и ставлю 13.
Идем дальше. Я тут недавно детализировано записал несколько своих рабочих дней, что я делал, с точностью до минут. У меня получилось, что я пол дня занимаюсь не пойми чем - ко мне приходят куча народу и задают вопросы, не понимают, задают уточняющие. Я помогаю в саппорте, я помогаю другим программистам, в некоторых случаях я за них делаю их работу, потому что они не-умеют/не-могут/не-хотят, делаю код ревью.
И это все отражается на моей скорости и опять ко мне возникают вопросы. Но при этом не учитывается в этих сторипоинтах. Серьезно, надо создавать задачу "ответы на вопросы и помощь команде" - и всегда закладывать туда 5 или даже 8 sp.
Следующий пункт
Так и в сторях этого нет. В сторях написано "я как {роль} хочу {сделать} чтобы получить {результат}". Короче, то что вы рассказываете - это для команд в 15 человек, из которых 3 аналитика, 5 программистов и 3 тестировщика, остальные - всякий менеджмент.
Но у нас например - 1.5 программиста и 0.33 тестировщика. И когда мне приходит стори, вот как я выше описал - я сначала должен надеть шляпу аналитика и пойти анализировать. Только никто с меня других задач по программированию в рамках спринта - не снимает. Так что лучше было начать с ограничений, типа "я буду рассказывать про скрам в командах от 10-15 человек"
Самый смак будет - когда удастся реализовать вообще без хранилища БД. По сути это некий алгоритм сжатия и распаковки, когда в самом коротком урл будет содержаться все что надо. Как пример - азбука Морзе.
Реальность такова - что нельзя четко посчитать сколько сэкономили. И всегда, даже с командой лютых сениоров, можно сказать, что вы выкладываете фичи слишком медленно.
Занимательное чтиво у вас тут.
Расскажу про свой опыт, но не в хронологическом порядке.
Я для себя определился с двумя определениям ООП:
Это объекты, наследования, интерфейсы, полиморфизм, инкапсуляция
Это объекты + инкапсуляция + обмен сообщениями
Первой попыткой осознать ООП был пет проект - кодирование настольной игры. Я начал с объектов доска, кубики, каточки, фишки игроков и так далее. Я не завершил его. Но в целом, думаю, что ООП хорошо бы помог описать все объекты и правила взаимодействия в этом конкретном случае.
Вторая попытка - UI-движок-генератор. Я подсмотрел идею на одном из реальных бизнес-проектов и захотел сделать такое же сам. Суть - берем классы с атрибутами (модели и контроллеры из MVC) и генерим view на vue / react / angular. Я использовал ООП, у меня вышла развесистая структура объектов с наследованиями, инкапсуляцией и интерфейсам - по сути полная модель М* и C* в памяти компьютера, с необходимыми мне свойствами. Поверх этого я наложил генератор, который проходился по этой модели от общего к частному и на выходе генерировал js / vue файлы.
По итогу - это были попытки использовать ООП согласно первому определению. И в целом неплохо получилось.
Что же насчет бизнес-приложений? Собственно весь мой рабочий опыт относится к ним.
В самом начале у меня были очень простые бизнес-приложения. По сути CRUD с отчетами. Я тогда писал на WinForms и у меня весь код был размещен в обработчиках button1_Click и в конструкторах форм. Тут был чистый процедурный подход - взять строку данных из БД, показать на UI, сохранить. Не было никакой бизнес-логики. Никаких domain / DI / слоеных архитектур - я тогда об этом еще не знал.
Так продолжалось довольно долго, лет 10. Я узнал про паттерны / DI / DDD / слои и так далее и стал все (ну кроме DDD) это применять. Мне казалось, что все шло гладко. Видимо позволяла сложность проектов. Они все еще по прежнему были CRUD, только теперь перекладывали json из БД во внешнюю систему и обратно. Хорошо лег паттерн адаптер (для взаимодействия с внешними системами). Иногда были очереди и местами кое-какая нагрузка. В какой-то момент я даже сделал микросервисы. Только тогда, я еще не знал что это так называется и, как выяснилось позже, я применил "анти-паттерн" - одна БД на всех. Зато с транзакциями у меня был полный порядок. Бизнес-логика если и была - то довольно простая и укладывалась в пределах IMyService.
Вспомнил... Глотком свежего воздуха был один проект с алгоритмом. Там надо было считать покрытие фондовых инструментов на основе корреляции цен. Я там тоже применил ООП по первому определению. И паттерн стратегия - три варианта расчета. Все легло хорошо.
И вот наступает примерно 2020 год я устраиваюсь в компанию в сфере логистики. Мне дают проект в сложной предметной области с кучей исключительных и уникальных случаев. И вот тут начинаются проблемы.
Все эти фичи, опции, и уникальные обработчики размазываются тонким слоем по всей кодовой базе. Это просто ад. Тут я начинаю думать, что процедурный подход с анемичной моделью дал сбой. Пытался как-то реорганизовывать код. Но по сути все это было просто перекладыванием проблем из одного места в другое. Попробовать кардинально другое (полноценное DDD / функциональные языки) я не решался, потому что это долго почти с нуля туда заходить. А для DDD, к тому же, нужны были ресурсы на нормальный бизнес-анализ, которых не было.
Ну допустим. А что если действительно было бы лучше DDD / ООП? Тем более, что к тому моменту я прошел Route 256 в озоне и там дали какие-то базовые вещи о том, как проектировать предметную область и затем перекладывать это в программный код.
И вот однажды, у нас появилась новая фича, которая должна была выбирать оптимальный склад, с учетом остатков и собственно обновлять остатки на складах, чтобы не продать то, чего уже нет. И хорошо бы пару серверов, чтобы понадежней. А раз у нас больше одного сервера - то запрос может попасть на любой их них. Получаем параллельную обработку.
А как вы параллельно обработаете обновление остатков на складе? Никак. Там по любому где-то должно быть в один поток или откат лишнего резерва на границе перехода от "еще есть" и "уже закончилось". То есть нужны транзакции / блокировки. И что в этом случае предлагает ООП / DDD? Самому на коленке закодить
распределенныйACID? Нет спасибо. Давайте лучше по старинке - например БД + хранимка + read committed (на крайняк serializable) + встроенные средства блокировок на строку в таблице - это точно работает, до определенной нагрузки и пока можем поднимать мощность сервера в условном AWS Cloud.Но ведь хранимка в БД - это уже не ООП, правда ведь?
---
В итоге:
Когда ты делаешь CPU bound - алгоритмы, расчеты, моделирование - ООП тут работает четко
Когда ты делаешь простой I/O bound - процедурный поход позволяет с этим жить, при наличии нормального бизнес/системного анализа немного дольше
Когда делаешь сложный, но локальный / малонагруженный, I/O data bound - пожалуй это можно осилить с помощью ООП / DDD. Ну будешь из IRepository на каждый запрос доставать полную модель, валидировать по ее правилам и потом сохранять обратно. В данном случае не страшно, пусть весь мир подождет
Но вот как делать сложный облачный / распределенный / высоконагруженный I/O data bound - я пока не представляю. Совокупность требований и возможных оптимизаций начинают выводить из контекста ООП / DDD, которые могли бы помочь не размазывать фичи по всей кодовой базе.
Ништяк - без деклараций, можно вычитать пенсионные 100% если один работаешь и дешево - в регионах порядка 10-20-30 тыс. В Москве дорого.
В ковид из-за наличия окведа по настройке компьютеров (95.хх что ли) - налоговая вернула 7 тыщ за патент за тот год, типа поддержка малого бизнеса 🙂
А эта статья разве не на конкурс Хабра по ИИ футурологии?
Но ведь это же не только про айтишников? Например это
Чтобы быть в таком состоянии - не обязательно же быть именно айтишником?