Разработчик программ это кто – «Кем работать в сфере разработки компьютерных игр, если языки программирования — не моё?» – Яндекс.Знатоки — Вебджем.рф

Содержание

Кто такие разработчики? Сложно ли быть разработчиком?

Обновление раздела “Мастерская”

Совсем недавно в социальных сетях мы опубликовали инсайд обновленного раздела “Мастерская”.

Что же изменилось? Разумеется, внешний вид 🙂 Теперь вы можете увидеть сроки релиза скриптового решения, на каком языке будет он написан, примерную стоимость, а также узнать, посмотрев на график и информативную табличку, на каком этапе находится разработка.

И это всё? На сегодня да. Но далее у нас планируется следующее: внедрение корзины на сайте, переработка рейтинга скриптов (будет оценка только после покупки и возможность оставить отзыв), адаптация под мобильные телефоны/планшеты и несколько изменений в дизайне. Следите за нами в социальных сетях: «ВКонтакте», Facebook и Twitter, чтобы быть в курсе всех новостей!

У вас есть замечания или пожелания по удобству сайта? Пишите! Мы обязательно прислушаемся к вашему мнению.

Кроме этого, на сегодняшний день уже пять скриптов, предложенных на форуме, были разработаны и выданы авторам этих идей бесплатно! Кстати, сейчас уже четыре идеи, предложенных на форуме, находятся в разработке, это: VIP объявления, смена логина пользователем, ссылка на источник замечания, имиджборд на основе форума, и как только скрипт будет опубликован в нашем магазине, он будет предоставлен автору идеи абсолютно бесплатно!

Не оставайтесь в стороне и получите скрипт, о котором мечтаете, просто предложив свою идею в специальной теме: http://u.to/YKq-Cw.

Кто такие разработчики?

Может это герои, которые имеют суперспобности, кто же они? Безусловно, отчасти так и есть 🙂 Но если ответить без фанатизма, разработчик

(анг. developer) – это тот же человек, который имеет специальное образование.

Разработчики есть в разных сферах – одни занимаются созданием аппаратуры и механизмов, другие разрабатывают программное обеспечение, веб-сайты, схемы. Если бы не было этих умельцев, которые с точки зрения обычного пользователя творят чудеса, вы бы банально не смогли прочитать этот или любой другой текст в сети в силу отсутствия площадки. При наличии знаний и навыков разработчик способен реализовать практически любой проект от замысла до реализации.

По своей профессии его можно сравнить с писателем, ведь он составляет алгоритмы, но только на языках программирования, делая из них программы, доступные и понятные пользователю. Если не будет их – не будет развития новых технологий, остановится разработка современных веб-сайтов, скриптов, дополнений и т.п. Грубо говоря, интернет и всё, что с ним связано, перестанут существовать или по крайней мере развиваться.

Резюмируя, заметим, что программирование скорее является размышлением, а не банальным набором странных циферок и буковок. В обычной жизни все люди также занимаются программированием, когда спят, гуляют или просто смотрят в окно, размышляя. Разработчик не может просто сесть за компьютер, написать несколько тысяч строк кода и после этого успешно реализовать их в веб-проекте. Примерно 80% времени разработчики просто думают – ходят или сидят. Они придумывают концепцию и то, как исправить её потенциальные недостатки, решают, как она должна работать в дальнейшем, и так далее. Размышления являются основой процесса, с их помощью разработчики могут устранить проблемы и писать код дальше.

Сложно быть разработчиком?

Бытует мнение, что работа у программистов несложная. Что там может быть сложного – сиди себе с умным видом, тыкай по клавишам и получай за это деньги. К сожалению, так думают только люди, которые далеки от сферы информационных технологий. На плечах разработчиков лежит тяжелая и ответственная работа. Прежде всего, это умственный труд, который намного сложнее физического. Каждый программист должен иметь знания в области технологий разработки программного обеспечения, иметь аналитический склад ума и уметь мыслить абстрактно.

Чем занимаются разработчики?

Целью разработчика является создание программного обеспечения для автоматизации работы различных предприятий, обработки больших объёмов информации или решения каких-либо проблем, связанных с информационными технологиями.
Разработчики могут работать в больших корпорациях, маленьких компаниях или самостоятельно в качестве фрилансеров. Иногда разработчики-одиночки объединяются в группы для совместной работы над сложным проектом, если они не могут справиться самостоятельно или понимают, что это займет много времени.

Разработчики делятся на несколько категорий. Их можно классифицировать по сферам информационных технологий, в которых они работают. Каждому из них требуется знать конкретный язык программирования и набор инструментов для работы в своей области.

Например, веб-разработчик – это тот, кто создаёт веб-приложения и веб-сайты. Веб-разработчик участвует в таких процессах, как разработка веб-дизайна, вёрстка страниц, программирование сайтов или приложений на стороне клиента и сервера, конфигурирование веб-серверов.
Стоит отметить, что все перечисленные операции делает не один и тот же человек. Выполнением каждой задачи занимаются разные люди – специалисты в одной из сфер веб-разработки.

Если вкратце – фронт-энд и бэк-энд применяются параллельно следующим образом: посетитель от лица фронт-энд выполняет действия (нажатие на кнопку или пункта меню) и бэк-энд запускает выполнение той или иной функции в ответ.

Фронт-энд разработчик (анг. front-end developer) — занимается созданием интерфейса, внешнего вида сайта или веб-приложения, то есть визуальной частью.
Его задача состоит в том, чтобы сделать взаимодействие пользователя со страницей сайта настолько комфортным, насколько это возможно. Иными словами, он занимается работой над клиентской частью проекта – всем, что обрабатывается браузером со стороны пользователя.
Основными базовыми инструментами фронтенд-разработчика являются: HTML, CSS, JavaScript.
Чтобы облегчить рутинную работу, фронтенд-разработчики применяют различные вспомогательные инструменты, в составе которых могут быть: jQuery, LESS, Sass/SCSS, Bootstrap, Prototype, AngularJS, Ember.js, Backbone, React.js, Grunt Gulp и многое другое. И это далеко не исчерпывающий список того, что должен знать и с чем работает фронт-энд разработчик.

Бэк-энд разработчик (анг. back-end developer) — занимается обработкой пользовательской информацией, полученной из фронт-энда, и возвращает результат в тот же фронт-энд в понятной ему форме. Это означает, что бэкенд-разработчик работает с серверными технологиями.

Бэкэнд допускает взаимодействие пользователя с данными хранящимися на сервере через внешний интерфейс, но скрывает внутреннюю реализацию проекта, не допуская внешнего вмешательства в работу приложения. Если взять, к примеру, HTML/CSS и JavaScript, которые обрабатываются и работают на стороне клиента, то их содержимое может просмотреть любой пользователь. Всё что обрабатывается и работает на сервере не может быть доступно для просмотра. Пользователь видит лишь результат работы этого приложения.
Основным инструментами бэкенд-разработчика может являться любой серверный язык веб-программирования, это могут быть: PHP, Python, Ruby, Java, Perl и тому подобные.
В состав вспомогательных средств может входить огромное количество инструментов. Например, при работе с языком программирования PHP в ходе разработки могут понадобиться фреймворки Symfony, Codeigniter, Yii, Zend Framework, Kohana и другие. Для хранения данных применяется MySQL/SQLite, где используется язык структурированных запросов SQL.

Фулл-стак разработчики (анг. full stack developer) — это разработчики, которые работают одновременно с фронт-эндом и бэк-эндом. Такие специалисты хорошо знают как клиентские технологии, так и серверные.

Типы разработчиков

Гуру — это профессионал. Богатый опыт позволяет ему руководить целой командой разработчиков. Коллеги всегда консультируются с ним и спрашивают совета. Он быстро вникает в суть происходящих дел и способен сам решить абсолютно любую проблему без чьей-либо помощи. В безвыходной ситуации такой разработчик способен совершать невероятные вещи и выходить из сложных ситуаций. Это очень ценное сокровище. В средних и крупных компаниях он, как правило, занимает должность технического директора. Менеджеры и заказчики испытывают симпатию к таким разработчикам.

Теоретик — это хороший специалист, знающий о программировании всё. Он постоянно тратит время на свое обучение и учит других, как правильно программировать. Он может постоянно доказывать, что написанный другим программистом код далеко не оптимален. Очень часто теоретик, имея обширные теоретические знания, не очень хорошо показывает себя на практике.

Мистер рефракторинг — это любитель переписывать программный код. Он стремится сделать идеальным не только чужой код, но и свой. Ни один участок в коде не останется нетронутым! Такой разработчик считает, что нет предела совершенству. Поэтому часто он не успевает выполнить работу над проектом в срок, переписывая по сто раз один и тот же код, надеясь сделать его безупречным и идеальным.

Планктон — это, как правило, молодой или неопытный разработчик, который совершенно не имеет понятия, что он делает и что вообще происходит. Он очень нуждается в наставнике или помощи коллег. После его вмешательства обычно что-нибудь выходит из строя или ломается. Планктон полагается на бэкапы, когда понимает, что делает что-то не так. Когда совсем не понимает, что ему делать, ищет подсказки в Google или задает вопросы на специализированных форумах, надеясь, что ему помогут. Совершенно не хочет учиться или не имеет желания это делать.

Экспериментатор — это такой тип, для которого очень важно быть в курсе всех последних событий и новостей в мире IT-индустрии. Экспериментатор постоянно меняет средства и инструменты разработки. В очередном проекте он норовит использовать новые редакторы, фреймворки, библиотеки, о которых узнал совсем недавно. Большая часть его времени может уйти не на работу, а на эксперименты с новыми технологиями, которые, по его мнению, помогут улучшить процесс разработки.

Лапшакодер (спагеттикодер) — это разработчик, который очень быстро справляется с поставленной задачей, однако код его далек от совершенства. Лапшакодеры не любят комментировать и документировать свой программный код, из-за чего другим программистам бывает очень сложно или совсем невозможно разобраться в нем. Такой плохой код называют спагетти-кодом или лапшой. Обычно спагетти-код получается вследствие лени или неопытности разработчика, иногда из-за слишком сжатых сроков или прессинга со стороны менеджера. Лапшакодеру должны быть благодарны любители переписывать программный код 🙂

Процесс разработки

Любой программный продукт обладает такими качествами, как мобильность, надежность, эффективность, модифицируемость, коммуникативность и наличие человеческого фактора. Прежде чем приступить к разработке, происходит сбор информации, необходимой для разработки, а затем производится её анализ. После этого создается техническое задание на основании требований и задумки.

Следующим этапом является проектирование модели разрабатываемого приложения. Проектирование позволяет создать общий план или концепцию, используемую для разработки. Уже после проектирования разработчики приступают к самому интересному – к написанию кода. После разработки приложения происходит тестирование и поиск проблем, из-за которых скрипт работает некорректно или не так, как надо. Тестирование производят в несколько этапов. На каждом этапе тестируется отдельная задача. Полностью протестированное приложение может быть выпущено для использования в виде beta-версии до момента появления стабильной версии или полноценного продукта.

Если проект большой, то над ним обычно работает целая команда. Каждый специалист выполняет свою задачу, которая ему поставлена. Здесь очень важно умение работать в команде.

Таким образом, процесс разработки программы не такое легкое дело, каким может показаться на первый взгляд.

Мифы о разработчиках

создать квиз

Любая профессия со временем обрастает определенным количеством неубедительных мифов, которые становятся неотъемлемой частью профессии. Далеко не все из них являются правдивыми. Мы решили разрушить несколько наиболее распространенных мифов, касающихся разработчиков.

Миф #1. Программист-универсал.
Каждому программисту приходилось слышать: “ты же программист, почини мне…”. Большинство людей, кто далёк от темы информационных технологий, думают, что если ты программист, то ты способен исправить любую технику, в том числе не только компьютерную, написать любое программное обеспечение, короче говоря, сделать все, что связано с электроникой. Однако они не учитывают того, что, как и в любой другой профессии, программисты специализируются на чем-то конкретном. Например, не всякий веб-разработчик будет заниматься ремонтом аппаратного обеспечения компьютера. Универсальных программистов, которые специализируются на нескольких направлениях, мало и, как правило, это очень дорогие специалисты.

Миф #2. У разработчиков нет хобби.
Зачастую это действительно так. Работа для программиста является не только средством заработка, но и удовольствием.
Это тот редкий случай, когда работу и хобби можно совместить. Хотя даже программисты ходят в кино, катаются на велосипеде и даже занимаются бодибилдингом. 🙂

Миф #3. Разработчики неряшливый народ.
Отчасти это правда, однако это касается не только программистов. Поддерживать порядок удается далеко не каждому, но не все программисты неряшливы.

Миф #4. Небрежность во внешнем виде.
Это может показаться странным, но обычно разработчики действительно имеют специфичный внешний вид. Они крайне небрежно относятся к своему внешнему виду, могут отрастить волосы по плечи, быть небритыми, одеваться в старую и рваную одежду. Всё это объясняется отсутствием лишнего времени и сильной увлеченностью своей профессией.

Миф #5. Женщин разработчиков не бывает.
Факт остается фактом – по-настоящему профессиональных женщин-разработчиков нет. Можно встретить женщин-программистов, у которых очень развита внимательность и ответственность, но они уступают сильному полу по многим другим параметрам.

Миф #6. Профессиональный юмор.
Как ни старайся, но это правда. Профессиональный юмор разработчика может понять лишь разработчик.

Миф #7. Разработчики боятся женщин.
Очень часто слышно, что разработчики считают общение с противоположным полом ненужной тратой времени. Они просто не могут позволить себе такую роскошь из-за сильной увлеченности своей работой. А как же иначе? Ведь за время, потраченное с красивой девушкой, можно написать несколько тысяч строк кода! 🙂

Разработка программного обеспечения для начинающих

Разработка программного обеспечения интересна как программистам, так и тем, кто таковыми хочет стать. В статье затронуты концепции, необходимые для старта.

Статья разделена на 4 части. Обратите внимание, что важные слова или словосочетания, введенные в этой серии, выделены жирным шрифтом. В конце каждого из четырех разделов будет приведена короткая викторина, проверяющая знания и подробно объясняющая некоторые моменты.

Самый простой и точный вариант ответа: «Программирование – это акт инструктирования компьютеров для выполнения задач». Еще его называют разработкой или кодингом.

Итак, что такое компьютерная программа? ПО представляет собой последовательность инструкций, выполняемых ПК. Компьютер же – это любое устройство, способное обрабатывать код. Сюда относятся стационарные ПК, ноутбуки, планшеты, банкоматы, Raspberry Pi, серверы etc.

Разработка программного обеспечения и аналогия

Во-первых, примеры программирования есть даже в повседневной жизни. Вселенная довольно предсказуема: день и ночь, времена года, восход и закат. Люди проходят через такие этапы, как встреча нового дня, посещение школы, университета или работа. Мы получаем инструкции от начальников и учителей. Также существуют рецепты, следуя которым можно приготовить блюдо.

Во-вторых, каждый раз, когда мы используем девайсы, встроенный в них код уже работает в фоновом режиме. Перемещение курсора с одной части экрана в другую может показаться простой задачей, но на самом деле за данный процесс отвечает немало строк написанного кода. Акт, столь же простой, как ввод букв в Google Docs, приводит к тому, что код выполняется в фоновом режиме. Это нормальные повседневные процессы, свойственные всем IT-устройствам.

Компьютерные программы также являются кодом. Однако лучше не использовать слово «коды»: это непрофессионально.

Естественный язык компьютера

Машины пользуются своим собственным языком. Они не понимают русский, английский или испанский. Естественным языком электронного оборудования является двоичный код — 1 и 0. Он представляют собой два состояния: on (1), off (0).

Осваивайте языки программирования

Чтобы общаться с машинами, которые говорят на двоичном языке, мы осваиваем такие языки, которые максимально близки к нашему собственному, а именно – языки программирования. Они четко структурированы и должны быть тщательно изучены.

Существуют высокий и низкий уровни. Языки программирования высокого уровня находятся дальше от машинного, чем языки низкого уровня. Это «дальше» обычно называют абстракцией.

Компьютер нуждается в понимании нашего человеческого языка. Для этого понадобится переводчик.

Определение переводчиков

Исходный код относится к коду, написанному на выбранном языке программирования. Переводчики же несут ответственность за преобразование исходного кода в машинный язык (те самые единицы и нули). Мы можем ссылаться на двоичные файлы, такие как код объекта, программу или общепринятый сегодня термин – приложение.

Переводчики могут быть любыми:

интерпретаторы;
компиляторы;
гибриды интерпретаторов и компиляторов;
ассемблеры.

Интерпретаторы

Чтобы разработка программного обеспечения прошла успешно, нужно понимать, что языки могут интерпретироваться. В таком случае переводчик обрабатывает исходный код по строкам и в готовой программе (приложении) также запускает каждую строку. Это означает, что интерпретируемый исходный код запускается до тех пор, пока не встретит ошибку. Затем интерпретатор перестает сообщать о таких ошибках.

Python – хороший пример интерпретируемого языка программирования.

Компиляторы

Компиляторы работают по-разному. Они полностью конвертируют исходный код с помощью компиляции в двоичный файл. Затем выполняется двоичный код. Если в исходном варианте были ошибки, они обнаруживаются и помечаются во время компиляции. Это прерывает процесс генерации двоичного кода.

Интерпретаторы работают построчно и выполняют одну линию перед тем, как перейти к следующей. Компилятор же переводит все строки программы в файл (двоичный) и выполняет его целиком.

Помните определение компьютерной программы? Это последовательность инструкций для компьютера. Выполнение программы обычно называется процессом. Такие ПО используют определенные ресурсы в компьютерной системе или любом другом девайсе. К ресурсам относятся память, дисковое пространство и файловая система.

Мы используем слово «run» при выполнении компьютерной программы. Время, затрачиваемое на запуск, называется временем выполнения программы.

Обычно рассматриваются продукты, известные как приложения. Еще мы ассоциируем программы с платформами или средами, в которых они работают или для которых предназначены. Существуют веб-приложения, запускаемые в браузерах, есть мобильные ПО, работающие на смартфонах, а также настольные, такие как Evernote.

Интерпретируемый исходный код выполняется из исходного файла, скомпилированный – преобразовывается в двоичный файл. Затем этот файл выполняется. Скомпилированный код может завершиться неудачно во время выполнения даже после успешной компиляции.

Гибридные переводчики

Гибридный переводчик представляет собой комбинацию интерпретатора и компилятора. Популярным гибридным языком программирования является Java.

Разработка программного обеспечения на Java удобна. Сначала исходный код компилируется в промежуточный формат, известный как Bytecode. Затем Bytecode интерпретируется и выполняется с помощью виртуальной машины. Это позволяет гибридным переводчикам запускать байт-код в различных операционных системах, делать его кроссплатформенным.

Ассемблеры

Ассемблер также используется для перевода низкоуровневого языка Ассемблер в двоичный, но мы сосредоточимся на языках высокого уровня.

Хороший способ понять различия переводчиков – лично увидеть их работу. Просто загрузите необходимые и установите на компьютер.

Часто задаваемый вопрос

Вот вопрос, который обычно задают начинающие: «С какого языка начать?»

Существуют сотни ЯП. Они оцениваются по популярности, комьюнити, долгосрочной поддержке, педагогике и использованию. Они также могут быть оценены по техническим параметрам. Например, являются ли они функциональными, императивными, статическими, сильными или слабо типизированными.

Некоторые языки программирования предназначены исключительно для образовательных целей, а не для использования в бизнесе. Хороший пример – ЯП для детей. Также существуют мощные языки, которые легко настроить и изучить. Python – один из них. Обычно его и рекомендуют начинающим.

Если вы заинтересованы в более подробном изучении вопроса, вот несколько хороших исследований.

Когда вы захотите изучить новый язык, понадобится переводчик языка. Это программа, которая устанавливается и настраивается в компьютерной системе.

Рекомендуем начать осваивать работу с командной строкой (CLI). Подумайте о терминале как об альтернативе графическому интерфейсу (GUI). Работая с компьютером посредством GUI, вы зависите от визуальных представлений каталогов и всего, что делаете. Но при использовании CLI вы взаимодействуете с компьютером напрямую, с помощью терминала и специальных команд.

$_

В Windows встроенный терминал представляет собой командную строку. Для пользователей Mac и Linux по умолчанию установлен терминал Bash. Чтобы использовать его в Windows, установите Git Bash или PowerShell.

Двигаемся дальше

Приготовьтесь, ведь разработка программного обеспечения началась! Подготовимся к написанию первой строки кода. Для этого потребуется следующее:

Компьютерная система. Необязательно сложный или очень дорогой ПК. Подойдет просто компьютер, который хорошо работает.
Установка CLI. Вот хороший курс для начала работы.
Установка текстового редактора (например, Notepad++).
Понимание хотя бы одного языка программирования. Из статьи вы узнаете основные элементы, которые составляют фундамент большинства ЯП.

Резюмируя вышесказанное, мы изучили основы с введением в переводчики. Слово «исходный код» уже не странно для вас. Более подробно мы рассмотрим его дальше.

Викторина

Разработка программного обеспечения: какие основные инструменты нужны для начала?
Какую команду следует использовать для таких операций в Bash (CLI):

Проверить текущий каталог
Перейти в каталог с именем «bin» (bin находится в текущем каталоге)
Создать новый каталог под названием «lib»
Создать новый файл под названием «book.py»
Перечислить содержимое текущего каталога

Ответы на вопросы

Компьютер, текстовый редактор, оболочка (терминал) и компилятор / интерпретатор
Следует использовать такие команды:

Проверить текущий каталог: pwd
Перейти в каталог с именем «bin»: cd bin
Создать новый каталог под названием «lib»: mkdir lib
Создать новый файл под названием «book.py»: touch book.py
Перечислить содержимое текущего каталога: ls

Часть 2: Исходный код и его 11 составляющих

Разработка программного обеспечения — это… Что такое Разработка программного обеспечения?

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему. Таким образом начал обретать популярность термин Баг — ошибка программного обеспечения.

Разрабо́тка програ́ммного обеспе́чения (англ. software engineering, software development) — это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.

Сложность разработки ПО

Как и другие традиционные инженерные дисциплины, разработка программного обеспечения имеет дело с проблемами качества, стоимости и надёжности. Некоторые программы содержат миллионы строк исходного кода, которые, как ожидается, должны правильно исполняться в изменяющихся условиях. Сложность ПО сравнима со сложностью наиболее сложных из современных машин, таких как самолеты.

Разделы дисциплины

Разработка программного обеспечения может быть разделена на несколько разделов. Это:

Требования к программному обеспечению: извлечение, анализ, спецификация и ратификация требований для программного обеспечения.
Проектирование программного обеспечения: проектирование программного обеспечения средствами Автоматизированной Разработки Программного Обеспечения (CASE) и стандарты формата описаний, такие как Унифицированный Язык Моделирования (UML), использую различные подходы: проблемно-ориентированное проектирование и т.д..
Инженерия программного обеспечения: создание программного обеспечения с помощью языков программирования.
Тестирование программного обеспечения: поиск и исправление ошибок в программе.
Обслуживание программного обеспечения: программные системы часто имеют проблемы совместимости и переносимости, а также нуждаются в последующих модификациях в течение долгого времени после того, как закончена их первая версия. Подобласть имеет дело с этими проблемами.
Управление конфигурацией программного обеспечения: так как системы программного обеспечения очень сложны и модифицируются в процессе эксплуатации, их конфигурации должны управляться стандартизированным и структурированным методом.
Управление разработкой программного обеспечения: управление системами программного обеспечения имеет заимствования из управления проектами, но есть нюансы, не встречающиеся в других дисциплинах управления.
Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.
Инструменты разработки программного обеспечения, см. CASE: методика оценки сложности системы, выбора средств разработки и применения программной системы.
Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.
Локализация программного обеспечения, ветвь языковой промышленности.

Процесс и методология

Основная статья: Процесс разработки программного обеспечения

На протяжении нескольких десятилетий стоит задача поиска повторяемого, предсказуемого процесса или методологии, которая бы улучшила продуктивность, качество и надёжность разработки. Одни пытались систематизировать и формализовать этот, по-видимому, малопредсказуемый процесс. Другие применяли к нему методы управления проектами и методы программной инженерии. Третьи считали, что без постоянного контроля со стороны заказчика разработка ПО выходит из-под контроля, съедая лишнее время и средства.

Опыт управления разработкой программ отражается в соответствующих руководствах, обычаях и стандартах. Если при разработке используется несколько стандартов и нормативных документов, то имеет смысл составить профиль.

Информатика как научная дисциплина предлагает и использует на базе методов структурного программирования технологию надежной разработки программного обеспечения, используя тестирование программ и их верификацию на основе методов доказательного программирования для систематического анализа правильности алгоритмов и разработки программ без алгоритмических ошибок.

Данная методология направлена на решение задач на ЭВМ, аналогичной технологии разработки алгоритмов и программ, используемой на олимпиадах по программированию отечественными студентами и программистами с использованием тестирования и структурного псевдокода для документирования программ в корпорации IBM с 70-х годов.

Методология структурного проектирования программного обеспечения может использоваться с применением самых различных языков и средств программирования для разработки надёжных программ самого различного назначения. Одним из таких проектов была разработка бортового программного обеспечения для космического корабля «Буран», в котором впервые использовался бортовой компьютер для автоматического управления аппарата, совершившего успешный старт и посадку космического корабля.

При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки. Примером современной методологии проектирования может быть проблемно-ориентированное проектирование.

Участники процесса разработки ПО

Проблемы разработки ПО

Наиболее распространёнными проблемами, возникающими в процессе разработки ПО, считают:

Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.
Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить — следствием этого процесса является то, что этап проектирования сокращается.
Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объём выполненной и оставшейся работы.
Данная проблема возникает на этапе, когда проект, завершённый более чем наполовину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.
Недостаток трассировки.
Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени.
Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы.
Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств.
Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.
Недостаточная надёжность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. В этом направлении много работали Кнут, Дейкстра и Вирт. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках.
Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.
Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам.
Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

См. также

Ссылки

Литература

Иан Соммервилл Инженерия программного обеспечения = Software Engineering. — 6-е изд. — М.: «Вильямс», 2002. — С. 642. — ISBN 5-8459-0330-0

Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. — М.: «Диалектика», 2006. — С. 592. — ISBN 978-5-8459-1181-0

«Кем работать в сфере разработки компьютерных игр, если языки программирования — не моё?» – Яндекс.Знатоки

Профессий и специальностей в геймдеве — огромное множество и относятся они к самым различным сферам, так что если вам очень хочется участвовать в разработке игр, вы можете запросто выбрать профессию по душе.

Чтобы понять, какие именно бывают профессии в геймдеве кроме программирования, давайте рассмотрим компоненты, из которых состоит игра. Если представить их схематично, то получится вот такая схема:

На схеме области компонентов игры условно разделены на два класса. Внутренние — это то, из чего непосредственно состоит игра, те, без которых игрок она не может быть выполнена и без которых игрок не представляет себе игр. Внешние сферы — это компоненты которые как бы обслуживают игру. Иными словами. без них создание игры также не может обойтись, но это то, что появляется на определенном этапе разработки и пропадает, когда этот этап закончен, не оставляя за собой внутренние сферы.

Итак, теперь про все что есть на схеме поподробнее.

Внутренние сферы

1. Механика, или “во что играть”

Например, возможность драться с противниками и побеждать в битве — это механика. Возможность пригласить друга в игру и играть вместе с ним — это механика. Даже перетаскивание предмета в интерфейсе — это тоже механика.

Но чтобы было понятнее, давайте разберемся, что такое игровая механика?

Это термин, который обозначает английское “элемент геймплея”. По сути своей, игровые механики — это функционал игры, они также определяют правила, по которым протекает игровой процесс. Часть механики может быть очевидна игроку, а часть нет. Возьмем для примера игровые автоматы: когда игрок дергает за ручку, слоты начинают крутиться и ему выпадает определенный приз. Это очевидная игроку часть игровой механики. Но в тот момент, пока слоты крутятся, происходит проигрывание некоего алгоритма вычисления награды, выпадающих призовых и не призовых слотов, с учетом уже сделанных ранее спинов — это тоже час механики игры, которая игроку неизвестна. То же самое касается и простых игр. Скажем, игрок понимает, что если он нажмет левую кнопку мыши в игре “Ведьмак”, зафиксировав при этом Геральта на противнике, то он взмахнет мечом. При каких условиях меч заденет противника, какая именно анимация удара будет проигрывать в данный момент — это все неочевидная часть механики, которая, тем не менее, определяет функционал игры.

Профессии в сфере механики

Геймдизайнер

Это человек, который занимается разработкой концепции игры, пишет дизайн докуметацию, разрабатывает и описывает игровые механики, пишет задачи для программистов и художников, считает игровой баланс. Фактически, геймдизайнер не является безусловным лидером коллектива, но точно может считаться «цементом», скрепляющим все остальные отделы и игру в единое целое. Геймдизайнер — носитель разрабатываемой концепции и человек, который знает, что нужно целевой аудитории проекта.

Левел-дизайнер

Это человек, который занимается созданием игрового окружения. Естественно, кроме художественной ценности, создаваемое игровое окружение должно отвечать геймплейным целям. Например, на уровне шутеров аптечки и патроны должны быть разложены в строго определенных местах, а в match-3 — фишки должны стоять так, чтобы за требуемое количество ходов их было сложнее всего собрать. Левел-дизайн — это целое искусство: разложить предметы так, чтобы заставить игрока “исследовать”, идя словно по хлебным крошкам, удивлять, раздражать, радовать, ужасать — все это задача левел-дизайнера.

1) Создание уровней.

В случае с головоломками или платформерами, например, он создает непосредственно уровни с задачами для игрока, то есть, в специальном редакторе расставляет платформы и препятствия, раскладывает приманки и бонусы, или придумывает загадки.

2) Создание окружения.

Если мы говорим о более масштабных играх, левел-дизайнер так же в редакторе занимается сборкой игрового мира из уже готовых объектов. В больших компаниях, например, это может быть целая команда левел-дизайнеров, каждый из которых занимается своей частью работы: один — ландшафтом, второй — интерьерами, третий — градостроением.

2. Технология, или “как играть”

Этот пункт вы можете пропустить, потому что он как раз про программистов и программирование. Технология — это то, чего никогда не увидит игрок. Это, собственно, инструмент, с помощью которого сделана ваша игра. Это игровой движок, это сервер, это утилиты для работы с контентом игры, это строчки кода — это то, что собирает вместе все прочие элементы игры в одно целое и заставляет работать.

Профессии в сфере технологии

Программист архитектуры игры

Это основной программист, с которым приходится работать геймдизайнеру в рамках будничных задач. Это человек, который воплощает в жизнь записанные на бумаге игровые механики, то есть, занимается непосредственным программированием самой игры.

Специалисты в этой области есть самые разнообразные и как правило, каждый из них специализируется на одном-двух языках программирования.

Серверный программист

Есть игры, которые хранят данные прямо на устройстве, а есть игры, которые хранят данные на сервере. Сервер — это выделенный компьютер, которые производит свои вычисления и операции, а также хранит данные пользователя. Например, если вы скачали из Google Play шахматы, где вы играете с искусственным интеллектом, то для такой игры сервер не нужен. Все данные о ваших ходах хранятся на устройстве. Поэтому в такую игру даже можно играть без интернета — передавать данные никуда не нужно. А вот если вы скачали шахматы, где нужно играть с другими игроками, или в этой игре есть какие-то лидерборды, которые учитывают количество выигранных и проигранных партий, то для такой игры уже понадобится сервер, чтобы хранить данные игроков: забирать ход одного игрока и передавать его другому, хранить данные для составления лидербордов.

Именно написанием инфраструктуры для сервера занимается серверный программист.

UI программист

UI расшифровывается как User Interfaсe, то есть, пользовательский интерфейс. Все окна, всплывающие подсказки и маленькие окошечки, кнопочки и галочки — это интерфейсы и элементы интерфейса. Интерфейс — это целая огромная область, которая стоит немного особняком от архитектуры игры. В каждом окне есть своя логика: куда можно нажать и к чему это приведет, можно ли перетаскивать предметы мышкой, что и как отображается в этом окне и многое другое. UI программист верстает окно и подключает к нему эту логику, прокидывая связи между интерфейсом и игровой механикой. Например, блуждая по локации вы подобрали какой-то предмет — нажали на него и он отправился в инвентарь. А где его потом найти? Версткой окна и тем, чтобы этот предмет в виде иконки нужного размера попал в соответствующий раздел инвентаря и занимается UI программист.

Программист дополнительных инструментов

Когда созданы основные игровые механики и понятно, какими сущностями они будут обладать, нужно сделать так, чтобы в игру можно было легко добавлять новый контент и изменять уже существующий. Если все это делать силами программистов, то тогда вам потребуется целая команда людей, которые будут прибавлять и убавлять запятую то тут, то там. Поэтому существует особый тип программистов — люди, которые занимаются разработкой дополнительных инструментов для игры. Например, если вы занимаетесь разработкой платформера, то при создании уровней вам наверняка потребуется какой-то редактор, в котором можно создавать и тестировать уровни. Или какая-то база данных, которая содержит всю самую важную информацию об игровых предметах: какая картинка привязана к предмету, как он называется, сколько он стоит, как действует и столько времени и так далее. А разработка программ под такие нужды — это целая отдельная работа, для которой нужны свои специалисты.

3. Эстетика, или “как выглядит игра”

Вообще эстетика — это дисциплина, изучающая выразительные формы окружающего мира. Применительно к данной ситуации, эстетика — это те аспекты игры, которые отвечают за чувственное восприятие игрока. Сюда входит и то, что мы видим в игре: (заставки, иконки, картинки персонажи), и то, как они двигаются (эффекты, анимации, катсцены), и то, как они звучат (саундтреки, звуки для игровых действий, интерфейсов).

Профессии в сфере эстетики

2D художник

Это художник, который создает финальную версию 2D арта, то есть, арта нарисованного в Photoshop. Это могут быть иконки, могут быть портреты персонажей, художественные элементы интерфейсов, игровые заставки. Некоторые игры полностью выполнены в 2D, так что там даже и не нужны другие художники.

3D художник

Это художник, который создает объемные модели объектов и персонажей в специальных программах типа Autodesk Maya и Zbrush. 3D модели нужны тогда, когда во время движения, например, нужно иметь возможность в любую секунду времени видеть персонажа со всех сторон. Или если нужно объемное пространство, похожее на реальный мир, в котором игрок должен свободно ходить, в то время как в 2D играх это как правило статичный бэкграунд на котором двигается малоподвижный персонаж.

Аниматор

Как бы это банально ни звучало, это человек, который делает анимации для игры. Анимации тоже бывают разных типов:

Покадровые (спрайтовые) — когда все движение рисуется отдельными кадрами, которые потом очень быстро проигрываются один за другим
Скелетная 2D — когда 2D картинка нарезается на отдельные картинки (ассеты), каждой из которых присваиваются кости, связанные в один общий скелет.
3D анимация — это тоже скелетная анимация, только скелет находится внутри 3D модели.

Художник по интерфейсу / Дизайнер интерфейса

Это особая категория художников, которая кроме навыков рисования обладает также знаниями принципов построения интерфейсов. Вообще разработка интерфейса — это целая наука: нужно разбираться в психологии человека, современных тенденциях в области интерфейсов, базовых законах построения интерфейса, различие между интерфейсами на разных девайсах, операционных системах, плюс нужно уметь наиболее емко, читаемо и удобно расположить всю необходимую информацию и весь необходимый функционал, который задумал для той, или иной механики геймдизайнер.

Дизайнер звука

Иногда на проекте есть свой отдел, занимающийся звуками и музыкой, иногда их заказывают сторонней студии, которая работает на аутсорсе. Суть одна: все игровые действия, будь то нажатие на кнопку интерфейса, или шаги персонажа, или локация — все это нуждается в звуковом сопровождении.

4. История, или “о чем эта игра”

Это сюжет игры, или ее сеттинг. Сеттинг — это время, место и обстоятельства, в которых разворачиваются действия вашей игры. Проще говоря, это мир, в котором происходят события.

Сюжет — это непосредственно ваша история, которая развивается в рамках выбранного вами сеттинга, выливаясь в последовательность каких-то событий.

Профессии в сфере истории

Нарративный дизайнер

Работая с геймдизайнерами, художниками и дизайнерами звука, нарративный дизайнер делает все, чтобы история игры, в ее самом художественном смысле, была максимально точно донесена до игрока. Если при слове «история» вам сразу приходят в голову диалоги персонажей и описания предметов — то вы немного промахнулись, в игре история, если она не будет положена на игровые механики, геймплей, левел дизайн и прочие составляющие — никогда ничего не расскажет игроку. Нарративный диайнер занят тем, что работая с текстовым сюжетом он придумывает то, как вплечти ее в игровой процесс максимально естественным образом и избавить игровой мир от игровых условностей, обыграв их сюжетно. Продробнее об этом можно почитать в ответах на этот вопрос.

Сценарист

Это зачастую привлеченный со стороны писатель, который пишет художественный текст сюжета для игры, прорабатывает персонажей, события, взаимосвязь между ними, придумывает интересные повороты истории. Как правило, его работа на проекте заканчивается с завершением сценария.

Внешние сферы

1. Тестирование, или “правильно ли работает моя игра”

Тестирование позволяет проверить, что все работает именно так, как должно быть.

Профессии в сфере тестирования

Тестировщик

Многие считают, что тестирование игры — это очень легкое и увлекательное занятие. Сидишь себе и играешь целыми днями — работа мечты! Как бы не так. Многие путают работу тестировщика с деятельностью фокус группы. Профессиональный специалист занимается дотошной и доскональной проверкой каждой закорючки, каждой кнопки, каждого пыльного уголка игры. Его задача — прочитать техническое описание конкретной фичи, или интерфейса, и проверить, чтобы их работа в игре соответствовала этому самому описанию. К тому же, нужно проверить, чтобы в самых экстремальных и неприспособленных для этого условиях, работоспособность фичи оставалась прежней. Поэтому тестировщику важно знать на каких принципах базируется техническая часть игры, нужно отлично знать ее возможности и потенциальные места, плюс к этому нужно уметь точно и емко описывать найденные проблемы и шаги для их воспроизведения. Тестировщики — это люди крайне усидчивые и внимательные, потому что стоит только на минуту расслабиться, как тут же выскочит баг, и проглядеть как он появился очень легко.

2. Маркетинг, или “как мне продать мою игру”

Сюда входит вся работа по продвижению игры, привлечению потенциальных игроков и стратегии поддержания их интереса к игре. Сюда же входит ценообразование и определение рынка для конечного продукта.

В каждой сфере существует свой набор специалистов, у каждого из которых свой набор ключевых функций. Если вычеркнуть из перечисленных сфер хотя бы одну — разработка игры станет в итоге невозможной. Иногда, в зависимости от проекта, эти сферы частично или полностью сливаются между собой, и их функции соединяются в одном специалисте. Но об этом я расскажу чуть позже.

Профессии в сфере маркетинга

Маркетолог

Это человек, который занимается продвижением игры на различных правильно выбранных рынках, разрабатывает стратегию наращивания числа пользователей. Это включает в себя решения в духе “сначала откроемся на этом рынке, а потом на этом”, и “давайте купим рекламу вот в этом блоге, а вот эти ребята напишут о нас бесплатно”. В общем, маркетолог занимается разработкой полной стратегии проидвижения игры, ищет способы показать игру наибольшему количеству людей из числа целевой аудитории и преподнести ее так, чтобы она казалась уникальной и важной для каждого конкретного потребителя.

Аналитик

После того, как игра разработана и выпущена, она никогда не отправляется в свободное плавание безнадзорно. Нельзя забывать, что то, что для вас, как для разработчика кажется естественным и понятным, для игрока может представляться под совершенно другим углом. Нужно анализировать результаты игрового процесса всех игроков, находить места, в которых они испытывают затруднения и искать причины этого, потому что чаще всего, сами игроки на вопрос о том, что им непонятно и почему, что им не нравится и почему — не могут ответить внятно. Поэтому, к различным игровым событиям привязываются определенные ключи, которые приходят разработчику сообщая, как долго игрок проходит конкретный этап, в каком месте игроки покидают игру, какой выбор делает большинство игроков в той или иной ситуации и так далее. Полученные тонны информации нужно собирать, проанализировать, и превратить в четкие выводы, которые могут быть руководством к действию для разработчиков.

Компьютерная программа — Википедия

Компьютерная программа.

Компью́терная програ́мма — 1) комбинация компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления (стандарт ISO/IEC/IEEE 24765:2010)^[1]; 2) синтаксическая единица, которая соответствует правилам определённого языка программирования, состоящая из определений и операторов или инструкций, необходимых для определённой функции, задачи или решения проблемы (стандарт ISO/IEC 2382-1:1993)^[2].

Первое определение соответствует понятию «исполняемая программа», второе относится к понятию «исходный текст».

Другие определения из нормативных документов:

данные, предназначенные для управления конкретными компонентами системы обработки данных в целях реализации определённого алгоритма (ГОСТ 19781—90)^[3];
представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств с целью получения определённого результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения (Гражданский кодекс Российской Федерации)^[4].

Компьютерные программы как объект авторского права и других прав интеллектуальной собственности относятся к категории нематериальных активов.

Чаще всего образ программы хранится в виде исполняемого модуля (отдельного файла или группы файлов). Из этого образа, находящегося, как правило, на диске, исполняемая программа в оперативной памяти может быть построена программным загрузчиком.

В системном программировании программой называются данные, которые используются процессором как инструкции по управлению компьютерной системой^[5]. В состав программы может входить как машинный код, исполняемый процессором для достижения некоторой цели, так и необходимые для этого данные. Отличительной особенностью программы является её нахождение в памяти и исполнение процессором.

Процесс разработки программного обеспечения состоит из нескольких этапов, из которых в узком смысле лишь непосредственное создание программного кода носит название «программирование». В широком смысле под программированием часто подразумевается весь процесс разработки ПО, а людей, занимающихся этим видом деятельности, называют программистами.

Запись исходных текстов программ при помощи языков программирования облегчает понимание и редактирование человеком. Этому, в частности, помогают комментарии, допустимые в синтаксисе большинства языков. Для выполнения на компьютере готовый текст программы преобразуется (компилируется) в машинный код.

Некоторые языки программирования позволяют обходиться без предварительной компиляции программы и переводят её в инструкции машинного кода непосредственно во время исполнения. Этот процесс называется динамической компиляцией, и он позволяет добиться большей переносимости программ между разными аппаратными и программными платформами при сохранении многих плюсов компиляции.

Интерпретируемые программы, для которых, как правило, не применяется процесс компиляции и которые интерпретируются операционной системой или специальными программами-интерпретаторами, называются скриптами или «сценариями».

Исходные тексты компьютерных программ в большинстве языков программирования состоят из списка инструкций, точно описывающих заложенный алгоритм. Подобный подход в программировании называется императивным. Однако применяются и другие методологии программирования. Например, описание исходных и требуемых характеристик обрабатываемых данных и предоставление выбора подходящего алгоритма решения специализированной программе-интерпретатору — такой подход называется декларативным программированием. К декларативному программированию относятся функциональное и логическое, а также менее распространённые виды программирования.

Программы могут создаваться в текстовом виде и визуально. В первом случае исходный код набирается вручную, во втором функциональность программы задаётся с помощью элементов графического интерфейса пользователя, а текст программы генерируется автоматически и может быть как доступен для изменения вручную, так и полностью скрыт от программиста.

До момента, когда пользователь компьютера явно или неявно выдаст запрос на выполнение компьютерной программы, она обычно хранится в энергонезависимой памяти. При получении такого запроса программа посредством другой компьютерной программы, называющейся операционной системой, загружается в память с произвольным доступом, откуда её непосредственно может выполнять центральный процессор. После этого центральный процессор выполняет программу, инструкция за инструкцией, до её завершения. Выполняющаяся программа называется процессом^[6]. Завершение программы происходит либо по достижению её последней инструкции (обычно передающей управление операционной системе) либо по ошибке, программной или аппаратной.

Одновременное выполнение[править | править код]

Многие операционные системы поддерживают механизм многозадачности, который позволяет создать эффект одновременной работы нескольких компьютерных программ на одном компьютере. Операционные системы могут выполнять несколько программ, используя диспетчер операционной системы — программный механизм для переключения процессов, выполняемых процессором. Хотя в каждый момент времени выполняется только одна программа, при достаточно частом переключении пользователь может взаимодействовать со всеми программами во время их работы^[7]. Современные многопроцессорные компьютеры или компьютеры с многоядерными процессорами поддерживают одновременное выполнение нескольких программ аппаратно^[8].

Фрагменты кода одной и той же компьютерной программы могут одновременно выполняться с помощью потоков выполнения. Существуют многопоточные процессоры, специально оптимизированные для выполнения нескольких потоков.

Самомодифицирующиеся программы[править | править код]

Считается, что выполняющаяся компьютерная программа отличается от данных, которые она обрабатывает. Однако это отличие размывается, когда компьютерная программа модифицирует сама себя. Модифицированная компьютерная программа затем выполняется как часть исходной программы. Самомодификация кода возможна в программах, написанных в машинном коде, на ассемблере, Лиспе, Си, Коболе, ПЛ/1 и Прологе.

Большинство пользователей компьютеров используют программы, предназначенные для выполнения конкретных прикладных задач, таких, как подготовка и оформление документов, математические вычисления, обработка изображений и т. п. Соответствующие программные средства называют прикладными программами или прикладным программным обеспечением. Управление компонентами вычислительной системы и формирование среды для функционирования прикладных программ берёт на себя системное программное обеспечение, наиболее важной составляющей которого является операционная система.

Согласно ст. 1261 ГК РФ программой для ЭВМ является представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определённого результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения.

Программы с общедоступными исходными текстами называются открытыми.

Компьютерные программы в большинстве стран являются объектами авторского права (включая Украину и Россию). В некоторых странах компьютерные программы могут защищаться патентами. Патентованию компьютерных программ способствовало Соглашение о торговых аспектах прав интеллектуальной собственности, которое установило минимальные^[9] требования к охраняемому ряду объектов прав интеллектуальной собственности и фактически разрешило патентовать программы. Соглашение ТРИПС обязательно для выполнения на территории Украины и России как государств-членов ВТО.

Таким образом программа может охраняться и как «литературное произведение» и как «изобретение». Для определения режима правовой охраны в первом случае используется «текст кода», в другом — признаки применяемые для изобретений, предлагаемых для патентования (то есть нужно доказать «инновационность», «оригинальность» и «неочевидность», а также возможность решения существующей технической проблемы и коммерческую пригодность)^[10]. При этом существует проблема правового разграничения компьютерных программ от проприетарного цифрового контента и проприетарного программного обеспечения^[11].

Исключительное право на программы для ЭВМ и базы данных возникает автоматически с момента её создания и действует в течение всей жизни автора и семидесяти лет, считая с 1 января года, следующего за годом смерти автора (либо смерти последнего из соавторов).

Действующим законодательством Российской Федерации не предусмотрено патентование компьютерных программ как таковых. Данные объекты интеллектуальной собственности охраняются авторским правом, которое возникает автоматически с момента их создания и не требуют обязательной государственной регистрации. Однако программы для ЭВМ и базы данных могут быть зарегистрированы в Роспатенте по желанию правообладателя.^[12]

Авторское и некоторые другие^{[какие?]} права интеллектуальной собственности позволяют ограничивать доступ к исходным текстам программ.

Silberschatz Abraham. Operating System Concepts, Fourth Edition. — Addison-Wesley, 1994. — С. 97. — ISBN 0-201-50480-4.
Knuth, Donald E. The Art of Computer Programming, Volume 1, 3rd Edition (англ.). — Boston: Addison-Wesley, 1997. — ISBN 978-0-201-89683-1.
Knuth, Donald E. The Art of Computer Programming, Volume 2, 3rd Edition (англ.). — Boston: Addison-Wesley, 1997. — ISBN 978-0-201-89684-8.
Knuth, Donald E. The Art of Computer Programming, Volume 3, 3rd Edition (англ.). — Boston: Addison-Wesley, 1997. — ISBN 978-0-201-89685-5.

Эта статья или раздел описывает ситуацию применительно лишь к одному региону, возможно, нарушая при этом правило о взвешенности изложения.

Вы можете помочь Википедии, добавив информацию для других стран и регионов.

Что нужно для разработки игр программисту и кем реально является разработчик игр со стороны программиста

Большинство людей (нормальных), которые планируют заниматься программированием (как хобби или основной профессией) обычно задаются вопросами: «Что такое программирование?», «Зачем мне нужно программирование?», «Какой язык я буду учить?», «Что я получу в итоге?».

Таким был и я. Я очень люблю разрабатывать игры и занимаюсь этим с 5-го класса. Моей первой нормальной (как я тогда думал) игрой — был симулятор бомжа. Написал я эту игру на C#, используя лишь Visual Studio и Windows Form. В дальнейшем я переписал проект под WPF и он стал более приятно выглядеть.

Возвращаясь к теме заголовка, хочу сразу же ответить на первую его часть (левую): чтобы быть разработчиком игр/разрабатывать игры, вам нужно лишь ваше желание и иметь компьютер(хотя в наше время можно и на телефоне писать код, но делать этого не надо). Если вы реально хотите разрабатывать игры, то нужно определиться с приоритетами. Вы должны понимать, чем для вас является это дело — хобби или всё же профессиональная деятельность, которой вы будете верны, скорее всего, всю жизнь.

Если вариант №1, то вам нужно принять то, что времени на разработку игры уйдет больше, чем у человека, посвятившему этому жизнь, и то, что вы не напишите какой-нибудь «шедевр» больше, чем Flappy Bird.

Если вариант №2, то у вас больше возможностей, по сравнению с вашими конкурентами из варианта №1: во-первых, вы всегда занимаетесь программированием, у вас постоянная практика/теория, ваша жизнь связана с этим почти до конца вашей жизни. Конечно, вы всё также не сможете написать в одиночку AAA-Project, но уже есть возможность написать интересную игрушку.

Итак, для разработки игр, нам потребуется следующее:

Компьютер
Желание создавать игры
Желание учиться
Установить приоритеты

Разработка игр требует множества знаний. Это одна из самых творческих сфер в программировании, но и также самая требовательная. Сейчас математика и физика в разработке игр всё больше автоматизируется, но раньше вам точно нужны были бы знания высшей математики и минимум знания всего курса физики в школе и колледже/универе. Тем не менее, лишним знание этих предметов не будет, особенно, если вы хотите разрабатывать собственные движки. Никогда не бойтесь чего-либо. Если вы не дружите с математикой, физикой и матлогикой, то я вам НЕ рекомендую заниматься разработкой игр, НО, если же вы просто прогуливали занятия и чувствуете, что можете учить эти предметы, не имея колоссальных затруднений, то пожалуйста — двери вам открыты.

Теперь перейдем ко второй части вопроса (правой). Задайте себе вопрос: «Кем является разработчик игр?». Не знаете? Ничего страшного, сейчас мы попробуем разобрать. Итак разработчик игр, скорее всего, разрабатывает игры? Логично, но нам нужен более подробный анализ. Минимум для этой профессии мы уже определили, но что он делает, если разбить этот минимум на блоки?

Разработчик игр занимается следующим:

Принимает задание
Формулирует проект и задание в письменном виде (для себя)
Обсуждает реализацию со своими коллегами
Снова формулирует проект и задание в письменном виде
Если задание сложносоставное — разбивает его на меньшие блоки
Пишет код для решения задач
Смотрит свой код, исправляет его недочеты
Кооперируется с коллегами для того, чтобы удостовериться, что ошибок минимум (ведь не может быть такого, чтобы мы писали код идеальным)
Дописывает мелкие детали и штрихи
Оптимизирует
Проверяет работоспособность
Выпускает в продакшн

Вот мы уже и видим, что такое словосочетание хранит в себе больший смысл. Конечно, такой вариант не для всех, везде по-разному, но я старался описать приближенный вариант ко мне и моим друзьям/коллегам/знакомым, которые делают также.

Я хочу сказать, что разработка игр не так проста, как кажется новичкам. Это очень сложный процесс, если вы хотите сделать действительно приятную для окружающих продукт. Если вам сложно смотреть с точки зрения других, смотрите со своей. Только не говорите себе: «Ну, здесь можно схалявить, мне и так зайдет». Видите сложность? Преодолейте её! Только так вы сможете совершенствовать свои навыки и повышать свой опыт. Игра должна быть приятна минимум вам, а уже потом, если вы планируете выдать её в общественность, то нужно её отшлифовать под другие желания. Как это сделать? Просто покажите своим друзьям или знакомым ваш проект (даже недоделанный) и спросите, чтобы они хотели видеть в игре подобного рода.

Статья подходит к концу, и здесь стоит отметить, что не спешите с выпуском своих проектов на рынок. Я на личном опыте знаю, что это плохая идея и потом выйдет вам боком (если не сразу, то потом точно). Учитесь-практикуйтесь-смотрите, и так по кругу, пока не поймете, что сделали то, что действительно хотели, и то, что нравится хотя бы одному вашему товарищу.

P.S.

Обязательно учитесь работать в команде!

Что входит в обязанности ведущего разработчика / Habr

Вот эта большая статья Джона Олспау называется «Быть ведущим инженером». В первый раз я прочитала её примерно четыре года назад, когда только перешла на нынешнюю работу, и она действительно повлияла на представления об этом направлении моей карьеры.

Перечитав её сейчас, действительно интересной там кажется одна вещь, что эмпатия и помощь команде — важная часть работы сеньора. Что, конечно, является правдой!

Но сейчас я вижу, что большинство или все ведущие инженеры, которых я знаю, берут на себя значительную помощь другим сотрудникам вдобавок к своей личной работе по программированию. Сейчас мне кажется, что я и мои коллеги сталкиваются не столько с проблемой «Что?? Нужно РАЗГОВАРИВАТЬ С ЛЮДЬМИ?? НЕВЕРОЯТНО», сколько с другой проблемой: «Как сбалансировать всю эту руководящую работу со своим индивидуальным вкладом / программированием? Сколько и какой работы я должен делать?». Поэтому вместо того, чтобы говорить о признаках сеньора из статьи Олспау (с которыми я полностью согласна), хочу поговорить о работе, которую мы делаем.

«Чем занимается ведущий инженер» — огромная тема, а здесь лишь небольшая статья, так что следует иметь в виду:

Тут лишь одно возможное описание того, чем может заниматься ведущий инженер. Есть много подходов к работе, и это не должно стать догмой.
Я в основном работала только в одной компании, поэтому мой опыт и взгляды, очевидно, довольно ограничены.
Очевидно, есть много уровней «сеньора». Речь идёт примерно об уровне P3/P4 в иерархии Mozilla (senior engineer / staff engineer), может быть, немного ближе к уровню «staff».

Это вещи, которые я рассматриваю больше как работу ведущего инженера и меньше как работу менеджера (хотя менеджеры определённо делают кое-что из перечисленного, особенно создание новых проектов и связывание проектов с бизнес-приоритетами).

Почти вся эта работа по сути техническая: помочь кому-то справиться со сложным проектом — это явно человеческое взаимодействие, но проблемы, над которыми мы будем работать вместе, как правило, будут техническими! («Может, если упростить дизайн, то мы сможем быстрее справиться!»).

Писать код (очевидно).
Делать код-ревью (очевидно).
Писать и рассматривать документацию по дизайну. Как и в случае с другими ревью, сторонний взгляд, вероятно, поможет улучшить дизайн.
Помогать коллегам, если они застряли. Иногда люди застревают на проекте, и важно им помочь! Я думаю об этом не столько о «парашюте с неба и доставке людям ваших магических знаний», сколько о «совместной работе, чтобы понять проблему и посмотреть, справятся ли два мозга быстрее, чем один» :). Это также означает совместную работу, а не решение проблемы вместо другого человека.
Поддерживать коллег на высоком уровне. Для разных людей «уровень» имеет разное значение (для моей команды это означает надёжность/безопасность/удобство продукта). Если кто-то принимает решение, которое мне не нравится, значит, либо я знаю что-то, чего не знает он, или он знает что-то, чего не знаю я! Поэтому не нужно говорить: «Эй, ты сделал это неправильно, нужно сделать X вместо этого», а лучше просто дать им дополнительную информацию, которой у них не было, и часто это решает вопрос. И довольно часто оказывается, что мне чего-то не хватало, и на самом деле их решение было вполне разумным! В прошлом я иногда видела, как ведущие инженеры пытаются обеспечить соблюдение стандартов качества, всё громче повторяя своё мнение, потому что они думают, что их мнение верно. Лично я не нашла полезным такой подход.
Создавать новые проекты. Команда разработчиков программного обеспечения — это не место с нулевой суммой! Лучшие инженеры, которых я знаю, не оставляют себе самую интересную работу, они создают новые интересные/важные проекты и создают пространство, чтобы другие делали эту работу. Например, кто-то из моей команды начал переписывать нашу систему деплоя. Проект оказался суперуспешным, и теперь целая команда работает над новыми функциями, которые стало легче реализовать!
Планировать работу своих проектов. Речь о том, чтобы записать/сообщить дорожную карту для проектов, над которыми вы работаете, и убедиться, что люди понимают план.
Заранее сообщать о рисках проекта. Очень важно распознать, когда что-то идёт не очень хорошо, сообщить об этом другим инженерам/менеджерам и решить, что делать.
Сообщать об успехах!
Делать сторонние проекты, которые приносят пользу команде/компании. Я вижу, что многие сеньоры иногда делают небольшие, но важные проекты (например, создают инструменты разработки / помогают устанавливать политики), которые в конечном итоге помогают многим людям выполнять свою работу намного лучше.
Быть в курсе, как проекты соотносятся с приоритетами бизнеса.
Решать, когда прекратить проект. Оказывается, на удивление сложно понять, когда нужно остановиться / не начинать работу над чем-то. 🙂

На первое месте я поставила «писать код», потому что в реальности эта задача легко скатывается вниз в списке приоритетов. 🙂

В списке отсутствует пункт «делать оценки/прогнозы». Здесь я ещё не очень хороша, но я думаю, что когда-нибудь стоит потратить на это больше времени.

Список кажется большим. Кажется, что если заниматься всеми этими вещами, то они поглотят все ваши интеллектуальные ресурсы. Думаю, что в целом имеет смысл выделить какую-то часть и решить: «Прямо сейчас я собираюсь сосредоточиться на X, Y и Z, я думаю, что мой мозг взорвётся, если я попытаюсь сделать B и C».

Тут немного сложнее. Я не говорю, что такими вещами категорически нельзя заниматься. Большинство ведущих инженеров, которых я знаю, тратят огромное количество времени, думая об этих проблемах, и немного работают в этом направлении.

Но мне кажется, что полезно провести некоторую границу, потому что у некоторых людей высокое чувство ответственности за команду и компанию — и они готовы взяться за всё подряд, в результате чего будут перегружены работой и не смогут вносить технический вклад, который на самом деле является их основным делом. Поэтому установление некоторых границ помогает определить, по каким вопросам есть смысл попросить о помощи, когда ситуация становится неспокойной. Ваши реальные границы зависят от вас / вашей команды. 🙂

Большинство из перечисленного ниже — работа менеджера. Оговорка: менеджеры делают намного больше, чем перечисленное здесь (например, «создают новые проекты»), а в некоторых компаниях некоторое из перечисленного может фактически быть работой ведущего инженера (например, спринт-менеджмент).

Убедиться, что каждый сотрудник вознаграждается по заслугам за свою работу.
Убедиться, что работа справедливо распределена.
Убедиться, что люди хорошо работают вместе.
Обеспечить сплочённость команды.
Поговорить наедине с каждым сотрудником.
Обучать новых менеджеров, помогать им понять, что от них ждут (хотя я думаю, что ведущие программисты часто действительно приходят к такой деятельности?).
Управлять сторонними проектами (у меня на работе это дело любого инженера, ведущего тот проект).
Быть менеджером по продукту.
Вести спринт-менеджмент спринтом / определять этапы работы для каждого / проводить еженедельные митинги.

Недавно я столкнулась с интересной ситуацией, когда обсуждала с менеджером свои обязанности — и мы поняли, что очень по-разному на них смотрим! Мы прояснили ситуацию, и теперь всё в порядке, но это заставило меня понять, что очень важно договориться об ожиданиях. 🙂

Когда я начинала как инженер, работа была довольно простой — я писала код, пыталась придумать проекты, которые имели смысл, и всё было прекрасно. У моего менеджера всегда было чёткое представление о моей работе, ничего слишком сложного. Теперь ситуация изменилась! Поэтому теперь я считаю, что обязана определить работу, которую:

Я могу делать / долговременно подходит для меня.
Я хочу сделать / которая в целом приятна и соответствует моим личным целям.
Представляет ценность для команды / организации.

Точная формулировка будет отличаться для разных людей (не у всех одинаковые интересы и сильные стороны, например, я ещё не слишком хороша в код-ревью!). Думаю, по этой причине ещё важнее обсудить эту тему и согласовать ожидания.
Думаю, очень важно отказаться от работы, которую я не могу сделать или которая в долгосрочной перспективе не доставит радости! Кажется заманчивым взять на себя много работы, даже если она вам не очень нравится («О, это хорошо для команды!», «Ну кто-то же должен это сделать!»). Конечно, иногда я беру на себя задачи только потому, что они должны быть выполнены, но думаю, что для здоровья команды на самом деле очень важно, чтобы сотрудники делали то, что им в целом нравится и чем они могут заниматься в долгосрочной перспективе.

Поэтому я возьму небольшие задачи, которые просто нужно сделать, но важно не говорить при этом: «О, конечно, я потрачу большую часть своего времени на то, что у меня плохо получается и что мне не нравится, нет проблем» :). И если «кто-то» должен это сделать, возможно, это просто означает, что нам нужно нанять/обучить кого-то нового, чтобы заполнить пробел. 🙂

Хотя я чувствую, что начинаю понимать, что такое «ведущий инженер» (уже 7 лет в моей карьере), но я по-прежнему чувствую, что нужно ещё многое узнать об этом, и мне было бы интересно услышать, как другие люди определяют границы своей работы!

Разработчик программ это кто – «Кем работать в сфере разработки компьютерных игр, если языки программирования — не моё?» – Яндекс.Знатоки