5 плохих привычек разработчиков PHP


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

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

Станьте Backend-разработчиком на PHP
Подробнее

За 5 месяцев Вы овладеете современными инструментами и лучшими практиками для глубокого понимания процесса разработки на PHP.

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

Так какие же 5 худших привычек программирования на PHP существуют?

# 1 Использование кода PHP без понимания того, что он делает

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

Заманчиво просто оставить все как есть. Но это плохая привычка, которую вы действительно должны сломать.

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

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

вернуться в меню ↑

# 2 «Я исправлю это позже…»

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

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

Бывает, правда? В этих случаях у вас может возникнуть соблазн сказать: «Хорошо, я исправлю это позже…»

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

В конце концов, вы просто забудете об ошибке. Что не хорошо. Конечно, не каждая ошибка должна быть исправлена ​​немедленно. Но важно не продолжать добавлять обходные пути вместо того, чтобы есть лягушку и исправлять код навсегда.

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

В этих случаях пометьте ошибочный код тегом (например, классический / * Bugfix * /) и очень скоро добавьте процесс проверки в свое расписание.

Очень скоро означает или через 2-3 дня (более того, вы забудете о деталях ошибки!) или как только закончите свою текущую работу (которая, опять же, должна закончиться не более, чем через пару дней).

вернуться в меню ↑

#3 Не пишите комментарии

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

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

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

Но… Вы когда-нибудь пытались взглянуть на код, который вы написали несколькими месяцами ранее? Если это не прокомментировано, скорее всего, вы не очень разберетесь в этом.

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

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

Стратегия № 1 для начала использования комментариев заключается в следующем: писать комментарии перед написанием кода. Например. Вы собираетесь написать функцию? Начните с комментария функции, описывающего ее назначение, аргументы и возвращаемое значение; затем напишите фактический код PHP.

вернуться в меню ↑

# 4 Недооценка безопасности

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

Типичным примером являются инъекции SQL. DOS-атаки и повышение привилегий — другие примеры.

Слишком часто разработчики недооценивают этот риск, оставляя свои системы уязвимыми для различных видов атак. Наиболее распространенные ошибки безопасности, которые я видел, касаются проверки ввода.

То есть: проверка, проверка и очистка данных из строки запроса (и других источников, включая базы данных, локальные файлы и удаленные ресурсы). Атаки SQL-инъекций также очень распространены.

На самом деле, они все еще были угрозой безопасности в сети № 1 в 2017 году.

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

Чтобы избавиться от этой привычки, задайте себе этот вопрос: «Я точно знаю, что происходит, когда мое приложение получает любую возможную комбинацию входных данных?

Станьте Backend-разработчиком на PHP
Подробнее

За 5 месяцев Вы овладеете современными инструментами и лучшими практиками для глубокого понимания процесса разработки на PHP.

Я на 100% уверен, что все будет работать нормально и моя система будет в безопасности, независимо от того, как приложение будет использоваться удаленными клиентами? » Ваше приложение будет защищено только тогда, когда ваш ответ будет Да.

вернуться в меню ↑

# 5 Не заботиться о масштабируемости

Последняя плохая привычка — игнорировать масштабируемость. Это значит: не заботиться о том, насколько хорошо ваше приложение будет вести себя, когда оно будет расти.

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

Но… Будет ли он работать с 100, 1000, 10000 пользователями? Будет ли оно работать нормально, если база данных будет содержать 10000 элементов или когда удаленные клиенты, получающие данные JSON, будут в 100 раз больше?

Будет ли база данных поддерживать эту рабочую нагрузку? Будет ли время ответа по-прежнему приемлемым? И насколько увеличится потребление системной памяти?

Сейчас: Вам не нужно писать 1000x масштабируемый код с самого начала. Возможно, вашему приложению даже не нужно будет так много масштабировать.

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

Как вы избавляетесь от этой привычки? Добавьте тест на масштабируемость на этапе тестирования / отладки.

Запустите ваше приложение, используя 10x, 100x или 1000x набор данных, который вы использовали на этапе разработки, и посмотрите, как оно работает.

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

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

Есть вопрос или дополнение?

      Оставить отзыв

      EdAdvisor
      Регистрация
      Сброс пароля
      Сравнить товары
      • Итого (0)
      Сравнить
      0