Вы когда-нибудь задумывались о том, как вы пишете код, проведя много лет в программировании? Да!

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

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

1. НЕ ИГНОРИРУЙТЕ ИСКЛЮЧЕНИЕ

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

Отсутствие обработки исключений может привести к:

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

Существует ряд распространенных оправданий, с каким из следующих вы согласны:

  • Это дополнительная работа, и у меня приближается крайний срок.
  • Обработка исключений загромождает поток кода, затрудняя его чтение и определение «нормального» потока выполнения.
  • Это всего лишь игрушечная программа, и ее не нужно писать на уровне, пригодном для производства.

2. НЕ ПРОСТО РЕСТРУКТУРИЗИРУЙТЕ

Реструктуризация не всегда гарантирует, что новый код будет лучше или даже так же хорош, как предыдущая попытка. Я видел несколько неудачных попыток реструктуризации. Если что-то не сломано, зачем это чинить? То, что стиль или структура кода не соответствует вашим личным предпочтениям, не является уважительной причиной для реструктуризации. Думать, что вы могли бы сделать работу лучше, чем предыдущий программист, также не является уважительной причиной.

3. ОБРАЩАЙТЕ ВНИМАНИЕ НА ПРОИЗВОДИТЕЛЬНОСТЬ

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

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

4. ОДНОЛИНЕЙНОЕ РЕШЕНИЕ

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

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

5. ИМЕНА ДОЛЖНЫ БЫТЬ ЛОГИЧНЫМИ

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

6. ЛИЧНАЯ ПРИВЯЗАННОСТЬ НЕ ХОРОША

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

7. СНАЧАЛА ИНТЕГРИРУЙТЕ, ПОТОМ ПРОВЕРЬТЕ, А ПОТОМ ОТКАЗАЙТЕСЬ

Часто, когда программист представляет стороннюю библиотеку, фреймворк, интерфейс или сервис, его любимым делом является прямая интеграция со своим собственным кодом. Каков результат? Вдруг не смогу им пользоваться. Я не могу запустить его. Я не знаю, в чем проблема, я не могу сказать, проблема ли это в сторонней библиотеке или моя собственная проблема. Таким образом, вам всегда нужно сначала запустить официальную демонстрацию, а затем найти способ добавить в нее свою бизнес-логику.

8. СОБЕРИТЕ ТРЕБОВАНИЯ, ПРЕЖДЕ ЧЕМ НАПИСАТЬ КОД

Хорошей привычкой при написании кода должно быть продумывание всех деталей требований в голове и получение деталей. Не все, что вы изучаете, должно быть связано с технологиями. Изучите область, в которой вы работаете, чтобы лучше понять требования и помочь решить бизнес-проблему. Научиться быть более продуктивным — как работать лучше — это еще один хороший вариант. Чем больше вы вовлечены в понимание требований и решение бизнес-задачи; тем больше шансов получить повышение.

Программисты не устанавливают системные требования; клиент делает.

9. НАПИШИТЕ ЮНИТ-ТЕСТ

Написание модульного тестапредоставляет доказательства того, насколько легко модуль кода подвергается модульному тестированию. Это помогает выявить наличие качеств разработки, которые вы хотели бы иметь в коде, таких как низкая связанность и высокая связность. Многие программисты не понимают ценности модульного теста. Неважно, когда рефакторится код и меняется спрос, нельзя кричать! Хорошее модульное тестирование, ваша логика будет ясна.

Хороший модульный тест предоставляет информацию о поведении кода.

10. ОТКАЗАТЬСЯ ОТ ПИСАНИЯ ПЛОХОГО КОДА

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

«Каждый дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям». — Мартин Фаулер