потому что разработчики не пользуются им по прямому назначению, а заняты визуализацией музыкальных частот
Будем честны - в нормальных компаниях разработчики погружены в реализацию, а не генерацию идей, генерацию дизайна, генерацию и аналитику данных и так далее по списку чем разработчик может заниматься, но не так эффективно как его коллеги по цеху
Именно на таких горбах и ездит менеджмент бизнес. "Твой" продукт, "заплакавшийся ребенок" - если человек воспринимает код своего работодателя так и никак иначе, то где быть месту личности этого человека?
Вопрос не по основной теме статьи, но все же - почему jenkins, а не что то более "модное/современное" - teamcity, gitlab ci/cd, github actions and e.t.c?
P.S.: Если ответ "исторически сложилось" то лучше не отвечать)
Компании и грейды в них - это в большинстве своем уникальный набор параметров которые на самом деле почти бессмысленно сравнивать. Где то будет меньше требований по тех скиллам, где то больше по софтскилам и т.д. - почти все уникально и основано на историческом опыте руководства/людей которые имею полномочия и компетенцию натягивать любую сову на любой глобус. Приравнивать на себя, тем более не работая в компании кажется интересным, но бесполезным экспериментом)
Все бы ничего, однако, согласитесь, это не всегда работает. Я думаю нет смысла придираться к частностям, так как в других комментариях уже это сделали, но все же лично меня больше всего задел пункт, с котором я никак не могу согласиться — Не пишите неуязвимый код. Где та грань между НЕ неуязвимым кодом и говнокодом или же на скорую руку собранным дерьмом непонятного качества. Требуемого качества пересечения этой границы помогают достичь тесты, ревью коллег и некоторые другие инструменты и способы улучшения кода, но вот что делать тем кто работает один или совсем небольшими командами?
P.S. Как всегда не стоит забывать что все советы это конечно хорошо, но личный удачный/не_удачный опыт ничем не заменишь
Использование в RecyclerView.ViewHolder — это решение отсебятины вы ведь сами написали, в отличии от всего того что выше прямиком пришедшее из документации?
Позвольте добавить замечание в 1001 статью про даггер.
В плюсы наверное стоит добавить одно из его приемуществ перед другими фреймворками — компайлтайм есепшны. Вы упадете если что то не так в 95% случаев до того как все будет собрано.
В минусы так же стоит добавить рядом с кодогенерацией время. В крупных проектах это действительно становится проблемой
Почему бы подразумевать по умолчанию исправление некоторого техдолга/рефакторинг в стандартный план? Точно так же как и тесты, кодревью и все остальное?
Я понимаю, что не везде это возможно по тем или иным причинам, но на мой взгляд стремится к этому уже будет хорошо. Хотя бы для себя
Раскройте пожалуйста главную тему — какая разница между этим решением и старым-добрым горизонтальным recyclerview с кастомными viewgroup/обычными viewholder вместо fragment? Уже много лет разработчики решают эту проблему одинаково и достаточно просто, однако тут появляется «уникальное» решение от гугла, которое по сути ничего не решает, как мне показалось.
Согласен на все 100%. Когда я пользуюсь услугами мастера по ремонту велосипеда я обязательно прошу его показать его собственный, у любого более-менее состоявшегося веломеханика найдутся велосипед с душой отремонтированный и в идеальном состоянии, какие то лично придуманные инструменты и прочие наработки. Обычно даже у мастеров стажеров есть что показать.
Как бы это странно не звучало, но вот это все про «нам важны люди заинтересованные в продукте, а не деньгах» это либо самообман либо просто самопиар. Уровень зарплаты позволяет покупать мнение разработчиков и вынуждает их говорить что им интересен продукт, заставлять сидеть на ненужных и бесполезных, в большинстве своём, митингов/скрамингов/ретро и прочей эффективно-менеджерской ерунде. Это похвально, я не критикую, просто строить из себя «не таких как все» как минимум наивно и не красиво
И автор наконец то перестанет каждую наносекунду выпускать по новости посвященной этому продукту
Интересный и подробный разбор! Благодрю за проделанную работу, возможно она кому то сэкономит несколько человекодней.
Ждем продолжения.
Будем честны - в нормальных компаниях разработчики погружены в реализацию, а не генерацию идей, генерацию дизайна, генерацию и аналитику данных и так далее по списку чем разработчик может заниматься, но не так эффективно как его коллеги по цеху
Что ж - вы идеальный исполнитель - чем больше таких тем выгоднее бизнесу.
На ваш взгляд аналитики - не разработчики?
Именно на таких горбах и ездит менеджмент бизнес. "Твой" продукт, "заплакавшийся ребенок" - если человек воспринимает код своего работодателя так и никак иначе, то где быть месту личности этого человека?
Вопрос не по основной теме статьи, но все же - почему jenkins, а не что то более "модное/современное" - teamcity, gitlab ci/cd, github actions and e.t.c?
P.S.: Если ответ "исторически сложилось" то лучше не отвечать)
Компании и грейды в них - это в большинстве своем уникальный набор параметров которые на самом деле почти бессмысленно сравнивать. Где то будет меньше требований по тех скиллам, где то больше по софтскилам и т.д. - почти все уникально и основано на историческом опыте руководства/людей которые имею полномочия и компетенцию натягивать любую сову на любой глобус. Приравнивать на себя, тем более не работая в компании кажется интересным, но бесполезным экспериментом)
Надеюсь у вас не все решения так принимаются)
Готов поспорить что это компания с именем начинающееся на P, а заканчивающаяся на ostuf
Кажется я начинаю понимать зачем Ситимобил спрашивает про все уровни osi.
Все бы ничего, однако, согласитесь, это не всегда работает. Я думаю нет смысла придираться к частностям, так как в других комментариях уже это сделали, но все же лично меня больше всего задел пункт, с котором я никак не могу согласиться — Не пишите неуязвимый код. Где та грань между НЕ неуязвимым кодом и говнокодом или же на скорую руку собранным дерьмом непонятного качества. Требуемого качества пересечения этой границы помогают достичь тесты, ревью коллег и некоторые другие инструменты и способы улучшения кода, но вот что делать тем кто работает один или совсем небольшими командами?
P.S. Как всегда не стоит забывать что все советы это конечно хорошо, но личный удачный/не_удачный опыт ничем не заменишь
Использование в RecyclerView.ViewHolder— это решение отсебятины вы ведь сами написали, в отличии от всего того что выше прямиком пришедшее из документации?UPD: добавьте тег перевод, пожалуйста
Позвольте добавить замечание в 1001 статью про даггер.
В плюсы наверное стоит добавить одно из его приемуществ перед другими фреймворками — компайлтайм есепшны. Вы упадете если что то не так в 95% случаев до того как все будет собрано.
В минусы так же стоит добавить рядом с кодогенерацией время. В крупных проектах это действительно становится проблемой
На ваш взгляд у спортинвентаря из декатлона приемлемое качество, и это я не только о велосипедах?
Имхо — для начинающих попробовать
- Но в то же время и не «ашанбайк»Простите, но все таки ашанбайк
Я понимаю, что не везде это возможно по тем или иным причинам, но на мой взгляд стремится к этому уже будет хорошо. Хотя бы для себя