Модель сверхэффективного программиста (2)

начало

Итак, первая «микра» — обучение.

Программирование — это процесс непрерывного обучения. Технологии, платформы, языки, проекты, кодовая база, все они постоянно меняются, и соответственно надо всё время быть в курсе новинок (учиться, учиться и учиться (с)).

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

Как чаще всего программируют юниоры, да и некоторые миддлы? Нагуглить нужный кусок кода, впихнуть его в свой проект, и потом с вероятностью 90% расстраиваться по поводу того, что он не работает, и тупить. Ну или если вдруг изредка повезёт, переходить к следующей задаче.
Главный минус этого подхода в том, что копипаста приводит к появлению в проекте множества частей кода, которые работают непонятно как для разработчика, а потому и непредсказуемо. Сколько побочных эффектов принесёт тупо вставленный из StackOverflow код, неведомо. Да и сам этот код далеко не всегда решает именно ту задачу, для которой был вставлен.

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

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

Несмотря на вроде бы не такое и сильное отличие, подход профессионалов, немного проигрывая в плане времени тактически, очень сильно влияет на их производительность в долгосрочной перспективе. По этому поводу в ближайшие дни я выложу на сайте очень интересную игру-тренажёр, созданную по концепции The Carnegie Mellon Software Engineering Institute. Она посвящена именно этому моменту — что лучше, получить скорейшую выгоду в программном проекте, или инвестировать в долгосрочные преимущества.

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

Далее рассмотрим вторую «микру» — быстрый фидбек от создаваемого кода.

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *