Видел) В паре проектов за последние лет пять. Но есть нюансы.
Первый без этих подходов просто не работал бы. Сложность логики подразумевала, что нахрапом и тем же KISS не решить, в итоге первые пару недель ты плюешься от этого кода и его структуры, а когда все понял, осознаешь, что по-другому это просто невозможно написать. Первый раз в жизни, когда желание отрефачить чей-то код полностью пропало.
Второй - проект с нуля с очень сильной командой, начали с основательной проработки архитектуры и подходов, что помогло нам через полгода. Скорость поддержки и починки багов отличалась местами в несколько раз, по сравнению с аналогичной старой фичей, чисто за счёт грамотной, хоть и сложной архитектуры.
За шутки автору конечно спасибо. Но в целом, суть поста, можно уложить в одну мысль - чистота/архитектура должны быть применимы к конкретной задаче и условиям, а не раскатываться повсеместно по принципу чисто/красиво, потому что так надо или в умной книжке написано. Код должен быть максимально понятным и простым, насколько это позволяет задача, соблюдая баланс между чистотой - простотой поддержки - читаемостью. Надо писать так, что если завтра отшибает память, ты сможешь понять то, что ты написал и продолжить поддержку.
Часто вижу критику этих книг от разных авторов, коллег, разработчиков, из-за чего возникает ощущение, что они их не читали или не поняли смысл до конца. Это просто рекомендации и базовые принципы, которые должен знать разработчик, но при этом уметь понимать, когда и какой из этих принципов применим в той или иной ситуации.
Сам не раз в работе видел красиво написанный код, от адептов супер архитектурных подходов с кучей прослоек/абстракций/компонентов/модулей. Только почему-то этот код был написан для решения простейших задач на пару-тройку классов. И без наличия этих адептов в команде все сразу превращалось в абсолютно не поддерживаемую, перегруженную кашу.
Могу слегка помочь автору. Часть боли он уже сказал, это webView и работа с картами. Где ещё могут быть небольшие трудности:
Переезд мышления на парадигму UDF (https://developer.android.com/develop/ui/compose/architecture), имутабельный интерфейс и необходимость привыкнуть к тому, что все изменения UI, это изменение стейта,
Переходный период миграции на Compose в большом проекте. Какое-то время будет зоопарк из классических Fragment + View, и Compose. Все переезжают по-разному, но как по мне, самый безопасный вариант, это не встройка отдельных Compose View, а переписывание всего контента на Compose в рамках одного Fragment.
Часть стандартных компонентов из Compose Material имеют встроенные padding/margin, которые не убрать через modifier.
Не совсем привычная работа с BottomSheet и ему подобными
Работа с modifier (фон, отступы, рамки и прочее), где на внешний вид влияет порядок вызова модификаторов. Первое время надо будет привыкать
Scope родительской Compostable функции, который определяет возможности части modifier вложенных элементов. Для кастомных UI элементов, иногда нужно явно указывать Scope родительского контейнера, чтобы применять нужные модификаторы (modifier)
Но все это решаемо, описано в официальной документации или давно разобрано сообществом. Поэтому больших трудности при миграции не будет. А новый проект/фичу написать на Compose будет ещё проще
Не про тех пиратов ожидал увидеть пост. Если по полочкам:
Автор утверждает, что пишет уже много лет. Возникает вопрос, почему тогда эта статья так трудно и нудно читается. Опыт автора не чувствуется при прочтении
Возможно это взгляд из моего личного пузыря, но что я, что мое окружение часто покупает физические издания понравившихся книг, либо используют тот же ЛитРес с аналогами. Только вот проблема, не всегда нужное произведение есть в наличии или в том же ЛитРес, как читать? Терпеть пока появится?
Проблема современной литературы не в пиратах, а в ее содержании. Художественная или документальная, не важно, часто это просто сложно воспринимать из-за слога и структуры повествования, либо из-за отсутствия свежих идей, качественной переработки старых
Пираты помогают сохранить историю и дать доступ тем, у кого нет возможности покупать книги в цифре или физические, а ещё порой выступают в качестве переводчиков, что тоже немаловажно
Как обычный читатель, я бы порекомендовал автору попробовать либо новые способы распространения контента, либо новые темы для литературного творчества, возможно найти более подходящий жанр. А так, всю историю быть писателем является не таким уж простым призванием. И вот здесь я действительно уважаю ваш выбор
А я просто пришел сказать спасибо за интересную статью. Не со всеми идеями согласен, но в любом случае приятно видеть действительно профильный контент на Хабре.
З.Ы.: Почему не со всем согласен, часто, но далеко не всегда нужно строгое разделение и множество абстракций. Команда должна это отслеживать и держать необходимый для них самих уровень абстракции. В общем как всегда - суть в балансе, который индивидуален для команды/проекта/направления продукта. Повидал не мало кода, где как раз таки чистую архитектуру воспринимали более важной, по сравнению с самой логикой, в итоге через год невозможно было распутать даже простые обращения к серверу или БД
Храбр не жалобная книга, но жалобная публикация появилась. Кажется качество контента постепенно перетекает в филиал Пикабу. А если по теме - Ваша безопасность, это в первую очередь Ваша ответственность, включающая не только знание кредов, но и знание требований/ограничений сервисов и продуктов, которыми пользуетесь. Чем больше в сети менее технически подготовленных пользователей - тем сложнее и муторнее правила безопасности для более подкованных, потому что любые правила будут ориентироваться в первую очередь на самое слабое звено. Если бы до сих пор все было только на кредах, вместо этой публикации появилась бы другая, на тему "У моей тётушки украли пароль от банка, почему безопасники не придумали более надёжный способ входа в аккаунт",
Позволю себе немного ворваться в обсуждение. По прошлому опыту, из наших систем, с точки зрения интеграции, более точной настройки и адекватной поддержки от вендора, имхо, решения от Positive Technologies одни из самых удобных и функциональных. На момент когда работали с ними, параллельно внедряли решения от Check Point и Fortinet, было с чем сравнивать. Но тогда не хватало фичей, по сравнению с зарубежными аналогами
Немного не хватает подробностей основной задачи, которая решается этим железом и описания модулей. Не все знают что и для чего NRF. А так почему бы и нет, кому-то эта статья точно пригодится. В любом случае это лучше, чем переведенные нечитабельные статьи без указания оригинала, которые частенько попадаются на Хабре.
Позволю себе ворваться, т.к. вижу комментарии на тему китайских аналогов, зачем нужна такая если есть мембранки и прочее.
Несколько лет (минимум 4) пользуюсь механикой Keychron K2 с тихими свичами. Металлическая рама - реально решает в плане прочности и устойчивости, все живое до сих пор, стоит уверенно и не сдвигается от порыва ветра или пинка по столу как дешёвые пластиковые варианты. Плата там тоже отличная, никаких косяков по части прошивки, даже пользуюсь фичами с запоминанием устройств, к которым подключается клавиатура. Наличие понимания ОС девайса тоже штука полезная. По беспроводу соединение стабильное. Батарею держит очень хорошо, даже не могу вспомнить насколько часто ее заряжаю.
Китайские аналоги есть - проживут они точно меньше.
В плане дизайна - на вкус и цвет у всех фломастеры будут разные, тут цепляться вообще нет смысла. А если глянуть на "моду", то там как раз возвращаются к старой классике
Разрекламированные игровые и "профессиональные" варианты других брендов будут дороже, а качество такое же.
Так что в целом - Keychron сейчас близко к золотой середине в плане цена-качество-функционал
Видел) В паре проектов за последние лет пять. Но есть нюансы.
Первый без этих подходов просто не работал бы. Сложность логики подразумевала, что нахрапом и тем же KISS не решить, в итоге первые пару недель ты плюешься от этого кода и его структуры, а когда все понял, осознаешь, что по-другому это просто невозможно написать. Первый раз в жизни, когда желание отрефачить чей-то код полностью пропало.
Второй - проект с нуля с очень сильной командой, начали с основательной проработки архитектуры и подходов, что помогло нам через полгода. Скорость поддержки и починки багов отличалась местами в несколько раз, по сравнению с аналогичной старой фичей, чисто за счёт грамотной, хоть и сложной архитектуры.
За шутки автору конечно спасибо. Но в целом, суть поста, можно уложить в одну мысль - чистота/архитектура должны быть применимы к конкретной задаче и условиям, а не раскатываться повсеместно по принципу чисто/красиво, потому что так надо или в умной книжке написано. Код должен быть максимально понятным и простым, насколько это позволяет задача, соблюдая баланс между чистотой - простотой поддержки - читаемостью. Надо писать так, что если завтра отшибает память, ты сможешь понять то, что ты написал и продолжить поддержку.
Часто вижу критику этих книг от разных авторов, коллег, разработчиков, из-за чего возникает ощущение, что они их не читали или не поняли смысл до конца. Это просто рекомендации и базовые принципы, которые должен знать разработчик, но при этом уметь понимать, когда и какой из этих принципов применим в той или иной ситуации.
Сам не раз в работе видел красиво написанный код, от адептов супер архитектурных подходов с кучей прослоек/абстракций/компонентов/модулей. Только почему-то этот код был написан для решения простейших задач на пару-тройку классов. И без наличия этих адептов в команде все сразу превращалось в абсолютно не поддерживаемую, перегруженную кашу.
Могу слегка помочь автору. Часть боли он уже сказал, это webView и работа с картами. Где ещё могут быть небольшие трудности:
Переезд мышления на парадигму UDF (https://developer.android.com/develop/ui/compose/architecture), имутабельный интерфейс и необходимость привыкнуть к тому, что все изменения UI, это изменение стейта,
Переходный период миграции на Compose в большом проекте. Какое-то время будет зоопарк из классических Fragment + View, и Compose. Все переезжают по-разному, но как по мне, самый безопасный вариант, это не встройка отдельных Compose View, а переписывание всего контента на Compose в рамках одного Fragment.
Часть стандартных компонентов из Compose Material имеют встроенные padding/margin, которые не убрать через modifier.
Не совсем привычная работа с BottomSheet и ему подобными
Работа с modifier (фон, отступы, рамки и прочее), где на внешний вид влияет порядок вызова модификаторов. Первое время надо будет привыкать
Scope родительской Compostable функции, который определяет возможности части modifier вложенных элементов. Для кастомных UI элементов, иногда нужно явно указывать Scope родительского контейнера, чтобы применять нужные модификаторы (modifier)
Во время миграции могут возникнуть проблемы с влиянием жизненного цикла Fragment/Activity на отрисовку Compose внутри (https://medium.com/@tangkegaga/why-viewcompositionstrategy-compose-and-view-work-together-905933a8ac99)
Для более оптимальной работы Compose ещё стоит получше изучить рекомпозицию и стабильные функции (https://habr.com/ru/companies/yandex/articles/841154/)
Но все это решаемо, описано в официальной документации или давно разобрано сообществом. Поэтому больших трудности при миграции не будет. А новый проект/фичу написать на Compose будет ещё проще
Не про тех пиратов ожидал увидеть пост. Если по полочкам:
Автор утверждает, что пишет уже много лет. Возникает вопрос, почему тогда эта статья так трудно и нудно читается. Опыт автора не чувствуется при прочтении
Возможно это взгляд из моего личного пузыря, но что я, что мое окружение часто покупает физические издания понравившихся книг, либо используют тот же ЛитРес с аналогами. Только вот проблема, не всегда нужное произведение есть в наличии или в том же ЛитРес, как читать? Терпеть пока появится?
Проблема современной литературы не в пиратах, а в ее содержании. Художественная или документальная, не важно, часто это просто сложно воспринимать из-за слога и структуры повествования, либо из-за отсутствия свежих идей, качественной переработки старых
Пираты помогают сохранить историю и дать доступ тем, у кого нет возможности покупать книги в цифре или физические, а ещё порой выступают в качестве переводчиков, что тоже немаловажно
Как обычный читатель, я бы порекомендовал автору попробовать либо новые способы распространения контента, либо новые темы для литературного творчества, возможно найти более подходящий жанр. А так, всю историю быть писателем является не таким уж простым призванием. И вот здесь я действительно уважаю ваш выбор
А я просто пришел сказать спасибо за интересную статью. Не со всеми идеями согласен, но в любом случае приятно видеть действительно профильный контент на Хабре.
З.Ы.: Почему не со всем согласен, часто, но далеко не всегда нужно строгое разделение и множество абстракций. Команда должна это отслеживать и держать необходимый для них самих уровень абстракции. В общем как всегда - суть в балансе, который индивидуален для команды/проекта/направления продукта. Повидал не мало кода, где как раз таки чистую архитектуру воспринимали более важной, по сравнению с самой логикой, в итоге через год невозможно было распутать даже простые обращения к серверу или БД
Храбр не жалобная книга, но жалобная публикация появилась. Кажется качество контента постепенно перетекает в филиал Пикабу. А если по теме - Ваша безопасность, это в первую очередь Ваша ответственность, включающая не только знание кредов, но и знание требований/ограничений сервисов и продуктов, которыми пользуетесь. Чем больше в сети менее технически подготовленных пользователей - тем сложнее и муторнее правила безопасности для более подкованных, потому что любые правила будут ориентироваться в первую очередь на самое слабое звено. Если бы до сих пор все было только на кредах, вместо этой публикации появилась бы другая, на тему "У моей тётушки украли пароль от банка, почему безопасники не придумали более надёжный способ входа в аккаунт",
Позволю себе немного ворваться в обсуждение. По прошлому опыту, из наших систем, с точки зрения интеграции, более точной настройки и адекватной поддержки от вендора, имхо, решения от Positive Technologies одни из самых удобных и функциональных. На момент когда работали с ними, параллельно внедряли решения от Check Point и Fortinet, было с чем сравнивать. Но тогда не хватало фичей, по сравнению с зарубежными аналогами
Немного не хватает подробностей основной задачи, которая решается этим железом и описания модулей. Не все знают что и для чего NRF. А так почему бы и нет, кому-то эта статья точно пригодится. В любом случае это лучше, чем переведенные нечитабельные статьи без указания оригинала, которые частенько попадаются на Хабре.
Простите, но проще читать оригинал статьи, нежели машинный перевод без редактуры. Слишком много этого последнее время на Хабре стало
Позволю себе ворваться, т.к. вижу комментарии на тему китайских аналогов, зачем нужна такая если есть мембранки и прочее.
Несколько лет (минимум 4) пользуюсь механикой Keychron K2 с тихими свичами. Металлическая рама - реально решает в плане прочности и устойчивости, все живое до сих пор, стоит уверенно и не сдвигается от порыва ветра или пинка по столу как дешёвые пластиковые варианты. Плата там тоже отличная, никаких косяков по части прошивки, даже пользуюсь фичами с запоминанием устройств, к которым подключается клавиатура. Наличие понимания ОС девайса тоже штука полезная. По беспроводу соединение стабильное. Батарею держит очень хорошо, даже не могу вспомнить насколько часто ее заряжаю.
Китайские аналоги есть - проживут они точно меньше.
В плане дизайна - на вкус и цвет у всех фломастеры будут разные, тут цепляться вообще нет смысла. А если глянуть на "моду", то там как раз возвращаются к старой классике
Разрекламированные игровые и "профессиональные" варианты других брендов будут дороже, а качество такое же.
Так что в целом - Keychron сейчас близко к золотой середине в плане цена-качество-функционал