описание первой задачи -"хранить состояние об включенном аккаунте и об удаленном аккаунте" решение сразу же применено вредное - заводим флаги is_active и is_deleted. что будет записано в is_active когда аккаунт удален is_deleted=true - в is_active может быть записано любое значение (зачем оно нужно тогда ?), может быть is_deleted=true и is_active=true (а что это значит) ? или же возможен единственный вариант is_deleted=true и is_active=false ? одновременно звучит бизнес требование - "обеспечить жизненный цикл аккаунта". а у него состояния - активный, удален, выключен. тогда действительно да - надо заводить словарь с константами. реализация словаря зависит от ваших технологических условий. автор тут дельно предложил использовать enum - как один из вариантов возможно.
правда хочу сказать, что в старых системах тот сценарий, что описан в статье может запросто случиться. ввели лет 6 назад поле для аккаунта is_active, вы пришли после - статусы жизненного цикла добавить нереально, так как проект большой, а приходится. вот и начинаешь есть кактус.
это все в мобильнике? или пользователь тоже мобильный? даже если так - посредине склада пользователю срочно требуется посмотреть номекулатуру в 100 000 записей о товаре? и какие выводы можно сделать по такой объмной выборке ?
да тут наверно вы правы - крутясь внутри финтеха в одних и тех же задачах много лет возникает иллюзия что выгоднее разработчику иметь бизнес навыки на высоком уровне. тем более что заказчик этжом ниже и если коммуникация налажена то все прекрасно. а если заказчик в другом городе или доступен только по конференциям - ну автор про это наверно и не знает. короче специфика
основаная тема материала - все делают все. если ты будешь общаться с бизнесом, то ты уже не будешь разрабатывать - будешь все болшье и больше тратить время на совещания и меньше на разработку. то есть из разработчика превратишься в менеджера - легко деквалифицироватся.
и тем не менее как правильно сказать невозможно - неясно что такое правильно. анекдот "быстро качественно и дешево" это не анекдот. у автора есть пример быстро и качественно? правда в чем качество ( критерий) и быстрота - это какой срок? что дочно можно сказать - бизнес задача реализована или нет. как реализована - оценить можно
кто может позволить себе прототипирование с учетом требований для инвалидов? какой их процент? приложение для заказа еды - ориентировано на массовость - иначе прибыли не будет. кто будет адаптацию под инвалидов
в примере со списком надо было переставить sublist(0,1) на sublist(0,3) - как я понял списко меняли в одном месте. если была бы ситуация, когда у вас были два списка с длиной один и три, то тут надо поставить заметку "если будет еще такой список то тут уже пора делать параметризованный список". читат я где то то ли методика то ли подход - на такие вещи реагируем только по третьему преценденту
я бы сказал что тема статьи не про вредный тип boolean, а про ошибки проектирования системы. причем автор привел пример ошибки не одну
описание первой задачи -"хранить состояние об включенном аккаунте и об удаленном аккаунте"
решение сразу же применено вредное - заводим флаги is_active и is_deleted.
что будет записано в is_active когда аккаунт удален is_deleted=true - в is_active может быть записано любое значение (зачем оно нужно тогда ?), может быть is_deleted=true и is_active=true (а что это значит) ? или же возможен единственный вариант is_deleted=true и is_active=false ?
одновременно звучит бизнес требование - "обеспечить жизненный цикл аккаунта". а у него состояния - активный, удален, выключен.
тогда действительно да - надо заводить словарь с константами. реализация словаря зависит от ваших технологических условий.
автор тут дельно предложил использовать enum - как один из вариантов возможно.
правда хочу сказать, что в старых системах тот сценарий, что описан в статье может запросто случиться. ввели лет 6 назад поле для аккаунта is_active, вы пришли после - статусы жизненного цикла добавить нереально, так как проект большой, а приходится. вот и начинаешь есть кактус.
это все в мобильнике? или пользователь тоже мобильный?
даже если так - посредине склада пользователю срочно требуется посмотреть номекулатуру в 100 000 записей о товаре?
и какие выводы можно сделать по такой объмной выборке ?
все равно непонятно зачем вашему пользователю 500 000 записей - он с ними что делает?
так код фронтед должен быть минифицирован. иначе свою зарплату сотрудники получают зря
да тут наверно вы правы - крутясь внутри финтеха в одних и тех же задачах много лет возникает иллюзия что выгоднее разработчику иметь бизнес навыки на высоком уровне.
тем более что заказчик этжом ниже и если коммуникация налажена то все прекрасно.
а если заказчик в другом городе или доступен только по конференциям - ну автор про это наверно и не знает.
короче специфика
основаная тема материала - все делают все.
если ты будешь общаться с бизнесом, то ты уже не будешь разрабатывать - будешь все болшье и больше тратить время на совещания и меньше на разработку.
то есть из разработчика превратишься в менеджера - легко деквалифицироватся.
и тем не менее как правильно сказать невозможно - неясно что такое правильно.
анекдот "быстро качественно и дешево" это не анекдот. у автора есть пример быстро и качественно?
правда в чем качество ( критерий) и быстрота - это какой срок?
что дочно можно сказать - бизнес задача реализована или нет. как реализована - оценить можно
ну ну - то то американцев все на улицу выставлять принялись
кто может позволить себе прототипирование с учетом требований для инвалидов?
какой их процент?
приложение для заказа еды - ориентировано на массовость - иначе прибыли не будет. кто будет адаптацию под инвалидов
я тут мощно задумался - полиморфизм и наследование - в чем разница друг от друга ?
в примере со списком надо было переставить sublist(0,1) на sublist(0,3) - как я понял списко меняли в одном месте. если была бы ситуация, когда у вас были два списка с длиной один и три, то тут надо поставить заметку "если будет еще такой список то тут уже пора делать параметризованный список".
читат я где то то ли методика то ли подход - на такие вещи реагируем только по третьему преценденту