Если вы хотите стать хорошим разработчиком, вам следует больше думать об «удалении», чем о «написании».

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

Удалить сложнее, чем написать.

Обычно младший разработчик моей команды каждый раз что-то добавляет для решения проблемы. Добавление переменных для хранения некоторых данных, добавление функций для обработки чего-либо, добавление флагов для управления чем-либо и т. д. Однако старший разработчик ничего не добавляет легко. Иногда он абстрагирует какой-то процесс и уменьшает дубликаты. Удаление старых комментариев, удаление ненужных частей и т. д. Наконец, его PR делает продукт проще и понятнее, чем раньше, независимо от того, решает ли он проблему.

Я знаю, я знаю, что удаление действительно ужасно. Практически случаи, даже если вы добавляете в свой продукт какие-то новые вещи, продукт не вызывает фатальной ошибки. Но если изменить или удалить кажущиеся ненужными вещи, это может вызвать некоторый дефект. Если у вас есть опыт работы с каким-либо проектом по обслуживанию, особенно переданным от другого человека, я думаю, вы видели много запутанного и сложного или выглядящего расточительным (но это точно рабочий :0) продукт. И вы, возможно, проигнорировали что-то над головой. Тебе действительно не хотелось это видеть, но ты работал над этим с ворчанием. Если это так, я хочу сказать, пожалуйста, остановите это и давайте улучшим его. Одним из простых способов является «удаление». Практически к таким продуктам добавлено много ненужных кем-то вещей. Удаление делает его маленьким и простым. Это означает, что наше развитие повысится.

Удалить сложнее, чем написать. Удалить что-то действительно сложнее, чем добавить. По этой причине становится большой разница между старшим и младшим разработчиком.

Что я могу удалить?

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

Неподходящие/неиспользуемые/ненужные:

  • Переменная
  • Класс
  • Оператор if, else (сначала вернитесь)
  • Функция
  • Комментарий
  • Предупреждение
  • API
  • Git коммит
  • История Git (раздавить)
  • Филиал
  • Файл, который не нужен VCS (Используйте .gitignore)
  • База данных
  • Таблица
  • Столбец
  • Записывать
  • Ресурс EC2
  • Ковш S3
  • МТГ

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

Удаление означает принятие на себя ответственности

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

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