Суть работы программиста: В чем заключается суть работы программиста

Содержание

В чем заключается суть работы программиста

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

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

Какими же качествами нужно обладать, чтобы стать признанным профессионалом в этой сфере? Чему научат в вузах? Что придется осваивать самостоятельно?

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

Где и чему учат

Остановимся на специальности «Прикладная математика», так как она дает общие теоретические принципы программирования, обширную математическую базу для решения поставленных задач, а другие специальности все-таки готовят специалистов по их автоматизации. После окончания института студент получает квалификацию «инженер-математик». Студенты изучают практически все распространенные языки программирования (высокого и низкого уровня), уделяют внимание специальным языкам (предназначенным для решения узкопрофильных задач), а также знакомятся с пакетами готовых программ, которые в дальнейшем могут использовать в своих разработках (графические системы, СУБД, САПР и т. д.). Изучение этих предметов вырабатывает системное мышление, позволяет оценить проблему в комплексе – и подобрать наилучший вариант ее решения, применяя все полученные навыки.

Этапы работы

1. Любой процесс программирования начинается с постановки задачи.

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

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

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

Тут важно, чтобы не получилось как в известной шутке:

2. Далее следует определить, какая техника понадобится для автоматизации поставленной задачи.

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

3. Все вопросы прояснены – можно приступать, собственно, к написанию программы.

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

Чем полнее алгоритм отслеживает стандартные и нестандартные ситуации, тем лучше будет работать программа в дальнейшем – и не зависать при каждом «удобном» (непредусмотренном) случае. 

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

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

4. После написания программы начинается, как ни странно, самый трудоемкий этап – ее отладка.

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

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

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

В лучшем случае, если вы справились с постановкой задачи и на всех этапах работы контактировали с заказчиком (или постановщиком задачи), замечаний будет немного. Маленькие доработки – и программа готова.

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

Так что если вы решили, что программирование – это дело вашей жизни, то вас ждут МИРЭА, МГИЭМ и другие вузы. Но не забывайте, что высокооплачиваемым профессионалом вы сможете сделать себя только сами и учиться придется всю оставшуюся жизнь (или по крайней мере до пенсии).

Профессия Программист. Описание профессии. Кто такой Программист. Описание профессии

  • Банковское делоПрофессии: Агент банкаБанкирБанковский работники еще 6 профессий
  • Бизнес-информатика

    Профессии: ERP-программистБизнес-аналитикБизнес-консультанти еще 9 профессий

  • Гостиничное дело

    Профессии: Администратор гостиницыи еще 7 профессий

  • Гостиничное дело

    Профессии: Event-координаторHR-менеджери еще 6 профессий

  • Гостиничный сервисПрофессии: Администратор гостиницыГорничнаяОфициантПортье
  • Государственное и муниципальное управление

    Профессии: в государственных корпорацияхи еще 3 профессии

  • Государственное и муниципальное управление
  • Издательское дело

    Профессии: Ведущий редакторКорректорОтветственный редактори еще 2 профессии

  • Информатика и вычислительная техника

    Профессии: Web-программистWeb-разработчики еще 9 профессий

  • Информационные системы и технологии

    Профессии: Инженер по телекоммуникациями еще 4 профессии

  • Информационные системы и технологии

    Профессии: Web-программистАдминистратор баз данныхи еще 7 профессий

  • Коррекционная педагогика в начальном образованииПрофессии: Воспитатель детского садаЛогопеди еще 2 профессии
  • Лингвистика

    Профессии: Преподаватель русского языка как иностранногои еще 2 профессии

  • Лингвистика

    Профессии: Гид-переводчик для иностранных делегацийи еще 4 профессии

  • Математическое обеспечение и администрирование информационных систем

    Профессии: Web-программистАдминистратор баз данныхи еще 8 профессий

  • Менеджмент

    Профессии: ДиректорМенеджер проектови еще 2 профессии

  • Менеджмент

    Профессии: и еще 6 профессий

  • Наноинженерия

    Профессии: Инженер в области нанотехнологийи еще 5 профессий

  • Обеспечение информационной безопасности автоматизированных систем
  • Операционная деятельность в логистике
  • Педагогическое образование

    Профессии: и еще 6 профессий

  • Педагогическое образование

    Профессии: Вожатый оздоровительного лагеряи еще 3 профессии

  • Перевод и переводоведение

    Профессии: Переводчик в бюро переводови еще 4 профессии

  • Право и организация социального обеспеченияПрофессии: Социальный работникЮрист
  • Прикладная информатика

    Профессии: Администратор баз данныхи еще 8 профессий

  • Прикладная информатика

    Профессии: Инженер-исследовательСистемный аналитик

  • Прикладная информатика (по отраслям)Профессии: Mobile-разработчики еще 2 профессии
  • Прикладная математика и информатика

    Профессии: Инженер-конструкторИнженер-электроники еще 2 профессии

  • Прикладная математика и информатика

    Профессии: Администратор баз данныхАналитик баз данныхи еще 9 профессий

  • Психология

    Профессии: КоучПсихологПсихолог-консультантСемейный психолог

  • Психология

    Профессии: ПсихологПсихолог-консультантСемейный психолог

  • Психолого-педагогическое образование

    Профессии: Детский психологПедагог-психологи еще 3 профессии

  • Психолого-педагогическое образование

    Профессии: Детский психологПедагог-психологи еще 2 профессии

  • РекламаПрофессии: Специалист по рекламе
  • Реклама и связи с общественностью

    Профессии: PR-специалистамидиректорами по PRи еще 2 профессии

  • Реклама и связи с общественностью

    Профессии: бренд-менеджерамиимиджмейкерамимедиа-байерамии еще 4 профессии

  • Социальная работа

    Профессии: Социальный педагогСоциальный работники еще 2 профессии

  • Специальное (дефектологическое) образование

    Профессии: и еще 3 профессии

  • Специальное (дефектологическое) образование

    Профессии: учитель-логопед

  • Таможенное дело

    Профессии: Специалист по валютным операциямСпециалист по ВЭД и еще 4 профессии

  • Туризм

    Профессии: Бизнес-аналитик в сфере туризмаи еще 6 профессий

  • Туризм

    Профессии: и еще 7 профессий

  • ТуризмПрофессии: Специалист по туризмуЭкскурсовод
  • Управление персоналом

    Профессии: Менеджер по персоналуи еще 4 профессии

  • Управление персоналом

    Профессии: директор по персоналуменеджер по персоналуи еще 5 профессий

  • Финансы и кредит

    Профессии: Инвестиционный менеджери еще 5 профессий

  • Экономика

    Профессии: и еще 5 профессий

  • Экономика

    Профессии: Аудитори еще 6 профессий

  • Экономика и бухгалтерский учет (по отраслям)Профессии: БухгалтерКассирСпециалист по налогообложениюи еще 1 профессия
  • Электроэнергетика и электротехника

    Профессии: и еще 6 профессий

  • Юриспруденция

    Профессии: Ассистент кафедрыКоучМедиаторНотариусПрокурори еще 5 профессий

  • Юриспруденция

    Профессии: АдвокатИнспектор уголовного розыскаКриминалисти еще 5 профессий

  • ПРОГРАММИСТ СУТЬ ПРОГРАММИСТА Программист это специалист

    ПРОГРАММИСТ

    СУТЬ ПРОГРАММИСТА Программист – это специалист, который занимается созданием различных алгоритмов (программ) машинного поведения и обучения, используя языки программирования.

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

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

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

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

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

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

    СПАСИБО ЗА ВНИМАНИЕ

    Можно ли стать программистом за три месяца?

    Карантин здорово располагает к обучению, а исчезающие с рынка труда рабочие места – к тому, чтобы, если уж учиться, то получить профессию надежную и перспективную, которая не позволит пойти камнем на дно в тяжелые времена. Если есть на свете профессии, способные гарантировать трудоустройство в кризис, то «программист» — одна из них. Во всяком случае, таков стереотип. А вот еще аргумент, почему работа в IT так привлекательна. По результатам проведенного нами опроса (опрашивали работодателей), 85% компаний до четверти сотрудников готовы оставить на удаленке.

    А кто у нас работает на удаленке? По данным сайта CNews, каждая вторая вакансия для удаленщиков на российских сайтах по трудоустройству так или иначе связана с программированием. Вот пазл и сложился: программирование – это стабильная занятость, конкурентные зарплаты, возможность работать дистанционно. И люди идут учиться. Как пишет Gazeta.ru,  в Skillbox число учеников с марта по август выросло в 4,5 раза, и профессии, к которым пользователи стремятся больше всего – разработка программного обеспечения и гейм-дизайн.

    Еще один стереотип, который легко становится путеводной звездой для людей то ли слишком мечтательных, то ли малость ленивых – что профессию «программист» можно получить легко и быстро. Средняя продолжительность краткосрочных курсов – до 4-х месяцев. (Конечно, на рынке образовательных услуг предлагают не только краткосрочные курсы, но и их в том числе.) Команда поисковика в сфере работы Trud.com собрала мнения экспертов на тему «Можно ли стать программистом за 3 месяца», причем мы обратились к представителям и коммерческих обучающих компаний, и вузовской среды, и к работодателям, и к самим программистам, чтобы получить полную картину. Полученные нами выводы вряд ли станут новостью для состоявшихся профессионалов или для тех, кто находится на середине пути к карьерной вершине, а вот начинающим или поглядывающим в сторону курсов – могут быть полезны (надеемся).

    Почему в вузе начинают с Паскаля

    Мнение вузовских преподавателей интересно постольку, поскольку в большинстве вакансий и сегодня пишут: «наличие диплома – плюс». Хорошо быть активным и целеустремленным самоучкой, но все-таки в alma mater, видимо, не семечки на занятиях лузгают.

    Чтобы ответить на вопрос о сроках обучения программированию, Вовк Елена Тимофеевна, зам. директора Учебного центра ф-та ВМК (вычислительной математики и кибернетики) МГУ им. М.В. Ломоносова, и Якушин Алексей Валериевич, ответственный за дополнительное образование на этом же факультете, предлагают разобраться, а кто, собственно, собрался в программисты.

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

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

    Почему же Паскаль? «Есть языки, используемые и наиболее удобные для начального обучения программированию, — поясняет Алексей Валериевич. — К ним обносится язык Паскаль. Именно на этот язык идеально ложится логика алгоритма при прозрачном синтаксисе языка».

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

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

    За три месяца – можно. Только осторожно

    Рассуждать на заданную в заголовке тему следует с учетом отправной точки: а кого мы называем программистом?

    «В блоке профессий, которые на бытовом уровне зовут «программистом», вполне есть те, которые можно освоить настолько, чтобы работать по специальности. Сборка сайтов на современных движках, вёрстка, создание Landing-страниц – всё это вполне осваиваемые за три месяца навыки, с которыми можно идти дальше работать/стажироваться. Да, ты будешь не профи, но вклинишься и стартанёшь», – рассуждает Лютер Ежов, разработчик в компании RentATeam.

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

    В качестве примера можно привести профессию «тестировщик». Антон Немкин, председатель совета фонда Цифровая долина Сочи, считает, что за три месяца можно пройти базовый курс по функциональному тестированию и стать Junior-тестировщиком. «Правда, имейте в виду, что сейчас требования к QA-специалистам гораздо выше, потому что на одно место может претендовать несколько десятков человек, так что устроитесь ли вы – большой вопрос», — добавляет Антон.

    Курсы как средство повышения квалификации

    Михаил Краев, Менеджер проекта в ГородРабот.ру, считает, что курсы – идеальный вариант для тех, кто уже пишет код. «Курсы – оптимальная возможность изучить что-то новое и понять, на что способен новый язык, познакомиться с его спецификой и синтаксисом. Я бы ещё посоветовал не бросаться сразу на платные курсы, а сначала попробовать бесплатные варианты обучения, чтобы сформировалась понимание, где используется тот или иной язык программирования, и нужен ли он будет тебе».

    Юлия Киселева, руководитель отдела по работе с персоналом компании Galileosky, подчеркивает, что курсы – полезная штука для желающих переквалифицироваться. «Если вы, например, переучиваетесь (с тестировщика или с другого языка), зная основы, то курсы дадут отличный шанс попасть на начальные позиции и далее уже развиваться в конкретной компании».

    «Быть в IT» не равно «быть программистом»

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

    Дмитрий Скрипкин, директор по персоналу компании «Рексофт», по-дружески протягивает руку представителям нетехнических профессий и напоминает, что отсутствие технического образования – не повод навсегда отказаться от идеи, как говорят, «войти в IT».

    Дмитрий напоминает, что сегодня востребованы некоторые специальности, о которых раньше и не слышали или, по крайней мере, в их представителях не нуждались так остро, как сейчас, например, UX-дизайнер или бизнес-аналитик. «Вряд ли будет разумно стремиться именно в разработку, не имея технического образования или сопутствующей базы, – считает Дмитрий. – Скорее, имеет смысл найти близкое вам направление и переквалифицироваться. К примеру, экономист может достаточно просто стать бизнес-аналитиком, статистик — специалистом по Data Science, менеджер любого направления — тестировщиком, графический дизайнер — UX/UI-дизайнером, специалист из любой сферы, хорошо разбирающийся в своей отрасли и бизнес-процессах своей компании, потенциально может стать руководителем проекта, и так далее». Для такой цели как раз и подойдут краткосрочные курсы. При этом подойти к их выбору стоит максимально прагматично. «Спросите совета у знакомых, работающих в этой сфере. Задайте вопрос о курсах HR-специалистам IT-компаний, спросите, есть ли возможность дальнейшей стажировки», — рекомендует HRD.

    Кейс из жизни

    Рассказывает Ольга Кутейникова, директор по продуктам компании Digital Contact:
    «История с COVID выбросила на рынок огромное количество «новоявленных» программистов. Буквально на днях на проект потребовался JS-разработчик. Мы, как обычно, опубликовали вакансию с требованием опыта от 3-х лет, и началось… За пару дней мы получили более 500 откликов, из которых релевантных было только четыре кандидата. Остальные — это студенты, которые закончили курсы программистов от GeekBrains, Skillfactory, Яндекс.Практикум. Причем большая часть – те, кто вчера были сантехниками, крановщиками, продавцами. Много соискателей старше 35 лет, с внушительным опытом за плечами, но совершенно не связанным с IT. Конечно, мне, как профессиональному участнику IT-рынка, печально смотреть, как продается иллюзия возможности вот так вот, за три месяца, стать программистом. Компании покупают не знание языка программирования, а опыт, мышление, которые приобретаются годами. Средний опыт программирования в нашей компании – 5-6 лет. Минимальный релевантный опыт кандидата, которого мы готовы рассматривать – 3 года, при этом предпочтение всегда будет не в пользу фрилансеров. Если кандидат все это время фрилансил, делал сайты на WordPress или настраивал CRM, то такого кандидата мы не можем пригласить для реализации задач, поставленных перед компанией. Это просто финансово неэффективно. Единственное место, где может найти себе работу в качестве интерна такой кандидат – это крупные IT-компании, которые готовы обучать, но нужно понимать, что деньги, которые такие компании готовы платить, будут ниже того, что человек с опытом мог бы получить, оставаясь в своей индустрии».

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

    Закончить хочется цитатой Лютера Ежова о моменте, когда вы можете смело сказать, что вам удалось «войти в IT». «Что считать точкой входа в профессию? Для меня это выглядит так: начал зарабатывать кодом или твой код принимается крупными опенсорс игроками – значит, вошёл. Вопрос склада ума, характера».

    Источник: статья на Habr

    9 признаков того, что вам суждено стать программистом

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

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


    Что такое программист?

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

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

    • Устранение проблем
    • Обновление и тестирование кода
    • Оптимизация систем в соответствии с потребностями клиента
    • Помощь людям в вопросах ИТ

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

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


    Какие навыки нужны программисту?

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

    Разное: Лучшие языки программирования для изучения

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

    Что касается других «мягких» навыков, то общение является обязательным условием. В отличие от машин, людям обычно нужны простые слова, чтобы понять, что делает их компьютер. Работая с другими людьми, вы должны уметь четко и эффективно объяснять свою работу, особенно в отчетах.

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

    Это основные качества успешного программиста, которые стоит расширить за счет дополнительных навыков. Чтобы вы лучше представляли свои перспективы, базовая зарплата старшего программиста в Мексике составляет от $97 000 до $732 000 в год — по данным Payscale.

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


    1. Вы чувствуете себя комфортно рядом с компьютерами

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

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


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


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

    Если вы владеете этим навыком, даже на одном языке программирования, таком как Python, вы уже программист.

    3.

    3. Вы умеете решать компьютерные задачи

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

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


    4. Вы быстро замечаете важные детали

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

    Узнайте, соответствует ли ваш опыт и интуиция этому пункту. В противном случае сделайте все возможное, чтобы развить в себе внимательность к деталям. Это сделает вас более эффективным и ценным для работодателей.


    5. Вам нравится узнавать больше об ИТ

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

    Ссылка: Узнайте, как создавать классы в jаvascript


    6. Вы хорошо объясняете суть и особенности работы компьютеров

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


    7. Вы можете работать над разными задачами одновременно


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

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


    8. Вы можете эффективно управлять своими задачами и временем

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

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


    9. Вы можете мыслить нестандартно


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

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


    Учитесь кодить как профессиональный программист

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

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

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

    Почему я так люблю программирование? Я имею в виду, что я получаю необоснованное удовлетворение от того, что программа хорошо работает и что она четко написана и хорошо организована. Меня всегда привлекало программирование, и чем больше я узнаю об этом, тем больше я хочу учиться и тем больше я хочу совершенствоваться.

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

    Креативное решение проблем

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

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

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

    Выражение идей

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

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

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

    Сочувствие к другим

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

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

    Делать что-то, что люди ценят и от чего зависят, невероятно приятно. Для этого вам нужно знать их мотивы, а для этого вам нужна эмпатия.

    Аналитическое мышление

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

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

    Устранение скуки

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

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

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

    Журнал программиста: Церемония против сущности

    На днях я слушал одно из шоу Hanselminutes Скотта Хансельмана. Я не могу вспомнить, было ли это шоу 196 или шоу 197 (вероятно, это было шоу IronRuby), но на одном из таких шоу разговор зашел о Ceremony vs Essence.

    Я раньше не слышал о Церемонии против Сущности, так что я узнал об этом.

    Ceremony vs Essence, как я понимаю, это фреймворк для критики языков программирования.Похоже, его изобрел Нил Форд из Thoughtworks, и он был представлен в серии основных докладов на конференциях в 2008 году. (К сожалению, я нигде не могу найти слайды его основных докладов в Интернете — у кого-нибудь есть ссылка?)

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

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

    Итак, например, некоторые люди смотрят на языки со статической типизацией, такие как C или Java, и замечают, что необходимость определять ваши переменные заранее и точно указывать тип переменной является «церемонией» и отвлекает от «суть» использования переменной. Этот момент довольно хорошо изложен в паре эссе Стюарта Хэллоуэя:

    Клинк Шэнк делает аналогичный вывод с точки зрения тестирования в своем эссе: Essence over Ceremony in Unit Testing.

    Я думаю, что, отложив на мгновение в сторону языковые дебаты относительно Ruby-против-Java-против-JavaScript-против-чего бы то ни было, можно сделать очевидный универсальный вывод: чем проще, тем лучше. Чем проще, тем понятнее, чем проще, тем меньше кода, чем проще, тем легче настраивать, поддерживать, документировать и отлаживать.

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

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

    И это всегда приятно.

    отзывов | The Essence of Software

    Похвала Essence of Software#

    «Провокационное переосмысление разработки программного обеспечения как дисциплины дизайна. Слишком часто программное обеспечение воплощает запутанные и противоречивые ментальные модели. Применяя по-настоящему ориентированный на человека подход со множеством ярких примеров, Джексон предлагает нам инструменты, позволяющие переосмыслить то, как мы разрабатываем программное обеспечение, чтобы сделать его более удобным и полезным.”— Элизабет Черчилль, директор по взаимодействию с пользователями, Google

    «Книга Дэниела Джексона «Сущность программного обеспечения» — это монументальная работа. Он обеспечивает новую структуру для осмысления программного обеспечения с точки зрения концепций. Широкомасштабный, он использует современные примеры, которые читатель знает. А поскольку книга (и многочисленные примечания к ней) предназначена для чтения разными способами, каждый инженер-программист найдет в ней что-то ценное». — Фредерик П. Брукс-младший, автор книги «Мифический человеко-месяц: Software Engineering

    «Я не могу сказать достаточно хороших слов об этой книге.Книга «Сущность программного обеспечения» необходима для чтения всем, кто занимается созданием программного обеспечения, отвечающего человеческим потребностям и целям. Его глубокая практическая основа предлагает широко полезный, чрезвычайно расширяющий возможности способ думать о разработке программного обеспечения и заниматься им». — Митчелл Капор, основатель Lotus Development Corporation

    «Книга Дэниела Джексона «Сущность программного обеспечения» присоединится к книге Фреда Брукса «Мифический человек». Месяц как влиятельное руководство по созданию отличных программных продуктов и инструментов. Дизайнеры придут к работе с более широким кругозором, более ясными мыслями и способностью создавать превосходное программное обеспечение.”— Ben Shneiderman, University of Maryland

    «The Essence of Software не просто даст вам новые идеи: новые и тщательно разработанные концепции программного обеспечения Дэниела Джексона изменят ваше представление о дизайне, программном обеспечении и программировании — о чем угодно. системы или языки, которыми вы пользуетесь, независимо от того, являетесь ли вы начинающим программистом, профессиональным программистом или исследователем. Это знаковая книга, которая сделает цифровой мир лучше». — Гарольд Тимблби, автор книги Fix IT: See and Solution the Problems of Digital Healthcare

    «Трудно сдержать восторг по поводу этой книги… Его идеи свежи, но знакомы, радикальны, но очевидны, глубоки, но просты.Я буду перечитывать ее снова и снова в течение многих лет. Важная веха в нашей дисциплине». — Башар Нусейбе, Университет Лимерика, главный научный сотрудник LERO

    Сущность и случайность в Unix Tradition

    Сущность и случайность в Unix Tradition

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

    Это различение может быть затруднено, потому что черты, возникшие как несчастные случаи иногда оказывались весьма полезными. Рассмотрим в качестве примера правило «Молчание — золото». Дизайн интерфейса Unix мы рассмотрели в главе 11; это началось как адаптация к медленному телетайпы, но продолжали, потому что программы с кратким выводом могли быть легче комбинировать в сценариях.Сегодня в условиях, когда наличие многих программ, работающих через графический интерфейс, является нормальным явлением. третий вид полезности: тихие программы не отвлекают и не тратят впустую внимание пользователя.

    С другой стороны, некоторые черты, которые когда-то казались важными для Unix оказались авариями, связанными с определенным набором затрат отношения. Например, в старой школе Unix предпочтение отдавалось дизайну программ (и мини-языки, такие как awk(1)), выполнявшие построчную обработку входной поток или запись в момент обработки двоичных файлов, с любым контекст, который необходимо поддерживать между фрагментами, переносимыми сложный код конечного автомата.С другой стороны, дизайн Unix новой школы рука, в целом доволен предположением, что программа может читать весь его ввод в память, а затем произвольно обращаться к нему по желанию. Действительно, современные Unix-системы предоставляют вызов mmap(2), который позволяет программист, чтобы отобразить весь файл в виртуальную память и полностью скрывает сериализацию ввода-вывода в дисковое пространство и обратно.

    Это изменение избавляет от экономии памяти, чтобы сделать ее проще и эффективнее прозрачный код. Это адаптация к падающей стоимости памяти относительно времени программиста.Многие различия между дизайн Unix старой школы в 1970-х и 1980-х годах и дизайн нового школу после 1990 года можно проследить до огромного изменения относительных затрат что сегодня делает все ресурсы машины на несколько порядков дешевле по отношению к времени программиста, чем в 1969 году.

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

    Описание главы 2 первое из этих изменений: рост межсетевого взаимодействия, от угол истории культуры, рассказывая, как TCP/IP принес оригинальные культуры Unix и ARPANET вместе после 1980 года.В Главе 7 материал об устаревших IPC и сетевые методы, такие как System V STREAMS, намекают на многочисленные фальстарты, ошибки и тупики, которые занимали разработчиков Unix на протяжении многих лет. следующего десятилетия. Была большая путаница по поводу протоколы, [153] и о связь между межмашинной сетью и межпроцессным взаимодействием обмен данными между процессами на одной машине.

    В конце концов путаница была устранена, когда победил TCP/IP и BSD Розетки вновь заявил о важности Unix Метафора «все есть поток байтов».Стало нормальным использовать BSD сокеты как для IPC, так и для сети, старые методы для обоих в основном вышли из употребления, а программное обеспечение Unix становилось все более безразличным к были ли взаимодействующие компоненты размещены на одном и том же или на разных машины. Изобретение Всемирной паутины в 1990-1991 гг. логический результат.

    При растровой графике и примере Macintosh появились в 1984 году, через несколько лет после TCP/IP, они представляли собой гораздо более сложный вызов. Оригинальные графические интерфейсы от Xerox ПАРК и Apple были красивы, но связаны слишком многими уровнями системы чтобы программисты Unix чувствовали себя комфортно с их дизайном. незамедлительным ответом Unix-программистов было разделение политики из механизма явный принцип; оконная система X установил его к 1988 году. Разделив наборы виджетов X от диспетчер отображения, выполнявший низкоуровневую графику, они создали архитектура, которая была модульной и чистой в терминах Unix, и та, которая может легко разработать лучшую политику с течением времени.

    Но это была самая легкая часть проблемы. Трудная часть была решение о том, должна ли Unix вообще иметь унифицированную политику интерфейса, и если да, то каким он должен быть.Несколько разных попыток установить его с помощью проприетарных инструментов (например, Motif) не удалось. Сегодня, в 2003 году GTK и Qt соревнуются друг с другом за эту роль. В то время как дебаты по этому вопросу не закончились в 2003 г., упорство различные стили пользовательского интерфейса, которые мы отметили в главе 11, кажутся красноречивыми. Дизайн новой школы Unix имеет сохранил командную строку и разобрался с противоречиями между графическим интерфейсом и командной строкой. подходит путем написания множества пар CLI-движок/GUI-интерфейс, которые могут использоваться в обоих стилях.

    При разработке персонального компьютера в качестве технология сама по себе.Микросхемы 386 и более поздние были достаточно мощными, чтобы придать системам, разработанным вокруг них, соотношение затрат, подобное мини-компьютеры, рабочие станции и серверы, на которых созрел Unix. Настоящей проблемой было изменение потенциального рынка для Unix; в гораздо более низкая общая стоимость оборудования, производимого персональными компьютерами привлекательным для гораздо более широкого, менее технически искушенного пользователя Население.

    Поставщики проприетарных Unix, привыкшие к более высокой прибыли от продавать более мощные системы искушенным покупателям, никогда не заинтересованы в этом более широком рынке.Первые серьезные инициативы к рабочему столу конечного пользователя пришли из сообщества открытого исходного кода и были установлены по существу идеологическим причинам. По состоянию на середину 2003 г. исследования рынка показывают, что Linux достиг примерно Там доля 4–5%, что близко к доле Apple Macintosh.

    Независимо от того, будет ли Linux когда-либо существенно лучше этого, природа реакции сообщества Unix уже ясна. Мы исследовал его при изучении Linux в главе 3. Он включает в себя принятие нескольких технологий (например, XML) из других источников и прилагая много усилий для натурализация графических интерфейсов в мире Unix.Но под тематическими графическими интерфейсами и установочной упаковке, основной упор по-прежнему делается на модульность и чистый код — при получении инфраструктуры для серьезное, высоконадежное вычислительное и коммуникационное право.

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

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

    IBM100 — ФОРТРАН

    С момента создания в 1954 г. и коммерческого выпуска в 1957 г. в качестве прародителя программного обеспечения Fortran (FORMula TRANslator) стал первым стандартом компьютерного языка, «помог открыть дверь в современные вычисления» и вполне может быть самым влиятельным программным продуктом. в истории. Fortran освободил компьютеры от исключительного владения программистов и открыл их почти для всех остальных. Он все еще используется более чем через 50 лет после его создания.

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

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

    Разработчик UNIX ® (Кен Томпсон из Bell Labs в 1969 г.) вспоминает, что «95% людей, которые программировали в первые годы, никогда бы не сделали этого без Fortran». Программа, по сути, является компилятором: программист, использующий Фортран, пишет только 5 процентов всех инструкций, а программа генерирует (компилирует) оставшиеся 95 процентов для компьютера.

    В конце 1940-х и начале 1950-х годов Джон Бэкус, главный автор Фортрана, собрал и направил команду молодых мужчин и женщин с разными способностями, чтобы сделать компьютеры более полезными для их основных пользователей — ученых и математиков.Его процесс согласования и интеграции, казалось бы, разрозненных талантов и навыков для достижения конкретной цели — решения проблем — был беспрецедентным. В команду входили инженеры, криптограф, шахматный волшебник, программисты и математики вроде Бэкуса. «В то время мы были хакерами, — вспоминал член команды Ричард Голдберг.

    Бэкус понимал, что инженерам нужен язык для кодирования собственных задач. Его раздражало то, что он считал «рукопашным боем» с компьютером и его очень трудоемким программированием.Несмотря на то, что он был программистом — недавно появившейся должности, которую даже он не понимал в то время, — Бэкус сказал, что ему «не нравилось писать программы, и поэтому, когда я работал над IBM 701 (первый компьютер), я писал программы для расчета траекторий ракет, я начал работу над системой программирования, чтобы упростить написание программ». Это будет называться «Скоростное кодирование».

    «Мы думали, что это хороший проект, но потом все сказали нам, что это невозможно», — вспоминает Бэкус. «Было ощущение, что мы действительно хотели их показать.

    Fortran разрабатывался в течение трех лет и завершился дебютной презентацией в феврале 1957 года на Western Joint Computer Conference в Лос-Анджелесе. В материалах этой конференции презентационный документ группы заключался в краткой форме: «Язык системы предназначен для выражения практически любой числовой процедуры».

    По словам Дж.А.Н. Ли, ведущим компьютерным историком», как сообщается в New York Times.

    «В первую очередь Fortran механизировал организацию циклов, — сказал Бэкус. Цикл, широко используемый в научной работе и при расчете заработной платы, представляет собой серию инструкций, повторяемых несколько раз, пока не будет достигнут определенный результат. Как писал Бэкус в научной статье 1979 года, его команда «продолжила поднимать вопрос: «Может ли машина перевести достаточно богатый математический язык в достаточно экономичную программу с достаточно низкими затратами, чтобы сделать все это возможным?»

    Руководители многих отраслей быстро осознали важность Фортрана благодаря его способности повышать производительность за счет сокращения времени и усилий, затрачиваемых на написание конкретных программных приложений.Банки начали использовать Fortran для создания интенсивных программ обработки чисел для оценки рисков, а страховые компании использовали его для создания актуарных таблиц. А поскольку другие поставщики компьютеров сделали его доступным для работы на своих машинах, используя стандарт IBM, Fortran уже на раннем этапе своей истории мог работать на разных операционных платформах и зарекомендовал себя как надежный.

    В 1975 году Бэкус был награжден Национальной медалью науки. Он был первым сотрудником IBM, получившим эту награду. Два года спустя он был награжден не менее престижной премией Тьюринга от Ассоциации вычислительной техники.Бэкус также был награжден премией Чарльза Старка Дрейпера Национальной инженерной академии, самой уважаемой наградой в отрасли.

    The Essence of Programming Languages ​​

    Актуально существует множество методологий, технологий, языков, методов, вариантов и т. д., которые могут использоваться в течение длительного времени для системных программных комплексов. В частности, число важных технических и языковых компонентов, включенных в состав репрезентативных аспектов относительной совместимости двух систем, и ла inmensa mayoría de las metodologías de análisis y diseño orientados a objetos incluyen componentes para la modelización estructural де компортамьенто.Esta situación es specialmente relay cuando la naturaleza del sistema que se ha de modellizar es esencialmente dinámica, tal como ocurre por ejemplo en lo sistemas reactivos o en lo sistemas de tiempo real. Пара ла modelización де Эсте типо де систем, се хан desarrollado distintosformalismos específicos, сказки como Statecharts о Redes де Петри, пункт лос дие су Вез се хан elaborado multitud де variantes. Esta compleja situación sugiere la conveniencia de disponer de un marco que Permita describir los conceptos esenciales ligados a la репрезентация де comportamiento мошенников independencia del lenguaje o técnica concreta que se utilice.Este Marco Allowiría эль estudio detallado де estos lenguajes о técnicas, siendo este un paso previo para el análisis posterior de Problemas Tales como comparación, адаптация, преобразование и т. д. De dichos lenguajes. En este trabajo se presenta una solucion a este Problema, a través de la introducción de una arquitectura genérica, denominada arquitectura NÓESIS. Como medio para abstraer las specialidades de cada lenguaje o técnica concreta, para el desarrollo de la arquitectura utilizaremos una perspectiva de metamodelización.Se ha demostrado Que el uso de la perspectiva de metamodelización es un medio válido para mejorar la usabilidad, comprensibilidad y legibilidad durante el estudio (анализ, анализ, сравнение, адаптация и т. д.) де lenguajes y técnicas. En concreto en este trabajo utilizamos una técnica de metamodelización concreta, la técnica NÓESIS, ilustrándola en primer término mediante un ejemplo de metamodelo del modelo de bases de datos RM/T. El uso de esta técnica junto con las directrices que proporciona la arquitectura NÓESIS nos han allowido desarrollar un metamodelo de Statecharts que recoge toda la potencia expresiva de esteformalismo, tanto en un sentido más cercano a los самим аспектам sintácticos como en los aspectos puramente de comportamiento.Como prueba de la versatilidad de la arquitectura NÓESIS, en este trabajo se incluye también un metamodelo of UML State Machines, la version orientada to objeto de Statecharts que ha sido incluida dentro de UML. Специфика этой другой метамодели определяется тем, как используется язык метамоделирования в соответствии с UML, и используется «официальное» определение этого языка. Estos ejemplos prueban Que la utilización de la arquitectura Noesis es independiente de la Perspectiva de metamodelización utilizada, siendo por tanto una herramienta гибкий пара-ла-представление де-аспектос-де-comportamiento.В настоящее время существует множество методологий, приемов, языков, методов, инструментов и т. д., которые можно использовать для разработки сложных программных систем. В частности, многие из этих методов и языков участвуют в представлении аспектов, связанных с поведением систем, и большинство методологий и языков объектно-ориентированного анализа и проектирования включают компоненты, посвященные структурному моделированию, наряду с другими компонентами, посвященными поведенческому моделированию. Эта ситуация особенно актуальна, когда моделируемая система по своей сути является динамической, как, например, в случае реактивных систем или систем реального времени.Несколько формализмов, таких как диаграммы состояний или сети Петри, были разработаны специально для моделирования таких систем, и было создано большое количество вариантов каждого из этих формализмов. Эта сложная ситуация предполагает полезность схемы, позволяющей описывать основные понятия, связанные с представлением поведения, независимо от каждой конкретной техники. Эта структура позволит подробно изучить эти языки и методы, и это исследование является предварительным шагом для анализа некоторых вопросов, касающихся этих языков, таких как сравнение, адаптация, преобразование и другие.В данной диссертации представлено решение этой проблемы путем введения общей архитектуры, называемой архитектурой NOESIS. Мы используем точку зрения метамоделирования, чтобы отделиться от особенностей каждого языка или техники. Метамоделирование все чаще используется в качестве инструмента разработки программного обеспечения и методов, и в литературе было доказано, что использование точки зрения метамоделирования эффективно для повышения удобства использования, понятности и удобочитаемости во время исследования (анализ, проектирование, сравнение, адаптация, и т. д.) языков и методов. В частности, в нашей работе мы используем особый метод метамоделирования, метод NOESIS. Мы объясняем основные конструкции этой техники с помощью метамодели модели базы данных RM/T. Использование техники NOESIS вместе с рекомендациями, которые предоставляет архитектура NOESIS, позволило нам разработать метамодель диаграмм состояний, которая полностью отражает выразительную силу этого формализма, аналогично синтаксическим аспектам, а также чисто поведенческим аспектам. аспекты.Чтобы доказать универсальность архитектуры NOESIS, в эту работу мы также включили метамодель машин состояний UML, объектно-ориентированную версию диаграмм состояний, собранных в UML. Следуя стилю определения UML, который использует сам UML, во второй метамодели мы использовали UML в качестве языка метамоделирования. Эти примеры доказывают, что архитектуру NOESIS можно использовать независимо от принятой точки зрения метамоделирования, и поэтому эта архитектура является гибким подходом к представлению поведенческих аспектов.

    Сущность и особенности программной инженерии

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

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

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

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

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

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

    Это должно быть тяжело? — Существенные трудности

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

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

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

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

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

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

    Рассмотрим неотъемлемые свойства этой неустранимой сущности современных программных систем: сложность, конформность, изменчивость и невидимость.

    Сложность

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

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

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

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

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

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

    Соответствие

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

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

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

    Изменяемость

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

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

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

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

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

    Невидимость

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

    Реальность программного обеспечения не встроена в пространство. Следовательно, у него нет готового геометрического представления, как у земли есть карты, у кремниевых чипов есть диаграммы, у компьютеров есть схемы соединений. Как только мы попытаемся изобразить структуру программного обеспечения, мы обнаружим, что она представляет собой не один, а несколько общих ориентированных графов, наложенных друг на друга.Несколько графиков могут представлять поток управления, поток данных, шаблоны зависимости, временную последовательность, отношения пространства имен. Эти графы обычно даже не планарны, а тем более иерархичны. Действительно, одним из способов установления концептуального контроля над такой структурой является принудительное сокращение ссылок до тех пор, пока один или несколько графов не станут иерархическими [1].

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

    Прорывы прошлого решили случайные трудности

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

    Языки высокого уровня

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

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

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

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

    Совместное использование времени

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

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

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

    Объединенная среда программирования

    Unix и Interlisp, первые интегрированные среды программирования, получившие широкое распространение, по-видимому, повысили производительность за счет интегральных факторов.Почему?

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

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

    Благодаря этим успехам среда является предметом многих современных исследований в области разработки программного обеспечения. Мы рассмотрим их обещания и ограничения в следующем разделе.

    Надежды на серебро

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

    Ада и другие усовершенствования языка высокого уровня

    Одной из самых разрекламированных последних разработок является Ada, универсальный язык высокого уровня 1980-х годов.Ада не только отражает эволюционные улучшения языковых концепций, но и воплощает в себе функции, поощряющие современный дизайн и модульность. Возможно, философия Ада является большим шагом вперед, чем язык Ада, поскольку это философия модульности, абстрактных типов данных, иерархического структурирования. Ада чрезмерно богата, что является естественным результатом процесса, в ходе которого к ее дизайну предъявлялись требования. Это не фатально, так как подмножество рабочих словарей может решить проблему обучения, а аппаратные усовершенствования дадут нам дешевые MIPS для оплаты затрат на компиляцию.Продвижение структурирования систем программного обеспечения действительно является очень хорошим применением увеличения MIPS, которое можно купить за наши доллары. Операционные системы, громко порицаемые в 1960-х годах за их память и затраты на цикл, оказались отличной формой для использования некоторых MIPS и дешевых байтов памяти прошлого аппаратного всплеска.

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

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

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

    Многие изучающие искусство возлагают больше надежд на объектно-ориентированное программирование, чем на какие-либо другие современные технические причуды [2]. Я среди них. Марк Шерман из Дартмута отмечает в CSnet News, что нужно быть осторожным, чтобы различать две отдельные идеи, которые идут под этим названием: абстрактные типы данных и иерархические типы . Концепция абстрактного типа данных заключается в том, что тип объекта должен определяться именем, набором правильных значений и набором правильных операций, а не его структурой хранения, которая должна быть скрыта.Примерами являются пакеты Ады (с приватными типами) и модули Модулы.

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

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

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

    Искусственный интеллект

    Многие люди ожидают, что достижения в области искусственного интеллекта обеспечат революционный прорыв, который приведет к значительному повышению производительности и качества программного обеспечения [3]. Я не. Чтобы понять, почему, мы должны проанализировать, что подразумевается под «искусственным интеллектом».

    Д.Л. Парнас прояснил терминологический хаос [4]:

      Сегодня широко используются два совершенно разных определения ИИ.AI-1: Использование компьютеров для решения проблем, которые раньше можно было решить только с помощью человеческого интеллекта. AI-2: Использование определенного набора методов программирования, известного как эвристическое или программирование на основе правил. В этом подходе эксперты-люди изучаются, чтобы определить, какие эвристики или эмпирические правила они используют при решении проблем … Программа предназначена для решения проблемы так, как ее решают люди.
      Первое определение имеет скользящее значение… Что-то может соответствовать определению ИИ-1 сегодня, но как только мы увидим, как работает программа, и поймем проблему, мы больше не будем думать об этом как об ИИ… К сожалению, я не могу определить набор технологий, уникальных для этой области… Большая часть работы связана с конкретными проблемами, и требуется некоторая абстракция или творчество, чтобы понять, как ее передать.

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

    Технология экспертных систем AI-2 заслуживает отдельного раздела.

    Экспертные системы

    Наиболее продвинутой частью искусства искусственного интеллекта и наиболее широко применяемой является технология построения экспертных систем.Многие ученые-программисты усердно работают над применением этой технологии в среде разработки программного обеспечения [3,5]. Какова концепция и каковы перспективы?

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

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

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

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

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

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

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

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

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

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

    «Автоматическое» программирование

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

    Парнас [4] подразумевает, что этот термин используется для обозначения гламура, а не семантического содержания, утверждая:

      Короче говоря, автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем тот, который был доступен программисту в настоящее время.

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

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

    Эти приложения имеют очень благоприятные свойства:

    • Задачи легко охарактеризовать относительно небольшим количеством параметров.

    • Существует много известных методов решения для предоставления библиотеки альтернатив.

    • Обширный анализ привел к четким правилам выбора методов решения с учетом параметров задачи.

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

    Графическое программирование

    Любимой темой для докторских диссертаций в области разработки программного обеспечения является графическое или визуальное программирование — применение компьютерной графики в разработке программного обеспечения [6,7]. Иногда перспективность такого подхода постулируется аналогией с проектированием микросхем СБИС, в которых компьютерная графика играет столь плодотворную роль.Иногда теоретик оправдывает свой подход, рассматривая блок-схемы как идеальное средство разработки программы и предоставляя мощные средства для их построения.

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

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

    Во-вторых, современные экраны слишком малы (в пикселях), чтобы отображать как объем, так и разрешение любой серьезной подробной диаграммы программного обеспечения. Так называемая «метафора рабочего стола» сегодняшней рабочей станции — это метафора «сиденье самолета». Любой, кто перетасовывал полные бумаги на коленях, сидя между двумя дородными пассажирами, заметит разницу — одновременно можно увидеть лишь очень немногое.Настоящий рабочий стол обеспечивает обзор и произвольный доступ к множеству страниц. Более того, известно, что во время сильных приступов творчества не один программист или писатель отказывались от рабочего стола в пользу более просторного пола. Аппаратная технология должна будет значительно продвинуться вперед, прежде чем объем наших возможностей станет достаточным для задачи разработки программного обеспечения.

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

    Проверка программы

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

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

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

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

    Окружающая среда и инструменты

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

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

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

    Рабочие станции

    Какие выгоды можно ожидать для искусства программного обеспечения от определенного и быстрого увеличения мощности и объема памяти отдельной рабочей станции? Итак, сколько MIPS можно использовать с пользой? Составление и редактирование программ и документов полностью поддерживаются сегодняшними скоростями. Компиляция может выдержать ускорение, но увеличение скорости машины в 10 раз, несомненно, сделает время на обдумывание доминирующим занятием программиста.Действительно, сейчас так кажется.

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

    Многообещающие атаки на концептуальную сущность

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

    Все технологические атаки на случайности программного процесса фундаментально ограничиваются уравнением производительности:

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

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

    Купить против сборки

    Наиболее радикальное решение для создания программного обеспечения — вообще не создавать его.

    С каждым днем ​​это становится проще, так как все больше и больше поставщиков предлагают все больше и больше лучших программных продуктов для головокружительного разнообразия приложений. Пока мы, инженеры-программисты, трудились над методологией производства, революция персональных компьютеров создала не один, а множество массовых рынков программного обеспечения.В каждом газетном киоске есть ежемесячные журналы, которые отсортированы по типам машин, рекламируют и пересматривают десятки продуктов по ценам от нескольких долларов до нескольких сотен долларов. Более специализированные источники предлагают очень мощные продукты для рабочих станций и других рынков Unix. Даже программные инструменты и среды можно купить в готовом виде. В другом месте я предложил торговую площадку для отдельных модулей [9].

    Любой такой продукт дешевле купить, чем строить заново. Даже при стоимости в сто тысяч долларов купленный программный продукт стоит примерно столько же, сколько один программисто-год.И доставка немедленная! Немедленно, по крайней мере, для продуктов, которые действительно существуют, продуктов, разработчик которых может порекомендовать продукты счастливому пользователю. Более того, такие продукты, как правило, гораздо лучше документированы и несколько лучше обслуживаются, чем программное обеспечение собственной разработки.

    Я считаю, что развитие массового рынка — это наиболее глубокая долгосрочная тенденция в программной инженерии. Стоимость программного обеспечения всегда была стоимостью разработки, а не стоимости репликации. Разделение этой стоимости даже между несколькими пользователями радикально снижает стоимость в расчете на одного пользователя.С другой стороны, использование 90 161 n 90 162 копий программной системы эффективно увеличивает производительность ее разработчиков на 90 161 n 90 162 . Это повышение производительности дисциплины и нации.

    Главный вопрос, конечно, в применимости. Могу ли я использовать доступный готовый пакет для выполнения своей задачи? Здесь произошла удивительная вещь. В течение 1950-х и 1960-х годов исследование за исследованием показывали, что пользователи не будут использовать готовые пакеты для расчета заработной платы, управления запасами, дебиторской задолженности и так далее.Требования были слишком специализированными, вариации от случая к случаю слишком велики. В 1980-х мы обнаружили, что такие пакеты пользуются большим спросом и широко используются. Что изменилось?

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

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

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

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

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

    Требования, уточнение и быстрое прототипирование

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

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

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

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

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

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

    Инкрементальная разработка — Растите, а не создавайте, Программное обеспечение

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

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

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

    Так должно быть и с нашими программными системами. Несколько лет назад Харлан Миллс предложил развивать любую программную систему путем постепенной разработки [10].То есть сначала нужно заставить систему работать, даже если она не делает ничего полезного, кроме вызова надлежащего набора фиктивных подпрограмм. Затем, шаг за шагом, он должен быть конкретизирован, а подпрограммы, в свою очередь, превращены в действия или вызовы пустых заглушек на уровне ниже.

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

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

    В больших проектах можно реализовать те же преимущества, что и в моих маленьких [11].

    Великие дизайнеры

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

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

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

    Различия не мелкие — они скорее похожи на различия между Сальери и Моцартом.Исследование за исследованием показывают, что самые лучшие дизайнеры создают конструкции, которые быстрее, меньше, проще, чище и с меньшими усилиями [12]. Различия между великим и средним подходом на порядок.

    Небольшое ретроспективное исследование показывает, что, хотя многие прекрасные и полезные программные системы были разработаны комитетами и созданы как часть многокомпонентных проектов, те программные системы, которые вызвали восторг у страстных поклонников, являются продуктами одного или нескольких дизайнерских умов, великих дизайнеров.Рассмотрим Unix, APL, Pascal, Modula, интерфейс Smalltalk и даже Fortran; и сравните их с Cobol, PL/1, Algol, MVS/370 и MS-DOS.

    Интересные товары
    Да
    Unix
    APL
    Pascal
    Modula
    Smalltalk
    Fortran
    Кобол
    PL/1
    Алгол
    MVS/370
    MS-DOS
    Таблица 1. Захватывающие vs.полезные, но малоинтересные программные продукты

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

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

    Как вырастить великих дизайнеров? Место не позволяет долго рассуждать, но некоторые шаги очевидны:

    • Как можно раньше систематически выявляйте лучших дизайнеров. Лучшие часто не самые опытные.

    • Назначьте карьерного наставника, который будет отвечать за развитие потенциального клиента, и тщательно ведите картотеку карьеры.

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

    • Предоставление развивающимся дизайнерам возможности взаимодействовать и стимулировать друг друга.

    Благодарности

    Я благодарю Гордона Белла, Брюса Бьюкенена, Рика Хейса-Рота, Роберта Патрика и, особенно, Дэвида Парнаса за их понимание и вдохновляющие идеи, а также Ребекку Бирли за техническое оформление статьи.

    Рекомендации

    1. Д.Л. Парнас, «Проектирование программного обеспечения для простоты расширения и сокращения», IEEE Trans.Программная инженерия , том 5 № 2, март 1979 г., стр. 128-138

    2. Г. Буч, «Объектно-ориентированное проектирование», Программная инженерия с Адой , 1983, Бенджамин Каммингс, Менло-Парк, Калифорния.

    3. IEEE Trans. Software Engineering (специальный выпуск по искусственному интеллекту и разработке программного обеспечения), J. Mostow, гостевое издание, Vol.11, No.11, ноябрь 1985 г.

    4. DL Парнас, «Программные аспекты систем стратегической обороны», , American Scientist , ноябрь 2016 г.1985

    5. Р. Бальцер, «15-летний взгляд на автоматическое программирование», IEEE Trans. Software Engineering (специальный выпуск по искусственному интеллекту и разработке программного обеспечения), J. Mostow, гостевое издание, Vol.18, No.8, август 1985 г.

    6. Computer (специальный выпуск по визуальному программированию), RB Graphton and Т. Итикава, приглашенные редакторы, том 18, № 8, август 1985 г.

    7. Г. Ридер, «Обзор современных методов графического программирования», Компьютер (специальный выпуск по визуальному программированию), Р.Б. Графтон и Т. Итикава, приглашенные редакторы, том 18, № 8, август 1985 г., стр. 11-25

    8. Ф. П. Брукс, Мифический человеко-месяц , 1975, Аддисон-Уэсли, Рединг, Mass., New York, Chapter 14

    9. Defense Science Board, Report of the Task Force on Military Software , в печати

    10. H.D. Миллс, «Программирование сверху вниз в больших системах», в Методы отладки в больших системах , Р.

    Добавить комментарий

    Ваш адрес email не будет опубликован.