Тут ведь нет ничего нового, все та же дилема как писать меньше кода и получить меньше ошибок в рантайме. Хорошо бы свалить все на компилятор, чтобы ошибок в принципе не возникало- добро пожаловать в Haskell, с его "маниакальной" строгой типизацией. Для языков с динамической типизацией тоже есть свои библиотеки описания и проверки типов. И если надоело, что код то и дело падает в рантайме, то без строгого контроля за типами данных не обойтись. Только ведь вот какое дело, работы это только добавит. Тут все как в поговорке: "семь раз отмерь ....".
Приобретение знания самостоятельно - один скил (Самоучка). Умение решать несвойственные и неинтересные задачи - другой (Вуз с его системой дисциплин). А дальше вопрос, насколько вы углубляетесь в свою стезю и сколько вам приходится заниматся тем, что не интересно. И еще. Вузовское образование принудительно расширяет кругозор, закладывая основы. Самоучка выбирает и исследует то что интересно. И у того и у другого есть пробелы в областях компетенций, в которые они не полезут за поиском решения, так как даже не подозревают о такой возможности. Хорошо если есть тот кто может охватить необъятное и указать конкурирующие варианты решения. Резюме. Как бы вы не учились отдуваться руководителю проекта :)
Мне кажется, подвох здесь кроется в том, что означает - быть программистом. Должен ли аналитик собственноручно писать программы, и оттачивать нюансы использования библиотек? На мой взгляд - нет. Безусловно, аналитик должен хорошо знать очень много вещей, но не так глубоко как программист. Хорошие программисты, специалисты своего дела - постоянно углубляют свои знания в выбранной области специализации, в то время как от аналитика, требуется не столько глубина, сколько широта знаний. Хороший аналитик ценен тем, что способен находить решения на стыке множества областей и технологий. И недостаток знаний специфики той или иной области компенсируется умением получать нужную информацию, в том числе и у тех кто лучше всего в этом разбирается. Но для того чтобы понимать, что отвечают специалисты, аналитик должен погружаться в каждую исследуемую область. Здорово если аналитик вырастает из программиста, но очень плохо, если аналитик тянет в свою работу наработанные подходы и продолжает следовать им не пытаясь выйти из колеи. Ну и из личного опыта, колоссальный рост для аналитика и архитектора дает изучение парадигмы функционального программирования. Сама идеология фп заставляет в первую очередь думать над функциями верхнего уровня и обеспечивающими их структурами данных, не отвлекаясь на нюансы конкретных реализаций. Фактически фп заставляет самостоятельно формировать язык описания предметной области в терминах которого решается задача. Это сильно способствует развитию аналитического восприятия задачи. И вовсе не обязательно реализовывать проект на фп. Ведь аналитик не пишет программы, его задача максимально подробно формировать для пользователя и разработчика непротиворечивую модель предметной области.
Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений. Если же, рассматривать реальное программирование от данных, как например это происходит в языках функционального программирования типа Haskell, то описанные в статье ситуации не возникают, так как еще этапе проектирования досконально выясняются все особенности данных с которыми предстоит оперировать. Собственно говоря, только опираясь на глубокий анализ данных с которыми предстоит работать программе можно определить подходящее архитектурное решение.
Тут ведь нет ничего нового, все та же дилема как писать меньше кода и получить меньше ошибок в рантайме. Хорошо бы свалить все на компилятор, чтобы ошибок в принципе не возникало- добро пожаловать в Haskell, с его "маниакальной" строгой типизацией. Для языков с динамической типизацией тоже есть свои библиотеки описания и проверки типов. И если надоело, что код то и дело падает в рантайме, то без строгого контроля за типами данных не обойтись. Только ведь вот какое дело, работы это только добавит. Тут все как в поговорке: "семь раз отмерь ....".
Приобретение знания самостоятельно - один скил (Самоучка). Умение решать несвойственные и неинтересные задачи - другой (Вуз с его системой дисциплин). А дальше вопрос, насколько вы углубляетесь в свою стезю и сколько вам приходится заниматся тем, что не интересно. И еще. Вузовское образование принудительно расширяет кругозор, закладывая основы. Самоучка выбирает и исследует то что интересно. И у того и у другого есть пробелы в областях компетенций, в которые они не полезут за поиском решения, так как даже не подозревают о такой возможности. Хорошо если есть тот кто может охватить необъятное и указать конкурирующие варианты решения. Резюме. Как бы вы не учились отдуваться руководителю проекта :)
Мне кажется, подвох здесь кроется в том, что означает - быть программистом. Должен ли аналитик собственноручно писать программы, и оттачивать нюансы использования библиотек? На мой взгляд - нет. Безусловно, аналитик должен хорошо знать очень много вещей, но не так глубоко как программист. Хорошие программисты, специалисты своего дела - постоянно углубляют свои знания в выбранной области специализации, в то время как от аналитика, требуется не столько глубина, сколько широта знаний. Хороший аналитик ценен тем, что способен находить решения на стыке множества областей и технологий. И недостаток знаний специфики той или иной области компенсируется умением получать нужную информацию, в том числе и у тех кто лучше всего в этом разбирается. Но для того чтобы понимать, что отвечают специалисты, аналитик должен погружаться в каждую исследуемую область. Здорово если аналитик вырастает из программиста, но очень плохо, если аналитик тянет в свою работу наработанные подходы и продолжает следовать им не пытаясь выйти из колеи. Ну и из личного опыта, колоссальный рост для аналитика и архитектора дает изучение парадигмы функционального программирования. Сама идеология фп заставляет в первую очередь думать над функциями верхнего уровня и обеспечивающими их структурами данных, не отвлекаясь на нюансы конкретных реализаций. Фактически фп заставляет самостоятельно формировать язык описания предметной области в терминах которого решается задача. Это сильно способствует развитию аналитического восприятия задачи. И вовсе не обязательно реализовывать проект на фп. Ведь аналитик не пишет программы, его задача максимально подробно формировать для пользователя и разработчика непротиворечивую модель предметной области.
Не сталкивался с подобным использованием термина "программирование от данных". В статье описан классический сценарий, неполной постановки задачи, когда решается сиюминутная проблема без анализа последствий принятия конкретных архитектурных решений. Если же, рассматривать реальное программирование от данных, как например это происходит в языках функционального программирования типа Haskell, то описанные в статье ситуации не возникают, так как еще этапе проектирования досконально выясняются все особенности данных с которыми предстоит оперировать. Собственно говоря, только опираясь на глубокий анализ данных с которыми предстоит работать программе можно определить подходящее архитектурное решение.