Наследование приложений на новой работе

Question

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

Я работаю в небольшом магазине без руководящих принципов и всегда задавался вопросом, каково здесь правило. Некоторые приложения написаны очень хорошо, но не следуют стандартам, которые я использую (имена переменных и т. Д.), И я не хочу их «портить». Я нахожу себя немного более последовательным.

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

ДОПОЛНИТЕЛЬНАЯ МЫСЛЬ

А когда я начну свои собственные проекты? Итак, теперь я ввел новый стандарт кодирования в миксе:

1. Хороший код - но не мой стиль
2. Плохой код с плохой практикой и отсутствием стандартов
3. Мои собственные стандарты

Answer 1

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

Answer 2

Если на одном модуле работают несколько разработчиков, не меняйте стиль.

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

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

Одно изменение за раз.

Исправьте все отступы по своему вкусу и зафиксируйте это изменение.

Исправьте все расстановки фигурных скобок по своему вкусу и зафиксируйте это изменение.

Исправьте все другие форматирования по своему усмотрению и подтвердите это изменение.

Исправьте все имена по своему вкусу и подтвердите это изменение.

Не тратьте на это много времени.

Если это займет больше часа или двух, тогда сократите.

Сделать описание фиксации понятным.

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

Использовать автоматизированные инструменты

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

Запустите свои тесты

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

Убедитесь, что все знают, что вы делаете

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

Не делай этого снова

Это разовая вещь.

Answer 3

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

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

Answer 4

Опубликовать руководство по стилю, которое следует передовым методам, и сформировать консенсус относительно его. Рефакторинг старого кода по мере необходимости.

Answer 5

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

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

Для таких вещей, как отступы, межстрочный интервал, имена переменных, однострочный ifs v.s. многострочный ifs, реальность такова, что ваш стиль кодирования, вероятно, так же плох, как вы думаете, их стиль.

Answer 6

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

Answer 7

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

Я говорю, вводите стандарты кодирования, если их нет или те, которые существуют, явно ошибочны и / или глупы (например, «Все переменные должны быть длиной не более 4 символов», «Каждый столбец базы данных varchar (255) пуст ", так далее.). Очевидно, что если у вас есть команда, вам нужно прийти к соглашению относительно того, какие практики следует применять, но если вы являетесь одиночным разработчиком, то у вас есть свободное правление и ИМО, вы должны навести порядок в хаосе.

Answer 8

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

Answer 9

композиция часто предпочтительнее наследования

: - P

Answer 10

Я следую стандартам компании, если они есть.

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

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