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

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

Обычно я занимаюсь тем, что запускаю стрим на своём ютуб-канале, открываю Visual Studio и делаю свою видеоигру, попутно объясняя что да как. Но какое-то время назад Microsoft умудрилась так удачно сломать мне мою любимую IDE, что всё встало раком на неделю, а откатиться на прошлую версию Community Edition не позволяет. Поэтому, чтобы не раздолбать голову об клавиатуру во время очередной (четвёртый раз за три месяца) паузы, я попытался нести доброе, разумное, вечное в ином формате. Сделать что-то, что позволить войти в это дело с абсолютного нуля. Мои стримы для этого подходят не очень, так что начну с пересказа школьных учебников информатики с поправкой на опыт, полученный в отрасли. А там, глядишь, и до более сложных концепций доживём.

Дисклеймеры:

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

Одна из них провозглашена Никлаусом Виртом и звучит так: программа = алгоритм + структуры данных. Алгоритм - то, что мы делаем. Структуры данных - то, с чем мы это делаем. Мой план на первые статьи - говорить об каждой из этих половинок по очереди. Сегодня немножко поговорим про первое.

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

И в наших ЭВМ алгоритмы писались на языках, которые понятны этим ЭВМ конечно. И они их понимали, и добросовестно выполняли, но был нюанс. Понимаете, в чём дело. Одно дело, когда алгоритм выглядит так:

Это немного ломает мозг, но если вы это прочитаете внимательно, то поймёте: если проделать это шаг за шагом, на экране появится самое большое число из тех, что ввёл пользователь. И пока наш алгоритм состоит из 10-15 шагов это не проблема для профессионала, привычного ко всему. А вот когда шагов уже хотя бы 30-50, это со-о-о-овсе-е-ем другое дело:

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

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

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

Демонстрация идей:

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

Ещё один важный нюанс — отступы. Отступы — это важно. Команды постоянно «вкладываются» и без отступов вы не поймёте, что куда вложено. Например, в Python программа откажется выполняться, если вы обходитесь с отступами абы как. В других языках вас побьют после код-ревью. Такая визуализация, объясняющая, что во что входит, необходима. Именно поэтому программный код всегда пишется моноширинным шрифтом. Без специальной функции «код» в редакторе постов DTF эти туториалы были бы невозможны.

Теперь примеры на настоящих языках.

Обратите внимание на фигурные скобки. Это наследие языка C, который застал ещё Холодную войну. Они означают "объединить несколько команд в одну". Те самые "линии" из нескольких команд. Очень удобно для компилятора. Многие языки имеют такие конструкции. Да, вы можете записать код в одну строчку, но захочется ли вам так писать? Вам же потом это поддерживать.

Теперь пример на Python.

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

Код выглядит похожим на C#, но не потому что похожи языки. Как раз таки python и C# считаются крайне непохожими языками. Дело в том, что линейное выполнение, ветвление и цикл — это действительно основа. Есть в нашем мире немало экзотики со своей атмосферой, но если мы говорим о том, с чем вы столкнётесь в этой жизни, не входя в айти слишком глубоко, то это оно. Теперь по отдельности о трёх кирпичах.

Тут всё просто. Команды перечисляются одна за другой. Чаще всего их разделяют точкой с запятой. Иногда просто пишут на отдельной строчке. И почти всегда есть способ сказать ЭВМ "следующая команда — выполнить эти несколько команд по порядку". С помощью те же фигурных скобок. Дальше я иногда буду называть команды операторами, ладно?

Вы уже видели классический if. На всякий случай, покажу как выглядит классический if в его полной форме.

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

А теперь примеры. Частая ситуация на языке C#:

Да, мы нарушили здесь правило отступов. Потому что иначе последняя команда, которая "вложена" в другие команды на восьмом, что ли уровне, уедет за другой край экрана. А ведь в каждой ветке может быть что-то посложнее, чем "текст на экране". Специально для таких случаев в python (помним, что там с отступами всё предельно серьёзно) пришлось придумать свой "многоветочный» if. Вот как выглядит та же ситуация на этом языке (elif — это сокращение от else if) :

Так вот, python единственный известный мне язык, где возникла необходимость в "многоветочном" if. Для чего нам нужно ветвление? Чтобы наш алгоритм мог принять решение. И классический if позволяет принять решение, исходя из "истина/ложь". Но иногда нам надо принять решение на основе числа или строки, или каких-то данных сложнее, чем "0/1". И вот для этого почти во всех известных мне языках есть оператор выбора. Как обычно, сначала C#, потом python.

Резюмируем. Оператор ветвления нам нужен, чтобы в какой-то поворотный момент принять решение, что делать дальше. Для случаев, когда параметр для принятия решения сложнее, чем "да/нет", вводятся операторы ветвления сложнее. Это ок, потому что их можно свести к класическим "if" и они упрощают программы.

Сначала классический цикл на python. Просто делаем что-то, пока не сделаем это на все сто процентов. Простая идея.

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

Во многих языках есть штуки типа break, continue и прочих. Итак, ещё одна частая, не слишком удобная ситуация. Пускай, на python.

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

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

Но если break ещё относительно нечастое явление, то вот следующая штука, о которой я хочу рассказать — ваш самый верный друг и товарищ. И это шаблон «итератор»! Вам он, скорее всего, известен, как цикл foreach (он же цикл for в python).

Вернёмся к этим ребятам.

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

Думаю, теперь видно, что код стал намного проще. Во-первых, исчезло из поля зрения условие. Вам не надо думать, что значит "numbers[checking_now] < numbers.Count". Вы глянули на слово "foreach" и сразу поняли, когда этот цикл кончится. Когда переберём все numbers по одному. Во-вторых, переменная checking_now исчезла из поля зрения. В-третьих, внутри цикла мы работаем с number, не вспоминая о numbers. Работаем с отдельной штучкой без надобности смотреть на всю кучку. number выглядит как-то понятнее, чем numbers[checking_now]. Одним словом, удобненько. И не обязательно речь идёт о числах.

Когда это превращается в программу, понятную компьютеру, оно подставит вместо нашего красивого foreach/for обычный цикл while. Сводится к нашим трём кирпичам + делает программы понятнее.

Те, кому в этой жизни мало хардкора, могут почитать очень подробно с задротскими деталями о том, как работает этот цикл практически во всех языках, в легендарной книге "Банды четырёх". Книга называется "Приёмы объектно-ориентированного проектирования. Паттерны проектирования". Авторы: Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес. Открываете паттерн "итератор" (шаблон "перечислятор", бережём корни русского языка) , и читаете тот раздел. Но это, повторяю, для тех, кто хочет сломать себе мозг о профессиональные детали.

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

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

Первое - требования.

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

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

Второе - псевдокод.

Тут легко. Не можешь написать на python, C# или Javascript? Напиши на русском. Не можешь написать на русском? Што ш, смотри пункт первый. Или обрисуй хотя бы в общих чертах, что именно ЭВМ должна делать.

Почему это упрощает дело? В человеческом мозгу всё плохо с оперативной памятью (правило "5+-2" как раз о том), зато всё хорошо с видеокартой. И вещи, которые обрабатываются глазами, уже не занимают место в оперативке. Так что текст перед глазами с вашими мыслями разгружает ваш мозг от этих самых мыслей. Отсюда следующий совет.

Третье - визуализируй.

Если даже текстом не идёт, нарисуй! Что именно? Всё, что поможет как-то выкристаллизовать решение. Блок-схемы, тракты данных, диаграммы, способов слишком много, чтобы дать хоть чуть-чуть деталей. Люди разные, но в норме на рабочем месте программиста тетрадь и ручка имеются как раз для таких зарисовок. Ладно, дам чуть-чуть примеров:

Четвёртое - разделяй и властвуй.

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

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

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

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

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

N.B. Об этом есть немного в "Совершенном коде" Макконела. А целиком об этом есть небольшая книжка Джона Остерхаута "Philosophy of Software Design". Обе рекомендую прочитать сразу же, как только хоть что-то узнаете об объектах.

Пятое - итерируй.

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

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

Да, всегда надо спрашивать себя "а не говно ли я делаю?". И, само собой, надо всегда быть готовым к ответу "да". Эта работа, к сожалению, требует высокой самооценки.

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

Канал на ютубе

https://www.youtube.com/c/ExplainingEveryString

Паблик вк

https://vk.com/explainingeverystring

Дискорд-сервер

Иллюстрация нарисована этим художником: