Те, кто пишет "добавить новое поле на страницу формы" понимают сущность проектирования и его єтапы еще меньше тебя. Если ты пишешь для них, то объясняй им как это плохо. Но нечего говорить, что ТЗ не нужно.
Извини за поздний комментарий. Но только сейчас статья попала на глаза. Нулевым мифом нужно считать термин "архитектура" в любом контексте, кроме архитектуры (в строительстве). По большому счету под архитектурой понимают структуру. И введение нового термина (красивого) не добавляет ничего к пониманию систем. Но путаницу вводит.
Мой первый начальник любил повторять "Что бы показать абсурдность идеи ее нужно довести до абсурда". Наиболее хорошо и, главное кратко, это реализовано в притчах, анекдотах, афоризмах. В этом контексте вспоминается старая притча.
Приходит к барину Ванька и говорит: "Барин я пашу как лошадь, а ты повышаешь жалованье Иван Ивановичу". В это время слышно за окном звон колокольчиков. Барин спрашивает:
Что это Ваня?
Сейчас сбегаю узнаю.
Прибегает и сообщает
Это какраван идет.
А что продают?
Сейчас сбегаю узнаю.
.....
А тут приходит Иван Иванович и говорит: "Барин там караван. Продают специи по рублю за пуд. Я договорился взять все оптом по 80 коп. И с окресными хозяевами договорился что купят по 2 рубля. У тебя будет навар 500 рублей"
Так и в больинстве случаев. Не повышают потому, что ты Ванька, а не Иван Иванович.
Кроме того, если ты нормальный разработчик, то за пять лет дорастешь до синьора. Дальше зарплата у тебя не будет повышаться. Нужно либо идти в архитекторы, либо в руководители. И то, и другое мало кому подходит. Не хватает способностей. И их не приобретешь - не дано. Я знаю большое количество отличных специалистов. И что бы повысить ему зарплату назначали руководителем. И он все портил. никакой с него руководитель, но отличный разработчик. Поэтому и не повышают.
Один знакомый директор оборонного предприятия как то сказал одному из начальников цеха: "Если ты делаешь работу своего подчиненного, то один из вас не нужен". Наверное это основное решение проблемы.
Полноее непонимание Waterfall. Эта модель нигде не применяется (разве, что по недопониманию). Сам Ройс, котрый и ввел данное понятие, говорил что она иллюстрация "как не надо делать" и указал, что она должна быть доработана до итеративной модели. И в этой концепции план это вторичное. На первом месте стоит разработка проекта вкотором и определяется "что и как мы будем делать". А потом уже при имеющемся утвержденном проекте формируется план его реализации. Относительно Agile . После постройки комнаты для козы решение сделать балкон реально возникнет проблема: комната не предназначена для пристройки балкона (не выдержит консольной нагрузки). Поэтому для постройки балкона нужно переделать комнату козы. А это затраты и сроки. Еше хуже с бассейном на крыше. Осел может захотеть бассейн по площади большей чем нижний этаж. Кроме того несущие стены и фундамент могут не выдержать такой нагрузки и обрушиться. Это снова затраты и время. И на средине проекта может прийти экономист и спроит "Ребята, а у вас деньги есть?" Поэтому Agile можно применять для простых проектов, в которых нужно постоянно показывать "прогресс"
Очень правильная цитата в одном из комментариев к этой статье "Много всякой фигни". Я скажу даже, что "Все одна фигня". Формализованные вопросы собеседования не позволят найти хорошего программиста.
Начнем с трех составляющих старшего инженера, которые автор выпытал у ChatGPT.
Методология разработки вообще никак не связана с СКРАМ. Скрам – это плохая практика управления для "небольшой команды", но ни как не методология проектирования. Автор мог бы спросить у ChatGPT или Википедии. Например, ChatGPT выдал такое определение: "Методология проектирования (или проектирования систем) - это набор принципов, подходов, практик и процессов, используемых для разработки и построения технических и информационных систем". Оно в целом коррелирует с определением в Вики. И скрама в определении нет.
Принципы проектирования программного обеспечения. Автор снова путается. Для него принципы проектирования сводятся к патернам. Вероятно, он сам не знает что такое принципы KISS, YAGNI, dry, SOLID и пр.
Языки программирования. Знание нескольких языков программирования (включая любимый автором статьи питон) не делает из человека программиста. В лучшем случае (в сочетании со знанием патернов) – кодера. Можно провести аналогию. Много людей умеют писать по русски (английски, французски, …), но большинство из них не может написать даже небольшой рассказ. Кстати, такие известные писатели и поэты как, Пушкин, Баратынский, Маяковский, Кэрролл, Хемингуэй, Кристи и много других были безграмотными и писали с ошибками.
Наверное, более правильно определять уровень программиста поговорив с ним о тех проектах, в разработке которых он принимал участие и какую роль выполнял в них. Таки образом можно будет определить уровень сложности проектов, которые кандидат сможет разрабатывать. А если посмотреть как изменялась его роль в проектах, то можно оценить его амбициозность.
Комментарий достаточно большой и не совсем по теме статьи. Это скорее набросок отдельнй статьи "Какие должны быть конструкторы, что бы мифы превратить в реальность".
И теперь мои комментарии к этой потенциальной статье.
1) Относительно "гибридных" конструкторов. Они уже имеют устоявшееся название "low code". Да, языки программирования они используют, как правило, уже существующие. Например, React Native, javascript и пр.
2) Относительно нового языка программирования. Из контекста статьи (комментария) понятно, что речь идет об алгоритмическом (императивном) язуке программирования. Все языки имеют пять групп операторов: описание данных (в т.ч. объектов); выражения; условные операторы; операторы циклов; функции (методы). И вообщем эти операторы написаны на "разговорном" языке, или очень близко к нему. Да, некоторые языки более компактные, емкие. Но компактность языка и его выразительность незначительно влияют на размер кода. В коде больше места занимают названия переменных. В принципе, изучение языка программирования не продолжительное. Значительно больше времени уходит на изучение библиотек.
3) Если говорить о перспективном языке, то, по моему, нужно создавать декларативный язык для разработки мобильных приложений. В котором просто для каждого экрана нужно указать "ЧТО" он должен делать. Как известно, "ЧТО" нужно делать определяет UX дизайнер. Поэтому нужно на основе этого зыка разработать графический редактор для UX дизайнера. И для каждой платформы написать свой компилятор. Таким образом будет обеспечена нативность, высокая скорость создания приложений и хорошее качество.
Совершенно верно. Особенно проявляется "программистская" основа в конструкторах у которых имеется работа со сценариями. В сценарии под кубиками закамуфлированы практически все конструкции алгоритмических языков
Предполагаю что под термином «система» ты подразумеваеш IDE Android Studio. Студия не создает класс MyApp. При создании нового проекта она создает только MainActivity. Поэтому, после создания нового проекта можеш смело создавать там класс MyApp. В принципе, название класса может быть любым. Нужно только, чтобы он наследовался от Application, в его методе onCreate иницировались классы MyParams и MyDeclareScreens (метод DeclareParam.build) и что бы он был описан в манифесте (в секции application атрибут android:name=".MyApp")
85-90% не совсем призрачны. Эти цифры получены при разработке реальных коммерческих приложений. И они показывают сколько функционала, в процентном отношении, приходится на кастомные элементы. Относительно «в 40-50 раз меньше кода» пару проектов разрабатывались, как по традиционной технологии, так и с применением библиотеки. После чего путем деления общего SLOC по первому и второму варианту.
Библиотека позволяет: подключать кастомные активити и фрагменты, в том числе и с компонентами библиотеки, подключать кастомный код к описанию экранов. Также имеется возможность разрабатывать кастомные компоненты и подключать их проекту с возможностью использования этих компонентов в следующих проектах.
У них разные предназначения. Такие инструменты как Litho, Flutter, Jetpack Compose предназначены для декларативного описания интерфейса UI (ресурсов, XML файлов). Логика пишется на императивном языке программирования, например: Java, Kotlin. DePro ориентировано на программирование именно логики. В статье указано, что ресурсы формируются обычным способом.
Недостатки следуют из полюсов. Недавно делал доклад о библиотеке в одной из компаний. В конце обсуждений один из программистов задал вопрос: «А что мы, программисты, будем делать?». Он увидел минус в том, что при переходе на работу с библиотекой его могут сократить.
Ну а по серьезному, сечас библиотека покрывает порядка 85-90% распространенного функционала. Нужно довести этот показатель до 99%
Супер. Я еще бы к твоим методам добавил - Активно используйте ИИ. Его текст будет настолько красив насколько и бессмысленный"
Те, кто пишет "добавить новое поле на страницу формы" понимают сущность проектирования и его єтапы еще меньше тебя. Если ты пишешь для них, то объясняй им как это плохо. Но нечего говорить, что ТЗ не нужно.
Ты просто не поняла то, что критикуешь.
Извини за поздний комментарий. Но только сейчас статья попала на глаза. Нулевым мифом нужно считать термин "архитектура" в любом контексте, кроме архитектуры (в строительстве). По большому счету под архитектурой понимают структуру. И введение нового термина (красивого) не добавляет ничего к пониманию систем. Но путаницу вводит.
Мой первый начальник любил повторять "Что бы показать абсурдность идеи ее нужно довести до абсурда". Наиболее хорошо и, главное кратко, это реализовано в притчах, анекдотах, афоризмах. В этом контексте вспоминается старая притча.
Приходит к барину Ванька и говорит: "Барин я пашу как лошадь, а ты повышаешь жалованье Иван Ивановичу". В это время слышно за окном звон колокольчиков. Барин спрашивает:
Что это Ваня?
Сейчас сбегаю узнаю.
Прибегает и сообщает
Это какраван идет.
А что продают?
Сейчас сбегаю узнаю.
.....
А тут приходит Иван Иванович и говорит: "Барин там караван. Продают специи по рублю за пуд. Я договорился взять все оптом по 80 коп. И с окресными хозяевами договорился что купят по 2 рубля. У тебя будет навар 500 рублей"
Так и в больинстве случаев. Не повышают потому, что ты Ванька, а не Иван Иванович.
Кроме того, если ты нормальный разработчик, то за пять лет дорастешь до синьора. Дальше зарплата у тебя не будет повышаться. Нужно либо идти в архитекторы, либо в руководители. И то, и другое мало кому подходит. Не хватает способностей. И их не приобретешь - не дано. Я знаю большое количество отличных специалистов. И что бы повысить ему зарплату назначали руководителем. И он все портил. никакой с него руководитель, но отличный разработчик. Поэтому и не повышают.
Один знакомый директор оборонного предприятия как то сказал одному из начальников цеха: "Если ты делаешь работу своего подчиненного, то один из вас не нужен". Наверное это основное решение проблемы.
Полноее непонимание Waterfall. Эта модель нигде не применяется (разве, что по недопониманию). Сам Ройс, котрый и ввел данное понятие, говорил что она иллюстрация "как не надо делать" и указал, что она должна быть доработана до итеративной модели. И в этой концепции план это вторичное. На первом месте стоит разработка проекта вкотором и определяется "что и как мы будем делать". А потом уже при имеющемся утвержденном проекте формируется план его реализации. Относительно Agile . После постройки комнаты для козы решение сделать балкон реально возникнет проблема: комната не предназначена для пристройки балкона (не выдержит консольной нагрузки). Поэтому для постройки балкона нужно переделать комнату козы. А это затраты и сроки. Еше хуже с бассейном на крыше. Осел может захотеть бассейн по площади большей чем нижний этаж. Кроме того несущие стены и фундамент могут не выдержать такой нагрузки и обрушиться. Это снова затраты и время. И на средине проекта может прийти экономист и спроит "Ребята, а у вас деньги есть?" Поэтому Agile можно применять для простых проектов, в которых нужно постоянно показывать "прогресс"
Для правдоподобности автору не плохо було посмотреть определение модели, хотя бы в Википедии. А потом, возможно, и статья была бы другая
Если будет интересно, то лучше пообщаться в телеграм @idedepro
https://youtu.be/51JklUB-21Q
Очень правильная цитата в одном из комментариев к этой статье "Много всякой фигни". Я скажу даже, что "Все одна фигня". Формализованные вопросы собеседования не позволят найти хорошего программиста.
Начнем с трех составляющих старшего инженера, которые автор выпытал у ChatGPT.
Методология разработки вообще никак не связана с СКРАМ. Скрам – это плохая практика управления для "небольшой команды", но ни как не методология проектирования. Автор мог бы спросить у ChatGPT или Википедии. Например, ChatGPT выдал такое определение: "Методология проектирования (или проектирования систем) - это набор принципов, подходов, практик и процессов, используемых для разработки и построения технических и информационных систем". Оно в целом коррелирует с определением в Вики. И скрама в определении нет.
Принципы проектирования программного обеспечения. Автор снова путается. Для него принципы проектирования сводятся к патернам. Вероятно, он сам не знает что такое принципы KISS, YAGNI, dry, SOLID и пр.
Языки программирования. Знание нескольких языков программирования (включая любимый автором статьи питон) не делает из человека программиста. В лучшем случае (в сочетании со знанием патернов) – кодера. Можно провести аналогию. Много людей умеют писать по русски (английски, французски, …), но большинство из них не может написать даже небольшой рассказ. Кстати, такие известные писатели и поэты как, Пушкин, Баратынский, Маяковский, Кэрролл, Хемингуэй, Кристи и много других были безграмотными и писали с ошибками.
Наверное, более правильно определять уровень программиста поговорив с ним о тех проектах, в разработке которых он принимал участие и какую роль выполнял в них. Таки образом можно будет определить уровень сложности проектов, которые кандидат сможет разрабатывать. А если посмотреть как изменялась его роль в проектах, то можно оценить его амбициозность.
И еще раз. Статья плохая.
Комментарий достаточно большой и не совсем по теме статьи. Это скорее набросок отдельнй статьи "Какие должны быть конструкторы, что бы мифы превратить в реальность".
И теперь мои комментарии к этой потенциальной статье.
1) Относительно "гибридных" конструкторов. Они уже имеют устоявшееся название "low code". Да, языки программирования они используют, как правило, уже существующие. Например, React Native, javascript и пр.
2) Относительно нового языка программирования. Из контекста статьи (комментария) понятно, что речь идет об алгоритмическом (императивном) язуке программирования. Все языки имеют пять групп операторов: описание данных (в т.ч. объектов); выражения; условные операторы; операторы циклов; функции (методы). И вообщем эти операторы написаны на "разговорном" языке, или очень близко к нему. Да, некоторые языки более компактные, емкие. Но компактность языка и его выразительность незначительно влияют на размер кода. В коде больше места занимают названия переменных. В принципе, изучение языка программирования не продолжительное. Значительно больше времени уходит на изучение библиотек.
3) Если говорить о перспективном языке, то, по моему, нужно создавать декларативный язык для разработки мобильных приложений. В котором просто для каждого экрана нужно указать "ЧТО" он должен делать. Как известно, "ЧТО" нужно делать определяет UX дизайнер. Поэтому нужно на основе этого зыка разработать графический редактор для UX дизайнера. И для каждой платформы написать свой компилятор. Таким образом будет обеспечена нативность, высокая скорость создания приложений и хорошее качество.
Не совсем понятен вопрос. Какой "инструмент", какую "задачу" и какие "проблемы"?
Совершенно верно. Особенно проявляется "программистская" основа в конструкторах у которых имеется работа со сценариями. В сценарии под кубиками закамуфлированы практически все конструкции алгоритмических языков
Библиотека позволяет: подключать кастомные активити и фрагменты, в том числе и с компонентами библиотеки, подключать кастомный код к описанию экранов. Также имеется возможность разрабатывать кастомные компоненты и подключать их проекту с возможностью использования этих компонентов в следующих проектах.
Ну а по серьезному, сечас библиотека покрывает порядка 85-90% распространенного функционала. Нужно довести этот показатель до 99%