Почему со временем неизбежно изменяются методы программирования

Почему со временем неизбежно изменяются методы программирования

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

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

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

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

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

Основные логические структуры описаны нами ранее:

• следование — последовательность операторов, групп операторов, выполняемых друг за другом в порядке их следования в тексте программы;

• ветвление — управляющая структура, которая в зависимости от выполнения заданного условия определяет выбор для исполнения одного из двух или более заданных в этой структуре групп операторов;

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

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

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

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

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

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

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

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

&nbspпредыдущая &nbsp &nbsp &nbsp &nbsp&nbspменю &nbsp &nbsp &nbsp &nbspвверх &nbsp &nbsp &nbsp &nbsp&nbspследующая

§ 46. Что такое ООП?

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

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

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

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

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

В конце 60-х годов XX века появилась новая идея — применить в разработке программ тот подход, который использует человек в повседневной жизни. Люди воспринимают мир как множество объектов — предметов, животных, людей — это отмечал ещё в XVII веке французский математик и философ Рене Декарт. Все объекты имеют внутреннее устройство и состояние, свойства (внешние характеристики) и поведение. Чтобы справиться со сложностью окружающего мира, люди часто не вникают в детали внутреннего устройства и игнорируют многие свойства объектов, ограничиваясь лишь теми, которые необходимы для решения их практических задач. Такой приём называется абстракцией.
Абстракция — это выделение существенных характеристик объекта, отличающих его от других объектов.

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

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

Здесь А, Б, В и Г — объекты «верхнего уровня»; Бг, Б2 и Б3 — под объекты объекта Б и т. д.

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

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

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

© Вопросы и задания

1. Почему со временем неизбежно изменяются методы программирования?

2. Что такое декомпозиция, зачем она применяется?

3. Что такое процедурное программирование? Какой вид декомпозиции в нём используется?

4. Какие проблемы в программировании привели к появлению ООП?

5. Как выполняется декомпозиция алгоритмов в процедурных языках программирования?

6. Что такое абстракция? Зачем она используется в обычной жизни?

7. Объясните, как связана абстракция с моделированием.

8. Какие преимущества даёт объектный подход в программировании?

9. Какой вид декомпозиции используется в ООП?

10. Что такое интерфейс? Приведите примеры объектов, у которых одинаковый интерфейс и разное устройство.

а) «Проблемы процедурного программирования»

б) «Глобальные переменные: за и против»

в) «ООП: достоинства и недостатки»

Язык(и) программирования будущего

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

• Какая технология придет на смену JavaScript?
• Есть ли у Kotlin шанс заменить Java?
• Заменит ли Rust язык C++?
• У какого языка на замену C, если выбирать между D, Go и Rust, самые большие перспективы?

Особенно мне нравится последний вопрос, потому что человек, задавший его, настолько убежден в бесславном конце C, что привел готовые альтернативы. Мне кажется, что подобные вопросы стали возникать чаще, чем раньше, с момента публикации академического документа Energy Efficiency across Programming Languages: Как соотносятся энергия, время и память». (При желании можно ознакомиться с текстом здесь). Полагаю, все эти вопросы по факту сводятся к одному: каким будет язык (или языки) программирования будущего? Сегодня, опираясь на результаты из упомянутого выше документа и анализируя иную статистическую информацию, мы попытаемся разобраться в этом вопросе. Но прежде, чем начать, я хочу уверить вас, что буду максимально объективен, поскольку не хочу выдавать желаемое за действительное. Давайте начнем с самого главного: того самого документа.

Документ

Если вы все-таки дочитали до этого места, я почти уверен, что вы видели таблицу, приведенную ниже:

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

Прежде всего, следует задуматься о том, как измерялись перечисленные в таблице показатели. Как правило, для измерения производительности процессоров применяются бенчмарки. Для оценки языков программирования авторы написали свои бенчмарки из 10 разных задач, при этом для их решения был использован один и тот же алгоритм, приведенный в Computer Language Benchmark Game.

Кроме того, языки программирования были распределены по категориям на основании их парадигмы:

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

Следующий шаг — проведение тестов CLBG. Авторы поделились результатами нескольких испытаний. Давайте посмотрим на них.

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

Когда я впервые увидел таблицу, представленную выше, в социальных сетях, я подумал, что сортировкой по времени выполнения почему-то пренебрегли. Оказывается, авторы ее указали только для ряда репрезентативных тестов. К примеру, в тесте с бинарным деревом C, C++ и Rust дали наилучшие результаты, но с точки зрения памяти Rust показал несколько худшую производительность. С другой стороны, то же самое относится к C в бенчмарке fannkuch-redux. Так что не всё так однозначно.

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

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

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

Язык C в итоге кажется наилучшим с точки зрения энергопотребления и производительности, но проигрывает по использованию памяти. Впрочем, даже в отношении памяти он совсем не плох. Далее следуют Rust и C++. Можно сказать, что C и Rust являются лучшими языками программирования в ми. Минуточку! Они же не поддерживают объектно-ориентированное программирование. (Вы могли бы подумать, что Rust поддерживает ООП, но фактически в нем есть только интерфейсы (вернее, трейты), но не вся ООП-структура). Тем не менее, в организациях, как правило, активно используется ООП, не говоря уже о важности удобства использования языка. C, C++ и Rust не так уж просты, они заставляют думать о времени жизни объектов, динамическом распределении и т.д.

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

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

Статистика Google

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

Похоже, Java по-прежнему используется чаще, чем другие компилируемые языки, хотя показатели значительно снизились. C и C++ идут вплотную друг к другу. А вот Rust оказался на самом дне. Возможно, это связано с тем, что это новый язык, но справедливости ради следует отметить, что Rust нов лишь на фоне C и C++. Он вышел в июле 2010 года. Прошло почти 12 лет, и с тех пор не произошло никаких заметных изменений. Результаты этой статистики сильно отличаются от тех, что мы видели ранее. Давайте теперь возьмем Java и еще 4 языка: Kotlin, Javascript, Python и Go.

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

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

Индекс TIOBE

TIOBE — это компания, специализирующаяся на оценке и отслеживании качества программного обеспечения. Чтобы узнать о ней больше, посетите их сайт. Их главная услуга — проверка качества кодовой базы программного обеспечения. Они создали показатель под названием TQI (TIOBE Quality Indicator), и ниже приведен пример его использования.

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

На основании этого индекса ниже я приведу актуальные результаты:

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

Ясно, что Java долгое время доминировал в этой среде наряду с С. Однако Python набирает все большую популярность и выходит в лидеры. Здесь следует обратить внимание на один важный момент: Тенденции постоянно меняются. Java был первым, но теперь его место занял Python, хотя до 2010 года о нем мало кто слышал. В этой связи возникает вопрос, как можно оценить будущий потенциал языков программирования?

Оценка потенциальных возможностей

В последние 10 лет машинное обучение и искусственный интеллект стали очень популярны. Язык Python оказался наиболее оптимальным для подобных операций, поскольку в нем есть хороший API для языка C, а если вам нужна производительность, можно комбинировать его с C и C++. В этом направлении Python стал самым используемым языком в мире согласно поисковым трендам и индексам.

Однако это не означает, что Python сохранит свое место. Некоторые другие языки могут показать лучшую производительность, чем Python, и вытеснить его. Например, возьмем язык Rust. Amazon и Facebook заявили, что они начали использовать Rust для разработки своих внутренних инструментов CLI (интерфейс командной строки). Кроме того, ядро Linux, начиная с версии 6.1, включает Rust. Это очень значительный объем поддержки для языка программирования, и, мы видим, всего за год он поднялся с 26-го места на 20-е.

Но главный вопрос все еще остается без ответа. Как же нам предсказать будущее?

Ответ

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

Зачем же мы это делаем? Фанатично поддерживаем язык или какую-то технологию? Универсальный ответ: потому что мы ленивы. Мы изучаем язык программирования или технологию, затем формируем зону комфорта в рамках этих инструментов. А потом не хотим менять их, чтобы не выходить за пределы зоны комфорта. Люди, которые слишком фанатично поддерживают C и C++, делают это потому, что они не хотят учить новый язык, например, Rust, с нуля. Люди, которые чересчур рьяно выступают за Rust, делают это потому, что не хотят учить C и C++, так как они сложноваты и в них есть много вещей, с которыми нужно быть осторожным. Я думаю, что оба эти подхода ошибочны и неправильны, и мы не должны совершать эту ошибку.

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

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

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

• языки программирования
• сравнение

• Блог компании ISPsystem
• Программирование

Некоторые малоизвестные факты о программировании

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

Программист тратит 10-20% своего времени на написание собственно кода, и большинство программистов пишут всего 10-12 строк кода в день, которые попадают в конечный продукт, независимо от их уровня. Хорошие программисты тратят большую часть оставшихся 90% времени на размышления, исследования и эксперименты в поисках наилучшего решения. Плохие программисты тратят это время на отладку, случайные изменения в коде и последующую проверку его на работоспособность.

«Хороший токарь работает в несколько раз лучше среднего, но хороший программист стоит в 10000 раз больше, чем обычный»
Билл Гейтс.

Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний. И это не преувеличение — исследования, проводящиеся с 1960-х годов, чётко это показывают. Плохой программист не просто непродуктивен: он не только не выполняет свою работу, но ещё и создаёт проблемы, которые приходится решать другим.

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

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

В исследовании 2004-го года было обнаружено, что большая часть программных проектов (51%) сталкиваются с критическими проблемами (срыв сроков, превышение бюджета, невыполнение обязательств, нарушения функционала и т.п. — прим. пер.), а 15% полностью проваливаются. Это лучше, чем в 1994-м, когда последних было 31%.

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

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

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

• программирование
• производительность труда
• архитектура приложений
• факты
• работа