Код проверки будущего

Где я работаю, разработчики всегда говорят мне, что «я добавил это на всякий случай на будущее» или «Я думаю, что это хорошая идея, потому что они, вероятно, когда-нибудь захотят». Я думаю, это здорово, что они активно пытаются предвидеть будущие изменения, но я не могу не думать, что это излишне и рискует написать код, который может никогда не понадобиться и, следовательно, непродуктивно (я также думаю, что некоторые разработчики просто хотят попробовать что-то ради этого нового). Являются ли аргументы для доказательства будущего недействительными, если вы просто пишете хороший, чистый организованный код?

Ну, во-первых, есть некоторые вещи, которые требуют уточнения:

• Проверка будущего не добавляет ничего .
• Проверка будущего гарантирует, что вы сможете легко добавлять код / ​​функции, не нарушая существующую функциональность.

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

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

Мой 2с

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

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

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

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

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

• Подобно вышеописанному, экспонирование части вашего приложения через SOAP или REST API позволяет добиться аналогичных результатов. Какие бы технологии ни развивались, вам не обязательно нужно переписывать каждую часть приложения, потому что новые технологии все равно смогут взаимодействовать со старыми.

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

Так что, во что бы то ни стало, создайте код на будущее (НАСА по-прежнему отправляет космические корабли с использованием Фортрана), но не пишите код «на всякий случай».

Подумайте, сколько раз вы включали кусок кода в производственную среду и думали: «Слава богу, я написал это 2 года назад!».

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

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

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

Защитное программирование : проверяйте ввод за пределы того, что вам действительно нужно в текущем приложении. Всякий раз, когда вы вызываете API, обязательно убедитесь, что их ввод - это то, что вы ожидаете. В будущем люди будут смешивать новые версии кода, поэтому объем ошибок и возврат API будут отличаться от того, что есть сейчас.

Устранить неопределенное поведение : у большого количества кода есть поведение, которое как бы развивается из ниоткуда. Определенные комбинации ввода приводят к определенному результату, который на самом деле никто не намеревался, но именно так и происходит. Теперь неизбежно кто-то будет полагаться на это поведение, но никто не будет знать об этом, поскольку оно не определено. Любой, кто попытается изменить поведение в будущем, непреднамеренно сломает вещи. Используйте проверки безопасности сейчас и попробуйте удалить / заблокировать все неопределенные варианты использования кода.

Automated Test Suite : я уверен, что вы можете найти тома, написанные о необходимости модульных тестов. В отношении проверки будущего, однако, это является критическим моментом, когда кто-то может реорганизовать код. Рефакторинг необходим для поддержания чистого кода, но если вам не хватает хорошего набора тестов, вы не сможете безопасно провести рефакторинг.

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

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

«Будущее доказательство» в лучшем случае означает «слабосвязанный дизайн». В 80% случаев люди имеют в виду «гибкий», когда говорят «будущее». Иногда говорят, что это звучит круто. Но, по крайней мере, они доставляют что-то вовремя, что работает.

«Будущее доказательство» в худшем случае бессмысленно. 20% времени - это оправдание тратить время на исследование альтернативных технологий вместо того, чтобы просто что-то предлагать. Они ничего не доставляют (или то, что они доставляют, слишком сложно для рассматриваемой проблемы).

Есть два крайних случая.

1. Неизменное предвидение. На самом деле можно точно предсказать будущее. В этом случае, пожалуйста, примените это мощное предвидение для будущего подтверждения кода. Лучше применять надежное предвидение, чтобы предсказать рыночные тенденции, рано уйти на пенсию и прекратить кодирование.

2. Один из них "ведет" будущее. То есть у человека есть какая-то новая технология, готовая к развертыванию в будущем, которая потребует переписывания того, что будет доставлено прямо сейчас. Странно, что сначала никто не развертывает эту классную будущую вещь.

   Мы должны реализовать проект «А», зная, что проект «В» приведет к немедленной переписке «А». Только в этом случае мы могли бы иметь возможность доказать «А» в будущем.

ЯГНИ = Тебе это не нужно .

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

Смотрите также: Позолота .

Не обращая внимания на заголовок вопроса и придерживаясь основного положения о том, как «положить вещи, потому что кто-то может захотеть это когда-нибудь» ...

Ответ - нет. Никогда. Не пишите ни строчки кода, который вам не нужен сегодня. Вот почему:

1. Программа сейчас более сложная, чем должна быть.
2. Возможно, вам никогда не понадобится эта функция, поэтому вы потратили впустую свое время.
3. Вы не знаете, какими будут требования к этой функции, если кто-нибудь когда-нибудь попросит ее об этом. Так что вам все равно придется это выяснить и изменить.

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