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

У меня есть первая настоящая работа программистом, но я не могу решить никаких проблем из-за используемого стиля кодирования. Код здесь:

• Не имеет комментариев
• Не имеет функций (50, 100, 200, 300 или более строк, выполняемых последовательно)
• Использует много ifутверждений с множеством путей
• Имеет переменные , которые не имеют никакого смысла (например .: cf_cfop, CF_Natop, lnom, r_procod)
• Использует старый язык (Visual FoxPro 8 от 2002 года), но есть новые выпуски от 2007 года.

Я чувствую, что вернулся в 1970-е годы. Нормально ли для программиста, знакомого с ООП, чистым кодом, шаблонами проектирования и т. Д., Возникать проблемы с кодированием по старинке?

РЕДАКТИРОВАТЬ : Все ответы очень хорошие. Для моей (не) надежды, похоже, существует много такого рода кодовой базы по всему миру. Пункт, упомянутый во всех ответах - это рефакторинг кода. Да, мне действительно нравится это делать. В моем личном проекте я всегда делаю это, но ... я не могу изменить код. Программистам разрешено изменять только файлы в задании, для которого они предназначены.

Каждое изменение в старом коде должно быть прокомментировано в коде (даже с Subversion в качестве контроля версий), плюс метаинформация (дата, программист, задача), связанная с этим изменением (это стало беспорядком, есть код с 3 использованными строками и 50 старые строки прокомментировали). Я думаю, что это не только проблема кода, но и проблема управления разработкой программного обеспечения.

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

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

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

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

Этот стиль кодирования (если вы даже хотите называть его любым стилем) - это плохой стиль кодирования.

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

У вас проблемы с плохой базой кода, ни больше, ни меньше.

Таких кодовых баз существует и их много - тот факт, что у вас есть проблемы с ними, свидетельствует о том, насколько они могут быть плохими (и что у вас есть хорошее обучение).

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

Я работаю над проектом C # с очень плохой структурой, а не за то, что вы описываете. Просто объединили 12 отдельных функций (очевидное копирование-вставка) в одну, которая принимает один параметр.

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

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

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

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

• не оставляйте комментариев - исправьте это, когда узнаете
• не имеет функций (50, 100, 200, 300 или более строк, выполняемых последовательно)

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

• использует много операторов if с большим количеством путей - я не совсем уверен, что вы имеете в виду здесь
• имеет переменные, которые не имеют смысла (например: cf_cfop, CF_Natop, lnom, r_procod) -

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

• использует язык, с которым я не знаком (Visual FoxPro 8 от 2002) - это ваша проблема, а не код

Это звучит для меня как возможность .

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

Теперь, это не поможет вам, если вы подойдете к своему работодателю и скажете ему, что все должно измениться. Таким образом, хитрость заключается в том, чтобы поиграть некоторое время, задать много вопросов, и когда вам потребуется написать код, вам нужно будет играть по их правилам со всеми комментариями и т. Д., Так как вам нужно будет оставить других разработчиков используя любую систему, которую они в настоящее время предпочитают, в то же время вы можете ввести разумный рефакторинг, который вам ничем не рискует. Вы можете извлечь несколько методов и, если ваш язык поддерживает это, ввести несколько модульных тестов. Когда вас спросят, почему вы сделали это таким образом, или если вам сказали, что вы делаете что-то «не так», избегайте оборонительных или аргументированных высказываний, когда будете правильно представлять свою позицию для предпочитаемого стиля кодирования. Например, вы можете ссылаться на такие книги, как «Чистый код» Боба Мартина, или вы можете ссылаться на другие книги, статьи или даже вопросы и ответы, с которыми вы столкнулись на сайте Programmers.SE. Все, что вы можете найти полезным, чтобы поддержать вашу позицию фактами, которые могут быть за пределами вашего опыта в глазах людей, с которыми вы работаете.

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

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

Добро пожаловать в джунгли !

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

Мой совет :

1. Начните обучение и ознакомьтесь с: используемым языком программирования (Clipper / dBase) и средой (Visual FoxPro)

2. Прочитайте и проанализируйте кодовую базу и начните комментировать ее

3. организация / рефакторинг кода (решение проблемы слишком большого количества последовательных строк)

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

Чтобы ответить на ваш вопрос: Да, люди / компании везде используют инфраструктуру, которая может быть построена на дерьмовом коде. Интегрируя себя в такие ситуации, это может быть очень трудно иметь дело.

Прошлым летом я работал стажером, разрабатывая приложение, которое будет использоваться командой QA, прикрепленной к конкретному отделу. Команда QA использовала множество автономных скриптов (VBScript, Perl, Bash) для запуска тестов на базах данных и тому подобном, и они хотели собрать их все в одном приложении. Проблема с этим, однако, заключается в том, что эти сценарии использовались в других местах компании (таким образом, основные функциональные возможности / имена переменных не могли быть изменены), и код «добавлялся» в течение почти 10 лет; много дерьма накопилось.

Вот что вы можете с этим сделать:

1. Обратитесь за помощью: ваши коллеги, которым приходилось искать этот код, вероятно, знакомы с его особенностями. То, что для вас глупо и запутанно, прекрасно для них. Так что попросите о помощи!
2. Рефакторинг всякий раз, когда это возможно: если вам нужно просматривать / поддерживать этот код в течение длительного периода времени, реорганизуйте его, когда сможете. Даже если вы выполняете поиск и замену по имени переменной, каждый маленький кусочек помогает. В той компании, которую я организовал прошлым летом, была похожая проблема с использованием дерьмовых имен переменных. Каждый раз, когда я мог, я пробовал их код через гребень с мелкими зубами, меняя имена переменных, оптимизируя логику (например, группируя различные функции в 1) и т. Д. Делайте то же самое, когда у вас есть такая возможность!

Как и везде, до тех пор, пока внешние функции кода работают должным образом, не имеет значения, как работают внутренние компоненты.

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

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

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

Надеюсь это поможет.

Одна из вещей, которая торчит, - это ваш отредактированный комментарий

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

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

Я взял копию scx-инструмента Пола МакНета http://paulmcnett.com/scX.php и включил ее в свой цикл разработки. Он неплохо справляется с извлечением двоичного кода FoxPro в текстовый формат, который затем может быть помещен в исходный репозиторий, такой как Subversion, Mercurial или даже git. (Вы можете найти проект SubFox на http://vfpx.codeplex.com полезным.

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

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

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

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

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

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

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

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

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

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

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