Учиться программированию — пожизненная затея. Почти всегда будет попадаться что-то новое, о существовании чего вы ещё не знали.
Я общаюсь с большим количеством студентов, изучающих информатику, и многие из них считают, что научатся в университете программированию, а потом просто пойдут и применят эти знания в своей работе. Возможно, они постигнут какие-то бизнес-знания в процессе. Но профессиональные программисты сразу поймут, что они совсем новички, эти университетские выпускники.
После разговора с @PrototypeAlex, где мы обсуждали множество этапов, которые проходят разработчики, у меня появилось вдохновение написать об этом. За 30 лет, которые я пишу код, я прошёл почти через каждый описанный в статье этап, и некоторые были особенно болезненными.
Узнаёте себя на каком-нибудь из этих этапов? И что я пропустил? Многие этапы ускользают из моего поля зрения; мы никогда не перестаём учиться и делать открытия.
Великий Копипастер
Писать код трудно, но люди решили проблему за вас! Ваш браузер переходит к Stack Overflow при вводе "s" в адресной строке, и вы часами вставляете различные фрагменты кода, чтобы увидеть, какой из них выполняет то, что вам требуется. Иногда это высасывает моральные силы, но в итоге у вас появляется хоть какой-то рабочий код.
Что вы поймете: вы поймёте, что единственный способ научиться хорошо программировать — прорабатывать задачи самостоятельно. Даже если это тормозит вашу работу, вы обращаетесь к Stack Overflow всего пару раз в день. Ваши навыки в программировании улучшаются и теперь вы работаете намного быстрее и намного меньше зависите от кода, написанного другими.
Успешный Методист
Вы научились писать код, который делает то, что вам требуется, но с первого раза ничего не работает. И требования постоянно меняются. Вы втыкаете какой-нибудь код и копаетесь в нём, пока не заработает. Работает? Релизим! Вы безумно продуктивны, и вас хвалит продакт-менеджер.
Что вы поймете: код читается не только компьютерами, но и людьми. Вы начинаете работать над проектами с другими людьми, и они лезут на стену каждый раз, читая ваш код. Вы не написали ни одного теста, и они даже не могут сделать рефакторинг кода и улучшить его, не боясь сломать.
Вы понимаете, что трата времени на попытки сделать код чище может затормозить вас, но если вы это сделаете, ваш код можно будет легко поддерживать в будущем. Ваши партнёры по команде станут счастливее от работы с вами, а вы обеспечите долгосрочную ценность своей компании.
Умный Кодер
Теперь вы знаете разные приёмы своего любимого языка и можете сжать какую-то часть кода в разумный, маленький метод. Вы расслаблено сидите и хвалите себя за то, насколько он компактный! Глядите, какой крутой код, как же он подчёркивает ваши навыки.
Что вы поймете: иногда кажется достаточным просто быть умным, но — оказывается — это не слишком хорошо влияет на социальные взаимоотношения. Мозги других людей не работают так, как ваши, и несмотря на то, что они – хорошие программисты, они не сразу могут понять ваш "умный" код. Намного лучше, когда в вашем коде есть чётко выраженные концепции для всех, кто его читает. Вашему "умному" коду теперь есть место во всяких паззлах и задачках типа code golf.
Комментатор
Другим важно понимать ваш код, поэтому нужно проверять, что он очень хорошо прокомментирован. Вы объясняете, что происходит каждые несколько строк. Всё так приспособлено для чтения!
Что вы поймете: многие комментарии не точно описывают, что делает код, и это делает его удивительно трудночитаемым. Вы решаете, что будете использовать комментарии, чтобы объяснить, почему код написан именно так, как написан, а не описывать, что делает этот код.
Теперь ваш код удобен для чтения, использует описательные имена переменных и множество точно названных методов. Ваши методы высокого уровня читаются теперь почти как английский язык! А комментарии вставлены только там, где не получилось сделать само описательный код.
Рефакторщик Кода
Это дерьмовый код. Он наследуется больше пяти лет, нам нужно избавиться от него и начать новый. Серьезно, мы можем написать намного лучше. С новым было бы намного чище и проще работать.
Что вы поймете: профит от "устаревшего кода" — это то, что формирует вашу зарплату. На данный момент вы уже поработали с несколькими базами кода и поняли, что полноценных, не порченных местами, в мире не существует: вы знаете, что всегда существует технический долг.
Теперь вы сводите рефакторинг к минимуму, и делаете его частью ежедневных изменений, затрагивая только то, что необходимо для отправки этих изменений. Периодически вы обеспечиваете поддержку небольших рефакторинговых проектов, чтобы избавляться от худших и самых затрагиваемых частей кодовой базы. Вы стараетесь добиться того, чтобы новый код был хорошо спроектирован. Вы понимаете, что для факторизации необходим хороший бизнес-кейс.
Приверженец 100%
У вас есть редактор, натасканный автоматически контролировать качество кода по стандарту, и каждый раз перед коммитом вы запускаете проверку метрик, чтобы убедиться, что "код хороший". Все, что вы пишете, обязательно тестируется, и тестами покрыто 100% вашей работы. У вас появляется тёплое, уютное чувство от знания, что вся ваша работа количественно великолепна.
Что вы поймете: хотя у большинства хорошего кода хорошие метрики, вы обнаружите, что не весь код с хорошими метриками хорош сам по себе. Вы поймёте, что опирались на метрики, стандарты и лучшие методики слишком сильно, вместо того, чтобы использовать свои навыки для проверки, насколько хорошим является ваш код.
Теперь вы активно задействуете свои мозги, чтобы написать красивый код, перечитываете его, когда закончите, и используете код-ревью, чтобы удостовериться в правильном пути. Вы постигли принципы, лежащие за границами инструментальных измерений, вместо того, чтобы просто пытаться писать код, который добывает из инструмента определенное число. Вы до сих пор используете средства для метрик, но на уровне все кодовой базы, чтобы получить общее понимание, в каком состоянии код и на что можно обратить внимание, чтобы впоследствии улучшить.
Страсть к трендам
Использование новейших технологий делает ваш код ультрасовременным! Вы любите применять всё новое к production коду. Вы используете функциональный стиль программирования на Ruby, и первым задействовали NoSQL для приложения c формочками. Эти новые технологии намного продуктивнее и элегантнее. Это настолько захватывающее ощущение, и вы знаете, что стали очень ценным своему работодателю. Вы точно не останетесь на задворках истории.
Что вы поймете: страсть к трендам — это круто, но она тянет за собой проблемы. Вы тратите много времени, обходя пограничные случаи и пользуясь новой технологией, с которой никто ещё толком не знаком. Поддержки или библиотек, доступных для нового фреймворка, не так уж много, и людей с опытом его использования, которых вы могли бы нанять — тоже. У одного из конечных продуктов было состояние отказа, при котором потерялись некоторые данные, и для вас это было профессиональным позором.
Вы осознаёте, что использование традиционных технологий для конечных продуктов приносит большую ценность вашей компании, хоть это и более скучный путь, потому что новая технология вам очень нравилась. Вечерами вы ковыряетесь с игрушечными проектами, подпитывая свою одержимую радость и навыки до того момента, когда тренд станет достаточно крутым, чтобы ваш бизнес мог на него положиться.
Фанат Паттернов
Умные люди придумали элегантные паттерны для описания хорошего кода, и вы используете их в своем коде. Всё время. Многие разговоры с коллегами сводятся либо к использованию лучшего паттерна, либо к тому, как можно было бы написать что-то лучше, с другим паттерном. Вы знаете, что при таком подходе, ваш код будут любить умные люди, которые разработали эти паттерны.
Что вы поймете: наблюдая за тем, что ваши коллеги выполняют много работы за то время, как вы успеваете пробежаться только по мелочам, вы понимаете, что, возможно, вы слишком увлеклись. В конце концов, паттерн — это просто грубый шаблон, который ничего не проповедует, а просто направляет вас делать что-то полезное.
Теперь, когда вы усвоили эти шаблоны, можно перестать думать о "реализации паттерна X" и просто писать код, используя интуицию и опыт. Благодаря этому вы можете произвести много полезного кода. (А ещё ваши коллеги счастливы, что вы перестали говорить о паттернах).
Преждевременный оптимизатор
Монолитные приложения не элегантны, а ваша архитектура такая утончённая. Мелкие микро сервисы, каждый из которых управляет одной особенностью приложения, с умным решением для обмена сообщениями — очевидный способ разработки нового приложения. Вы начинаете так, как будто собираетесь продолжать в том же духе, и это гарантирует, что ваше приложение будет масштабируемым.
Что вы поймете: вы обнаружите, что микро сервисы сильно тормозят разработку, рождая всевозможные сложности, с которыми вы бы не столкнулись в монолите. Вы размышляете, что могли бы выйти на рынок намного быстрее, и, естественно, заработать деньги, чтобы быстрее профинансировать разработку, если бы начали с более простого дизайна.
Поскольку вы работали в крупных командах, вы знаете, что иметь больше сорока людей, работающих над одной базой кода — сложная конфигурация: каждый должен знать о системе всё, чтобы эффективно с ней работать, а это не масштабируется. Теперь вы видите плюсы и минусы, и откладываете решение делать рефакторинг сервисов до момента, пока это не обретёт экономический смысл.
Оракул
Ваш код великолепен. Все вам об этом говорят. К вам проявляют профессиональное уважение. Коллеги строятся в очередь к вашему столу, в надежде услышать комментарии об их коде. У вас стрессовая работа из-за вечной занятости, и вас беспокоит то, что компания держится на вас. Когда вы болеете, случаются плохие вещи.
Что вы поймете: вы понимаете, быть оракулом — плохая идея для работоспособности вашей организации. Вместо того чтобы тихо сидеть и писать великолепный код, вы расходуете время на активное обучение разработчиков своей компании. Вы пишете намного меньше кода, и по этой причине падает производительность вашей команды. Но вы понимаете, что если можете поднять уровень навыков каждого разработчика, вместе они напишут код, который вы не успели написать, а потом превзойдут вас.
Вы обнаружите, что разработчики стали более уверенно принимать собственные решения, и, хотя иногда не правильные, они учатся на своих ошибках и становятся отличными разработчиками благодаря вашему наставничеству.
Защитник
Вы один из senior-разработчиков крупной организации или ведущий разработчик в небольшой. Вы помогаете принимать бизнес-решения и обучать своих разработчиков быть великолепными. Но менеджмент или клиенты всегда находят способ принимать плохие решения, и вам приходится защищать свою команду от их некомпетентности. Они хотят реализовать не имеющие смысла, глупые функции или компоненты, которые усложнят код. Вы тратите много времени на борьбу с ними, защищая свой код и разработчиков, и иногда рушите отношения из-за своей страсти к сохранению счастливой команды.
Что вы поймете: разрушив приличное количество отношений, вы осознаете, что имеющийся код и работа — это заслуга менеджмента и клиентов. Вы приходите к выводу, что иногда люди без технического бэкграунда не могут предвидеть технические последствия своих запросов, и делаете своей миссией стать частью их команды, давать им ценную информацию и советы, чтобы у них была возможность правильного выбора. Единственный способ сформировать прочные и доверительные отношения с ними — вести себя, как описано выше.
Как только вы выскажетесь, лучшая стратегия — уйти с их пути, чтобы они могли принять правильное решение для своего бизнеса. Вы всегда будете рядом, чтобы поддержать их, если что-то пойдет не так, но в итоге окажется, что довольно часто всё идёт хорошо, потому что вы построили прекрасные отношения, а худшие решения зарезаются ещё у корня.
(Перевод Наталии Басс)
Комментарии (9)
Vjatcheslav3345
01.11.2016 12:52Вы решаете, что будете использовать комментарии, чтобы объяснить, почему код написан именно так, как написан, а не описывать, что делает этот код.
Я правильно понял? — комментарии должны описывать ИДЕИ, заложенные в код и описывать на высоком, можно сказать — "философском" уровне.
Akdmeh
01.11.2016 17:41Вспомнились рекомендации Боба Мартина с книги «Чистый код» (или «Совершенный код»):
Хорошо написанный код сам себя объясняет, и необходимость в комментариях почти отпадает.
Лучший комментарий — не написанный комментарий, когда код понятен сам по себе без лишних объяснений.
Каждый раз, когда вы используете комментарии для объяснения кода, вы признаете, что вам не удалось написать понятный код и вы используете «костыли» в виде дополнительных объяснений.
Исключения, конечно, есть, но их не так много (для использования документаторов и автоподсветки IDE, для указания копирайта и т.д.)
zenkz
01.11.2016 17:45+6Не считаю себя экспертом или оракулом, но как разработчик стараюсь придерживаться следующих правил в коде:
— Главные принципы хорошего кода — это KISS и DRY. Т.е. код должен быть максимально простым и понятным и в то же время в коде нужно избегать повторений и чтобы изменения происходили в минимальном количестве мест
— Архитектура приложения должна «расти» вместе с приложением: проект может начинаться как монолитный, далее может понадобится выделить сервисы, общие компоненты, реализовать взаимодействия и прочее. Соблюдение KISS и DRY позволяет достичь это сравнительно безболезненно.
— Хороший разработчик должен следить и пробовать передовые технологии, но в реальных проектах использовать технологии 1-2х летней давности (когда они становятся стабильными и проходит «пена» инновационности). Основная цель использования технологий — сократить время разработки и обеспечить стабильную работу системы. (К примеру активно применять .Net Core я планирую только через 1-2 года, а пока всё ещё сижу на классическом ASP.Net MVC/WebAPI)
— Тесты важны и нужны. Как минимум общие и сложные вещи в коде должны быть ими покрыты. С другой стороны я не сторонник TDD (вернее сторонник его только для написания сервисов, т.к. их сложно тестировать).
— Паттерны нельзя выучить, они должны получаться сами, когда ты пишешь код. Использование паттернов — скорее вопрос архитектуры, чем разработки.
— Код пишется для того, чтобы заработать деньги и удовлетворить клиентов. Если ваши предложения экономически невыгодны, то нужно наступить себе на горло и делать то, что принесёт большую прибыль.
— Универсального кода не существует. Код должен делать только одну специфичную вещь. Если стараться написать один код на все случаи жизни, то он будет сложным, менее безопасным и труднее в поддержке.
— Разработчик не должен бояться использовать чужой опыт и разумно копировать код. С другой стороны внешние библиотеки и плагины должны подключаться только в случае крайней необходимости, а простые вещи должны быть реализованы специфично для данного проекта. (К примеру не нужно прикручивать мощный табличный плагин вроде jqGrid или чего-то более современного только чтобы отобразить простые нередактируемые данные и сделать пагинацию).
gxcreator
Ребят, а куда переехали технические статьи?
stardust_kid
На Медиум.
DjoNIK
Что за медиум? Беглый поиск не помог попасть на it-ресурс с таким названием.
Redwan
Блог-платформа.
stardust_kid
medium.com
freetonik
Никуда, просто разбавляем.