для написания быстрого кода разработчик должен

09.07.202208.07.2022 admin 0 Comments

5 советов по быстрому написанию кода на любом языке программирования

Выполнение любой задачи в программировании включает в себя нескольких общих этапов:

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

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

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

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

По возможности применяйте метапрограммирование

Обычно для хранения наборов данных используются сложные типы данных. Например, если нужно хранить и обрабатывать данные о человеке, мы не передаем и не обрабатываем отдельные переменные, такие как имя, возраст, страна проживания и т. д. Вместо этого мы создаем один класс — объект “ключ-значение” — или структуру в соответствии с используемым языком.

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

Но если относиться к person как к данным и извлекать всю информацию (поля и значения), необходимую для генерации SQL-запроса во время выполнения программы, можно быстро написать высокодинамичный код. Эта техника называется “метапрограммирование”, и при работе с большинством популярных языков вы можете применять ее с помощью Reflection API.

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

Пишите готовый к коммитам код с первой попытки

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

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

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

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

Изучайте новейшие возможности языка, но используйте их с осторожностью

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

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

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

Старайтесь не переусердствовать при разработке

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

Есть два способа писать код:

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

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

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

Учитесь быстро печатать на клавиатуре

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

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

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

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

Источник

Секрет быстрого программирования: не задумывайтесь

Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том, ~~можно ли~~ как научиться программировать с космической скоростью.

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

Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код. Впрочем, дедлайны не должны приводить к сложности. Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто». То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.

Теперь давайте разберемся, как, собственно, стать быстрее? Может, это врожденное магическое умение? Надо ли быть «умнее» других, чтобы быть быстрым?

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

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

Это может звучать невероятно, но работает исключительно хорошо. Задумайтесь: когда вы сидите перед вашим редактором, но работа идет небыстро, потому ли это, что у вас низкая скорость набора? Я сомневаюсь: «слишком много набирать» — редкая проблема программистской производительности. Паузы, когда вы не набираете, — вот что все замедляет. А чем обычно заняты в таких паузах разработчики? Пытаются перестать думать — может быть, о проблеме, об инструментах, о сообщении в почте, да о чем угодно. Но всякий раз, когда такое случается, оно означает проблему. Размышления сами по себе — не проблема, но признак какой-то другой проблемы. Вероятно, вместо того, чтобы ходить по кругу в своих мыслях, вам стоит обратить внимание на что-то из этого:

Понимание

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

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

Таких вариантов — бесчисленное множество. Многие пользуются языком программирования, не разбираясь, что (, ), [, ], <, >, +, * и % означают в этом языке. Некоторые разработчики не понимают, как на самом деле работает компьютер. Помните мой «Единственный секрет программиста-рок-звезды»? Вот где суть! Ведь если ты по-настоящему понимаешь, тебе не надо прекращать ненужные размышления. Это также побудило меня написать книгу: понимание того, что есть незыблемые законы создания программного обеспечения, может избавить от многих эпизодов «борьбы с размышлениями».

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

Рисование

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

Начинание

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

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

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

Пропуск шагов

Еще одна специфическая проблема понимания — пропуск какого-то шага в правильной последовательности разработки. Например, наш объект Велосипед зависит от объектов Колеса, Педали и Рама. Если вы попытаетесь написать весь объект Велосипед без написания объектов Колеса, Педали и Рама, вам придется много обдумывать эти несуществующие классы. С другой стороны, если вы напишете класс Колеса, пока вообще не существует класс Велосипед, вам предстоит много размышлений о том, как класс Колеса будет использоваться классом Велосипед.

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

Не перепрыгивайте шаги при разработке своей системы — и это позволит вам быть продуктивным.

Физические проблемы

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

Отвлекающие факторы

Когда разработчик отвлекается на что-то внешнее, например, шум, ему может понадобиться некоторое время подумать, чтобы вспомнить, над чем он работал в своем решении. Ответ тут относительно прост: перед тем, как садитесь за разработку, убедитесь в том, что ваше окружение не побеспокоит вас или отвлекающие факторы не будут вас прерывать. Одним нужно закрыть дверь в свой офис, другим — надеть наушники, кому-то — поставить статус «Не беспокоить»: сделайте так, как вам нужно. Возможно, вам понадобится помощь вашего менеджера или сотрудников, чтобы создать действительно благоприятную для разработки среду.

Неуверенность в себе

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

Ложные представления

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

Бездействие

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

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

Как вам такой подход?

О переводчике
Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Источник