Наследование приложений на новой работе
При наследовании приложений на новой работе вы склонны придерживаться оригинальной практики кодирования разработчиков или начинаете применять свою собственную?
Я работаю в небольшом магазине без каких-либо инструкций и всегда задавался вопросом, какое здесь правило. Некоторые приложения написаны очень хорошо, но не соответствуют стандартам, которые я использую (имена переменных и т. Д.), И я не хочу их "портить". Я нахожу себя немного более последовательным.
Другие написаны очень плохо, и похоже, что разработчик передумал при каждом нажатии клавиши...
ДОПОЛНИТЕЛЬНАЯ МЫСЛЬ
Как насчет того, когда я начинаю свои собственные проекты? Итак, теперь я ввел новый стандарт кодирования в миксе:
- Хороший код - но не мой стиль
- Плохой код с плохой практикой и отсутствием стандартов
- Мои собственные стандарты
17 ответов
Если в коде есть стандарты, вы должны их придерживаться. Если нет, начните вводить свой собственный.
Если на одном модуле работают несколько разработчиков, не меняйте стиль.
Если вы передадите его другому разработчику в ближайшем будущем (эта роль временная), не меняйте стиль.
Если вы приобретаете полное, эксклюзивное, постоянное право собственности на модуль, измените его, но соблюдайте следующие правила:
Одно изменение за раз.
Исправьте все отступы по своему вкусу и зафиксируйте это изменение.
Зафиксируйте все расстановки по своему вкусу и зафиксируйте это изменение.
Зафиксируйте все остальные форматы по своему вкусу и зафиксируйте это изменение.
Зафиксируйте все имена по своему вкусу и зафиксируйте это изменение.
Не трать на это много времени.
Если это займет больше часа или двух, тогда сокращайте.
Сделайте описание фиксации понятным.
Таким образом, вы можете быстро игнорировать эти изменения при анализе истории изменений.
Используйте автоматизированные инструменты
чтобы убедиться, что результат является последовательным и полным, чтобы вам больше не приходилось с ним связываться.
Запустите ваши тесты
То, что ваши изменения не должны влиять на поведение, не означает, что они не будут. (Тройной негатив, ай!)
Убедитесь, что все знают, что вы делаете
У кого-то может появиться изменение, которое он хочет зафиксировать сейчас, и будет болезненно слиться с вашими изменениями. Кроме того, вы не хотите, чтобы кто-то удивлялся и говорил своему боссу раньше, чем вы.
Не делай этого снова
Это разовая вещь.
Опубликовать руководство по стилю, которое следует передовым методам, и сформировать консенсус в отношении его следования. Рефакторинг старого кода по мере необходимости.
Я заметил, что большинство людей думают, что кто бы ни пришел раньше, они не знали, как писать код. Тогда тот, кто придет за ними, думает о том же. Некоторые вещи - это здравый смысл, но большинство вещей - это просто личные предпочтения.
В случае серьезных проблем, т. Е. Использования комментариев и отсутствия комментариев, обновление кода, вероятно, облегчит работу и станет проще для всех. Даже тогда ваше время, вероятно, лучше всего потрачено на обновление кода, когда вы с ним сталкиваетесь, вместо того, чтобы приступать к огромному проекту по реорганизации всего (создавая новые проблемы в процессе).
Для таких вещей, как отступы, межстрочный интервал, имена переменных, однострочные ifs против многострочных ifs, реальность такова, что ваш стиль кодирования, вероятно, такой же плохой, как вы думаете, их стиль.
Я в той же лодке, что и ты. Одинокий разработчик, унаследовавший несколько приложений от последнего парня. я
Я придерживался того, что, по-видимому, является его стандартами для существующих проектов для обеспечения согласованности, и использовал свои собственные предпочтения для новых вещей.
Учитывая, что большинство приложений, которые я унаследовал, были взломаны "ковбойскими кодировщиками", которые не применяли даже самые базовые методы кодирования, мое мнение немного предвзято.
Я говорю о введении стандартов кодирования, если их нет или те, которые существуют, явно ошибочны и / или глупы (например, "Все переменные должны иметь длину не более 4 символов", "Каждый столбец базы данных равен varchar(255) null" и т. Д.)..). Очевидно, что если у вас есть команда, вам нужно будет прийти к соглашению относительно того, какие методы следует применять, но если вы одинокий разработчик, то у вас есть свободное правление и ИМО, вы должны навести порядок в хаосе.
Я думаю, это зависит от того, что вы подразумеваете под "практикой кодирования". Если вы имеете в виду такие вещи, как форматирование кода и соглашения об именах, а также вещи, которые я лично считаю "косметическими", то придерживайтесь того, что уже есть. Если вы имеете в виду такие вещи, как кодирование лучших prcatices и правильное написание кода, то вернитесь и исправьте проблемы, если это возможно, но по крайней мере заставьте ваш новый код следовать передовым методам.
- Если код работает и, похоже, имеет чистый формат. Не тратьте время на смену стиля.
- Если код плохо написан. Во что бы то ни стало измените это, когда у вас есть некоторое время простоя, или в следующий раз, когда вы работаете над проектом.
- Для новых проектов делайте их по-своему, так как не существует стандарта. Как и в случае с другими хорошо написанными программами, ваша программа должна быть достаточно простой в обслуживании.
Я бы применил к коду те же стандарты рефакторинга, что и если бы он соответствовал моим стандартам стиля. То есть я игнорировал бы стиль и просто продолжал заниматься своими делами.
Если не очень сложно следовать стилю, который есть в коде - что касается соглашений об именах, я бы пошел дальше и использовал их для нового кода.
Однако я не стал бы пытаться следить за такими вещами, как "табуляция не должна использоваться", "каждая строка должна быть с отступом в 2 пробела" и т. Д. Существует множество редакторов, где вы можете "красиво" кодировать в любое время, когда вам нужно. это в эти дни.
G-Man
Будет ли у вас когда-нибудь лучшая возможность обновить существующий код стандартным стилем? Возможно нет. Когда вы новичок в коде, у вас будет больше шансов потратить дополнительное время на внесение изменений, не связанных с новыми функциями и исправлениями ошибок. Отсутствие стандартов может обескураживать, но вряд ли у вас будет больше шансов стандартизировать, чем при первом наследовании кода.
Если это только ты, дерзай. Если это команда, особенно если кто-то из первоначальных разработчиков все еще рядом (или, вероятно, будет вызван для консультаций), придерживайтесь существующего стиля и практики, насколько это возможно. Не следуйте за ними через крысиную нору - если вы думаете, что они делают что-то глупое, измените это, но если это просто стилистическая вещь, придерживайтесь их стиля настолько, насколько это возможно.
В нескольких работах, на которых я работал, у нас не было правила о стиле кодирования, кроме "если вы вносите изменения в существующий файл / класс, используйте существующий стиль даже для нового кода".
Я следую стандартам компании, если таковые имеются.
Если их нет, а изменения невелики, я принимаю используемый стиль кодирования.
Если будут внесены большие изменения, и мне не нравится стиль кодера, я буду использовать свой собственный. И если существующий код будет плохим, я тоже это изменю.
Если бы я унаследовал код, который, очевидно, никогда не подвергался рефакторингу, я бы использовал это как возможность навязать некоторые из моих собственных структур.
Если люди ожидают, что я сделаю оценки времени и затрат на добавление функциональности в код, я должен быть близко знаком с ним и убедиться, что он соответствует моим стандартам.
Если код уже хорошо написан, это было бы благословением, с которым я бы не связывался. Но по моему опыту, это случалось не очень часто.
Короткий ответ: "Это зависит". Вот несколько факторов, которые я бы посчитал важными при определении того, сохранять ли старый стиль или нет:
1) Объем изменений. Если он близок к полной переписке приложения, то, возможно, имеет смысл ввести новый стандарт, если у вас есть тот, который, по вашему мнению, хорошо работает для вас.
2) Вероятность будущих изменений. Будет ли это меняться снова и снова? Если это так, то в конечном итоге может потребоваться некоторое время на раннем этапе. Это требует некоторого осмысления и предсказания будущего, но в некоторых случаях может быть легко увидеть, что будут происходить изменения снова и снова для некоторых систем, которые являются довольно сложными.
3) Какая часть кода является настройкой сторонней кодовой базы, например специфических настроек компании для продуктов Oracle для их бизнес-процессов, по сравнению с полностью домашним приложением. Влияние здесь заключается в том, что когда передаются новые версии и запрашивается обновление, может возникнуть какая-то боль в том, что ломается, так как оно было настроено так сильно.
Когда вы начинаете свои собственные проекты, используйте лучший из известных вам стандартов.
Я думаю, что это сильно зависит от конкретного случая.
- Если вы являетесь консультантом проекта в течение короткого времени, вам следует придерживаться того, что происходит.
- Если вы в течение длительного времени. Попробуйте преобразовать плохой код в вашу собственную схему.
- Если вы работаете в течение короткого времени, но работаете с изолированным модулем, используйте свою собственную схему.
Похоже, мы говорим о ситуации, в которой нет официальных руководств по стилю / лучших практик. В этом случае, как сказал Шон, я бы взял на себя инициативу по их созданию. Но... если это вообще возможно, выберите существующий, широко используемый стандарт. Скорее всего, это будет принято, все аргументы сделаны, и шансы на поддержку встроенных инструментов (редакторы, инструменты для проверки кода и т. Д.) Значительно возрастают.
Заставить других принять его часто лучше всего снизу вверх - написать новый код в соответствии с новыми стандартами, упомянуть другим, что вы это сделали, попросить обратную связь. Гораздо проще, чем пытаться получить одобрение и предварительный взнос.
В рамках существующего, уродливого проекта избегайте массовых изменений существующих модулей. Во-первых, различия и управление версиями могут привести к путанице, если файл будет внезапно переопределен.
Если чанк, над которым вы работаете, настолько плох, что его невозможно прочитать, я бы сделал начальную проверку только для его переформатирования; проследите за изменениями кода.