Дошла до раздела поиска работы… не было желания его изучать. Во всей информации, представленной до него, в целом — согласна. Читаешь и узнаешь себя много лет назад))) В целом процесс описан верный. Кодить можно научиться, но без базового понимания алгоритмов, как минимум — качество у новичков страдает.
При скитании по сети можно найти тонну информации, ты ее начинаешь перебирать, кушать дикими порциями, потом понимаешь, что что-то пошло не так…
Имея опыт самостоятельного изучения и с наставником могу посоветовать следующее:
1) начать изучение со строго типизированного языка — это упростит ваш переход на любой язык в дальнейшем;
2) изучить базовые алгоритмы, структуры и паттерны на мелких задачках, сугубо для понимания как это все работает (необязательно, что вы будете себя чувствовать, как рыба в воде на первых парах);
3) попробовать перевести эти мелкие задачки в реальную практику, пусть и выдуманного вами проекта.
Если следовать несколько другой схеме, то может получиться, так называемый — программист одного фреймворка)))
Пишите код, читайте профильные форумы и сообщества, задавайте свои вопросы — программисты действительно любят делиться знаниями, но все это делают по разному, так что не пугайтесь)))
Трудитесь, верьте в себя и все у вас обязательно получится!
Ну, если вы имеете ввиду такие методологии, как, например, agile и т.п., то no comment…
Но согласитесь, крайне не приятная ситуация, когда на поздних стадиях разработки вам говорят — ребят, давайте переделаем)))
Исходя из этого я очень часто стараюсь как можно более детально провести декомпозицию системы на компоненты и подсистемы… иначе можно очень круто встрять)))
Ну и вспомним анекдот про сферического коня в вакууме, конечно)))
Мой идеальный вариант иметь сначала ТЗ на проектирование с описанием функциональных требований. Пусть даже это будет только создание основной концепции. И только после этого разработка.
Хотя сегодняшние реалии таковы, что если это типовой проект, то решение чаще всего уже имеется в том или ином виде.
Все зависит от сегмента с которым работает конкретный участник процесса
Работать без ТЗ в наше время не приемлимо ни для разработчик(а/ов), ни для заказчика. Так называемая, правильная постановка задачи — должна быть описана в ТЗ)))
Перечитав несколько комментариев, пожалуй, отвечу здесь. Господа, под техническим писателем в данном контексте понимается "специально обученный человек", который с большей долей вероятности может вполне являться и разработчиком.
К проектной документации относится информация, начиная с технического задания, заканчивая описанием функциональной части проекта, которые служат инструкцией для пользователя.
К проектной документации относится собственно и само проектирование. Можете ознакомиться с технологией UML, почитать что такое ERD, IDEF, Use Case и т.п. диаграммы. Для разработки проекта большой командой — необходимо придерживаться некоторых стандартов. Представления документации, созданной в рамках проектирования системы в представленном на диаграммах, формализованном виде — позволяет облегчить жизнь разработчикам, пользователям, заказчикам и т.п.
Если я не ошибаюсь, то для тендерных проектов сначала создается проектная документация, на которую тоже может быть, кстати, выставлен тендер. Затем, на основании проектной документации выставляется требование на разработку.
Смысл в том, что здесь большая часть работы относится именно к проектированию систем и подготовке сопроводительной документации. В зависимости от того для каких целей создается документация.
Относительно проектирования системы и кому-то не ясных ТЗ могу сказать следующее.
Данная документация позволяет обосновать решения разработчиков при неоднозначности формулировок в ТЗ. Позволяет тестировщикам отличать баги от фич и т.п.
На самом деле об этом можно говорить бесконечно...
Это компетенция технически подкованного специалиста. Документацию к проекту кому-то писать надо. В данном случае для этого выделена отдельная позиция, чтобы разгрузить разработчиков.
Дошла до раздела поиска работы… не было желания его изучать. Во всей информации, представленной до него, в целом — согласна. Читаешь и узнаешь себя много лет назад))) В целом процесс описан верный. Кодить можно научиться, но без базового понимания алгоритмов, как минимум — качество у новичков страдает.
При скитании по сети можно найти тонну информации, ты ее начинаешь перебирать, кушать дикими порциями, потом понимаешь, что что-то пошло не так…
Имея опыт самостоятельного изучения и с наставником могу посоветовать следующее:
1) начать изучение со строго типизированного языка — это упростит ваш переход на любой язык в дальнейшем;
2) изучить базовые алгоритмы, структуры и паттерны на мелких задачках, сугубо для понимания как это все работает (необязательно, что вы будете себя чувствовать, как рыба в воде на первых парах);
3) попробовать перевести эти мелкие задачки в реальную практику, пусть и выдуманного вами проекта.
Если следовать несколько другой схеме, то может получиться, так называемый — программист одного фреймворка)))
Пишите код, читайте профильные форумы и сообщества, задавайте свои вопросы — программисты действительно любят делиться знаниями, но все это делают по разному, так что не пугайтесь)))
Трудитесь, верьте в себя и все у вас обязательно получится!
Ну, если вы имеете ввиду такие методологии, как, например, agile и т.п., то no comment…
Но согласитесь, крайне не приятная ситуация, когда на поздних стадиях разработки вам говорят — ребят, давайте переделаем)))
Исходя из этого я очень часто стараюсь как можно более детально провести декомпозицию системы на компоненты и подсистемы… иначе можно очень круто встрять)))
Ну и вспомним анекдот про сферического коня в вакууме, конечно)))
Мой идеальный вариант иметь сначала ТЗ на проектирование с описанием функциональных требований. Пусть даже это будет только создание основной концепции. И только после этого разработка.
Хотя сегодняшние реалии таковы, что если это типовой проект, то решение чаще всего уже имеется в том или ином виде.
Все зависит от сегмента с которым работает конкретный участник процесса
Работать без ТЗ в наше время не приемлимо ни для разработчик(а/ов), ни для заказчика. Так называемая, правильная постановка задачи — должна быть описана в ТЗ)))
Перечитав несколько комментариев, пожалуй, отвечу здесь. Господа, под техническим писателем в данном контексте понимается "специально обученный человек", который с большей долей вероятности может вполне являться и разработчиком.
К проектной документации относится информация, начиная с технического задания, заканчивая описанием функциональной части проекта, которые служат инструкцией для пользователя.
К проектной документации относится собственно и само проектирование. Можете ознакомиться с технологией UML, почитать что такое ERD, IDEF, Use Case и т.п. диаграммы. Для разработки проекта большой командой — необходимо придерживаться некоторых стандартов. Представления документации, созданной в рамках проектирования системы в представленном на диаграммах, формализованном виде — позволяет облегчить жизнь разработчикам, пользователям, заказчикам и т.п.
Если я не ошибаюсь, то для тендерных проектов сначала создается проектная документация, на которую тоже может быть, кстати, выставлен тендер. Затем, на основании проектной документации выставляется требование на разработку.
Смысл в том, что здесь большая часть работы относится именно к проектированию систем и подготовке сопроводительной документации. В зависимости от того для каких целей создается документация.
Относительно проектирования системы и кому-то не ясных ТЗ могу сказать следующее.
Данная документация позволяет обосновать решения разработчиков при неоднозначности формулировок в ТЗ. Позволяет тестировщикам отличать баги от фич и т.п.
На самом деле об этом можно говорить бесконечно...
Это компетенция технически подкованного специалиста. Документацию к проекту кому-то писать надо. В данном случае для этого выделена отдельная позиция, чтобы разгрузить разработчиков.