Наследование проектов WordPress: советы по разработке
Если вы управляете бизнесом, который сосредоточен как на разработке решений с нуля, так и на внедрении индивидуального решения в контексте уже существующих проектов (или, возможно, на том и другом), то вы, вероятно, в какой-то момент был в ситуации наследования проектов WordPress.
Работа над проектами с любой стороны приносит свой набор проблем — большинство из них приветствуются — но, похоже, гораздо чаще люди жалуются на работу с уже существующей кодовой базой.
Не то чтобы я не чувствовал этого, но я действительно думаю, что в этом есть определенная незрелость. С одной стороны, да, некоторые кодовые базы просто ужасны. Но тогда некоторые кодовые базы не так уж и плохи. На самом деле, я бы сказал, что они немного отличаются от того, как вы их разрабатываете.
Это тот случай, когда в игру вступают стандарты, но я пока отвлекся от этого.
Итак, допустим, вы наследуете проекты WordPress и вас не особенно впечатляет кодовая база, с которой вы работаете. Как получается, что вы все еще можете получать удовольствие от работы, которую делаете, не чувствуя необходимости критиковать каждый аспект того, с чем вы имеете дело?
Наследование проектов WordPress
Во-первых, эта идея жаловаться на работу других людей — это пресловутая вода, в которую я не люблю вступать.
- Я не знаю предыстории, которая привела к тому, что кодовая база находится в своем состоянии,
- Я не знаю, почему некоторые вещи были разработаны такими, какими они были (нехватка времени, отсутствие знакомства с проектом и т. д.),
- Мне поручено что-то сделать в контексте проекта, так зачем тратить время на то, что не входит в мои обязанности?
Я понимаю: бывают случаи, когда мы пишем код, который должен взаимодействовать с уже существующим кодом. И это может быть тяжело. Существуют шаблоны проектирования, которые не предназначены специально для этой ситуации.
Но вместо того, чтобы освещать это, я решил поделиться тремя вещами, которые, по моему мнению, показывают зрелость, когда дело доходит до разработки при наследовании проектов WordPress, которые могут нас раздражать.
1 Не рефакторинг всего
Как заявил Мартин Фаулер :
Дядя Боб называет этот оппортунистический рефакторинг соблюдением правила бойскаута: всегда оставляйте код в лучшем состоянии, чем вы его нашли.
В целом мне нравится это правило, но в зависимости от требований проекта это может не входить в наши обязанности.
Поэтому всякий раз, когда мы сталкиваемся с чем-то, что, как мы знаем, нуждается в рефакторинге, но проект работает гладко. Если вы вносите одно изменение в что-то, потому что считаете, что это необходимо сделать, вы не знаете, как это отразится на всем проекте.
Если у вас есть время сделать полную ревизию кода, это одно, а если нет, то ваша задача внедрить то, что вы согласились сделать.
2 Сосредоточьтесь на том, что вы согласились сделать
И это приводит к такому моменту: при наследовании проектов WordPress вам поручается определенный объем работы и ничего больше (вот почему у нас есть техническое задание, верно?).
Так что, как бы сильно вы ни хотели изменить окружение, в котором находитесь, не делайте этого. Сосредоточьтесь на том, что вы можете сделать, что можете сделать только вы и что вы согласились сделать.
Я думаю, что делать заметки о проблемах — это нормально, и я думаю, что это может быть даже полезно (и я сейчас расскажу об этом), но не теряйте фокуса на том, что вы согласились сделать. Делать что угодно, но непрофессионально.
3 Не осуждайте предыдущего разработчика
Еще одна распространенная вещь, особенно в случае с открытым исходным кодом, — судить разработчика, написавшего начальный набор кода, с которым вы работаете.
Что это? Я бы никогда так не написал.
Я имею в виду, сколько раз мы думали об этом про себя? Но мы не знаем времени, ограничений, опыта или контекста, в котором работал разработчик.
Код, который мы публикуем, не обязательно отражает уровень наших навыков. Это часто диктуется сторонними переменными, которые влияют на то, как мы реализуем решение.
И мы знаем, что это такое, верно? Сколько раз мы хотели сделать что-то одним способом, но ограничения и график, в соответствии с которым мы работаем, диктуют, что мы делаем?
Так почему же мы ожидаем, что эти разработчики будут другими?
Необязательно: предложите будущую поддержку
Как упоминалось ранее, если вы сталкиваетесь с проблемными областями в кодовой базе, это не означает, что дело безнадежно.
Вместо этого, когда вы сталкиваетесь с подобными проблемами, я думаю, будет хорошей идеей:
- делать заметки о вещах, которые вы видели,
- прокомментируйте, что бы вы сделали, чтобы исправить это и почему,
- поговорите с клиентом о том, что вы видели, и о преимуществах обновления.
Это, очевидно, ведет к будущей работе, но, возможно, более того, это позволяет вам предлагать решения для создания лучшего, более хорошо спроектированного программного обеспечения и позволяет вам убедиться, что вы делаете Интернет лучшим местом для CMS, которая так популярна.
Нет, эта работа никогда не гарантируется, но она полезна.
Я уверен, что есть больше
Это всего лишь три совета, которые я предлагаю, основываясь на своем опыте наследования проектов WordPress. Это не должно быть всеобъемлющим.
Вместо этого он дает несколько советов, которые позволят вам более внимательно относиться к работе других людей по отношению к вашей работе, более четко думать о том, что вы можете делать, сталкиваясь с подобными ситуациями, и выполнять больше работы, улучшая существующую. решение потенциально.
Но я знаю, что вещи, которые я упомянул, являются лишь некоторыми из моих наблюдений. Есть свой? Упомяните их в комментариях.