Должен ли я подготовить свой код для будущих изменений?

Ответ 1

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

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

Однако большую часть времени это не так. Вы часто найдете более экономичным (во времени и деньгах) только рефакторинг кода для повторного использования и конфигурирования, когда вы действительно знаете, что собираетесь использовать его снова. В остальное время реальные выгоды теряются.

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

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

Я задал аналогичный вопрос здесь Повторное использование кода: стоит ли это Это может помочь.

Ответ 2

В пределах причины и, конечно, если это не так много усилий.

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

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

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

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

Ответ 3

YAGNI.

http://en.wikipedia.org/wiki/YAGNI (* вставлен дружественным редактором:-) *)

исправить ошибки в том ужасном коде, который вы пишете сегодня.

когда приходит время.

Ответ 4

Если вы работаете в дружественном к рефакторингу lanuguage, я бы сказал НЕТ. (На других языках я не уверен)

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

Это сделает вашу базу кода подготовленной к тем, что принесет будущее.

(И, откровенно говоря, большинство ожиданий в будущем, как правило, недостаточно для того, чтобы не оправдывать его сегодня)

Изменить: это также зависит от того, что вы делаете. Разработка apis для внешних пользователей - это не то же самое, что разработка веб-приложения для вашей компании.

Ответ 5

Да - делая меньше.

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

Ответ 6

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

Чем больше времени вы потратили сегодня на обслуживание масштабируемых решений, тем меньше времени вы потратите в будущем при фактическом расширении

Ответ 7

Прогнозируемые или очень вероятные изменения - да, вообще-то хорошо иметь их в виду.

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

Ответ 8

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

Но подумайте дважды, если система позади затрудняет рефакторинг (базы данных).

Ответ 9

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

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

Ответ 10

Одним словом, да.

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

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

Ответ 11

Нет, никогда. Напишите хороший код, который легко повторить/рефакторинг, но подготовка к полураздутым усовершенствованиям - это имо, брат преждевременной оптимизации; вы, скорее всего, в конечном итоге будете делать то, что вам не нужно, или толкаете вас на определенный (возможно, не оптимальный) путь проектирования в будущем. Как говорит mfx, сделайте минимум, требуемый сейчас, и unit test все; это делает расширяющий код поворотным.

Ответ 12

В двух словах: да, всегда.

Ответ 13

То, что вы описываете, является неотъемлемой частью хорошего разработчика.

См. О написании поддерживаемого кода

Ответ 14

Очевидным ответом является ДА. Но более важным вопросом является то, как!

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

Я считаю, что лучше всего разработать архитектуру, адаптируемую к изменениям, чем пытаться указать конкретные изменения, которые могут (или не могут) произойти. Это хорошее упражнение, однако, спросить: "Что может измениться в будущем?", А затем сопротивляться искушению преждевременно реализовать потенциально ненужные функции, но, скорее, иметь такие возможности при создании архитектуры приложения.

Ответ 15

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

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

Ответ 16

Два простых принципа:

• ПОЦЕЛУЙ
• Всегда избегать зависимостей

Хорошее начало

Ответ 17

Да, но только путем написания поддерживаемого, легко реорганизованного кода.

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

Ответ 18

Это действительно важно. Это нужно делать хорошо, но он имеет опыт.

Если я подсчитаю количество изменений (через "diff" ) после выполнения типичного изменения требований, числа, подобные 10-50, являются общими.

Если я сделаю ошибку на любом из них, я вставил ошибку.

Итак, я всегда стараюсь, чтобы дизайн сохранял это число.

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

Ответ 19

Чтобы сбалансировать усилия с преимущества - это умение дизайна.

Не весь наш код должен быть гибким. Некоторые вещи не будут меняться.

Не потрачено впустую. Нахождение правильных частей для нашего внимания.

Tricky.

Ответ 20

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

Ответ 21

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

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

Ответ 22

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

Очевидные вещи, которые всегда будут вызывать проблемы:

• Рассеянная информация о конфигурации - вам нужно легко проверить и изменить этот материал.
• Неподтвержденный код - вам нужны тесты для внесения изменений с уверенностью
• Смешение проблем хранения и вывода с основной логикой - вы переключите экземпляры базы данных и выходные форматы, если только для тестирования
• Комплексная архитектура - вам нужна четкая ментальная модель системы.
• Устройства, требующие ручного вмешательства или обновления, чтобы они работали