From 641ea76f8538941c763ac3a4e13b680a8d12f723 Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:03:18 +0300 Subject: [PATCH 1/6] Fix punctuatio in 1-1-Approach.md --- content/ru/1-1-Approach.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ru/1-1-Approach.md b/content/ru/1-1-Approach.md index 4d0d924..1c0f679 100644 --- a/content/ru/1-1-Approach.md +++ b/content/ru/1-1-Approach.md @@ -4,11 +4,11 @@ > Главные навыки программиста — это чтение и исправление кода -Каждая тема содержит примеры хорошего кода и плохого кода. Эти примеры собраны из практики программирования и ревью проектов. Специально заготовленные примеры плохого кода будут работоспособны, но полны антипаттернов и проблем, которые нужно выявить и исправить. Даже самая первая практическая работа в курсе будет связана с исправлением кода, повышением его читабельности. Если давать традиционные задания (написать функцию по сигнатуре, алгоритм, класс), то начинающий, очевидно, реализует его не лучшим образом, но будет защищать свой код, потому что это первое, что он написал. А если задача будет "взять пример чужого плохого кода, найти проблемы и исправить", не переписать с нуля, а улучшить в несколько шагов, фиксируя и осознавая эти шаги, то включается критический подход. +Каждая тема содержит примеры хорошего кода и плохого кода. Эти примеры собраны из практики программирования и ревью проектов. Специально заготовленные примеры плохого кода будут работоспособны, но полны антипаттернов и проблем, которые нужно выявить и исправить. Даже самая первая практическая работа в курсе будет связана с исправлением кода, повышением его читабельности. Если давать традиционные задания (написать функцию по сигнатуре, алгоритм, класс), то начинающий, очевидно, реализует их не лучшим образом, но будет защищать свой код, потому что это первое, что он написал. А если задача будет "взять пример чужого плохого кода, найти проблемы и исправить", не переписать с нуля, а улучшить в несколько шагов, фиксируя и осознавая эти шаги, то включается критический подход. > Исправление плохого кода — один из самых эффективных способов обучения -Начинающий получает примеры ревью кода и по аналогии стремится исправить и свое задание. Такие итерации повторяются много раз, не теряя критичного настроя. Очень хорошо, если будет наставник, который наблюдает за улучшениями, и может корректировать и подсказывать. Но наставник ни в коем случае не должен делать работу за новичка, а скорее наталкивать его на то, как нужно думать о программировании и где искать решение. +Начинающий получает примеры ревью кода и по аналогии стремится исправить и свое задание. Такие итерации повторяются много раз, не теряя критичного настроя. Очень хорошо, если будет наставник, который наблюдает за улучшениями и может корректировать и подсказывать. Но наставник ни в коем случае не должен делать работу за новичка, а скорее наталкивать его на то, как нужно думать о программировании и где искать решение. > Наставник — незаменим на любом этапе профессионального роста From e13dd63a59a38faf76c78d1e761b59bcbf6f5fc4 Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:04:37 +0300 Subject: [PATCH 2/6] Fix punctuatio in 1-2-Examples.md --- content/ru/1-2-Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ru/1-2-Examples.md b/content/ru/1-2-Examples.md index 05e3c48..dfa82b6 100644 --- a/content/ru/1-2-Examples.md +++ b/content/ru/1-2-Examples.md @@ -1,6 +1,6 @@ ## 1.2. Примеры на языках JavaScript, Python и C -Примеры кода мы будем писать на разных языках, но предпочтение будет отдаваться не самым лучшим, красивым и быстрым, а тем, без которых нельзя обойтись. Мы возьмем `JavaScript`, как самый распространенный, `Python`, потому что есть области, где без него нельзя и `C`, как язык достаточно близкий к ассемблеру, все еще актуальный и оказавший самое большое влияние на современные языки по синтаксису и по заложенным в него идеям. Все три очень далеки от языка моей мечты, но это то, что у нас есть. На первый взгляд `Python` очень отличается от `JavaScript` и других C-подобных языков, хотя это только на первый взгляд, мы покажем, что он очень похож на `JavaScript` из-за того, что система типов, структуры данных, а особенно, встроенные коллекции в них очень похожи. Хоть синтаксически, различие в организации блоков кода при помощи отступов и фигурных скобок `{}` бросается в глаза, но на деле, такое различие не очень значимо, а между `JavaScript` и `Python` гораздо больше общего, чем у обоих с языком `C`. +Примеры кода мы будем писать на разных языках, но предпочтение будет отдаваться не самым лучшим, красивым и быстрым, а тем, без которых нельзя обойтись. Мы возьмем `JavaScript`, как самый распространенный, `Python`, потому что есть области, где без него нельзя, и `C`, как язык достаточно близкий к ассемблеру, все еще актуальный и оказавший самое большое влияние на современные языки по синтаксису и по заложенным в него идеям. Все три очень далеки от языка моей мечты, но это то, что у нас есть. На первый взгляд `Python` очень отличается от `JavaScript` и других C-подобных языков, хотя это только на первый взгляд, мы покажем, что он очень похож на `JavaScript` из-за того, что система типов, структуры данных, а особенно, встроенные коллекции в них очень похожи. Хоть синтаксически, различие в организации блоков кода при помощи отступов и фигурных скобок `{}` бросается в глаза, но на деле, такое различие не очень значимо, а между `JavaScript` и `Python` гораздо больше общего, чем у обоих с языком `C`. Начнем мы не с изучения синтаксиса, а сразу с чтения плохого кода и поиску в нем ошибок. Давайте посмотрим следующие фрагменты, первый будет на `JavaScript`: From b6c370448715d1ce9073d3579247277656324b5c Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:05:32 +0300 Subject: [PATCH 3/6] Fix punctuatio in 1-3-Modeling.md --- content/ru/1-3-Modeling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ru/1-3-Modeling.md b/content/ru/1-3-Modeling.md index 8f0dcb5..9e187a9 100644 --- a/content/ru/1-3-Modeling.md +++ b/content/ru/1-3-Modeling.md @@ -2,9 +2,9 @@ В основе любого программирования лежит моделирование, то есть создание модели решения задачи или модели объектов и процессов в памяти машины. Языки программирования предоставляют синтаксисы для конструирования ограничений при создании моделей. Любая конструкция и структура, призванная расширить функциональность и введенная в модель, приводит к дополнительным ограничениям. Повышение же уровня абстракции, наоборот, может снимать часть ограничений и уменьшать сложность модели и кода программы, выражающего эту модель. Мы все время балансируем между расширением функций и сверткой их в более обобщенную модель. Этот процесс может и должен быть многократно итеративным. -Удивительно, но человек способен успешно решать задачи, сложность которых превышает возможности его памяти и мышления, при помощи построения моделей и абстракций. Точность этих моделей определяет их пользу для принятия решений и выработки управляющих воздействий. Модель всегда не точна и отображает только малую часть реальности: одну или несколько ее сторон или аспектов. Однако, в ограниченных условиях использования, модель может быть неотличимой от реального объекта предметной области. Есть физические, математические, имитационные и другие модели, но нас будут интересовать, в первую очередь, информационные и алгоритмические модели. +Удивительно, но человек способен успешно решать задачи, сложность которых превышает возможности его памяти и мышления, при помощи построения моделей и абстракций. Точность этих моделей определяет их пользу для принятия решений и выработки управляющих воздействий. Модель всегда не точна и отображает только малую часть реальности: одну или несколько ее сторон или аспектов. Однако, в ограниченных условиях использования модель может быть неотличимой от реального объекта предметной области. Есть физические, математические, имитационные и другие модели, но нас будут интересовать, в первую очередь, информационные и алгоритмические модели. -Абстракция — это способ обобщения, сводящий множество различных, но схожих между собой случаев, к одной модели. Нас интересуют абстракции данных и абстрактные алгоритмы. Самые простые примеры абстракции в алгоритмах — это циклы (итерационное обобщение) и функции (процедуры и подпрограммы). При помощи цикла мы можем описать множество итераций одним блоком команд, предполагая его повторяемость несколько раз, с разными значениями переменных. Функции так же повторяются много раз с разными аргументами. Примеры абстракции данных — это массивы, ассоциативные массивы, списки, множества и т.д. В приложениях абстракции нужно объединять в уровни — слои абстракций. Низкоуровневые абстракции встроены в язык программирования (переменные, функции, массивы, события). Абстракции более высокого уровня содержатся в программных платформах, рантаймах, стандартных библиотеках, и внешних библиотеках или их можно построить самостоятельно из простых абстракций. Абстракции так называются потому, что решают абстрактные обобщенные задачи общего назначения, не связанные с предметной областью. +Абстракция — это способ обобщения, сводящий множество различных, но схожих между собой случаев, к одной модели. Нас интересуют абстракции данных и абстрактные алгоритмы. Самые простые примеры абстракции в алгоритмах — это циклы (итерационное обобщение) и функции (процедуры и подпрограммы). При помощи цикла мы можем описать множество итераций одним блоком команд, предполагая его повторяемость несколько раз, с разными значениями переменных. Функции так же повторяются много раз с разными аргументами. Примеры абстракции данных — это массивы, ассоциативные массивы, списки, множества и т.д. В приложениях абстракции нужно объединять в уровни — слои абстракций. Низкоуровневые абстракции встроены в язык программирования (переменные, функции, массивы, события). Абстракции более высокого уровня содержатся в программных платформах, рантаймах, стандартных библиотеках и внешних библиотеках или их можно построить самостоятельно из простых абстракций. Абстракции так называются потому, что решают абстрактные обобщенные задачи общего назначения, не связанные с предметной областью. Построение слоев абстракций — это чуть ли не самая важная задача программирования от удачного решения которой зависят такие характеристики программного решения, как гибкость настройки, простота модификации, способность к интеграции с другими системами и период жизни решения. Все слои, которые не привязаны к предметной области и конкретным прикладным задачам, мы будем называть системными. Над системными слоями программист надстраивает прикладные слои, абстракция которых наоборот снижается, универсальность уменьшается и конкретизируется применение, привязываясь к конкретным задачам. From 949fa3355ee9c044bb36167fbe9f8b532b229f9a Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:36:58 +0300 Subject: [PATCH 4/6] Fix punctuatio in 1-4-Program.md --- content/ru/1-4-Program.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/content/ru/1-4-Program.md b/content/ru/1-4-Program.md index 4c0a116..9273491 100644 --- a/content/ru/1-4-Program.md +++ b/content/ru/1-4-Program.md @@ -4,11 +4,11 @@ > Алгоритм (Algorithm) -Алгоритм это еще не программа, это идея решения задачи, описанная формально. Так, чтобы она была понятна другим, проверяема и реализуема. Алгоритм нельзя запустить, его можно преобразовать в код на каком-то языке программирования. Алгоритм содержит описание операций и может быть записан разными способами: формулой, блок-схемой, списком действий на человеческом языке. Он всегда ограничен конкретным классом задач, которые он решает за конечное время. Часто мы можем упростить и оптимизировать алгоритм, сузив класс задач. Например, переходя от вычисления суммы целых и дробных чисел к вычислению суммы только целых, мы можем сделать более эффективную реализацию. Можно и расширить класс задач для этого примера, разрешив подавать на вход еще и строчные представления чисел. Это сделает алгоритм более универсальным, но менее эффективным. Мы должны выбирать, что именно мы оптимизируем. В данном случае лучше разделить алгоритм на два, один будет приводить все числа к одному типу данных, а второй складывать. +Алгоритм — это еще не программа, это идея решения задачи, описанная формально. Так, чтобы она была понятна другим, проверяема и реализуема. Алгоритм нельзя запустить, его можно преобразовать в код на каком-то языке программирования. Алгоритм содержит описание операций и может быть записан разными способами: формулой, блок-схемой, списком действий на человеческом языке. Он всегда ограничен конкретным классом задач, которые он решает за конечное время. Часто мы можем упростить и оптимизировать алгоритм, сузив класс задач. Например, переходя от вычисления суммы целых и дробных чисел к вычислению суммы только целых, мы можем сделать более эффективную реализацию. Можно и расширить класс задач для этого примера, разрешив подавать на вход еще и строчные представления чисел. Это сделает алгоритм более универсальным, но менее эффективным. Мы должны выбирать, что именно мы оптимизируем. В данном случае лучше разделить алгоритм на два, один будет приводить все числа к одному типу данных, а второй складывать. > Пример реализации алгоритма НОД (GCD) -На `JavaScript` алгоритм Евклида, для нахождение НОД (общей меры или наибольшего общего делителя) можно написать так: +На `JavaScript` алгоритм Евклида для нахождения НОД (общей меры или наибольшего общего делителя) можно написать так: ```js const gcd = (a, b) => { @@ -17,7 +17,7 @@ const gcd = (a, b) => { }; ``` -Или даже короче, но станет не менее понятно, если вы сравните два эти варианта и проследите какие конструкции заменены: +Или даже короче, но станет не менее понятно, если вы сравните два эти варианта и проследите, какие конструкции заменены: ```js const gcd = (a, b) => (b === 0 ? a : gcd(b, a % b)); @@ -27,29 +27,29 @@ const gcd = (a, b) => (b === 0 ? a : gcd(b, a % b)); > Программа (Program) -В предыдущем примере мы имели дело с функцией, это часть программы, но чтобы она заработала, ее нужно вызвать и передать ей данные. Программный код и данные, объединенные в одно целое, это и есть программа. У Никлауса Вирта, автора многих языков, в том числе и Pascal, есть книга «Алгоритмы + Структуры данных = Программы». Ее название схватило очень важную истину, которая глубоко запечатлилась не только в мировоззрении читателей, но и в названиях курсов в ведущих ВУЗах, и даже на собеседованиях, когда испытуемого просят сконцентрироваться именно на этих двух вещах. За первые 50 лет существования индустрии программного обеспечения, оказалось, что структуры данных не менее важны, чем алгоритмы. Более того, многие известные программисты делают на них основную ставку, например, известна цитата Линуса Торвальдса: «Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и связях между ними». Дело в том, что выбор структур данных во многом предопределяет то, каким будет алгоритм, ограничивает его в рамках вычислительной сложности и семантики задачи, которую программист понимает через данные, разложенные в памяти, гораздо лучше, чем через последовательность операций. +В предыдущем примере мы имели дело с функцией (это часть программы), но чтобы она заработала, ее нужно вызвать и передать ей данные. Программный код и данные, объединенные в одно целое, это и есть программа. У Никлауса Вирта, автора многих языков, в том числе и Pascal, есть книга «Алгоритмы + Структуры данных = Программы». Ее название схватило очень важную истину, которая глубоко запечатлилась не только в мировоззрении читателей, но и в названиях курсов в ведущих ВУЗах, и даже на собеседованиях, когда испытуемого просят сконцентрироваться именно на этих двух вещах. За первые 50 лет существования индустрии программного обеспечения оказалось, что структуры данных не менее важны, чем алгоритмы. Более того, многие известные программисты делают на них основную ставку, например, известна цитата Линуса Торвальдса: «Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и связях между ними». Дело в том, что выбор структур данных во многом предопределяет то, каким будет алгоритм, ограничивает его в рамках вычислительной сложности и семантики задачи, которую программист понимает через данные, разложенные в памяти, гораздо лучше, чем через последовательность операций. Эрик Рэймонд выразил это так: «Умные структуры данных и тупой код работают куда лучше, чем наоборот». > Код позволяет найти общий язык -Однако, тот же Линус Торвальдс сказал нам еще и «Болтовня ничего не стоит. Покажите мне код». Это совсем не противоречит сказанному выше. Я думаю, что тут он имел в виду то, что программный код не допускает двусмысленности. Это универсальный язык, который позволяет программистам находить общий язык даже тогда, когда естественные языки, из-за своей многозначности не позволяют точно понять друг друга, можно сделать это просто взглянув на код. +Однако, тот же Линус Торвальдс сказал нам еще, что «Болтовня ничего не стоит. Покажите мне код». Это совсем не противоречит сказанному выше. Я думаю, что тут он имел в виду то, что программный код не допускает двусмысленности. Это универсальный язык, который позволяет программистам находить общий язык даже тогда, когда естественные языки из-за своей многозначности не позволяют точно понять друг друга; можно сделать это, просто взглянув на код. > Инженерия (Engineering) -Извлечение практической пользы из имеющихся ресурсов при помощи науки, техники, различных методик, организационной структуры, приемов и знаний это следующий уровень — инженерия. +Извлечение практической пользы из имеющихся ресурсов при помощи науки, техники, различных методик, организационной структуры, приемов и знаний — это следующий уровень, инженерия. Я помню, что в первые годы изучения программирования для меня уже было важно, чтобы код использовался людьми, улучшал их жизнь и сам жил долго. Олимпиадные задачи казались мне неинтересными, учебные задачи слишком надуманными, хотелось сконцентрироваться на том, что люди будут запускать на своих компьютерах каждый день: приложения баз данных, формы и таблицы, сетевые и коммуникационные приложения, программы, управляющие аппаратурой, работающие с датчиками, и множество инструментов для самих программистов. -Так же, как и в других инженерных отраслях, в программировании очень важна польза для человека, а не правильность и или стройность концепции. Инженерия призвана использовать научные достижения, а в тех местах, где научных знаний, имеющихся на сегодня, недостаточно, инженерия применяет интуицию, инженерную культуру, метод проб и ошибок, применение неосознанного опыта и опыта, имеющего недостаточное научное осмысление. +Так же, как и в других инженерных отраслях, в программировании очень важна польза для человека, а не правильность или стройность концепции. Инженерия призвана использовать научные достижения, а в тех местах, где научных знаний, имеющихся на сегодня, недостаточно, инженерия применяет интуицию, инженерную культуру, метод проб и ошибок, применение неосознанного опыта и опыта, имеющего недостаточное научное осмысление. -В этом и преимущество инженерии и недостаток. Мы имеем множество разных и противоречивых решений одной задачи, мы не всегда знаем почему что-то не работает, но это еще ладно, мы иногда удивляемся, почему что-то работает. Такой подход приводит к накоплению плохих практик в проектах и такому переплетению хороших и плохих практик, что разделить их очень сложно и часто усилия тратятся повторно на уже решенные задачи. Никлаус Вирт сказал «Программы становятся медленнее быстрее, чем "железо" становится быстрее» и мы часто сталкиваемся с тем, что написать программу заново проще, чем исправлять в ней ошибки. +В этом и преимущество инженерии и недостаток. Мы имеем множество разных и противоречивых решений одной задачи, мы не всегда знаем, почему что-то не работает, но это еще ладно, мы иногда удивляемся, почему что-то работает. Такой подход приводит к накоплению плохих практик в проектах и такому переплетению хороших и плохих практик, что разделить их очень сложно и часто усилия тратятся повторно на уже решенные задачи. Никлаус Вирт сказал: «Программы становятся медленнее быстрее, чем "железо" становится быстрее», и мы часто сталкиваемся с тем, что написать программу заново проще, чем исправлять в ней ошибки. > Инженерия программного обеспечения (Software engineering) Приложение инженерии к индустрии программного обеспечения включает архитектуру, исследование, разработку, тестирование, развертывание и поддержку ПО. -Индустрия программного обеспечения превратилась в мощную отрасль промышленности, обросла вспомогательными технологическими практиками, которые позволяют уменьшить влияние ее недостатков, уже приведенных выше и сделать конечный продукт достаточно надежным, чтобы он приносил прибыль, но недостаточно качественным, чтобы можно было выпускать все новые и новые его версии. +Индустрия программного обеспечения превратилась в мощную отрасль промышленности, обросла вспомогательными технологическими практиками, которые позволяют уменьшить влияние ее недостатков, уже приведенных выше, и сделать конечный продукт достаточно надежным, чтобы он приносил прибыль, но недостаточно качественным, чтобы можно было выпускать все новые и новые его версии. «Большинство программ на сегодняшний день подобны египетским пирамидам из миллиона кирпичиков друг на друге и без конструктивной целостности — они просто построены грубой силой и тысячами рабов» // Алан Кей @@ -61,24 +61,24 @@ const gcd = (a, b) => (b === 0 ? a : gcd(b, a % b)); Если выделить из программирования только написание исходного кода программы при помощи определенного синтаксиса (языка), стиля и парадигмы по готовому ТЗ (техническому заданию), то мы называем это кодированием, хоть слово можно считать устаревшим. -Разработка может быть разделена на проектирование и кодирование, и это дает более эффективное приложение сил на долгой дистанции, но часто приходится начинать программировать без ТЗ и без предварительного проектирования. Разработанные таким образом системы называются прототипами, MVP (minimum viable product), пилотными системами или стендами. Их польза заключается в проверке гипотез о полезности для потребителя или экономической эффективности их использования. +Разработка может быть разделена на проектирование и кодирование — и это дает более эффективное приложение сил на долгой дистанции, но часто приходится начинать программировать без ТЗ и без предварительного проектирования. Разработанные таким образом системы называются прототипами, MVP (minimum viable product), пилотными системами или стендами. Их польза заключается в проверке гипотез о полезности для потребителя или экономической эффективности их использования. -Программист не всегда осознает, что он делает, прототип или продукт, и мы получаем прототип, сделанный так добротно, как готовый продукт, или готовый продукт, сделанный как временное решение. Тем не менее, есть энтузиасты, которые любят свою работу, и именно на них держится эта отрасль, противоречивая и полная проблем. +Программист не всегда осознает, что он делает, прототип или продукт — и мы получаем прототип, сделанный так добротно, как готовый продукт, или готовый продукт, сделанный как временное решение. Тем не менее, есть энтузиасты, которые любят свою работу, и именно на них держится эта отрасль, противоречивая и полная проблем. «Большинство хороших программистов делают свою работу не потому, что ожидают оплаты или признания, а потому что получают удовольствие от программирования» // Линус Торвальдс > Разработчик vs программист -Есть сторонники каждого из названий, часто самоназвание `разработчик` или `программист` связано с особой профессиональной гордостью и даже надменным отношением к сторонникам другого названия. Было бы хорошо разделить эти профессии примерно так же, как разделились профессии водителя и автомеханика. Конечно, автомеханик может говорить, что водители ничего не смыслят в автомобилях, но массово людей возят именно водители. Так же и в ИТ, программист должен концентрироваться на абстракциях и создании программных компонентах, а разработчик — на применении готовых компонентов к задаче, что требует и других знаний и навыков, кроме программирования. +Есть сторонники каждого из названий, часто самоназвание `разработчик` или `программист` связано с особой профессиональной гордостью и даже надменным отношением к сторонникам другого названия. Было бы хорошо разделить эти профессии примерно так же, как разделились профессии водителя и автомеханика. Конечно, автомеханик может говорить, что водители ничего не смыслят в автомобилях, но массово людей возят именно водители. Так же и в ИТ, программист должен концентрироваться на абстракциях и создании программных компонентов, а разработчик — на применении готовых компонентов к задаче, что требует и других знаний и навыков кроме программирования. -Разницу между программистом и разработчиком можно показать на примере создания информационных систем (ИС). В мире существует потребность массового производства ИС для обеспечения нужд промышленности, транспорта, сферы обслуживания, логистики, торговли, медицины и т.д. Но сейчас информационные системы (ИС) – это дорогое удовольствие и для их разработки нужны высококвалифицированные кадры. ИС, как класс систем, подразумевает базы данных, пользовательские интерфейсы и бизнес-логику. Почти всегда ИС нуждается в интеграции с другими ИС. Таким образом, для разработки ИС нужны знания по СУБД (SQL или noSQL), фронтэнд (формы, UI/UX), бэкэнд (сервер приложений) и API. Поэтому ИС имеют большую стоимость владения, а эксплуатация связана с высокими рисками. Ведь ИС создают универсальные инженеры-программисты, которые пишут для каждой ИС много системного кода с нуля. Если разделить прикладное и системное программирование на две разные специальности и использовать высокоуровневую платформу, которую сделали системные программисты, то мы сможем переиспользовать до 80% кода в разных системах. Прикладные программисты, (т.е. разработчики) смогут тогда сосредоточиться только на задачах, связанных со спецификой предметной области. Это существенно снижает требования к прикладным программистам, а использование принципов свободного программного обеспечения, позволяет объединить усилия по созданию платформы и исключить риски, связанные с владением платформой. Open source лицензии не дают вендорам произвольно менять свою политику по отношению к потребителям и системным интеграторам, потому, что они не имеют блокирующего контроля над платформой и могут быть заменены конкурентами. +Разницу между программистом и разработчиком можно показать на примере создания информационных систем (ИС). В мире существует потребность массового производства ИС для обеспечения нужд промышленности, транспорта, сферы обслуживания, логистики, торговли, медицины и т.д. Но сейчас информационные системы (ИС) — это дорогое удовольствие и для их разработки нужны высококвалифицированные кадры. ИС как класс систем подразумевает базы данных, пользовательские интерфейсы и бизнес-логику. Почти всегда ИС нуждается в интеграции с другими ИС. Таким образом, для разработки ИС нужны знания по СУБД (SQL или noSQL), фронтэнд (формы, UI/UX), бэкэнд (сервер приложений) и API. Поэтому ИС имеют большую стоимость владения, а эксплуатация связана с высокими рисками. Ведь ИС создают универсальные инженеры-программисты, которые пишут для каждой ИС много системного кода с нуля. Если разделить прикладное и системное программирование на две разные специальности и использовать высокоуровневую платформу, которую сделали системные программисты, то мы сможем переиспользовать до 80% кода в разных системах. Прикладные программисты (т.е. разработчики) смогут тогда сосредоточиться только на задачах, связанных со спецификой предметной области. Это существенно снижает требования к прикладным программистам, а использование принципов свободного программного обеспечения позволяет объединить усилия по созданию платформы и исключить риски, связанные с владением платформой. Open source лицензии не дают вендорам произвольно менять свою политику по отношению к потребителям и системным интеграторам, потому что они не имеют блокирующего контроля над платформой и могут быть заменены конкурентами. Такой подход уже применялся неоднократно и позволил сделать на порядки доступнее бухгалтерское и офисное ПО, разработку веб-сайтов, даже компьютерные игры сейчас не пишут с нуля, а используют платформы, на которых даже начинающие могут быстро показать впечатляющие результаты. -Чтобы внедрить такой подход для ИС, нам нужны новые профессии, новая система подготовки кадров, новый подход к постановки задач и даже заказчик таких ИС должен думать о них совершенно иначе. Существующий спрос должен существенно измениться, вырасти на порядки благодаря тому, что теперь специализированные ИС будут доступны гораздо более широкому кругу потребителей и перестанут быть роскошью. +Чтобы внедрить такой подход для ИС, нам нужны новые профессии, новая система подготовки кадров, новый подход к постановке задач и даже заказчик таких ИС должен думать о них совершенно иначе. Существующий спрос должен существенно измениться, вырасти на порядки благодаря тому, что теперь специализированные ИС будут доступны гораздо более широкому кругу потребителей и перестанут быть роскошью. > Сложность и простота -Давайте же стремиться к тому, чтобы наши программы, были простыми и для потребителя и для нас самих, как людей, которые будут их много раз модифицировать и постоянно сталкиваться с теми решениями, которые мы заложили в них при первичной разработке. А если мы ограничены во времени и вынуждены писать неэффективный или малопонятный код, то следует планировать его переработку, рефакторинг и оптимизацию до того, как мы забудем его структуру и у нас выветрятся все идеи по улучшению. Накопление проблем в коде называется "технический долг" и он приводит не только к тому, что программы становятся менее гибкими и понятными, но и к тому, что наши младшие коллеги, подключаясь к проектам, читают и впитывают не лучшие практики и перенимают наш оверинжиниринг. Простота решения сложных задач, является целью хорошего программиста, скрытие сложности за программными абстракциями — это метод опытного инженера. +Давайте же стремиться к тому, чтобы наши программы были простыми и для потребителя и для нас как людей, которые будут их много раз модифицировать и постоянно сталкиваться с теми решениями, которые мы заложили в них при первичной разработке. А если мы ограничены во времени и вынуждены писать неэффективный или малопонятный код, то следует планировать его переработку, рефакторинг и оптимизацию до того, как мы забудем его структуру и у нас выветрятся все идеи по улучшению. Накопление проблем в коде называется "технический долг", и он приводит не только к тому, что программы становятся менее гибкими и понятными, но и к тому, что наши младшие коллеги, подключаясь к проектам, читают и впитывают не лучшие практики и перенимают наш оверинжиниринг. Простота решения сложных задач является целью хорошего программиста, скрытие сложности за программными абстракциями — это метод опытного инженера. «Я всегда мечтал о том, чтобы моим компьютером можно было пользоваться так же легко, как телефоном; моя мечта сбылась: я уже не могу разобраться, как пользоваться моим телефоном» // Бьёрн Страуструп From 210e0e2d5843a7cc7b45fac5bbc90dbf9d63ce42 Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:38:19 +0300 Subject: [PATCH 5/6] Fix punctuatio in 1-6-Engineer.md --- content/ru/1-6-Engineer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ru/1-6-Engineer.md b/content/ru/1-6-Engineer.md index d39e537..bd3b111 100644 --- a/content/ru/1-6-Engineer.md +++ b/content/ru/1-6-Engineer.md @@ -1,5 +1,5 @@ ## 1.6. Обзор специальности инженер-программист -Вокруг программирования, как и вокруг любой сферы своей деятельности, человек успел построить огромное количество предрассудков и заблуждений. Первейший источник проблем, это терминология, ведь различные парадигмы, языки и экосистемы насаждают свою терминологию, которая не только противоречива между собой, но и нелогична даже внутри отдельного сообщества. Более того, многие программисты самоучки и одиночки, выдумывают самобытную, ни на что не похожую терминологию и концепции, дублирующие друг друга. Оголтелые маркетологи тоже деструктивно влияют на ИТ отрасль вцелом, на формирование мировоззрения и терминологии. Выкручивая очевидные вещи, запутывая и усложняя концепции, они обеспечивают неисчерпаемую лавину проблем, на которой только и держится весь софтверный бизнес. Переманивая пользователей и программистов на свои технологии, гиганты индустрии нередко создают очень заманчивые и правдоподобные концепции, приводящие в итоге к несовместимости, войне стандартов и к явной зависимости от поставщика программной платформы. Группировки, захватывающие внимание людей, десятилетиями паразитируют на их внимании и бюджетах. Ведомые гордыней и тщеславием, некоторые разработчики и сами распространяют сомнительные, а иногда и заведомо тупиковые идеи. Ведь делать программное обеспечение хорошо - совершенно не выгодно для производителя. Ситуация существенно лучше в сфере свободного ПО и открытого кода, но децентрализованные энтузиасты слишком разобщены, чтобы эффективно противодействовать мощной пропаганде гигантов отрасли. +Вокруг программирования, как и вокруг любой сферы своей деятельности, человек успел построить огромное количество предрассудков и заблуждений. Первейший источник проблем — это терминология, ведь различные парадигмы, языки и экосистемы насаждают свою терминологию, которая не только противоречива между собой, но и нелогична даже внутри отдельного сообщества. Более того, многие программисты самоучки и одиночки выдумывают самобытную, ни на что не похожую терминологию и концепции, дублирующие друг друга. Оголтелые маркетологи тоже деструктивно влияют на ИТ отрасль вцелом, на формирование мировоззрения и терминологии. Выкручивая очевидные вещи, запутывая и усложняя концепции, они обеспечивают неисчерпаемую лавину проблем, на которой только и держится весь софтверный бизнес. Переманивая пользователей и программистов на свои технологии, гиганты индустрии нередко создают очень заманчивые и правдоподобные концепции, приводящие в итоге к несовместимости, войне стандартов и к явной зависимости от поставщика программной платформы. Группировки, захватывающие внимание людей, десятилетиями паразитируют на их внимании и бюджетах. Ведомые гордыней и тщеславием, некоторые разработчики и сами распространяют сомнительные, а иногда и заведомо тупиковые идеи. Ведь делать программное обеспечение хорошо — совершенно не выгодно для производителя. Ситуация существенно лучше в сфере свободного ПО и открытого кода, но децентрализованные энтузиасты слишком разобщены, чтобы эффективно противодействовать мощной пропаганде гигантов отрасли. -Как только какая-то технология или экосистема развивается в достаточной степени, чтобы на ней можно было создавать хорошие решения, она обязательно устаревает или производитель прекращает ее поддержку или она становится чересчур сложной. На моей памяти уже сменилось больше пяти таких технологических экосистем. +Как только какая-то технология или экосистема развивается в достаточной степени, чтобы на ней можно было создавать хорошие решения, она обязательно устаревает или производитель прекращает ее поддержку, или она становится чересчур сложной. На моей памяти уже сменилось больше пяти таких технологических экосистем. From 77c63925051fff681aa7dba04f080be529252454 Mon Sep 17 00:00:00 2001 From: Stanislav Tursky Date: Tue, 16 Aug 2022 01:39:17 +0300 Subject: [PATCH 6/6] Fix punctuatio in 1-7-Paradigms.md --- content/ru/1-7-Paradigms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ru/1-7-Paradigms.md b/content/ru/1-7-Paradigms.md index 5e6a822..9527df5 100644 --- a/content/ru/1-7-Paradigms.md +++ b/content/ru/1-7-Paradigms.md @@ -1,11 +1,11 @@ ## 1.7. Обзор парадигм программирования -Математик рассматривает программу как функцию, которую можно декомпозировать (разделить) на более простые функции так, чтобы программа-функция была их суперпозицией. То есть, грубо говоря, программа является сложной формулой, преобразователем данных, когда на вход подаются условия задачи, а на выходе мы получаем решение. Не всякий программист знаком с этой точкой зрения, хоть она и не идеальная, но полезная для переосмысления своей деятельности. Более распространена противоположная точка зрения, которую легко получить из практики программирования. Заключается она в написании программ исходя из представления пользователя, из рисунков экранов пользовательского интерфейса, и из инструментария, языка, платформы и библиотек. В результате, мы получаем не программу-функцию, а большую систему состояний, в которой происходит комбинаторный взрыв переходов и поведение которой непредсказуемо даже для автора, не то что для пользователя. Но нельзя сразу отметать этот, казалось бы, ужасный подход. В нем есть конструктивное зерно, и заключается оно в том, что не все программы возможно в краткие сроки реализовать в функциональной парадигме как преобразователями данных. Тем более что человеческая деятельность вся состоит из шагов и изменения состояний окружающих нас предметов по принципу пошаговых манипуляций ими, а представить ее в виде функций было бы достаточно неестественным для нашего мышления. +Математик рассматривает программу как функцию, которую можно декомпозировать (разделить) на более простые функции так, чтобы программа-функция была их суперпозицией. То есть, грубо говоря, программа является сложной формулой, преобразователем данных, когда на вход подаются условия задачи, а на выходе мы получаем решение. Не всякий программист знаком с этой точкой зрения, пусть она и не идеальная, но полезная для переосмысления своей деятельности. Более распространена противоположная точка зрения, которую легко получить из практики программирования. Заключается она в написании программ исходя из представления пользователя, из рисунков экранов пользовательского интерфейса и из инструментария, языка, платформы и библиотек. В результате мы получаем не программу-функцию, а большую систему состояний, в которой происходит комбинаторный взрыв переходов и поведение которой непредсказуемо даже для автора, не то что для пользователя. Но нельзя сразу отметать этот, казалось бы, ужасный подход. В нем есть конструктивное зерно, и заключается оно в том, что не все программы возможно в краткие сроки реализовать в функциональной парадигме как преобразователи данных. Тем более что человеческая деятельность вся состоит из шагов и изменения состояний окружающих нас предметов по принципу пошаговых манипуляций ими, а представить ее в виде функций было бы достаточно неестественным для нашего мышления. Парадигма задает набор идей и понятий, допущений и ограничений, концепций, принципов, постулатов, приемов и техник программирования для решения задач на вычислительной машине. В этом разделе мы рассмотрим некоторые из них поверхностно, а далее в книге будет специальная глава с более подробным обсуждением каждой парадигмы. Есть языки, которые поддерживают одну парадигму, а есть мультипарадигменные языки. Мы обратим внимание на разные языки и отличия реализации парадигм в них. -Для человека естественно представление о любом действии как о наборе шагов или алгоритме, это императивный подход. Шаги эти могут быть или линейными, или принятием решения о переходе к другому шагу плана, вместо того, чтобы исполнять действия последовательно. Принятие решения для машины — это операция сравнения, приводящая к ветвлению алгоритма, дающая варианты (обычно два). Действия можно условно разделить на внутренние и внешние. Во внутренних принимают участие только процессор и память, действие выполняется сразу, без ожидания, и имеет определенный результат, который доступен непосредственно на следующем шаге алгоритма. Внешние действия — это обращения к внешним устройствам ввода-вывода (сеть, диски, другие устройства), и они требуют ожидания реакции от устройства, которая придет за время, обычно неизвестное заранее. Мы отправляем управляющий сигнал периферийным устройствам о том, что им нужно что-то сделать и передаем им необходимые для этого данные. Далее у нас есть опять два варианта: или ожидать результата, и это будет называться блокирующим режимом ввода-вывода, или перейти к следующему шагу алгоритма, не дожидаясь результата, и это будет неблокирующий ввод-вывод. Такое разделение вызвано значительной разницей в длительности внутренних и внешних действий. Большинство внешних действий связаны с физическими операциями над внешней средой. Например, передача данных по беспроводной или проводной сети, запись или чтение с физического носителя, взаимодействие с датчикоом, реле или приводом. Такие операции часто имеют не цифровую, а аналоговую природу, поэтому требуется дополнительное преобразование данных, ожидание переходного процесса, ожидание нужного показания датчика или сигнала от устройства и т.д. Устройства ввода-вывода часто имеют свой контроллер, в котором выполняется отдельный поток операций, а взаимодействие между центральным процессором и устройствами ввода-вывода также требует согласования, что занимает время и может закончиться неудачно. +Для человека естественно представление о любом действии как о наборе шагов или алгоритме, это императивный подход. Шаги эти могут быть или линейными, или принятием решения о переходе к другому шагу плана, вместо того, чтобы исполнять действия последовательно. Принятие решения для машины — это операция сравнения, приводящая к ветвлению алгоритма, дающая варианты (обычно два). Действия можно условно разделить на внутренние и внешние. Во внутренних принимают участие только процессор и память, действие выполняется сразу, без ожидания, и имеет определенный результат, который доступен непосредственно на следующем шаге алгоритма. Внешние действия — это обращения к внешним устройствам ввода-вывода (сеть, диски, другие устройства), и они требуют ожидания реакции от устройства, которая придет за время, обычно неизвестное заранее. Мы отправляем управляющий сигнал периферийным устройствам о том, что им нужно что-то сделать, и передаем им необходимые для этого данные. Далее у нас есть опять два варианта: или ожидать результата, и это будет называться блокирующим режимом ввода-вывода, или перейти к следующему шагу алгоритма, не дожидаясь результата, и это будет неблокирующий ввод-вывод. Такое разделение вызвано значительной разницей в длительности внутренних и внешних действий. Большинство внешних действий связаны с физическими операциями над внешней средой. Например, передача данных по беспроводной или проводной сети, запись или чтение с физического носителя, взаимодействие с датчикоом, реле или приводом. Такие операции часто имеют не цифровую, а аналоговую природу, поэтому требуется дополнительное преобразование данных, ожидание переходного процесса, ожидание нужного показания датчика или сигнала от устройства и т.д. Устройства ввода-вывода часто имеют свой контроллер, в котором выполняется отдельный поток операций, а взаимодействие между центральным процессором и устройствами ввода-вывода также требует согласования, что занимает время и может закончиться неудачно. Парадигма предлагает обобщенную модель решения задач, определенный стиль, шаблоны, примеры хороших и плохих решений, применяемых для написания программного кода.