приходится описывать абсолютно все и это как минимум +30% к срокам разработки
Здесь есть некоторая ошибка)
Это не +30% к срокам разработки. Это (может быть и то с оценкой не согласен) максимум +30% к времени набора кода. Но минус десятки, а то и сотни процентов именно к времени разработки, за счет избегания тупых багов вроде банальных опечаток.
Учитывая, сколько сейчас обычных сайтов построено на решетках вроде вордпреса и друпала. Такой себе совет. Поможет только совсем уж от левых сайтов вида «zZShFJDH.......KJFHFyDJ.xyz».
Конечно это не проблемы технологий фронтэнда. Никто этого и не утверждал собственно))
Но проблемы людей, делающих этот самый фронтэнд, по другому просто не решить. Только созданием технологий которые уменьшают появление проблем создаваемых людьми.
В противном случае мы дальше С и С++ просто не ушли. Все бы делали без ошибок на этих языках. А может и дальше ассемблера, кто знает)
Если, если, если, если… У вас очень много условий при который обычный подход к построению web приложений будет хорошо работать.
При плохом качестве интернета проблемы будут разные. Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально. Так что ваше «первое не работает» далеко от истины. Только в каких-то совсем крайних случаях, когда все другие способы давно перестали работать…
Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект.
Что же вас всех в космос то тянет?
Вам дали задачу сделать библиотеку логирования в системе (апи для фронта, аудита, генерации отчета, что угодно еще). Какое вам особенное знание о направлении движения проекта нужно? Это четкая функция системы. Условно: джун будет писать ровно так как ему скажут, мидлу дадут направление, сеньер сам может предусмотреть что надо от того же логирования.
Думаю все эти рассказы про «мне надо знать направление бизнеса», оно от банального бессилия человека понять, что ему надо делать. Вот он и прячется за софистическими формулировка о необходимости чего-то…
Как иллюстрацию к сказанному, посмотрите на проект Spring для Java. Люди делают кучу достаточно гибких решений, которые с успехом применяются в самых разных проектах.
И никто из них не говорит «дайте мне видение вашего бизнеса и только тогда я смогу написать SpringData». Это и есть инженерные решения, которые должны принимать не менеджеры, а технари которых нанимают — как именно решать поставленную задачу бизнеса.
Статья большей частью выглядит как «Передача мнения как факта» )
Далеко не всегда надо все это соблюдать. Много частных случаев.
В моей практике были люди которые просто не понимали нормального отношения.
Им бесполезно было говорить «у тебя системная проблема».
Поэтому им и бикали и пикали и чего только не делали. А уволить их было невозможно…
Спасибо за статью, всегда хотелось знать как проектируются такие системы.
В результате мы достигли производительности около 8 млн транзакций в секунду. И буквально через два месяца в статье про LMAX Disruptor увидели описание схемы с такой же функциональностью.Теперь на одной стадии могло находиться несколько потоков исполнения. Все транзакции обрабатывались по очереди, в порядке поступления. В итоге пиковая производительность выросла с 18 тыс. до 50 тыс. транзакций в секунду.
Не очень понятно как вы от «8 млн транзакций в секунду» перешли к «выросла с 18 тыс. до 50 тыс. транзакций в секунду».
Просто интересно — а почему вы верите, что в сторах лежит клиент собранный именно из этих исходников? )) В чем проблема, перед сборкой для стора, добавлять нужные патчи?
Очень корявое передергивание…
Вы пытаетесь глупыми, за ранее корявыми примерами сместить фокус обсуждения с абсолютно корректного вопроса проектирования в ООП в плоскость семантики конкретного языка.
P.S. Если писать на JS, то все ваши вопросы открыты и ответы зависят от компетенции разработчика. Если писать например на Haskell, то большинство ваших примеров просто не скомпилятся ввиду несоответсвия типов.
Это вы так думаете)
А адепты ООП, ничего кроме ООП не видели. И «проектируют» архитектуру объектами.
И в документах описывают объекты. И думают, что все так делат. Потому, что их большинство и ничего другого они во круг не видят… Да и желания у них посмотреть как можно по другому, то же нет. Вот и получается замкнутый круг…
Я вообще не очень понимаю как некое соглашение не подтвержденное документально может иметь какую-то юридическую силу.
Я судился со стоянкой на которой разбили стекло на моей машине.
Владелец стоянки не выписывал никаких бумажек и не давал чеков. Думал, что никто ему ничего не предъявит.
Так вот, суд посчитал бумажку с номером места (которую получает водитель когда ставит машину), как простую письменную форму договора на ответственное хранение.В итоге стоянка все возместила.
К чему я это? Да к тому, что не все так просто, с юридической точки зрения, в выражении «не подтвержденное документально».
Речь не про терминал Алора, а про TV.
Они дали возможность торговать с сайта TV, используя все его возможности, просто указав свою учетку в Алоре. tradingview
Лично я предпочитаю не оставлять недочитанные статьи «на потом»
Да какое «на потом»?
Тебе повонили во время чтения. Ты поговорил, перключился на месенджер, отправил нужные сообщения. Перключаешься назад на хабр… хоп, а ты уже на главной и хз где ты был и что читал…
Здесь есть некоторая ошибка)
Это не +30% к срокам разработки. Это (может быть и то с оценкой не согласен) максимум +30% к времени набора кода. Но минус десятки, а то и сотни процентов именно к времени разработки, за счет избегания тупых багов вроде банальных опечаток.
Учитывая, сколько сейчас обычных сайтов построено на решетках вроде вордпреса и друпала. Такой себе совет. Поможет только совсем уж от левых сайтов вида «zZShFJDH.......KJFHFyDJ.xyz».
Спасибо, что не предложили собственное облако поднимать с закупкой серверов)
Но проблемы людей, делающих этот самый фронтэнд, по другому просто не решить. Только созданием технологий которые уменьшают появление проблем создаваемых людьми.
В противном случае мы дальше С и С++ просто не ушли. Все бы делали без ошибок на этих языках. А может и дальше ассемблера, кто знает)
Вот с этим, к сожалению, на фронте основные проблемы.
P.S. Т.е. понятно, что не все проекты такие. Но таковых подавляющее большинство.
При плохом качестве интернета проблемы будут разные. Скачать 1Мб клиента при плохом инете может быть просто невозможно. А вот передать пару сотен байтов изменений на королеве вполне реально. Так что ваше «первое не работает» далеко от истины. Только в каких-то совсем крайних случаях, когда все другие способы давно перестали работать…
Что же вас всех в космос то тянет?
Вам дали задачу сделать библиотеку логирования в системе (апи для фронта, аудита, генерации отчета, что угодно еще). Какое вам особенное знание о направлении движения проекта нужно? Это четкая функция системы. Условно: джун будет писать ровно так как ему скажут, мидлу дадут направление, сеньер сам может предусмотреть что надо от того же логирования.
Думаю все эти рассказы про «мне надо знать направление бизнеса», оно от банального бессилия человека понять, что ему надо делать. Вот он и прячется за софистическими формулировка о необходимости чего-то…
Как иллюстрацию к сказанному, посмотрите на проект Spring для Java. Люди делают кучу достаточно гибких решений, которые с успехом применяются в самых разных проектах.
И никто из них не говорит «дайте мне видение вашего бизнеса и только тогда я смогу написать SpringData». Это и есть инженерные решения, которые должны принимать не менеджеры, а технари которых нанимают — как именно решать поставленную задачу бизнеса.
Далеко не всегда надо все это соблюдать. Много частных случаев.
В моей практике были люди которые просто не понимали нормального отношения.
Им бесполезно было говорить «у тебя системная проблема».
Поэтому им и бикали и пикали и чего только не делали. А уволить их было невозможно…
Не очень понятно как вы от «8 млн транзакций в секунду» перешли к «выросла с 18 тыс. до 50 тыс. транзакций в секунду».
Вы пытаетесь глупыми, за ранее корявыми примерами сместить фокус обсуждения с абсолютно корректного вопроса проектирования в ООП в плоскость семантики конкретного языка.
P.S. Если писать на JS, то все ваши вопросы открыты и ответы зависят от компетенции разработчика. Если писать например на Haskell, то большинство ваших примеров просто не скомпилятся ввиду несоответсвия типов.
Ну тогда вы только подтвердили мой комментарий…
Это вы так думаете)
А адепты ООП, ничего кроме ООП не видели. И «проектируют» архитектуру объектами.
И в документах описывают объекты. И думают, что все так делат. Потому, что их большинство и ничего другого они во круг не видят… Да и желания у них посмотреть как можно по другому, то же нет. Вот и получается замкнутый круг…
С чего вы решили, что все резко забыли старые, хорошо работающие и не закрытые уязвимости?
Я судился со стоянкой на которой разбили стекло на моей машине.
Владелец стоянки не выписывал никаких бумажек и не давал чеков. Думал, что никто ему ничего не предъявит.
Так вот, суд посчитал бумажку с номером места (которую получает водитель когда ставит машину), как простую письменную форму договора на ответственное хранение.В итоге стоянка все возместила.
К чему я это? Да к тому, что не все так просто, с юридической точки зрения, в выражении «не подтвержденное документально».
Вам знакомо поняте «кража личности»?
Просто кто-то мог взять себе данные реального человека и творить сови делишки…
Они дали возможность торговать с сайта TV, используя все его возможности, просто указав свою учетку в Алоре.
tradingview
У Алора есть интеграция с TV. Можно прямо с TV торговать у них.
И все эти костыли будут не нужны.
Да какое «на потом»?
Тебе повонили во время чтения. Ты поговорил, перключился на месенджер, отправил нужные сообщения. Перключаешься назад на хабр… хоп, а ты уже на главной и хз где ты был и что читал…