Рефакторинг или Концентрат на Завершение Приложения

Хотели бы вы провести рефакторинг своего приложения или сосредоточиться на его завершении? Рефакторинг будет означать, что прогресс приложения будет замедляться.

Завершение приложения будет означать, что вы получите очень сложное приложение для поддержки в дальнейшем?

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

Сделай так, чтобы это работало. Тогда сделай это быстро. Наконец, сделай это красиво.

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

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

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

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

Я всегда рефакторинг, особенно с использованием TDD.

1. Написать тесты

2. Сделайте тесты успешными

3. Refactor

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

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

Рефакторинг подобен поднятию вашей комнаты.

Если вы держите вещи в чистоте, у вас есть линейные накладные расходы, пропорциональные количеству продуктивной работы, которую вы делаете над кодом, O (n) с точки зрения алгоритмиста. Предполагая, что вы тратите 10% своего времени на рефакторинг (или поддержание чистоты в комнате), эти 10% являются заданными, и они будут оставаться постоянными в течение долгого времени.

Однако, если вы бросаете свою грязную одежду в угол и продолжаете делать это, количество времени, которое вы собираетесь потратить, поднимая свою комнату, увеличивается, поскольку беспорядок становится более сложным. Предполагая, что каждый отдельный кусок грязного белья экспоненциально вносит вклад в требуемое время уборки, вы находитесь в ситуации O (e ⁿ ).

Любой, кто когда-либо углублялся в концепцию алгоритмической сложности, заметит, что где-то существует точка безубыточности, то есть оптимальное количество грязного белья, которое можно накапливать; сколько это зависит от постоянных факторов, которые отбрасываются в нотации big-O. Другим фактором является ценность вашей работы с течением времени: если ваша работа стоит очень дорого сейчас, но дешево на следующей неделе (то есть, в пятницу для этого проекта есть крайний срок и еще три, но после этого вы будете в основном бездействовать). ), уравнение может оказаться в пользу не рефакторинга.

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

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

TL; DR: если есть сомнения, рефакторинг. У вас должны быть действительно веские доказательства, прежде чем принимать решение не делать этого.

Если у вас есть возможность добавлять функции или исправлять ошибки, чтобы получить удовлетворение от продаж / удовлетворения потребностей клиентов, сделайте это. Как только появилось меньше новых требований, вы можете балансировать с рефакторингом. В какой-то момент вы должны убедиться, что пишете код, который хотят люди. При прочих равных условиях я бы скорее отбросил 100 часов кода, чем 1000. Именно это вы и сделаете, если никто не захочет.

Действительно зависит от того, где вы находитесь!

Другие вещи, чтобы думать о:

Насколько вы уверены, что вы правильно поняли функциональный дизайн? Не могли бы вы в конечном итоге изменить дизайн после получения обратной связи с пользователем?

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

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

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

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

Рефакторинг будет очень важен, так как вы работаете над заполнением заявки.

+ VES

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

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

3. Техническое обслуживание: последнее, но не менее важное, было бы легче поддерживать в долгосрочной перспективе.

-VE

1. Отнимает много времени : это будет намного больше времени на каждом этапе вашего прогресса. Так что может быть задержка в завершении.

Нижняя граница

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

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

Завершите это и рефакторинг это. Но если нет крайних сроков, чтобы спешить или сроки, я предлагаю рефакторинг, это было бы хорошо.