Что такое процесс создания компьютерных программ

Обновлено: 04.07.2024

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

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

Однако на сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта , имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ , проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI , Scrum и др.

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

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

Также возможна стандартизация процедуры разработки конкретного процесса как "вырезки" из стандартного. Основная идея стандартного процесса – курсирование внутри компании передового опыта, а также унификация средств разработки . Очень уж часто в компаниях различные департаменты и проекты сильно отличаются по зрелости процесса разработки , а также затруднено повторное использование передового опыта. Кроме того, случается, что компания использует несколько средств параллельных инструментов разработки, например, СУБД средства версионного контроля. Иногда это бывает оправдано (например, таковы требования заказчика ), часто это необходимо – например, Java , . NET (большая компетентность оффшорной компании позволяет ей брать более широкий спектр заказов). Но очень часто это произвольный выбор самих разработчиков. В любом случае, такая множественность существенно затрудняет миграцию специалистов из проекта в проект, использование результатов одного проекта в другом и т.д. Однако при организации стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено и подробно описано в подходе CMMI .

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

Совершенствование процесса

Определение. Совершенствование процесса ( software process improvement ) – это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем.

Происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средcтв разработки.
Наблюдается быстрый рост компаний и их выход на новые рынки, что требует новой организации работ.
Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки.

Что и каким образом можно улучшать.

Переход на новые средства разработки, языки программирования и т.д.
Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр.
Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI ).
Сертификация компании ( CMM / CMMI , ISO 9000 и пр.).

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

Главная трудность реального совершенствования процессов в компании заключается в том, что она при этом должна работать и создавать ПО , ее нельзя "закрыть на учет".

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

Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО ) существуют две следующие парадигмы .

Organization pull – инновации нацелены на решение конкретных проблем компании.
Technology push – широкомасштабное внедрение инноваций из стратегических соображений. Вместо конкретных проблем, которые будут решены после внедрения инновации , в этом случае рассматриваются показатели компании (эффективность, производительность , годовой оборот средств, увеличение стоимости акций публичной компании), которые будут увеличены, улучшены после внедрения инновации . При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которых в данный момент ничего не известно.

Пример использования стратегии organization pull – внедрение новых средств тестирования в ситуации, когда высоки требования по качеству в проекте, либо когда качество программной системы не удовлетворяет заказчика.

Пример использования стратегии technology push – переход компании со средств структурной разработки на объектно-ориентрованные. Еще один пример использования той же стратегии – внедрение стандартов качества ISO 9000 или CMMI . В обоих этих случаях компания не решает какую-то одну проблему или ряд проблем – она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д.

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

Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push .

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

Еще одно различие обеих стратегий: в случае с organization pull , как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push .

Классические модели процесса

Определение модели процесса. Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО , как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса ( process model ).

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

Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

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

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

Вид деятельности ( activity ) – это определенный тип работы, выполняемый в процессе разработки ПО . Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта , кодирование – программистом, тестирование – тестировщиком . Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди.

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

Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО . В RUP они называются рабочими процессами ( work flow ), в CMM – ключевыми областями процесса (key process area ). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования .

Были определены следующие шаги: разработка системных требований , разработка требований к ПО , анализ , проектирование, кодирование , тестирование, использование – см. рис. 2.1.

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

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

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

отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;
требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно полностью завершить разработку требований, дизайн системы и т.д. – все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии;
интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;
модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".

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

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

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

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

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

Программирование в широком смысле можно разбить на несколько стадий:

Содержание

История

Антикитерский механизм из Древней Греции был калькулятором, использовавшим шестерни различных размеров и конфигурации, обусловливавших его работу, [1] по отслеживанию метонова цикла, до сих пор использующегося в лунно-солнечных календарях. [2] Аль-Джазари построил программируемый автомат-гуманоид в 1206 году. Одна система, задействованная в этих устройствах, использовала зажимы и кулачки, помещённые в деревянный ящик в определённых местах, которые последовательно задействовали рычаги, которые, в свою очередь, управляли ударными инструментами.

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

Первое программируемое вычислительное устройство, Аналитическую машину, разработал Чарлз Бэббидж (но не смог её построить). 19 июля 1843 года графиня Ада Августа Лавлейс, дочь великого английского поэта Джорджа Байрона, как принято считать, написала первую в истории человечества программу для Аналитической машины. Эта программа решала уравнение Бернулли, выражающее закон сохранения энергии движущейся жидкости. В своей первой и единственной научной работе Ада Лавлейс рассмотрела большое число вопросов. Ряд высказанных ею общих положений (принцип экономии рабочих ячеек памяти, связь рекуррентных формул с циклическими процессами вычислений) сохранили свое принципиальное значение и для современного программирования. В материалах Бэббиджа и комментариях Лавлейс намечены такие понятия, как подпрограмма и библиотека подпрограмм, модификация команд и индексный регистр, которые стали употребляться только в 1950-х годах. Однако ни одна из программ написанных Адой Лавлейс никогда так и не была запущена.

Языки программирования

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

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

Программные средства

Скриншот фрагмента кода на языке Java в текстовом редакторе vim, демонстрирующий подсветку синтаксиса, поддержку Unicode, фолдинг

На олимпиадах по информатике и программированию с успехом используются только свободно распространяемые лицензионные инструментальные средства (в большинстве своём распространяются по лицензии GNU GPL). Из языков программирования на олимпиадах по программированию последние годы часто используются языки программирования Паскаль, C/C++ и Java.

Сегодня слово«Программирование» можно увидеть / услышать, как в какой-нибудь вирусной рекламе в социальной сети, так и в литературном или кинематографическом произведении. Однако что же такое, программирование и кто такие программисты? Не мудрствуя лукаво, можно поступить как матерый кодер и загуглить новое слово.

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

Суть программирования

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

Алгоритмы

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

Открыть чайник.
Если в чайнике нет воды — набрать воду из под крана.
Поставить чайник на газовую плиту.
Открыть газ.
Зажечь огонь.
Дождаться, пока закипит вода в чайнике.
Насыпать в чашку заварку.
Залить заварку горячей водой.

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

Существует несколько способов описания алгоритма:

граф — схемы;
словесный;
псевдокод;
программный код.

Языки программирования

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

Во время разработки программного продукта могут выделяться разные уровни абстракций. То есть по разному представляться объекты реального мира. В зависимости от этого языки программирования принято разбивать на следующие виды:

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

Объектно-ориентированное программирование

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

Работа программистом

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

Заключение

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

Статья разделена на 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++).
Понимание хотя бы одного языка программирования. Из статьи вы узнаете основные элементы, которые составляют фундамент большинства ЯП.

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

Читайте также: