Предисловие. Программирование.
Определим начальный статус, просто чтобы было понятно: времени на учёбу у всех на самом деле мало, это полностью вопрос самоорганизации рабочего пространства. 02.2024 - 39 лет, женат, двое детей, ипотека и дом с огородом, автомобиль, user Win.
Кто-то скажет: есть чем заниматься, времени на учёбу нет.
С другой стороны — всё уже есть, дом строить не надо, жену нашёл, детей родил, дерево посадил, займусь-ка магией, ой, программированием.
Писал сам, угловато, за красотой строки идите к GPT (но это неточно).
Программист = маг. Это, собственно, моё сорокалетнее ироничное понимание глубины своего невежества в программировании. Но надо его пересмотреть исходя из тех предпосылок, что уже сложились в процессе обучения. Что же такое программист? Нам не нужно готовое определение, нужно что-то ёмкое и понятное таким новичкам, как мы. Все знают, кто такой программист, но нас это не устраивает, мы же с начала начинаем. Давайте напишем определение.
Тезис — это непросто:
-
Программирование — это высокий старт: войти в сферу IT сложно материально, высокий порог входа именно по деньгам.
-
Программирование — это учёба, часто однообразная, скучная, тяжёлая (морально);
-
Программирование — это работа, часто однообразная, скучная, тяжёлая (морально).
Антитезис — ну да, тяжело, но край — со стула упадёшь, ногу сломаешь:
-
Сидит программист не в шахте, реально уничтожая свои лёгкие (и т.п.). Т.е. сгорел на работе —не про него;
-
Оплачивается дело неплохо. Профессионалам — более чем хорошо.
-
Кодить просто интересно (особенно если вникнуть, разобраться и полюбить).
-
В программировании много разных направлений, можно подобрать себе по душе как тематику разработки, так и стек.
Т.е. если вы решили стать программистом, надо быть готовым к тому, что придётся постоянно вкладывать много ресурсов, много учиться, много работать. Это касается именно программирования как такового, разные надстройки, поглощающие много ресурсов и, в удовольствие работающие, мы не учитываем, т. к. они нас будут, погонять, проверять, принимать на работу, и т. п.
Синтезируем: программист — человек. который много учится и готовится к работе, однообразно и скучно трудится, снова однообразно и скучно учится, сидит в комфортном офисе, получает +/- неплохие деньги, часто решает интересные и неинтересные задачи.
Т.е. работа-мечта любого здравого человека: непыльная, негрязная, здоровью слабо вредящая, очень неплохо оплачиваемая, но специфическая с точки зрения образования. Его тут нужно не просто получить, но постоянно им заниматься, а накапливаемый в процессе работы опыт иногда помогает, а иногда делает
Зная теперь в теории, кто такой программист, можно принимать решение, надо ли оно вам. К примеру, я всегда знал, что мне надо, никогда не боялся работы/учёбы, поэтому, как только увидел такую возможность — ухватился руками и ногами.
Вообще программирование для меня всегда было магией, автор — менеджер, но в другой области. Магия программирования притягивает, надо понимать, что это искусственно созданный обществом и рыночным предложением информационный фон, но не стоит его игнорировать, поскольку базисом его является реальная потребность в эффективных кадрах. Т.е. нам (широкой аудитории) обещают лёгкий заработок в этой сфере, искажая или не раскрывая реальную статистику, вовлекая большие массы легковерных ресурсов в этот рынок. Программист — продукт высокотехнологичного общества, специализированный, с очень высокой себестоимостью, в связи с чем большинство заинтересованных в этом продукте компаний вынужденно перекладывает себестоимость ресурса на сам ресурс, поскольку это вопрос их конкурентоспособности, ну и их менеджмент считает, что так надо.
Один из реальных вариантов для начинающего — бесплатное обучение. Чем он хорош?
• вам не пытаются что-то продать (это бесплатно);
• вас не пытаются чему-то научить (это так же бессмысленно, как и учить диалектике);
• вам дают возможность реализовать свой потенциал (если он есть);
• вам честно показывают, что это не всем дано: уже на этапе начального обучения отсеивается 2/3 потока.
При этом надо понимать: отсев — это не диагноз. Это форматирование потока под цели и задачи. Вероятно, таланты находятся в этом отсеве, т.к. они часто не формат.
Примерный старт на любых курсах + сообщество:
-
современное рабочее место, литература, место отдыха и питания.
-
интересное сообщество — читать, смотреть.
-
возможность обучения — поставлены адекватные задачи в адекватном окружении с использованием макетов внешних ресурсов.
На этом предисловие закончу, ибо многабукав.
Введение
Результатом данной работы планируется простое наглядное, визуальное (более 50%) пособие, помогающее осознать новичку (мне в том числе), что же происходит в коде С, расшарить по возможности его инструменты.
Или если проще — книжка с картинками для самых маленьких, на базе примера кода реальных программ.
Начинаем с нуля, и будем поднимать темы по ходу обучения и обратной связи от благонадёжных читателей. Отмечу, что хотя рассматриваю С как один инструмент из богатой линейки языков, с учётом исторической составляющей признал его обязательным базовым для начального обучения. То, что на нём уже написано, встречает нас каждый день много лет, когда мы просто запускаем наш вполне себе современный компьютер и периферию.
Часть 1. Интенсив.
Задачи раздела 1:
-
начало — что в начале? Что есть бытие программиста?
-
Linux
-
Git
-
С
Движение — основа всего, и в человеке природой заложена мобильность: как физическая, так и моральная. Адаптивность — одно из важнейших качеств и человека, и программиста в частности. Становиться программистом значит меняться коренным образом, менять образ жизни.
С чего начинается ваш интенсив? С массива изменений:
-
Самоорганизация — тебе необходимо чётко планировать, распределять всю свою нагрузку и ресурсы. Это сложно, этому надо учиться.
-
Новые инструменты — в процессе прохождения уже на начальном уровне вынуждены осваивать несколько базовых инструментов.
-
Ну и, конечно, код. Т.е. код — одно из многих условий, но недостаточное на обучении.
Как договаривались, визуализация вышесказанного — распределение событий и инструментов по важности. Ну и добавлю Bash, он мне просто нравится.
Поясню линейно:
-
Много время событийно посвящаем вращению в учёбе, в её событиях, пабликах, просто читаем о том самом .
-
Всё время, несмотря на то, с какими инструментами работаем, делаем мы это в консоли Linux.
-
Всю совместную работу с кодом обеспечивает Git, а там иной и нет.
-
Все программы пишем на «C».
-
Bash мне просто нравится в Linux, в нём удобно работать скриптами с объектами, простыми тестами.
Важно, это инструментарий одновременной работы. Т.е. этим всем нужно пользоваться как при приготовлении супа, где “язык” — это ингредиенты, но при этом ещё есть рецепт, кастрюля, стол, плита; они и не ингредиенты, и не суп, но они важны для того, чтобы приготовить суп (программу). Так и тут, это базовые инструменты. К примеру, 1 рабочий день дома, когда слетела система (а такое по неопытности бывает часто):
-
поставили линукс, инсталлировали инструменты;
-
скачали в локальный репозиторий базу;
-
изменили код С;
-
запушили результат в удалённый репозиторий;
-
создали скрипт-тест, протестили на утечки и норму кода;
-
запушили результат в удалённый репозиторий;
-
удалили локальный (можно не удалять).
После 6 месяцев обучения очевиден прогресс: несмотря на множество нерешённых задач, пул полученных знаний о программировании окупает себя соразмерно затратам. Получена база и уверенность, что это вполне по силам с нуля. Овладевая вышеуказанными инструментами, мы закладываем прочный базис дальнейшего развития, который по мере углубления в специализацию и знаний в программировании в дальнейшем наращивается почти автоматически. Но это всё ещё:
Часть 2. Си – структурное программирование.
Предисловие.
Зачем вообще понимание структурной программы? Что за структура? Начнём со словаря Ожегова, структура — внутреннее устройство. Ну, раз мы изучаем программу, то это внутреннее устройство программы. Что определяет это устройство?
-
Проект.
-
Условия.
Значит, понимание структуры программы позволяет нам её запроектировать на стадии, когда ничего ещё нет. Спланировать. Зачем? Потому что мы перенимаем опыт из других отраслей:
-
Строительство
-
Предпринимательство
Эти сферы зиждятся на проектах (инвестирование одобряется на основании проекта, работы выполняются на основании проекта, решения обоснованы в проекте). Связано это в этих отраслях с тем, что качественный проект значительно ускоряет производство работ, а некачественный — обуславливает большую часть ошибок. И если вы решаете избыточно большое количество проблем (существенно влияющих на размер итоговых затрат) на стадии строительства, запуска технологии, написании кода, это значит что у вас:
-
некачественный проект (непроработанность важных, критических моментов проекта — проблема сверху).
-
низкая культура производства (слабый подрядчик — проблема снизу). Что также может быть обусловлено проектом, но уже бюджетом и управленческими решениями.
Т.е. к структуре обращаются с целью сделать качественный проект программы, который учитывает большинство нюансов, влияющих на конечную стоимость производства. Конечно, есть люди, которые это делают интуитивно, но мы ищем именно системный подход, который любому учащемуся позволит сразу качественно подготовить проект структуры программы.
Тезис: чем качественнее у нас проект программы, тем меньше времени уходит на её написание и главное — тестирование и отладку. Рассматриваемая нами структура — это универсальный модуль проекта.
Проект программы — набор универсальных структурных модулей под задачу. Мы его определяем независимо от того, понимаем мы это или нет. Начиная писать программу без проекта, вы строите дом без проекта: как пойдёт так и будет. И тут можно сказать, что есть опытные люди, которые с оглядкой на свой опыт получат неплохое строение (программу). Но у нас-то опыта нет, поэтому мы начинаем со структуры программы, чтоб из этих кирпичиков в дальнейшем мы могли проектировать работающие проекты:
Архитектура Си:
-
Структурная программа.
-
Простая архитектура.
-
Архитектура функции.
-
Архитектура ошибки.
-
Сложная архитектура.
-
Структурная программа.
Определимся: мы ничего не знаем в начале нашего обучения структурному программированию, в силу отсутствия опыта и знаний, поэтому пойдём по простому пути: будем визуализировать то, что написано и сказано о языке Си, его структурах. Ведь самый информативный орган чувств у нас — глаза, попробуем насытить именно этот канал.
Надо полагать, что структурное программирование в Си никого не удивит. Эта парадигма зиждется на базисе:
1. Теорема Бёма-Якопини – алгоритм и три управляющие структуры.
2. Принцип Дейкстры – неизменность алгоритма.
Давайте визуализируем это, создав определённую структуру (pic_3. the_empty_structure). Наполнять её будем позже, сейчас же отметим только основные позиции:
-
Подход сверху вниз, или в глубину, когда, двигаясь от общей задачи, выявляем частные функции до её решения.
-
Декомпозиция на составные элементы в виде функций (действий, подпрограмм и т.п.), примем типовое: Input, Task, Output.
-
Один вход – один выход. Это делает процессы, происходящие в потоке исполнения программы, контролируемыми и отслеживаемыми.
Кроме визуализации ничего нового не планируется, мы отражаем всем известные базовые тезисы.
Input – preprocess
Task – process
Output - postprocess
Напишем пример программы, которую будем усложнять в процессе модификации структуры.
int main() {
int input, output = 0;
scanf("%d", &input);
output = input + 1;
printf("%d", output);
return 0;
}
И впишем её в выше исполненную визуализацию (pic_4. the_filled_structure).
-
Простая архитектура.
Вышеприведённый пример, хотя и является простейшим, но уже описывается простой структурной моделью. Но это пока неочевидно. Эта модель кажется статичной, излишне усложнённой автором, незаконченной, в связи с тем, что мы пока не реализовали поток исполнения программы. По теме потока мы пойдём так же и начнём с того, что мы ничего не знаем о потоке и даже на Хабре ничего не читали. Берём словарь Ожегова, «Поток — движущаяся масса чего-н» и логику. Уже лучше, очевидно, что-то движется.
Теперь мы знаем:движение чего-то - значит что-то есть, раз оно есть, то, вероятно, это движение чего-то, что является предметом, единицей нашего рассмотрения - программы(статичный код). Но программа — это не поток, а поток — это не программа, это её определённость, качество состояния этой программы. Т.е. что-то, что есть вне этой программы, но находится в непосредственной связи с ней. Подумаем, что делает программа в потоке. Это легко – исполняется.
Исполнение, обратимся к тому же словарю, — воспроизвести перед слушателями, зрителями, Казалось бы, какое отношение к нашему случаю это имеет? А самое прямое: программа — исполнитель специального жанра, и получив исходные данные, начинает исполнять заложенный в её архитектуру структурный алгоритм. А кто тут зритель? Любая утилита или процесс, предназначеные для её инициализации и получения результата.
Значит, поток исполнения программы – это воспроизведение заложенного в структуру программы кода с движением по нему в результате инициализации родительским процессом.
Выразим это, как и договаривались, в графической форме, где m[ ] — это текущая стадия движения по структуре (pic_5. The_model_program_execution_flow):
Выделенный на визуализации поток – для удобства восприятия, на самом деле он, конечно, также находится внутри «программы».
m4 = output(m3) = task(m2) = input(m1)
Отсюда и вытекает суть управления потоком: просто изменив или заменив на любом этапе функцию или условие, можно предсказуемо изменить результат, т.е. управлять программой.
Ну и конечно, вписываем в него конкретную часть, подхватив уже весь код и вписав его в программную часть структуры (pic_6. the_model_program_execution_flow_example):
До этой простой, в общем-то, структурной модели автор двигался порядка двух месяцев. Для новичка это совсем не очевидно, особенно при восприятии по простым одномерным структурным схемам и текстам. На нашей же присутствуют два измерения, т.е. визуально мы чётко можем выделить две меры:
• статичный код (программа);
• динамичный код, поток (исполнение кода на разных стадиях m[ ]).
Вообще структурное программирование по сути своей более просто для изучения разработчиком или студентом. От нас требуется только чётко придерживаться архитектуры, заданной методом декомпозиции, и придерживаться баланса – чтобы не было избыточно детальной декомпозиции.
В следующей статье продолжим знакомиться с визуализацией языка Си, сложной архитектурой.
Автор – участник Школы 21.
Автор: perryshe