Если программа работает для клиента, это хорошо.

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

Давайте начнем!!

Стандартизация

Когда у вас в команде 2-3 разработчика и у вас разный уровень навыков, способ написания кода будет недостаточно организован. Например, при именовании переменных один разработчик использует такие переменные:

$x = "John";

а другой разработчик использует осмысленные имена, подобные этому:

$full_name = "John Doe";

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

Разработка через тестирование

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

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

Объектно-ориентированное программирование

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

Вывод

Урок здесь, мои коллеги-инженеры, заключается в том, что будьте более внимательны не только к клиенту, но и к другим разработчикам и даже к себе. Чтобы приложение было в хорошем качестве, сам разработчик также должен иметь хорошую практику. Следование вышеуказанному пункту может быть полезным для вас, команды, проекта и даже клиента. Как сказал Аристотель:

Качество — это не действие, это привычка.