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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

Короткий ответ: «Это зависит». Вот несколько факторов, которые я бы посчитал важными при определении того, сохранять ли старый стиль или нет:

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Однако я бы не стал пытаться следить за такими вещами, как «табуляция не должна использоваться», «каждая строка должна быть с отступом в 2 пробела» и т. Д. Существует множество редакторов, где можно «красиво» код когда вам это нужно в эти дни.

G-Man

Answer 6

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

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

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

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

Answer 7

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