/ фото David Joyce CC
1. Измерение кода в строках
Каждый опытный программист знает, что качество кода не определяется его длиной или временем, которое было затрачено на его написание, считает Джордж Майна (George Maina), сотрудник компании-разработчика ПО Kopo Koop.
Более того, в идеале следует стремиться к тому, чтобы код был написан как можно понятнее, что должно привести к его упрощению и в результате к сокращению его объема. Если две программы функционируют одинаково, то лучшей будет та, код которой содержит меньше строк.
Способность писать короткий код часто воспринимается как показатель высокого уровня работы. Так считал и Стив Возняк, который в одном из своих интервью (см. его 14-ый ответ) отметил способность команды Макинтош писать короткий и качественный код как одну из черт их высокого профессионализма. Ему также приписывается фраза о том, что он мог сделать код из 10 строк, равный по функциональности коду из 100 строк.
Мэттью Фехер (Matthew Fecher), разработчик большого количества приложений на iOS, технический редактор книжной серии «iPhone for Dummies» и «Mac for Dummies», один из основных членов команды AudioKit, также говорит, что его намного больше впечатлит максимально простое решение, а усложнение кода приводит только к увеличению затраченного времени и конечной стоимости проекта.
2. Желание учиться и умение признавать ошибки
Одно из главных качеств, необходимых в программировании — стремление узнавать что-то новое. Речь идет не только о начальной стадии, когда необходимо учиться на своих ошибках и задавать как можно больше вопросов.
Потребность в развитии должна быть свойственна программисту на протяжении всей деятельности, говорит основатель сервиса по подбору разработчиков Scalable Path Дэмьен Филиатро (Damien Filiatrault).
Но в обучении можно использовать не только стандартные техники. Например, в чешском Университете Градец-Кралове для повышения и развития навыка программирования в обязательную программу был введен предмет компьютерной графики (разработчики учебной программы считают, что обучение компьютерной графике позволяет серьезно углубить знания программирования и тем, кто впоследствии не будет связывать карьеру с этим направлением).
Мэтт Милз (Matt Mills), художник, дизайнер и веб-разработчик, подтверждает на собственном опыте, что комбинирование графического дизайна и программирования может здорово расширить область профессиональной деятельности. При этом, по его словам, развитие творческого мышления через изобразительное искусство подталкивает на поиск креативных решений в программировании. А самым юным кодерам доступно даже офлайн-обучение программированию через танец. Малыши познают основные концепции новой для них науки, сравнивая их с последовательностью движений.
Программирование не зря преподается через искусство, еще Дональд Кнут в предисловии к своей книге «Искусство программирования» писал: «Наша дискуссия показывает, что программирование является сейчас и наукой, и искусством, и что обе эти стороны прекрасно дополняют друг друга… Программирование это искусство, потому что в нем применяются накопленные в мире знания, потому что оно требует умения и изобретательности, и особенно потому, что оно создает прекрасное. Программист, который подсознательно чувствует себя художником, будет наслаждаться тем, что он делает и будет делать это всё лучше».
Постоянное расширение горизонтов помогает специалистам легче признавать свои ошибки. Разработчик, работавший на ВМФ США, Мэтт Пикеринг (Matt Pickering), уверен, что растущее количество краткосрочных курсов, обещающих быстро научить человека кодить с нуля, не всегда идет на пользу начинающим специалистам. У них возникает ощущение, что после такого «введения в тему» они знают все, и углублять свои навыки им больше не требуется — налицо эффект Даннинга Крюгера, когда недостаток квалификации приводит к завышенной оценке своих профессиональных качеств.
3. Упор на результат, а не затраченное время
Быстро написать код — далеко не всегда значит успешно справиться с поставленной задачей, учитывая, что эта работа состоит из многих этапов: начиная от изучения требований и заканчивая исправлением багов. Поэтому главным все же остается качество окончательного продукта.
Петер Нироп (Peter Nierop), сотрудник студии разработки Compudivision, считает, что если уж говорить о времени, то гораздо важнее то, сколько времени вы сможете сэкономить пользователям со всего мира. И если благодаря вам они будут делать на три клика меньше, то это вполне стоит трех дней вашей работы (разумеется, ваше время важно, но перенос фокуса со своих усилий на конечный результат здорово помогает начинающим специалистам легче справляться со сложными и комплексными задачами).
Разработчик архитектуры приложений в компании Imagine Communications Скотт Палмер (Scott Palmer) объясняет, что популярные сегодня онлайн-тесты не могут адекватно оценивать качество кода и профессионализм программиста. Конечно, существуют временные рамки и дедлайны проектов, но задаваться целью тратить на создание кода как можно меньше времени — не самая хорошая и совершенно не оправданная (с точки зрения результата) идея.
Этот принцип лучше всего иллюстрирует индустрия видеоигр (разумеется, создание игры не сводится к работе программистов и гейм-дизайнеров, однако их труд в данном случае — ключевой). Например, выпуск Team Fortress 2 был анонсирован еще в 1998 году, а на прилавках игра появилась лишь 9 лет спустя. Ожидание явно стоило этого, учитывая тот факт, что в нее продолжают играть даже в 2016 году. Разработка Diablo III заняла еще больше, целых 11 лет. При этом в год выпуска (2012) игра побила все рекорды по предзаказу. А в 2015 году игра оказалась на 10 месте в рейтинге самых продаваемых игр (30 млн копий).
4. Необходимость предварительной работы
Разработчик интернет-провайдера EarthLink Telecommunication Ашиш Чандра (Ashish Chandra), описывая свой опыт, говорит, что большую часть рабочего времени и даже часть личного тратит на обдумывание кода и поиск оптимальных решений, которые можно внедрить. И даже 50 строк кода в день приобретают совсем другую ценность, когда к их написанию подошли очень вдумчиво.
Джо Армстронг (Joe Armstrong), создавший язык Erlang, при разработке ПО, например, предпочитал очень тщательно документировать все, что только возможно, перед тем, как приступать к непосредственному написанию кода. Очень часто предварительная подготовка играет достаточно большую роль и облегчает работу: Рави Шанкар (Ravi Sankar), инженер-программист в Microsoft, уверен, что так можно сократить или вовсе избежать последующих преобразований и исправлений.
Согласно опросу на Hacker News, многие программисты до сих пор делают записи в блокнотах и даже используют карточки, чтобы привести мысли в порядок и продумать код до начала самой работы. У некоторых заведен отдельный блокнот для каждого проекта, другие пишут или зарисовывают идеи в одном месте, а затем переводят записи в печатный вид. Но все они уверены, что это сокращает время, затраченное на сам процесс написания кода и помогает избежать большого количества ошибок.
5. Коммуникабельность
У коммуникабельности есть две важных стороны — умение работать в команде и понимать клиентов. Но для Криса Кемпа (Chris Kemp), генерального директора консалтинговой компании в сфере информационных технологий и бизнес-систем Paladin Consultants, клиент тоже является частью команды, поэтому услышать его и понять, согласовать план и цели проекта — залог создания успешного продукта (хотя, конечно, далеко не во всех компаниях эта задача лежит на плечах самих разработчиков).
Уже известный нам Мэтт Пикеринг считает, что для развития профессионализма поможет и более активное общение с коллегами-непрограммистами (про то, как объяснять им некоторые концепции, популярные в программировании, мы рассказывали здесь).
Поэтому Дамьен Филиатро включает (под пунктом 2) хорошие коммуникативные навыки в список отличительных черт высококлассного специалиста. Стивен Уайатт Буш (Stephen Wyatt Bush) поделился в своем блоге 10 заповедями программиста, которым его научил отец, работающий в Технологическом университете Тенесси. Согласно 5 заповеди, особое терпение следует проявлять в общении с людьми нетехнических специальностей, чтобы не поддерживать сложившийся у них стереотип о программистах.
Майкл Лайонс (Michael Lyons) и Роб Томсетт (Rob Thomsett) провели психологическое исследование на основе системы типологии личности Майерс — Бриггс (созданной на базе идей Карла Юнга). Они пришли к выводу, что половина или две трети всех программистов по ориентации сознания является интровертами, то есть нам больше интересен внутренний мир идей и ментальных процессов, чем внешний мир людей и предметов.
Две трети больше ориентированы на результат, чем на процесс, поэтому предпочитают иметь четкий план действий. 80% программистов более рациональны, нежели эмоциональны (в стандартной выборке из разных профессий эти качества распределяются 50 на 50), что помогает нам принимать решения, руководствуясь логикой, и писать хороший код.
Кевин О’Шоннесси (Kevin O'Shaughnessy), веб-разработчик из Британии, уверен, что определение своего типа личности способствует пониманию себя и даже анализу своих ошибок в работе. Поэтому он предлагает программистам пройти сам тест и ознакомиться с описанием всех типов личности – иногда это может помочь в споре или общении с коллегами и клиентами.
Джон Олспоу (John Allspaw), технический директор торговой площадки Etsy, пишет в своей статье о том, что чем выше вы поднимаетесь по карьерной лестнице, тем больше к вам предъявляется требований – поэтому универсальные практики для начинающих порой могут пригодиться и опытным разработчикам.
P.S. А какие полезные советы новичкам можете подсказать вы?
P.P.S. О чем еще мы пишем в нашем на Хабре:
Комментарии (32)
gsaw
22.11.2016 16:29+12У опытного программиста есть скрипт stackoverflow.sh, которому можно скормить ТЗ, а на выходе получить готовый проект надерганный из постов на stackoverflow.com
prefrontalCortex
22.11.2016 17:48+5Вы таки будете смеяться. Правда, не stackoverflow.sh, а howdoi.py.
muryk
22.11.2016 20:19+7Я бы поспорил с тем, что короткий код категорически всегда лучше и профессиональнее. Кто из нас не видел написанные в одну строку write-only конструкции, призванные показать крутость «а я вот так могу»? Я бы наоборот рассматривал аккуратную декомпозицию сложного действия в несколькострочный список коротких операций (да еще и с комментариями) как признак более опытного разработчика.
Source
22.11.2016 21:57Тут нужен баланс… Код должен быть настолько коротким, насколько это возможно без потери выразительности, но не короче :-)
LifeKILLED
22.11.2016 23:17+1Кто из нас не видел написанные в одну строку write-only конструкции, призванные показать крутость «а я вот так могу»?
Вы правы, но никто и не утверждал обратное. Ясное дело, что лепка костылей в одну строку приводит к нечитабельности. А в статье говорилось о ёмком и понятном коде.
poxu
23.11.2016 09:18А в статье говорилось о ёмком и понятном коде.
В статье в явном виде написано.
Если две программы функционируют одинаково, то лучшей будет та, код которой содержит меньше строк.
stranger777
23.11.2016 10:47Можно сформулировать так: «Краткость — сестра таланта, ясность — сестра понимания».
Str3lok
23.11.2016 18:25Тут скорее имеется не умение максимум логики уложить в минимум строк, а найти самое короткое решение задачи. А за излишнюю декомпозицию, в сособенности продиктованную прямолинейным single responsibility, иногда хочется прибить. Частенько люди решающие простую и неинтересную задачу, находят интерес в заведомом усложнении решения. 90% багов находится в связях между сущностями. Много сущностей — много кода — много связей — много багов — долгая разработка — долгая стабилизация — интересно делать любую задачу.
drwatson32
22.11.2016 23:54+1На первом курсе я думал, что для программиста нужен определенный склад ума, умение анализировать и составлять алгоритмы.
На втором курсе, я пошел работать интерном и думал, что для программиста нужно много и долго читать Страуструпа
На четвертом курсе, я перешел инженером-разработчиком и понял, что главное засыпать под подкасты Java Posse, ставить окружение и гуглить.
Каждый год приносил мне новое понимание, что нужно программисту.
На данный момент, лично я считаю, что самые банальные советы — самые правильные.
Первый совет — постоянно развиваться и быть в курсе всех изменений в своей основной области.
Второй совет — смотреть, что тащишь с гугла.
NIKOSV
23.11.2016 05:53+1Код пишет один, а читают и поддерживают его многие. Так что на первом месте должна быть простота, понятность, прогнозируемость, слабая связанность (чтобы в случае чего код можно было безопасно переписать или выкинуть не затрагивая другие компоненты) и дружелюбие к дебагингу. А вот во сколько строк кода это выльется — это уже второстепенное. Уж лучше читать простой, прогнозируемый, линейный код хоть и с небольшим копипастом, чем писанину и дизайн в стиле «смотри как я могу!».
AlexZaharow
23.11.2016 10:50+1Вот мои правила.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним.
4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
third112
23.11.2016 10:59+2Согласно опросу на Hacker News, многие программисты до сих пор делают записи в блокнотах
Предпочитаю использовать для этого обычный MS Word. Сначала записываю порядок основных действий, которые должна сделать программа, потом детализирую. (На бумаге часто не хватает места, чтобы вставить несколько строчек, приходится делать вставки-указатели, что может запутать запись.) Каждую строчку стоит начинать с "//". Переходя к кодингу сохраняю файл как «текст с разбиением на строки». Открываю в IDE и под каждым комментарием пишу нужный код. Примерно так же поступаю, когда нужно реализовать чужой алгоритм. Разбиваю описание на естественном языке или псевдокод на смысловые строки с "//" в начале и открываю в IDE. Просто, но удобно!
Если в задаче много сложных мат.формул, то вместо ворда использую LyX.
RomeoGolf
23.11.2016 18:09К вопросу о коммуникабельности: если есть желание расти профессионально, обязательно следует «залезть» в соседнюю область Пишешь сервер — напиши клиент. Пишешь фронт — напиши енд. Пишешь для контроллера — купи за 100 рублей на али авр (или стм), нарисуй и разведи утюгом плату, заставь это работать. Напиши для себя, в свободное время. Если стыдно за результат — можешь никому не показывать, но сделай это. 3/4 вопросов коммуникации со смежниками отпадут.
К вопросу о желании учиться — обязательно надо написать на ассемблере работоспособный проект сложнее хеллоуворда. На любом ассемблере, но интереснее — не интеловском, а типа PDP11 или вообще типа NM6406. После реализации конструкции switch/case отпадают вопросы, чем это лучше десятка if, после реализации функции с выделением места под локальные переменные в стеке отпадают вопросы про то, зачем писать stdcall и чем это отличается от других ...call и почему не стоит делать массив на 100000 элементов локальной переменной. Чем передача параметра по значению отлиается от передачи по ссылке. Не говоря уже о том, что пропадают вопросы, что такое указатель и чем он отличается от самих данных. Вот просто въедается, понимается не просто умом, а руками. Считаю, что асм ни разу не помешает даже PHP-шникам (или кто считает себя дальше всех от ассемблера?) для осознания тонкостей мастерства и оптимизации.
К вопросу о предварительной работе — надо не забывать и о последующей работе. Все, что стало в работе новым для себя, надо задокументировать. Как минимум — в виде хороших комментариев, хорошо бы виде дневника, а еще лучше — в виде статьи на тот же хабр или свой блог (если есть), где это может быть полезно и другим, но будет полезно и себе через какое-то время.
newnew94
23.11.2016 18:25Периодически пересматривать и переписывать свой код на предмет «оптимизации»)
jced
23.11.2016 18:25Странно, что в Вашей версии опытного программиста — опыт совсем не фигурирует в списке :)
Eswcvlad
23.11.2016 18:25Diablo III как пример «упора на результат»? Только фанатам серии этого не говорите…
Skit25
23.11.2016 18:25Иногда я пишу в блокнот мысли, идеи, задачи. Это действительно помогает.
Сейчас застрял в написании одного скрипта, а блокнот в столе, просто лень взять его и написать, что я хочу от программы! Очень ценный совет в статье, спасибо!
Изучение любой науки процесс постепенный. Скорость постижения у всех разная, но процесс примерно одинаков.
Один мудрец сказал: как только понял, что всё знаешь — начал деградировать! Как и описано в этой статье, важный момент всегда изучать.
vilgeforce
Главный совет — гуглить. Причем не готовые решения.
LeReve
А как составить запрос в гугле что бы он не показывал готовые решения?
vilgeforce
«Windows open file» ведет на MSDN, например.
tenbits
Вместо windows лучше сразу писать "msdn open file". Для поиска по Mozilla Developer Network пишем "mdn open file".
vilgeforce
Это уже следующий уровень гугления ;-)
MacIn
Следующий — это зайти на msdn.com и в поиске msdn вбить CreateFile
tenbits
А вы сравните два способа, через google и через msdn.com)
Google: в адр. строке "msdn CreateFile" [Enter] [Tab] (первый результат) [Enter] и вы уже на странице.
Msdn.com: в адр. строке "msdn.com" [Enter] [ Мышкой кликаем на поле пoиска] ["CreateFile"] [Enter] [Мышкой кликаем на первый результат].
Сравнили? И как вам, к тому же, скорость загрузки msdn?)
MacIn
В моем случае для google в адресной стрке набирается google.com и так далее, поэтому путь почти одинаков по длине.
Скорость загрузки? А что с ней не так?
Heisenbug
Она бывает безумно медленной.
MacIn
Ок, соглашусь насчет гугла — немного короче. Самое неудобное — то, что надо открывать поле поиска в msdn, остальное мелочи.
zenkz
Гуглить готовые решения — это не проблема (более того — это здорово ускоряет работу).
Проблема, если бездумно копировать эти решения в свой код.
Любой найденный код в интернете нужно адаптировать и брать… Т.е. иногда из готового решения тебе нужна только одна «правильная» строчка кода.
Ещё одна частая проблема начинающих разработчиков — подключать внешнюю библиотеку на каждый чих.
vilgeforce
Статья для начинающих. Ищущий готовые решения таким и останется. Потом, конечно, когда сможешь сам все написать — можно и готовое брать.
severgun
Это не случится. Ибо пагубная привычка копипастить — зло.
third112
ИМХО гуглить и готовые решения. Обычно решений либо не предлагается совсем, либо предлагается очень много. Первый случай не означает, что нужных решений нет. Скорее всего неверно сделан запрос. Во втором случае программисту поневоле придется вникать в решения, сравнивать их, чтобы выбрать оптимальное для своей задачи. Конечно, бывают халтурщики, которые из множества найденных решений выбирают одно случайным образом. Поэтому я бы посоветовал: гуглить не халтуря! Готовое решение хорошо тем, что можно разобраться в деталях, которые авторы многих «неготовых решений» опускают, считая очевидными и малозначительными. Кроме чтения кода и описания к нему (если таковое есть) очень полезно погонять решение под отладчиком и посмотреть шаг за шагом, как оно работает. Далее полезно бывает поэкспериментировать с этим решением внося изменения в код. Попробовать найти контр-пример, чтобы решение обвалилось. Так повозившись с несколькими готовыми решениями нередко придумываешь свое лучшее решение.
Так и во многих книгах по программированию автор приводит готовое решение и анализирует его, объясняя читателю чуть ли не каждую строчку кода.