Вчера утром, когда я работал над новой функцией, мне в голову пришла идея, а точнее «пауза». Я начал задаваться вопросом, что я делал на автопилоте. Итак, я остановился и вместо этого начал задавать себе вопросы. Я начал с вопроса: «Что я делаю?» и «Есть ли другие способы достичь этой цели?» В результате этих вопросов у меня возникла идея, которую я назвал «Стратегии разработки функций с MAN». Я считаю, что вам нужен контекст, так что давайте начнем с него.
У нас уже есть электронная почта. В настоящее время он поддерживает втягивание всей нашей электронной почты в большую корзину (входящие, отправленные и т. Д.), Которая попадает в большой список. Затем мы группируем эти электронные письма в разговоры. Мы используем Vue.js для управления пользовательским интерфейсом, поэтому у нас есть различные вспомогательные компоненты (дочерние и общие компоненты).
Моя задача - реализовать две новые функции:
- Добавить базовую поддержку папок (новый UI / UX)
- Удалите разговоры, поскольку наш целевой API не поддерживает их полностью (печальный факт, который мы узнали позже в процессе разработки).
Первый вопрос пришел от нашего ведущего дизайнера, который спросил, следует ли им добавлять новую разметку в новые файлы или применять ее к существующей разметке. Я предложил использовать существующую разметку. Некоторое время спустя в нашей ветке мы интегрировали новый и улучшенный дизайн в форме HTML / SASS / Vue.js в наш существующий код Vue.js. Вот и начинается моя работа по превращению его в функциональный.
Примерно в это же время и произошла «пауза». Когда я начал изменять структуры данных и переименовывать методы, код вошел в ужасно некорректное состояние. Наши модульные тесты перестали быть полезными, и эта часть приложения перестала работать. Вскоре я понял, что пройдет несколько дней, прежде чем приложение снова заработает, и еще несколько дней, прежде чем все ошибки будут исправлены (по крайней мере, те, которые мы нашли сразу). Мне это не понравилось. . Это вызвало у меня неприятное ощущение, что что-то не так, поэтому наступила «пауза».
ЧЕЛОВЕК. (Изменить, добавить, создать)
Как я уже упоминал ранее, я начал задавать себе вопросы: «Что я делаю?» Ответ был прост: «Я добавляю новую функцию к уже существующей». Второй вопрос: «Каковы мои возможности для достижения этой цели?» Ответ на второй - здесь раскрывается настоящая магия.
Я придумал три ответа:
- Изменить, реструктурируйте существующий код, пока он снова не заработает.
- Добавить: оставьте существующий код, но добавьте к нему новые функции, сохраняя рабочее состояние (т. е. имея исходный список адресов электронной почты, а также новый список папок рядом друг с другом)
- Новый, создайте новый код с нуля, используя стратегию повторного использования "копировать / вставить".
Именно наименование этих вариантов позволило мне продолжить поиски понимания проблемы. Чтобы понять эти варианты, я начал спрашивать себя о свойствах каждого варианта. Итак, давайте сделаем это сейчас.
№1 - Изменить существующий код
Плюсы:
- Существующая инфраструктура кода поддерживается
- Модульные тесты защищают вас
- Очистка практически отсутствует, так как она выполняется во время реструктуризации.
- Хорошо работает с небольшими изменениями (может использоваться для более крупных изменений, если разработчики достаточно образованы / квалифицированы, чтобы создавать на их основе качественный код)
Минусы:
- Система не работает до завершения реструктуризации
- Не работает с большими изменениями, так как вы входите в неприятное неисправное состояние
- Модульные тесты не помогают, потому что дают много ложных срабатываний.
# 2 - Добавить к существующему коду
Плюсы:
- Поддерживается существующая инфраструктура кода
- Система продолжает работать должным образом
- Хорошо работает с средними изменениями, поскольку вы сохраняете существующую инфраструктуру кода.
Минусы:
- Система находится в странном состоянии, какое-то время поддерживает несколько функций (пользовательский интерфейс будет выглядеть забавно)
- Очистка происходит в конце разработки и может быть сложной задачей, поскольку вы хотите убедиться, что удаляете только те части, которые больше не нужны. Модульные тесты могут немного помочь.
# 3 - Новый код
Плюсы:
- Четкая ментальная модель, поскольку мы работаем с нуля
- Рабочий код на протяжении всего процесса, поскольку каждое новое изменение основывается на последнем
- Повторное использование путем копирования / вставки из существующих функций
- Хорошо работает при больших изменениях
Минусы:
- Нет существующей инфраструктуры кода, на которую можно было бы положиться
- Легко упустить мелкие функции, которые вы забыли о существовании
- Исправления ошибок из предыдущих изменений можно легко потерять
- Никаких модульных тестов, которые могут помочь
- Разработчики влюблены в D.R.Y. и напуганы повторным использованием копий. Нам нужно понимать, что наши принципы являются именно такими принципами. Это не законы, они ориентиры.
Термины - Рефакторинг и реструктуризация
Во время обсуждения с коллегой (и другом) они предложили мне использовать термин «реструктуризация», а не «рефакторинг». Определение рефакторинга звучит так: «Рефакторинг кода - это процесс реструктуризации существующего компьютерного кода - изменения факторинга - без изменения его внешнего поведения». Таким образом, рефакторинг - это подмножество «реструктуризации кода». В этой статье я определенно говорю об «изменении внешнего поведения», и поэтому «рефакторинг» - неправильное слово.
Они хорошо подчеркивают, что существует косвенный путь к рефакторингу, который оставляет систему в рабочем состоянии. Вы достигаете этого, находя наименьшие возможные точки изменения / абстракции, чтобы система оставалась работоспособной. Например, предположим, что у вас есть карта с массивом, но вы хотите сгладить массив по большему количеству карт, вы можете «реорганизовать» массив, чтобы он имел один элемент на карте и просто создавал больше карт.
[{материал: [0, 1, 2,…]}] становится [{материал: [0]}, {материал: [0]}]
Он утверждает, что «рефакторинг» обычно лучше и быстрее, чем использование «New». Что касается меня, я считаю, что это действительно зависит от масштаба изменения структуры данных.
Когда что использовать - следите за структурой данных
Хорошо, давайте предположим, что все мы согласны с тем, что это наши варианты внесения изменений и что этих свойств достаточно, чтобы убедить нас, когда какой вариант использовать. Как определить, является ли изменение небольшим, средним или большим? Я обнаружил, что могу получить хорошее представление о том, насколько велико изменение / добавление, следуя структуре данных. Насколько сильно я изменил существующие структуры данных? Изменяю ли я основную структуру данных, от которой зависит весь код? Я считаю, что это главный вопрос, над которым стоит задуматься.
Понимание того, насколько происходит изменение структуры данных, скорее всего, скажет нам, насколько велик будет волновой эффект в нашем коде. Этот стиль мышления можно применять по-разному, от исправления ошибок до проектирования систем, но это уже другая статья.
Заключение - МУЖЧИНА (что звучит более грубо, чем я хочу)
Теперь у нас есть хорошая структура (MAN) для размышлений о внедрении новых функций в нашу систему. По крайней мере, это дает нам ментальную модель, в которой мы можем разумно обсуждать то, что мы делаем. В лучшем случае вы получаете систему, которая продолжает работать должным образом, пока вы меняете ее в соответствии с потребностями наших пользователей.
Поразмыслив над этой идеей, я пригласил еще пару человек из нашей команды, чтобы обсудить «ЧЕЛОВЕКА». Они были взволнованы и воскликнули: «Это самый интересный технический разговор, который у меня когда-либо был». Один из наших дизайнеров думал, что они могут применить это в своем процессе проектирования. Может ли это помочь вам неожиданным образом? Я надеюсь, что это так.
Что мне так интересно в этой ментальной модели, так это то, что мы, разработчики, постоянно пытаемся сделать наш код многоразовым, и D.R.Y. тем не менее, в этом контексте у нас есть новый образ мышления, который может помочь нам использовать правильный инструмент для работы. Даже на поверхностном уровне мы можем видеть, что внесение изменений в данные будет влиять на нашу систему по-разному (малые, средние, крупные). Значит ли это, что мы задумались об ограничениях повторного использования? По крайней мере, для меня.
Возвращаясь к исходному вопросу, который наш ведущий дизайнер задал мне: «Вы хотите новую разметку в новых файлах или мне следует изменить существующие?» Запрыгивая в машину времени, я говорю: «Пожалуйста, новенькая».
