Практическая работа по принципам компьютерного программирования

Обновлено: 30.06.2024

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

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

Во-вторых, даже если вы не хотите развивать хорошие навыки программирования, журналы заставят вас это сделать. Каждый авторитетный политологический журнал требует, чтобы вы предоставили сценарии репликации, а некоторые из лучших (например, American Journal of Political Science) начали проверять материалы репликации в качестве условия публикации. Лучше изучить Правильный Путь сейчас, когда у вас есть много времени, чем быть вынужденным, когда вы пишете диссертацию, работаете на рынке или ведете свои собственные курсы.

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

Как выразился Бауэрс (2011 г.): "Анализ данных — это компьютерное программирование". Получив степень доктора политических наук, вы по необходимости станете программистом. Перед вами стоит выбор: быть хорошим или плохим.

Уилсон и др. (2014) перечисляют восемь «передовых методов научных вычислений». Первые два заключают в себе большую часть того, что вам нужно знать:

  1. Пишите программы для людей, а не для компьютеров.
  2. Пусть компьютер сделает всю работу.

2.1 Пишите программы для людей, а не для компьютеров

Первые два слова здесь — писать программы — имеют решающее значение. Когда вы проводите анализ для исследовательского проекта, вы должны писать и запускать сценарии, а не вводить команды в консоль R (или Stata). Консоль эфемерна, но скрипты вечны, по крайней мере, если вы их сохраните.

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

Лично я предпочитаю, чтобы каждый сценарий был автономным и в идеале выполнял одну основную задачу. Типичная разбивка скриптов для моего проекта выглядит так:

  • 0-download.r : загружает данные
  • 1-clean.r : очищает данные
  • 2-run.r : запускает основной анализ.
  • 3-figs.r : генерирует цифры.

Точная структура зависит от характера проекта. Обратите внимание, что сценарии пронумерованы в порядке их запуска.

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

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

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

Моя основная эвристика для читаемости кода такова: Если завтра меня собьет автобус, сможет ли кто-нибудь из моих соавторов понять, что, черт возьми, я делаю, и закончить статью?

2.2 Пусть компьютер сделает всю работу

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

Например, представьте, что вы только что провели большой эксперимент и хотите оценить его влияние на подгруппы. 2 Ваши респонденты различаются по четырем переменным — партийному идентификатору (R или D), полу (мужской или женский), расе (белый или цветной) и образованию (степень колледжа или нет) — что дает вам 16 подгрупп. Вы могли скопировать и вставить свой код, чтобы оценить эффект лечения 16 раз. Но это плохая идея по нескольким причинам.

Копирование и вставка не масштабируются. Копирование-вставка управляема (хотя и ошибочна) для 16 итераций, но, вероятно, не для 50 и уж точно не более 100.

Внесение изменений становится болезненным.Предположим, вы решили изменить способ расчета оценки. Теперь вам нужно вернуться и индивидуально отредактировать 16 фрагментов кода.

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

Мы рассмотрим самые простые способы заставить компьютер повторять структурированные задачи — функции и операторы управления потоком. Чтобы проиллюстрировать это, мы будем использовать результат, который вы обсуждали в Статье I: центральную предельную теорему.

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

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

Давайте рассмотрим выборочное распределение коэффициентов двумерной регрессии из выборки данных \((X_n, Y_n)_^N\) , где \(N = 50\) . Предположим, что регрессор \(X_n\) имеет экспоненциальное распределение, \(X_n \sim \text(\lambda)\) с параметром скорости \(\lambda = 0,25\) . 4 Предположим, что ответ \(Y_n\) генерируется в соответствии с линейной моделью, \[Y_n = \alpha + \beta X_n + \epsilon_n,\], где \(\alpha = 1\) , \(\ бета = -2\) и \(\epsilon_n \sim U[-5, 5]\) . Чтобы сделать выборку из этой совокупности, мы можем использовать встроенные в R функции выборки случайных чисел: rexp для экспоненциальной переменной и runif для униформы. 5

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

Нас интересует распределение коэффициентов МНК по множеству выборок, подобных этой. Для начала давайте напишем функцию для извлечения предполагаемого наклона \(\hat_1\) из двумерной регрессии.

Этот код создает функцию с именем ols_coef . Он имеет два аргумента: x (вектор ковариации) и y (вектор ответа). Он запускает регрессию y на x, а затем возвращает s оценку наклона МНК в качестве выходных данных. Если мы запустим эту функцию для только что смоделированных x и y, она должна выдать коэффициент OLS, который мы видели ранее.

Помните, что нас интересует выборочное распределение коэффициентов МНК — их вероятностное распределение по всем возможным выборкам \(N = 50\) из определенной нами совокупности. Мы можем аппроксимировать это распределение, взяв новую выборку и много раз вычислив наклон МНК (например, 1000 или более). Это было бы невозможно с помощью копирования-вставки. Вместо этого мы будем использовать цикл for для многократного выполнения одной и той же операции.

Вот как работает цикл for. Мы указали i в качестве имени переменной индекса со значениями 1:n_replicates. Цикл for берет каждое значение в последовательности, присваивает его переменной i, а затем выполняет выражение в скобках. В данном случае это состоит в том, чтобы нарисовать выборку данных из того же распределения, которое мы использовали ранее, вычислить оценку наклона МНК и сохранить эту оценку как i-й элемент sample_dist. После завершения выражения в скобках цикл for переходит к следующему элементу заданной последовательности, пока не дойдет до конца.

Давайте посмотрим на результаты и сравним их с нашими ожиданиями. МНК непредвзят, поэтому мы должны ожидать, что средний расчетный наклон будет близок к истинному значению \(-2\) .

И, согласно CLT, оценки должны быть примерно нормально распределены.


Цикл for — это весело, но не злоупотребляйте им. Многие простые операции векторизованы и не требуют цикла. Например, предположим, что вы хотите взять квадрат последовательности чисел. Вы можете использовать цикл for…

… но быстрее (с точки зрения скорости вычислений) и проще просто воспользоваться преимуществами векторизации:

Еще одна полезная часть потока управления — операторы if/else. Они проверяют логическое условие — выражение, значение которого равно TRUE или FALSE — и запускают другой код в зависимости от значения выражения.(Возможно, вы захотите узнать об операторах сравнения: == , > , >= , , , и т. д.)

Давайте отредактируем функцию ols_coef, чтобы мы могли извлекать точку пересечения вместо наклона. Мы добавим в функцию еще один аргумент и реализуем параметр с помощью оператора if/else.

Вот как работает блок if/else в середине функции. Первая строка проверяет переменную наклона. Если TRUE, то выполняется первый набор скобок (извлекает наклон). Если нет, то он пропускает это и запускает второй набор скобок (извлекая точку пересечения).

Также обратите внимание на то, как мы написали наклон = ИСТИНА в аргументах функции. Это устанавливает TRUE в качестве значения по умолчанию, поэтому, если мы вызовем ols_coef() без явного указания аргумента наклона, предполагается, что мы хотели, чтобы он был TRUE .

Существует векторизованная версия операторов if/else, называемая, естественно, функцией ifelse. Эта функция принимает три аргумента, каждый из которых представляет собой вектор одинаковой длины: (1) логическое условие, (2) выходное значение, если условие истинно, (3) выходное значение, если условие равно ЛОЖЬ .

Функции, циклы for и операторы if/else — это лишь некоторые из полезных инструментов для программирования в R. 6 Но даже этих простых инструментов достаточно, чтобы вы могли делать гораздо больше в масштабе, чем вы могли бы с копией- вставить философию.

2.3 Отладка и обращение за помощью

Программировать сложно, и ошибки случаются часто. Как практически все, что мы делаем в академических кругах, это итеративный процесс: ваш код начинается плохо, и цель состоит в том, чтобы со временем сделать его менее плохим, пока он, наконец, не станет приемлемым. Вы всегда должны чувствовать себя желанными, чтобы попросить о помощи! Другим (включая меня) будет легче помочь вам, если вы будете следовать некоторым основным рекомендациям по поиску помощи с кодом.

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

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

Здесь мы запросили квадратный корень из строки символов, с которой sqrt не справляется, поэтому R выдает ошибку. Сообщение об ошибке сообщает нам, что произошло: «нечисловой аргумент математической функции», т. е. вы попытались выполнить математические операции над чем-то, что не является числом.

Первым шагом к исправлению подобной ошибки должно быть чтение сообщения об ошибке. Если вы не понимаете сообщение об ошибке, Google вам в помощь. Stack Overflow, страницы с ошибками GitHub и (в меньшей степени) R listservs — лучшие места для поиска полезных обсуждений сообщений об ошибках.

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

Здесь мы запросили у R квадратный корень из отрицательного числа. Поскольку R по умолчанию не работает с комплексными числами, это приводит к тому, что R предупреждает нас о том, что вывод содержит NaN, что означает «не число». Но обратите внимание, что, в отличие от приведенной выше ошибки, наш код действительно выдал результат.

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

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

Здесь нет сообщения об ошибке или предупреждения, но R не дал нам того, на что мы надеялись. Это, пожалуй, самая распространенная ситуация отладки. Обычно лучше всего действовать шаг за шагом и смотреть, что пошло не так.

Проблема в том, что x[x включает NA , а функция sum() по умолчанию обрабатывает любую сумму, включающую NA , как NA . Все становится яснее, когда мы шаг за шагом создаем наш код и сверяемся с документацией по используемым функциям.

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

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

Минимальный воспроизводимый пример может выглядеть следующим образом:

Проблема с извлечением элементов из каждой строки матрицы

Пример кода:

Ожидаемый результат: 2 , 8, 5, 200 (2-й элемент 1-й строки, 3-й элемент 2-й строки и т. д.)

Фактический вывод: 4, 5, 1, 4

< /цитата>

Это дает мне (или тому, кто помогает вам) именно то, что им нужно, чтобы разобраться в ситуации и помочь вам найти решение. 7

Что вам нельзя делать при обращении за помощью, так это отправлять кому-то 500 строк кода, который все равно не запустится на их компьютере, потому что он зависит от данных, которые не были предоставлены, с описание «Это не работает». Предоставление минимального воспроизводимого примера позволяет человеку, помогающему вам, сосредоточиться на реальной проблеме, не продираясь через множество не относящихся к делу материалов, которые на самом деле не соответствуют сути. Кроме того, процесс создания минимального воспроизводимого примера может быть полезен для отладки кода и понимания того, что на самом деле не так. Я бы сказал, что примерно в половине случаев, когда я собираюсь опубликовать что-то в Интернете в поисках помощи по кодированию R, я сам выясняю и исправляю проблему в процессе создания минимального воспроизводимого примера.

Ссылки

Бауэрс, Джейк. 2011. «Шесть шагов к улучшению отношений с собой в будущем». Политический методолог 18 (2): 2–8.

Уилсон, Грег, Д. А. Арулия, С. Титус Браун, Нил П. Чу Хонг, Мэтт Дэвис, Ричард Т. Гай, Стивен Х. Д. Хэддок и др. 2014. «Передовой опыт научных вычислений». PLOS Biology 12 (1): e1001745.

Или любая другая область социальных наук.↩︎

Иногда вы услышите, что одно из «предположений МНК» состоит в том, что регрессоры и/или член ошибки нормально распределены. Это одна из бесчисленных причин, почему это утверждение ложно.↩︎

Это правостороннее распределение со средним значением \(1 / \lambda = 4\) и дисперсией \(1 / \lambda^2 = 16\) .↩︎

Для моделирования доступно множество других дистрибутивов. См. ?Распределения в R.↩︎

К другим относятся функция replicate, семейство функций apply ( sapply , lapply , tapply , mapply , …), пакет foreach, пакет purrr — и это лишь некоторые из наиболее полезных функций, которые приходят мне в голову. ↩︎

Для этого конкретного примера вам следует использовать синтаксис x[cbind(c(1, 2, 3, 4), c(2, 3, 1, 2))] . Попробуйте!↩︎

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

Писать код легко. Написать хороший код сложно.

Плохой код бывает разных форм. Беспорядочный код, массивные цепочки if-else, программы, которые ломаются после одной корректировки, переменные, которые не имеют смысла — программа может сработать один раз, но после проверки она никогда не сможет выстоять.

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

Как написать эффективный код? Будучи дисциплинированным и целеустремленным. Вот 10 принципов программирования, которые сделают вас лучшим программистом.

1. Будь проще, глупец (KISS)

Звучит несколько резко, но это один из самых важных принципов кодирования, которому нужно следовать. Что означает ПОЦЕЛУЙ?

Это означает, что вы должны писать как можно более простой код. Одно из правил базового программирования — никогда не пытаться быть слишком умным или хвастаться толстым блоком сложного кода. Если вы можете написать сценарий в одну строку, напишите его в одну строку.

Вот простая функция:

Довольно просто. Его легко читать, и вы точно знаете, что происходит.

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

2. Напишите СУХОЙ код

Принцип компьютерного программирования "Не повторяйся" (DRY) означает, что код не должен повторяться. Это распространенная ошибка кодирования. При написании кода избегайте дублирования данных или логики. Если вы когда-либо копировали и вставляли код в свою программу, это не СУХОЙ код.

Взгляните на этот скрипт:

Вместо дублирования строк попробуйте найти алгоритм, использующий цикл.

DRY код прост в обслуживании. Легче отладить один цикл, который обрабатывает 50 повторений, чем 50 блоков кода, каждый из которых обрабатывает одно повторение.

3. Открыто/Закрыто

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

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

Их код сломается. Это, вероятно, сделает ваши когорты очень несчастными. Они больше не захотят пользоваться вашей библиотекой, какой бы полезной она ни была в период своего расцвета.

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

4. Композиция важнее наследования

Если вы пишете код с использованием объектно-ориентированного программирования, вы обнаружите, что этот принцип программирования очень полезен. Принцип композиции над наследованием гласит: объекты со сложным поведением должны содержать экземпляры объектов с индивидуальным поведением. Они не должны наследовать класс и добавлять новое поведение.

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

5. Единая ответственность

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

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

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

6. Разделение интересов

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

Хорошо известный пример — модель-представление-контроллер (MVC). MVC разделяет программу на три отдельные области: данные (модель), логика (контроллер) и то, что отображается на странице (представление). Варианты MVC распространены в самых популярных современных веб-фреймворках.

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

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

7. Вам это не понадобится (ЯГНИ)

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

Пытаясь написать СУХОЙ код, программисты могут нарушать этот принцип. Часто неопытные программисты пытаются написать как можно более абстрактный и универсальный код. Однако излишняя абстракция приводит к раздуванию кода, который невозможно поддерживать.

Применяйте принципы СУХОГО программирования только тогда, когда это необходимо; если вы заметили куски кода, написанные снова и снова, реализуйте уровень абстракции. Не заглядывайте слишком далеко вперед за счет текущей партии кода.

8. Документируйте свой код

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

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

Вот функция JavaScript с комментариями, которые помогут вам в коде:

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

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

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

9. Рефакторинг

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

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

10. Чистый код любой ценой

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

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

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

Изучение принципов компьютерного программирования: что делает хорошего программиста?

Чтобы научиться быть хорошим программистом, требуется немало времени и усилий. Эти 10 правил базового программирования помогут вам стать профессиональным программистом.

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

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

Держите в уме общую картину и сосредоточьтесь на деталях.

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

Чтение предшествует написанию

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

Размышление предшествует написанию кода

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

Покажите, как бы вы это сделали

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

Используйте общие шаблоны

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

Используйте модульный подход

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

Развить положительное отношение к отладке

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

Проверьте свою работу

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

Ожидать объяснений

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

Поощряйте сотрудничество

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

Находите значимые контексты

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

Поощряйте самостоятельное обучение

Независимая проектная работа учащихся дает возможность для самостоятельного обучения. Недвусмысленно предлагайте стратегии того, как учащиеся могут освоить новые концепции и методы, имеющие отношение к трудностям, с которыми они сталкиваются при работе над собственными проектами. Предложите надежные источники для самостоятельного изучения, включая учебники, языковую документацию, онлайн-материалы, такие как Isaac Computer Science и Runestone Interactive, и сообщества, такие как StackOverflow. Имейте в виду, что недостаточно копировать и вставлять код откуда-то еще, даже если указан источник: важно, чтобы ученики узнали, как работает код и как они могут применять изученный подход к другим задачам. Регулярная домашняя работа, в которой учащиеся продолжают работать над расширенным проектом и проводят собственное независимое изучение, чтобы помочь им в этом, может быть полезна, хотя учителям было бы разумно ожидать регулярных обновлений о прогрессе.

Предложить опыт использования нескольких подходов к разработке

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

Стремитесь к беглой речи

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

не повторяйте основное изображение

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

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

Что такое СУХОЙ?

Термин "не повторяйся" был введен в 1999 году Энди Хантом и Дэйвом Томасом в их книге Прагматичный программист. Они определили это как «Каждая часть знаний должна иметь единственное, недвусмысленное, авторитетное представление в системе».

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

Представьте, что вы запрограммировали приложение, которое бросает мяч вашей собаке раз в час в течение дня. Вместо того, чтобы писать весь код для поиска мяча, его подбора и броска мяча 24 раза (по одному разу в час), вы пишете код один раз и даете ему имя, например throw.ball . Затем все, что вам нужно сделать, это каждый раз набирать throw.ball.

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

У программистов есть чувство юмора, поэтому они также придумали антоним для DRY: WET, который может означать либо Нам нравится печатать, либо Тратить время всех, в зависимости от того, кого вы спросите.

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

Узнайте, где вы повторяетесь

Если вы когда-либо пробовали систему продуктивности, многое из этого покажется вам знакомым. Такие системы, как «Getting Things Done» (GTD) и «Zen to Done», следуют аналогичному процессу. Разница здесь в том, что мы подходим к процессу, фокусируясь на ненужном дублировании.

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

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

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

Попросите других выполнить их рутинные задачи. Это поможет вам заполнить пробелы.

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

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

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

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

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

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

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

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

Глядя на пример на изображении выше, я оценил каждое задание от 0 до 5 (5 – самый высокий балл) в каждой из четырех категорий. Затем я суммировал каждое задание — те, которые получили самые высокие баллы, — это те, которые лучше всего подходят для СУХОГО лечения.

Устраните повторение на работе

Теперь у вас есть четкое представление о том, какие задачи выиграют от DRY, поэтому пришло время исключить повторение.

Совет 1. Создавайте шаблоны

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

Если задача кажется слишком сложной для базового шаблона, вы можете создать стандартную рабочую процедуру (СОП). Пройдитесь по задаче и разбейте ее на отдельные этапы, которые затем можно использовать в качестве основы для собственной СОП или делегировать задачу кому-то другому.

Вот области, наиболее подходящие для шаблонов:

Электронные письма

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

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

Внутренние коммуникации

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

Внешние документы

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

Презентации

Если вы проводите более одной презентации в год, сделайте себе шаблон презентации. Даже если каждая презентация сильно отличается, скелет может быть одинаковым.

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

Совет 2. Найдите подходящие приложения

Есть ли приложение, которое может сделать эту работу за вас?

Ответ почти наверняка да.

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

То же самое касается практически всего: от планирования встреч до создания опросов.

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

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

Совет 3. Автоматизируйте повторяющиеся задачи

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

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

В зависимости от того, какие задачи получили наибольшее количество баллов в вашей оценке DRY, вы можете создать свой собственный рабочий процесс, но вот несколько идей, которые помогут вам начать работу:

Управление проектами

Внутренние коммуникации

Управление файлами

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

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

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

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

Изображение рук, печатающих код из Free-Photos через Pixabay. Изображение руки, делающей заметки из StartupStockPhotos через Pixabay. Изображение человека, смотрящего на доску объявлений из StartupStockPhotos через Pixabay. Карикатура эффективности от xkcd.

Получайте советы по продуктивности прямо на почту

Мы будем отправлять вам электронные письма 1–3 раза в неделю и никогда не разглашаем вашу информацию.

Дэниел Роуз – копирайтер, который помогает компаниям, работающим с клиентами в сегменте SaaS, избавляться от скучного текста и активно общаться со своими клиентами. В свободное время он читает триллеры, пишет триллеры или смотрит «Ковбой Бибоп» (снова).

Читайте также: