Как стать хорошим программистом

Зададимся вопросом: что нужно для того, чтобы стать хорошим программистом?

Как и везде, нужно развивать качества и навыки.

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

1.     Уметь читать и писать по-английски
2.     Уметь "вслепую" печатать на клавиатуре
3.     Уметь грамотно и связно выражаться

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

Со своего опыта могу сказать, что только с такими качествами можно нормально ориентироваться в разработке ПО.

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

И да, математика в общем не нужна.

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

1. Веб-приложения, такие, как, например, этот блог.
2. Приложения реального времени, такие, как, например, серьёзные симуляции виртуальной реальности ("компьютерные игры"), или Google Earth.
3. Программное обеспечение контроллеров, встроенное в аппаратуру ("встроенное ПО"), например, ПО калькулятора, стиральной машины, бионического протеза, инсулиновой помпы.
4. "Коробочное" ПО, традиционное, которое условно "устанавливается" на компьютер и позволяет решать какие-то задачи.

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

Я обещал книги. Вот они:

1. "Чистый код", Роберт Мартин
2. "Совершенный код", Стив Макконнелл
3. "Программист-прагматик. Путь от подмастерья к мастеру", Эндрю Хант et al.
4. "Идеальный программист", Роберт Мартин
5. "Алгоритмы. Руководство по разработке", Стивен Скиена
6. "Человеческий фактор. Успешные проекты и команды", Том ДеМарко et al.

Здесь перечислены книги, которые образуют фундамент знания разработчика любого ПО вообще. Они великолепны. Я вот "алгоритмы" ещё сам не дочитал, но это потому что она просто систематизирует то, что я уже на собственном опыте узнал из разных источников. После этих книг имеет смысл почитать хардкор:

1. "Структура и Интерпретация Компьютерных Программ", Харольд Абельсон et al.
2. На русском нет: "Concepts, Techniques, and Models of Computer Programming", Peter Van Roy

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

Ещё есть пять книг, описывающих приемы не разработки, а сопровождения программ.

1. "Рефакторинг", Мартин Фаулер et al.
2. "Приемы объектно-ориентированного проектирования. Паттерны проектирования", Эрих Гамма et al.
3. "Шаблоны корпоративных приложений", Мартин Фаулер et al.
4. На русском нет: "Specification by Example", Gojko Adzic
5. "Непрерывное развертывание ПО", Джез Хамбл

Весь этот свод из 13 книг - это Веды разработки ПО. Никто не скажет, как стать "хорошим программистом" лучше, чем они.

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

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

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

Например, вы решили стать разработчиком веб-приложений. Освойте платформу Ruby on Rails, пройдя последовательно вот это руководство: http://railstutorial.ru/chapters/4_0/beginning или платформу Node.js, начав отсюда: https://nodejs.org/documentation/tutorials/ (я предупреждал про английский язык), или платформу PHP, начав отсюда: http://php.net/manual/ru/ (я предупреждал про любовь к чтению). Это в целом равномощные платформы, разница только в синтаксисе и некоторых специфических возможностях, трудно реализуемых на смежных платформах.

Или вы решили писать встроенное ПО. Тогда стоит начать с проекта Arduino: http://www.arduino.cc/, правда придётся вложиться в "железо".

Или вы решили писать "коробочное" ПО, тут у вас огромный выбор языков программирования, например, Haskell: https://www.haskell.org/ или Erlang: http://learnyousomeerlang.com/ или C#: https://msdn.microsoft.com/ru-ru/library/67ef8sbd.aspx или Common Lisp: http://www.gigamonkeys.com/book/

Кстати, для оценки "хорошести" программиста можно воспользоваться вот этой "матрицей компетентности программиста": http://dev.by/pages/programming_matrix

Как написать пятиминутный доклад на студенческую конференцию

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

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

Если кому-то план покажется очевидным, рад за вас. Если нет — то вот он, пожалуйста.

1. С чем связана работа + что было выполнено. (2 предложения)

   «Моя работа связана с...»

   «В её рамках было разработано...»

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

2. Предметная область. (2 предложение)

   Скорее всего, в одно предложение уложиться не удастся, поэтому выделяется два.

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

   Скажем, если написали «Моя работа связана с разбором s-выражений при помощи многопоточных компиляторов на языке Haskell», значит, в одном предложении рассказываем, что такое s-выражения, в другом — что такое многопоточные компиляторы (раскрываем только самые сложные/конкретные концепции, на всё времени нет)

3. Задача. (1 предложение)

   «Решалась задача...» или «Была поставлена задача...»

   Одним предложением описываем поставленную задачу, так как контекст уже установлен.

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

   Я многократно видел примеры того, как единственным вопросом из зала было: «А как полученные вами результаты соответствуют вашей задаче?».

4. Актуальность. (1 предложение)

   «Данная задача имеет ценность, потому что...»

   Актуальность означает одно из двух: а) какую пользу принесёт решение вашей задачи или б) какие трудности существуют из-за того, что данная задача до сих пор не была решена.

5. Методы. (3 предложения)

   «Для решения задачи было использовано...»

   Ни в коем случае нельзя углубляться в подробности, потому что аудитория гарантированно уснёт. Они не занимались этой работой, им априори не так интересны детали.

   Если кому-то станет действительно интересно, он спросит после доклада.

6. Результаты + тесты. (2 предложения)

   «В качестве конечного результата было получено...»

   «Работа оттестирована на...» или «В качестве тестовых данных были использованы...»

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

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

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

7. Выводы. (1 предложение)

   «Полученные результаты позволяют сделать вывод о том, что...»

   Всегда спрашивают о выводе, если сам об этом не сказал.

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

8. Где может использоваться. (1 предложение)

   «Эта работа может быть использована для...»

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

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

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

Context-dependent Behat tests steps

Preamble is this: we have the PHP-based website, and we are testing it with the Behat+Mink+MinkExtension combo.

Suppose we want to write the following test scenario:

When I am in the Friends section

… (something there) …

Then I should see “My Friend” in search results

Let's define this steps in our FeatureContext. First step we can define with the following regexp: /^I am in the Friends section$/ because we really don’t need the method of FeatureContext class containing long switch enumerating every possible section of the site.

/**
 * @Given /^I am in the "Friends" section$/
 */
public function iAmInTheFriendsSection() {
 return new Given('I am on "/friends"');
}

Second step we can define with the following regexp: /^I(?: should)? see "([^"]*)" in the search results$/.

/**
 * @Then /^I should see "([^"]*)" in the search results$/
 */
public function iShouldSeeInTheSearchResults($search_term) {

 // separate helper function to search the "search results" HTML element
 $search_results = $this->getSearchResultsElement();

 // separate helper function to search the $search_term text in $search_results element
 $this->trySearchTextOnDomElement($search_term, $search_results);

}

It should be obvious why we use the custom test step instead of using the predefined test steps and writing something like 'I should see "My Friend" in ".search-wrapper form input[role="search"]" element'.

Then, someday, sure thing, we will want to write the following scenario:

When I am in the Shop section

… (something there) …

Then I should see “Interesting product” in search results

And in here, we have another “search results”, which should be found by completely different selector and which is located on different page.

So, this is the context-dependent statement: term “search results” depends on what “section” we mentioned previously. This is right from the linguistics. To be able to use this natural-language feature we need to implement it somehow.

I'll use the abbrev CDTS instead of longer "context-dependent test step".

Fortunately, Behat has a feature with exactly the same purpose: subcontexts. Unfortunately, it's not working in the way we need to use the CDTS properly.

In an ideal world, we can do this:

/**
* @Given /^I am in the Friends section$/
*/
public function iAmInTheFriendsSection() {
 $this->useContext('friends_section', new FriendsSectionContext())
 return new Given('I am on "/friends"');
}

and this would load the FriendsSectionContext and all CDTS definitions in it, like the following:

// in FriendsSectionContext class
/**
 * @Then /^I should see "([^"]*)" in the search results$/
 */
public function iShouldSeeInTheSearchResults($search_term) {
 // This selector is valid only in the context of "Friends" section.
 $search_results_selector = '#PeopleFinder #pf_all .results';

 // Logic to check if the given $search_term is the present in anything called "search results" in the context of "Friends" section.
 $search_results = $this->getSession()->getPage()->find('css', $search_results_selector);
 $search_term_present = strpos($search_results->getHtml(), $search_term);
 if ($search_term_present === false) {
  throw new Exception(...);
 }
}

We useContext different context class, we get different definition for the /^I should see "([^"]*)" in the search results$/ test step.

Unfortunately, Behat cannot load the test step definitions from subcontexts at runtime. Apparently, it’s because it should parse the regexps in docblocks corresponding to definitions or something like that. So, are forced to load all our subcontexts right in our constructor.

Apart from being horribly ineffective, this prevents us from defining the test steps having same regexp across several different separate subcontexts.

Workaround for this problem is this:

1. add the property to the FeatureContext which will hold the reference to current subcontext, name it like "location_context" or so,
2. make the context-setting ('I am in the "..." section') test step set the "location_context" to the subcontext needed (you can get the subcontext with the call to getSubcontext('alias')),
3. move the context-dependent logic to “normal” subcontext methods, which should have the same name across all subcontexts,
4. register all subcontexts with useContext under meaningful aliases like "friends_section", "shop_section", etc,
5. define the context-dependent test step like 'I should see "..." in search results' in main FeatureContext class,
6. in the definition of this step, get the context-dependent logic needed by calling the relevant method on the subcontext the "location_context" property currently points at.

So, we need our context-setting test steps to be like this:

/**
 * @Given /^I am in the "Friends" section$/
 */
public function iAmInTheFriendsSection() {
 $this->location_context = $this->getSubcontext('friends_section');
 return new Given('I am on "/people"');
}

Assuming 'friends_section' is an alias of the FriendsSectionContext, and it was set in the constructor, after this test step, our "location_context" will be FriendsSectionContext, and, say, it's getSearchResultsElement() will do exactly what we need in the "Friends" section.

Then, the context-depentent test step will be like this, getting the location-dependent logic from the "location_context" set previously:

/**
 * @Then /^I should see "([^"]*)" in the search results$/
 */
public function iShouldSeeInTheSearchResults($search_term) {
 // getSearchResultsElement() is defined in subcontext which was set before in $this->location_context
 $search_results = $this->location_context->getSearchResultsElement();
 $search_term_present = strpos($search_results->getHtml(), $search_term);
 if ($search_term_present === false) {
  throw new Exception(...);
 }
}

Main point is this: we want to check if something should appear in the "search results" entity in some different page → we can use the same test step in our .feature files, just explicitly name the section needed beforehand somewhere above in the text. This will make the .feature files a lot more human-readable.

This concludes the explanation about how to use this linguistic technique in Behat tests.

Простое и сложное в Common Lisp

Сегодня развлекался с моим любимым Common Lisp и обнаружил интересную деталь.

Допустим, мы хотим написать простую функцию для определения среднего арифметического набора заданных чисел. Чтобы она работала вот так:

(average 1 2 3 4)
5/2

...ну хорошо, хорошо:

(coerce (average 1 2 3 4) 'float)
2.5

Заметьте то, что я не хочу передавать в average список, я хочу кортеж чисел. Интересная деталь вот в чём: самая простая (в смысле, лаконичная) реализация, которая пришла мне в голову, это такая:

(defun average (&rest args)
  (/ (reduce #'+ args) (list-length args)))

Дело в том, что определение среднего арифметического — это задачка для средней школы, и мы вполне можем её дать в качестве задания по программированию на второй паре (на первой мы изучим весь синтаксис лиспа вместе с макросами defun и defvar). Но на самом деле мы не можем её дать, потому что у нас есть вот эта форма в решении: (reduce #'+ args), и, чтобы студенты смогли ей бегло пользоваться, нужно, чтобы они знали как минимум:

• о разделении пространства имён переменных и пространства имён функций;
• как передавать в функцию имя другой функции;
• о назначении и работе reduce, что для не знакомого с функциональными методами, вообще говоря, стопроцентная магия (особенно если их уже обработали алголоподобными языками);
• о том, что параметры, переданные через &rest, оборачиваются в список.

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

Конечно, мы можем соорудить нечто работающее из let и dotimes, но тогда зачем нам Common Lisp вообще? :)

Паттерн «Веб-функция»

Допустим, вам нужно написать endpoint для аякс-запроса. Или обычный обработчик обычного POST-запроса от веб-формы. Тогда основные действия, которые обязательно должны быть в процессе обработки, будут такие:

• Фильтрация входных данных (это НЕ валидация бизнес-правилами, только лишь такие действия, как укорачивание, очистка от окружающих пробелов, исключение непечатных символов, приведение к нижнему регистру и т. д.). Или мы можем даже сыграть роль адаптера и переименовать некоторые параметры запроса в вид, ожидаемый обработчиком.
• Обработка запроса. Здесь мы собственно делаем то, зачем существуем. Мы ожидаем уже более-менее очищенный от мусора массив входных параметров, возможно, среди которых есть ошибочные (например, числовое значение вне допустимого диапазона, или передан массив вместо скаляра).
• Форматирование результата для отклика клиенту. Например, мы можем возвращать JSON, или генерировать HTML страницу по шаблону. Или генерировать изображения. Или отдавать файлы с диска.

Если записать в функциональном стиле на PHP, то можно получить следующий шаблон хэндлера:

<?php

echo format(process(clean($_REQUEST)));

/**
 * Здесь очистка суперглобального массива $_REQUEST и генерация массива $request
 * 
 * @param array $request Данные запроса из массива $_POST или $_GET (или $_REQUEST).
 * @return array Очищенные данные из запроса, которые ожидает функция process.
 */
function clean($request)
{
  // TODO
  return $request;
}

/**
 * Здесь выполнение действий согласно запросу $request
 * 
 * @param array $request Параметры запроса, очищенные функцией clean.
 * @return array $result Результат работы со всей информацией, необходимой для форматирования ответа клиенту.
 */
function process($request)
{
  // TODO
  return $request;
}

/**
 * Здесь форматирование результата работы для выдачи клиенту.
 * 
 * @param array $result Результат работы, как он сгенерирован процессором. Нам не дозволяется использовать какие-либо другие данные.
 * @return string Форматированный ответ, готовый к отправке клиенту через echo.
 */
function format($result)
{
  // TODO
  return json_encode($result);
}
?>

Если process сталкивается с ошибкой, он пишет об этом в результат своей работы (например, в поле 'error') и сразу возвращает результат в format.

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

Мысли о третьем шаге в TDD

Сегодня второй раз в жизни пишу код согласно чистому TDD, прямо как заповедали такие мастера, как Роберт Мартин, Эндрю Хант и Майкл Физерс. Один случай меня заставил серьёзно задуматься о разнице в подходах к разработке.

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

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

Только после раздумья длиной что-то около полудня я понял, почему так важно соблюдать это правило, хотя ответ очень прост. Если ты напишешь код, который не предусматривают твои тесты, пусть даже он будет выполнять какую-то идейно полезную работу (а он, конечно же, будет выполнять идейно полезную работу), он не будет покрыт тестами. А код, который не покрыт тестами — это legacy код, которому положено гореть в аду. Более того, если ты оставишь весь этот код среди другого, чистого и покрытого тестами, он будет, как ржавая арматура, мешать добавлять новую функциональность. Так как он не покрыт тестами, а ты в целом стараешься следовать TDD, значит, все эти буквы становятся просто шумом, про полезность и надёжность которого ты не знаешь ничего.

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