что такое писать код
Программирование с нуля
Данная статья описывает основные конструкции в программировании и предназначена для тех, кто хочет в этом разобраться. Но статья не описывает все нюансы, потому что их слишком много. Если описывать их все, будет очень нудно и непонятно.
Использовать будем си-подобный синтаксис, то есть подобный языку си, но не будем вникать в заголовочные файлы, указатели и другие особенности относительно низкоуровневых языков, перейдём на синтаксис более высокоуровневых языков, которые сделают рутинную работу за нас. А конкретно, будем использовать синтаксис языка Java. Добро пожаловать под кат.
Двоичная система счисления
Числа в двоичной системе счисления состоят всего из двух знаков. Нуля и единицы. 00000001 – число один. 00000010 – число два. 00000100 – число 4. Как вы можете заметить, когда единица смещается влево, число увеличивается в два раза. Чтобы получилось число 3, необходимо написать 00000011. Таким образом можно составить все необходимые числа. В данном примере мы использовали двоичное число с восемью знаками, иначе говоря число восьмиразрядное. Чем больше у числа разрядов, тем большее оно может вместить значение. Например, восьмиразрядное число вмещает максимальное значение 255, если считать ноль, тогда 256, а в программировании ноль считается всегда. Если увеличить разряд на один, получится девятиразрядное число и его вместимость увеличится в два раза, то есть станет 512. Но так в программировании никогда не делается и обычно каждая следующая разрядность увеличивается вдвое. Один разряд, потом 2 разряда, потом 4 разряда, потом 8 разрядов, потом 16 разрядов, потом 32 разряда и далее.
Шестнадцатеричная система счисления
Всё аналогично двоичной, только вместо нулей и единиц участвуют цифры от 0 до 15. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, где A – 10, B – 11, C – 12, D – 13, E – 14, F – 15.
Знак минус в программировании
Буквы и знаки
Буквы, знаки, смайлики и так далее обозначаются также числами. Буква А может быть числом 00000001 или любым другим, или даже комбинацией чисел в зависимости от кодировки символов. Кодировок много.
Типы данных
В программировании есть типы данных. Числовые, такие как 233, которые разобрали выше. Называются почти везде int, от слова integer. С плавающей запятой, такие как 198,76, называются почти везде float. У букв тип char, у строк тип String. Тип bool имеет два значения – истина (true) и ложь (false). У этого типа реализация в разных языках разная, но самая простая, когда ноль — значит ложь, а любое другое число истину. Нестандартные типы данных, такие как числа с фиксированной запятой, рассматривать не будем.
Применение
Прежде чем использовать числа в программировании их нужно объявить, то есть сказать с помощью языка программирования, что они существуют.
Это стандартное объявление примитивного типа.
Сначала пишем тип, потом имя переменной, то есть нашего числа. Всегда заканчиваем наше выражение, да и любое, точкой с запятой.
Теперь мы можем использовать переменную по её имени.
Здесь мы присвоили переменной значение. В отличии от математики в программировании = значит взять значение справа и присвоить переменной слева. = — это знак/оператор присвоения.
Можно объединить объявление и присвоение, то есть сразу инициализировать переменную.
Буквы выделяются одинарными кавычками, строки выделяются двойными кавычками. Числа типа int не выделяются.
К числам с плавающей запятой одинарной точности в конце добавляется f.
К числам с плавающей запятой двойной точности ничего не добавляется.
Операторы
После того как мы записали наше выражение, например сложения,
получается значение. Но так как оно ни одной переменной не присваивается, оно исчезает. Чтобы присвоить значение переменной используется специальный оператор присвоения, который коротко описан выше.
Повторим ещё раз. Он берёт значение со своей правой стороны и присваивает его переменной в левой стороне. Это оператор =, и он не имеет ничего общего со знаком равно из математики.
Также у нас есть логические операторы, такие как (больше),
Принципы написания кода
Стандарты кодирования
Типичные проблемы многих таких стайл-гайдов:
1. Плохо обоснована их целесообразность
2. Они декларируют конкретные правила, вместо принципов.
3. Эти правила плохо обоснованы и нередко построены на противоречащих принципах.
В упомянутой статье всё обоснование необходимости стандартизации заключается в:
Хорошее руководство по оформлению кода позволит добиться следующего:
1. Установление стандарта качества кода для всех исходников;
2. Обеспечение согласованности между исходниками;
3. Следование стандартам всеми разработчиками;
4. Увеличение продуктивности.
1. [тут располагается картинка про ещё один стандарт] «Стандарт нужен для того, чтобы был стандарт» — не обосновывает его наличие.
2. В любом более-менее крупном проекте всегда будет куча кода, не соответствующая текущим веяниям моды оформления: изменения стайл-гайда со временем, легаси код, код сторонних библиотек, автогенерированный код. Это неизбежно и не так уж и плохо, как на первый взгляд может показаться.
3. То же что и первый пункт.
4. Уже теплее, но опять же, не обосновывается почему продуктивность от этого должна вырасти, и главное — на сколько.
По своему опыту могу сказать, что самое худшее решение — привыкнуть писать и читать код в каком-то одном стиле, от чего любой код написанный «не по правилам» будет вызывать раздражение, тревогу, гнев и желание навязывать окружающим свои привычки. Куда полезнее научиться воспринимать исходники, игнорируя оформление. И для этого наличие разнооформленного кода даже полезно. Я не говорю, что надо расслабиться и писать всё в одну строку, но, чтобы так не делать, есть куда более практичные причины, чем «стандарт нужен, чтобы всё было стандартно».
Как написать грамотный стандарт:
1. Определился с целями
2. Сформулировать принципы и провалидировать их на соответствие целям
3. Сформулировать минимум правил, для реализации этих принципов
Итак, попробуем
Цель: снизить стоимость поддержки путём наложения на себя и команду ограничений.
В чём заключается поддержка:
1. написание нового кода
2. изменение существующего, в том числе и автоматическая
3. поиск нужного участка кода
4. анализ логики работы кода
5. поиск источника неверного поведения
6. сравнение разных версий одного кода
7. перенос кода между ветками
Какие принципы помогут достичь поставленной цели:
1. Строки файла должны быть максимально независимы.
Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток. Каждый конфликт — это дополнительное иногда значительное время на его разрешение.
Несмотря на то, что эта простая идея проскакивает в одном из правил упомянутой в начале статьи, в другом же правиле мы видим явно противоречащую рекомендацию:
Вертикальное выравнивание — это может быть и красиво, но совершенно не практично по следующим причинам:
1. Добавление строки с более длинным именем (например, icon—person-premium) приведёт к изменению всех строк в группе.
2. Автоматическое переименовывание в большинстве случаев собьёт выравнивание (например, при изменении icon—person на icon—user в большинстве инструметов).
3. Иногда пробелы становятся неоправданно длинными, от чего воспринимать код становится сложнее.
Также тут можно заметить лишний семиколон (semicolon, точку с запятой). Единственная причина его появления в этом месте — слепое следование правилам стайл-гайда, не понимая его принципов.
В многострочных правилах, это действительно необходимо, чтобы добавляемые в конец строки не приводили к изменению уже существующих. Например:
Если вы пишете на javascript и можете позволить себе отказаться от ie8, то можете использовать хвостовую пунктуацию и в литералах:
Другой аспект этого принципа заключается в том, чтобы располагать на отдельных строках те сущности, которые меняются как правило независимо. Именно поэтому отдельные css-свойства не стоит располагать в одну строку. Более того, не стоит увлекаться и комплексными свойствами.
Ещё один яркий пример нарушения этого принципа — цепочки вызовов методов:
Тут мы постарались разместить каждое звено на отдельной строке, что позволяет добавлять/удалять/изменять звенья не трогая соседние строки, но между ними всё равно остаётся сильная связь из-за которой мы не можем, например, написать так:
Чтобы добавить такую логику придётся разбить цепочку на две и исправить их начала:
А вот при такой записи мы имеем полную свободу действий:
2. Не сваливать все яйца (код) в одну корзину (файл/директорию).
Если вам кажется, что в коде не хватает так называемых «секций», то скорее всего вы подобрались к верхнему порогу восприятия, когда, уже сложно находить нужные его участки. В этом случае естественным желанием является создание оглавления. Но оглавление в виде комментариев в начале файла не сравнится с оглавлением в виде списка файлов в директории. Располагая код в иерархии файловой системы вы довольно неплохо можете упорядочивать всё прибывающее число сущностей. Примерно то же самое вы скорее всего делаете и в рантайме, располагая код в иерархии неймспейсов, так что нет никакой причины иметь для одной сущности разные пространства имён: в рантайме и в файловой системе. Проще говоря, имена и иерархия директорий должна соответствовать именам и иерархии пространств имён.
Часто можно встретить размещение файлов в нескольких больших корзинах: «все картинки», «все скрипты», «все стили». И по мере роста проекта, в каждой из них появляется иерархия, частично одинаковая, но и с неизбежными отличиями. Задумайтесь: а так ли важен тип файла? Пространства имён куда важнее. Так зачем нужны эти типизированные корзины? Не лучше ли все файлы одного модуля хранить рядом, в одной директории, какими бы ни были их типы? Тем более, что типы могут меняться. Сравните:
Во втором случае, разрабатывая очередную формочку, вам не придётся метаться между директориями, раскладывая файлы в разные места. В случае удаления компоненты, вы не забудете удалить и картинки. Да и переносить компоненты между проектами становится гораздо проще.
3. Язык программирования — принципиально не естественный язык.
В отличие от письменной речи, которая читается строго последовательно, программный код на современных языках программирования представляет из себя двухмерную структуру. В них зачастую нет, например, необходимости ставить точки (семиколоны) в конце предложений:
JS частично понимает двухмерность кода, поэтому в нём семиколоны в конце строк являются тавтологиями:
А вот CSS не понимает, поэтому в нём, без них не обойтись:
Для улучшения восприятия токенов языка, пробелы могут быть расставлены совсем не по правилам письменной речи:
Для более удобной работы с автодополнением, слова могут изменять свой порядок, выстраиваясь от более важных и конкретных к менее важным и общим:
А правило именования коллекций с постфиксом «s» (что в большинстве случаев даёт множественную форму слова) в целях единообразия даёт безграмотные с точки зрения английского языка слова:
Но это меньшее зло по сравнению с требованием от каждого программиста хорошего знания всех английских словоформ.
5. Полные и одинаковые имена одной сущности в разных местах
Поиск по имени — довольно частая операция при работе с незнакомым кодом, поэтому важно писать код так, чтобы по имени можно было легко найти место, где оно определяется. Например, вы открыли страничку и обнаружили там класс «b-user__compact». Вам нужно узнать как он там появился. Поиск по строке «b-user__compact» ничего не выдаёт, потому, что имя этого класса нигде целиком не встречается — оно склеивается из кусочков. А всё потому, что кто-то решил уменьшить копипасту ценой усложения дебага:
Не делайте так. Если склеиваете имя из кусочков, то убедитесь, что эти кусочки содержат полный неймспейс того модуля, где он вводится в употребление:
По полученному классу «my-user__my-block-compact» сразу видно, что он склеен из двух кусков: один определён в модуле «my/block», а другой в «my/user» и оба легко находятся по соответствующим подстрокам. Аналогичная логика возможна и при использовании css-препроцессоров, где мы встречаемся с теми же проблемами:
Если же не используете css-препроцессоры, то тем более:
Как правильно писать код?
На протяжении свой карьеры программиста, я неоднократно сталкивался с тем, что программисты не умеют писать код. Причем это может касаться как начинающих так уже и очень опытных людей. Честно говоря, по моему мнению существуют единицы, которые действительно умеют это делать. Я не претендую на полноту освещение проблемы и на то что мое мнение правильное, а рассмотрю ее со своей точки зрения.
На мой взгляд не существует и не может существовать единого стандарта и каждый человек волен выбирать и адаптировать свои собственные подходы к программированию. Но есть некоторый набор практик, который помогает в подавляющем большинстве случаев.
Прежде всего хочется обратится к первоистокам проблемы. Что вообще не так и зачем надо что-то менять. Я думаю, что мечтой каждого программиста, является писать код максимально быстро и максимально красиво, причем чтоб все четко работало с первого раза. Это позволит чаще читать фишки и пить кофе с тестировщицами, для особо ярых даст больше времени для для развития себя как специалиста.
Одно из основных отличий профессионального программиста от новичка является система приоритетов. Как правило сделать код работающим очень не сложно, сделать его понятным намного сложнее (желательно конечно чтоб при этом он остался работающим). Поэтому профессионал зачастую больше времени проводит за рефакторингом чем за дебагом, что само по себе уже хорошо, однако хотелось бы и момент рефакторинга сократить до минимума.
Итак основные идеи, которые могут помочь писать код лучше
Имей идею
В любой вашей реализации должна быть идея, это как линия которая проходит через всю функциональность и связывает ее воедино. До того как сесть что-то писать, вы должны более менее представлять как это все будет работать, какие есть блоки, как они друг с другом взаимодействуют. Не садитесь писать просто так, придумайте концепцию, так и интереснее и зачастую результирующий код станет понятнее. Естественно уже придумав что-то стоит максимально оставаться в рамках этой концепции, не стоит менять все при первых проблемах, проблемы будут всегда. Также не стоит лениться и со словами, “да ладно и так затащит” втыкать какуюто затычку. Это к добру не приведет.
Идеала нет
А хочется конечно, чтоб он был, но его в 99.(9)% нет. Не стоит пытаться сделать код идеальным, получится еще хуже потратится намного больше времени. Это просто борьба с ветряными мельницами, все же нам платят за то что наше приложение работает а на за то, как оно шикарно написано. Часто поиски идеала приводят к постоянным сменам концепций, бесконечным переписыванием одного и того же, в конечном итоге надоедает, человек все бросает, затыкает все затычкам и “да ладно и так затащит”. Должно быть хорошо и удобно, идеал это не удел инженеров это удел поэтов, а программисты все таки инженеры.
Сохраняй фокус
Одной из основных проблем особенно у новичков является копание в деталях. Надо фокусироваться на 1 задаче в единицу времени. Что я хочу сказать, вы пишете какую-то функцию, натыкаетесь на какой-то не простой момент с которым надо разобраться. В большинстве случаев вы знаете, что эта проблема решается 100%, но не знаете как. Если переключиться на ее решение, вы собьетесь с фокуса текущей проблемы, потом для того, чтоб вернуться придется потратить время, переключение контекста никогда не было бесплатной операцией. Эта идея так же распространяется на детали реализации. Предположим вам надо написать функцию которая читает какие-то данные из базы и записывает их в файл. Вот то и есть вашим контекстом. Решите эту проблему потом решайте остальные (тоесть чтение из базы и запись в файл). Изначально мы пишем следующее:
и генерируем 2 заглушки для Read и Write, благо вижуал студия имеет магическую комбинацию клавиш alt+shift+f10, которую я прожимаю чаще всего (перебиндить ее на f1, просто f1 вместо поиска, мешает только то что это надо делать у всех). Что нам дает такой подход. Во-первых, мы пишем быстрее ибо остаемся в контексте. Во вторых мы пишем лучше ибо в один момент решаем одну задачу, да, ошибок будет меньше. В третьих мы получаем лучше код, он изначально формируется правильно. Функции называются правильно и по контексту, они получаются маленькие и простые. На мой взгляд это самая важная практика из всех перечисленных здесь.
Чувствуй запах
Как писал Фаулер в своем бессмертном произведении, у кода есть запах. Не буду сильно повторяться, скажу кратко. Если вы ощущаете, что с кодом что-то не так, подумайте как его улучшить. Такое чувство возникает как правило с опытом, однако если вы все время будете анализировать то, что пишете, после написания, оно у вас будет развиваться намного быстрее. Однако помните, идеала нет!
Лучше безобразно но единообразно
Выработайте свою систему именования переменных, функций и тп. старайтесь ее максимально придерживаться. Я вот например возвращаемое значение функции всегда называю result, может это не правильно и не отражает смысл, отсылка во времена делфи, но я так делаю и мне это нравится, мне так удобно. Также я всегда использую var никогда не использую явное типизирование (ну только когда выхода нет). Я так же стремлюсь всегда давать очень короткие имена переменным i,d,v,k для меня не проблема, ибо функции маленькие все понятно из контекста. Зачем писать currentNode если можно написать просто n и при это все равно все ясно? Более того, длинные имена переменных часто только усложняю изложение. Про стандарты кодирования я тут молчу это другая тема, их просто надо придерживаться.
Что? Где? Когда?
Задавайте себе больше вопросов по тому коду который вы пишете. Обрабатываются ли исключения? Правильно ли сделано управление ресурсами? Очищаются ли у вас кеши в нужный момент? Все ли хорошо с потокобезопасностью? Правильно ли вы используете библиотеки? В том ли месте находится функция которую вы пишете? Существует очень много вопросов которые стоит рассмотреть даже после того как код уже работает. Надо задаваться этими вопросами постоянно, тогда это войдет в привычку и все это будет делаться уже автоматом.
Будьте проще и люди к вам потянутся
Шаблоны проектирования, иерархии классов, элементы функционального программирования это все замечательные вещи. Однако стоит по возможности стараться все делать как можно проще. Чем проще код, тем он понятнее и тем легче его сопровождать. Глубокие иерархии классов очень сложно поддерживать и понимать. Зачастую наследования вообще стоит избегать, старайтесь заменять его реализацией интерфейсов. Шаблоны проектирования тоже дают великолепные решения, но подумайте, может стоит все сделать просто? Возможно оно так будет понятнее? Зачастую так оно и есть.
И на последок еще несколько замечаний
— Если вы дебажите свой код, который только что написали, что-то пошло не так.
— Стоит реже компилировать свой код, вообще стоит больше писать меньше собирать. Если вы конечно активно используете юнит тесты, то этот пункт в принципе отпадает, там и правда лучше чаще собирать и запускать тесты. Однако все равно не стоит это делать слишком уж часто.
— Изучите все возможности которые дает среда разработки, выучите горячие клавиши и используйте их, это очень сильно экономит время. Однако не советую сильно настраивать под себя среду, будет очень сложно если придется помогать коллеге за его компьютером.
Я здесь умышленно не привожу примеры кода, сейчас я пишу на C# (как пытливый читатель уже наверно догадался), но дело в том, что не существует принципиальных отличий в написании кода на PHP, C++, Delphi, C# и тп. даже на сильно отличающихся языках (например функциональных).
Хочу отметить, что простое прочтение каких-то правил и советов ничего не дает, надо отрабатывать. И вот это последняя мысль которую я хочу выразить. Не пишете просто код, всегда отрабатывайте и улучшайте свои навыки. “Сейчас просто напишу, а дома на кошках потренируюсь” ничего вам не даст совершенно. Можно было бы еще продолжить и расширить мой список, но я считаю изложенные моменты основными.
Программирование для себя: почему всем нужно научиться писать код
Nastya Nikolaeva
Навык программирования может пригодиться не только тем, кто хочет создавать программы или сайты профессионально. О том, как умение писать код может облегчить жизнь, рассказал Илья Щуров, доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ. T&P публикуют конспект его лекции «Программирование как новый английский, или Почему программирование не только для разработчиков».
Илья Щуров
доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ
Можно придумать множество классификаций, но в первую очередь я бы разделил программирование на две большие категории: программирование для кого-то, когда вы пишете программу, которой будут пользоваться люди, и программирование для себя. Профессиональное программирование — это в основном деятельность для других, и я бы не сказал, что она всегда приятна. Вне зависимости от того, заплатили вам за программу или вы пишете свободный софт, которым может пользоваться кто угодно, огромное количество людей предъявит претензии, что у них что-то не работает, и их всегда будет больше, чем тех, кто вас похвалит. А программирование для себя — занятие очень приятное, и сегодня мы обсудим именно его.
Писать код интересно, но, с другой стороны, это испытание. Ты взаимодействуешь с компьютером, и очень часто это взаимодействие, особенно если ты осваиваешь новую технологию, новый язык, выглядит так. Ты пишешь код, считаешь, что написал его верно, а компьютер говорит, что у тебя ошибка синтаксиса. Действительно, забыл точку с запятой, исправил, запустил заново. А компьютер говорит: «Закрой скобку». Через несколько таких итераций программа начинает работать, и становится ясно, кто в доме хозяин. Дело в том, что и у навыка программирования, и у процесса обучения ему есть некоторые побочные (в том числе положительные) эффекты.
1. Экстремальный опыт руководства
Компьютеры по сравнению с людьми очень глупые, они все понимают буквально, и если вы научились управлять машиной, то, скорее всего, вы справитесь с руководством любыми людьми.
2. Новый подход к информации
Вы начинаете по-другому смотреть на обработку информации, организацию информационных потоков и управления. Например, собирая массивы данных, вы уже задумываетесь, чтобы они были пригодны для последующей автоматической обработки. Это очень важно, если у вас большая организация или проект со множеством информационных потоков, с которыми нужно работать эффективно. Если у вас есть опыт автоматизации, вы довольно быстро поймете, в каком виде нужно получать информацию, чтобы потом ее ловко обрабатывать.
3. Профессиональная коммуникация
Если вы научитесь программировать хотя бы чуть-чуть, вам будет гораздо проще общаться с программистами. Полезно хотя бы на базовом уровне понимать, как устроен мир IT, и коммуницировать в этой сфере без посредников. Люди учат языки, чтобы лучше понять другую культуру, а языки программирования — технологии.
Почему уметь программировать может быть опасным? Первая причина — «тыжпрограммист». Если вдруг кто-то узнает, что вы умеете программировать, на вас начинают сыпаться запросы: «Переустанови мне операционную систему, пожалуйста, ты ж программист», «Почини чайник, ты ж программист» и так далее. Это не самая страшная проблема, есть пострашнее. Например, в 2001 году на первом курсе, когда интернет еще был медленным, я решил, что нужно сделать какую-то штуку, чтобы быстрее обмениваться информацией с друзьями. Я подумал: есть почта, и она работает. Тогда я завел отдельный почтовый ящик для нашей тусовки и написал скрипт. Робот заходил в этот ящик, брал письма, которые туда пришли, и пересылал их всем, кто был подписан на эту штуку. Так сейчас работают гугл-группы. Если я хотел написать всем, я отправлял письмо на этот общий ящик; если кто-то хотел ответить, он отвечал на него же, письмо попадало ко всем, и можно было что-то обсуждать.
Но у переполнился ящик, а когда ящик переполняется, почтовый сервер в ответ на любое письмо направляет отлуп, который тоже является письмом. Оно тоже попало в общий ящик, мой скрипт разослал его по всем адресам, в том числе и по тому, который переполнился. Почтовый сервер сгенерировал новый отлуп и так далее. В результате в воскресенье утром меня разбудил звонок моего друга, который аккуратно сказал: «Возможно, там проблема, потому что у меня в почтовом ящике 6 тысяч писем, и их количество увеличивается». Ничего особенно страшного не произошло, но это была проблема. Тогда я понял, что код легко может выйти из-под контроля и натворить бед, поэтому надо действовать аккуратно.
Это история как в «Маленьком принце»: вы в ответе за тех, кого приручили. Люди и процессы зависят от кода, который вы написали. То есть, как только вы делаете что-то полезное для других, цена ошибки возрастает.
Как научиться?
На эту тему есть две противоположные точки зрения. Первая: учиться программированию очень просто, основные команды можно освоить за три дня. Но тут высока вероятность, что, когда человек столкнется с трудностями, он решит, что его обманули и программирование — это не его. Программировать не просто, трудности возникают. Одна из причин этого состоит в том, что, когда вы программируете, вы каждый раз осваиваете новые технологии, а это всегда мучение.
Противоположное мнение заключается в том, что если вы не программируете со школьных лет, то нечего и начинать. Это тоже неправда. Программирование требует усилий, но вход в эту область открыт, даже если вы никогда им не занимались.
Вполне вероятно, что задача, с которой вы столкнулись, уже решена и это решение где-то лежит. Иногда разобраться с тем, как оно работает, сложнее, чем написать заново. Это стандартная программистская проблема, но для этого у нас есть Stack Overflow, одно из главных изобретений человечества в сфере программирования. Это сайт, где разработчики делятся опытом и отвечают на вопросы друг друга. У каждого участника свой уровень репутации, все очень удачно спроектировано, поэтому на простые вопросы можно получить ответ в течение десяти секунд. Это очень помогает. В современном мире вы не просто пишете программу — вы одновременно используете огромное количество программ и инструментов, уже созданных другими людьми.
Хороший способ научиться программировать — поставить перед собой задачу, которой вам было бы интересно заниматься, и потом попытаться ее решить. Конечно, есть множество онлайн-курсов — почитайте отзывы, чтобы выбрать подходящий. Первый язык программирования — это сложно, потому что нужно перестраивать то, как вы взаимодействуете с компьютерами и анализируете процессы. Универсальных ответов нет, все очень индивидуально. Кому-то достаточно почитать документацию, посмотреть примеры кода, и все понятно. В другой ситуации хорошо иметь наставника, который ответил бы на базовые вопросы. Вот несколько советов, которые кажутся мне важными.
1. Самый лучший способ что-то понять — найти работающий кусок кода, начать его модифицировать и изучать, что получится. Это нужно сделать после того, как вы разобрались с базовым синтаксисом. Подгоняйте код под свои задачи или просто экспериментируйте.
2. Если вы только учитесь программированию, не нужно сразу пытаться писать много кода до тех пор, пока вы не сможете корректно объяснять, чего хотите. Это нужно для того, чтобы компьютер выполнял команды четко и маленькими шажками. Всякий раз ваши эксперименты должны заканчиваться не тем, что вы случайно наткнулись на правильное решение, а пониманием, почему и как это работает.
3. Не беспокойтесь по поводу математики. Желательно знать, что такое остаток от деления числа на другое число, но все зависит от задач, которые перед вами стоят. Конечно, если вы хотите хитро обрабатывать данные, то вам нужна математика в том объеме, который нужен для такой обработки.
4. Не бойтесь. Когда вы будете начинать программировать для себя, наверное, вы будете писать не тот код, который понравится профессиональным разработчикам. Они скажут, что так не пишут, что это избыточно, что такой код будет сложно поддерживать, и так далее. Наверное, они будут правы. Но если вы пишете для себя и если вы только начинаете, это нормально, что ваши первые попытки не являются текстами уровня Льва Толстого. Если вы напишете программу, которая будет работать и решать вашу задачу, то это хорошо.
Есть мнение, что на фоне развития искусственного интеллекта и машинного обучения программисты скоро будут не нужны: компьютеры сами научатся себя программировать. Но мне кажется, что это не так. До тех пор, пока есть задачи и пока нужно объяснять, как их решать, программирование будет существовать. Безусловно, программирование сильно эволюционирует, за последние 20 лет оно изменилось очень сильно. Но от того, что компьютеры стали умнее, разработчиков меньше не стало — наоборот, их стало гораздо больше. И мне кажется, что дальше будет происходить то же самое.