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

Не поймите меня неправильно ...

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

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

Признавать, что есть проблема!

Первое правило решения проблем - знать проблему, которую нужно решить ...

Мне потребовалось время, чтобы отбросить свое эго, признать проблему, и с этого момента это было лишь вопросом времени, когда я увижу РЕАЛЬНЫЕ РЕЗУЛЬТАТЫ!

Если вы могли резонировать с этим, то эта статья создана для ВАС, мой друг!

1- Диагностируйте перед решением

Это говорит само за себя, но я сам какое-то время игнорировал это.

Я думаю, что очень недооценивается, насколько важно тратить время на понимание проблемы / ошибки перед написанием кода.

Убедитесь, что вы потратите пару часов:

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

2- Приоритет ремонтопригодности

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

Как студент; Я всегда работал над краткосрочными проектами, когда у вас есть проблема, а вы даете решение. БИНГО, вы прошли этот курс! Другими словами, моей целью было просто доказать, что я могу решить проблему!

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

Работа не заканчивается на выпуске продукта, вас ждет долгосрочное обслуживание!

Вы должны подумать:

  • Зависит ли ваша реализация от времени? (Добавление дополнительного кода может изменить время, а затем перейти к реализации, управляемой событиями)
  • Имеет ли ваша реализация зависимость класса / функции? (ваша реализация может работать не так, как ожидалось, если какие-либо зависимости изменились)
  • Будет ли когда-нибудь расширен этот класс или функциональность? Насколько сложно будет его расширить?

3- Сделайте ставку на переносимость

Переносимость означает, что одна и та же часть приложения не зависит от платформы / SDK.

Программное обеспечение обычно состоит из трех основных уровней: приложений, промежуточного программного обеспечения и платформы.

Уровень промежуточного программного обеспечения - это в значительной степени инкапсулированная функция API / SDK, уровень приложения должен использовать только функции промежуточного программного обеспечения и уровней платформы.

Отсутствие в приложении каких-либо прямых функций API / SDK гарантирует вам портативность!

Если вам нужно использовать другой API / SDK, работа будет выполняться только на уровне промежуточного программного обеспечения!

4- Сделайте ставку на удобочитаемость / чистое кодирование

Мы живем в мире, где почти все можно заменить, поэтому вашим будущим новым коллегам будет проще читать ваш код и быстро понимать!

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

Я не знаю ни одного разработчика, который читал бы Чистый код и не рекомендовал бы его публично!

5- Правило трехкратного рефакторинга

Следуя упомянутому ранее пункту обслуживания, когда точно пора провести рефакторинг вашего кода?

Я узнал это правило от своего очень умного коллеги (Томас В.)…

Вам разрешено вносить незначительные изменения в класс / функцию только дважды, в третий раз, когда вы выполняете правильный рефакторинг!

Вам либо нужно провести рефакторинг, используя:

  • Различные шаблоны проектирования.
  • Добавление обратных вызовов.
  • Разделите класс на несколько более мелких.

6- Продолжайте учиться

Хорошо, мы работаем в сфере высоких технологий, и каждый год появляются новые технологии / языки.

Не учитесь для краткосрочной задачи, учитесь для своей карьеры!

К счастью, Medium - одна из лучших платформ, которая держит нас в курсе всех новинок отрасли!

7- Документация

Следуя пункту о удобочитаемости, упомянутому ранее, документация является важной частью вашей повседневной работы!

Документацию можно разделить на 3 основные категории:

  • Документирование протоколов, методов шифрования / дешифрования и т. Д.
  • Документирование пользовательских случаев (желательно с использованием блок-схем, например, Draw.io)
  • Документирование Для разработчиков (например, диаграммы классов с использованием генератора документов исходного кода как Doxygen)

8- TDD (разработка через тестирование)

Самая известная точка роста - модульное тестирование!

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



Основы разработки через тестирование
TDD позволяет разрабатывать тесты для каждой функции, защищая программные процессы от сбоев во время и после… medium.com



Вам также может понравиться:



10 программных инструментов, которые должен иметь каждый встроенный разработчик!
Введение formus14.medium.com



Следите за другими техническими статьями!