Я вынужден писать плохой код. Как мне сохранить лицо? [закрыто]

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

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

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

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

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

Согласитесь с С.Лоттом из комментариев * (на этот раз :) Никто не заставляет вас писать плохой код. Дело в том, младший разработчик. часто (этот сайт также виноват в этом) теряются в лучших практиках, "прекрасном коде", ... как бы вы это ни называли ... и они мало что делают; или они делают это, но тратят много времени. Говоря им, что они пишут плохой код (который также работает), он получает, чем «через это», просто заставляет их что-то доставлять. Со временем это приводит к тому, что (теперь уже не :) младший разработчик очень быстро находит быстрое и грязное решение, но все остальное время тратит на его улучшение. Со временем вы узнаете больше и в какой-то момент вы начинаете предлагать быстрые и грязные решения, которые на самом деле являются хорошим кодом.

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

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

Никто не написал идеальное решение с первого раза.

* это было бы короче, был бы комментарий.

Комментарии к коду - ваш друг здесь.

Всякий раз, когда вы чувствуете, что вам нужно написать какой-нибудь дешевый хак из-за давления, просто скажите что-то вроде: «Этот код выполняет X из-за нехватки времени. В идеале, я бы вместо этого сделал Y.

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

Это зависит от того, как они заставляют вас.

По моему опыту, есть две возможности:

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

В этом случае, как уже сказано в большинстве других ответов, вам нужно «оптимизировать для крутости». У вас может не быть времени переписать кодовую базу в MVC, но в качестве первого шага, например, вы можете перестать склеивать свой SQL вручную и вместо этого написать хороший execute_sql($query, $params), который закладывает основу для таких абстракций, как fetch_customer($filter_params)и т. Д. Помните, всего наилучшего в конечном счете, существуют практики, когда ваш начальник получает продукт раньше, поэтому существует только конфликт между тем, сколько времени инвестировать в будущее по сравнению с текущим.

Когда вы устанавливаете правильный контекст («в течение 6 месяцев, не получая дополнительного времени, я реорганизовал монолитный код в MVC»), вы должны оставить свое имя в коде и попытаться гордиться, как терапевт, который учит жертву инсульта скажи отдельные слова снова.

Вам явно приказано реализовать его так, как вы считаете непригодным

Попытка отделить представление от модели не выдерживает проверки, потому что «это слишком сложно, почему вы просто не делаете простые SQL-запросы?». Вы execute_sqlполучаете консервы, потому что «кодер с дисциплиной не нуждается в этом».

Это дело плохо. По моему опыту, это обычно происходит с микроуправлением и лидерами команд, которые получили повышение по политическим причинам, а не за свои успехи. Реальная проблема заключается в том, что вы отвечаете за что-то (код), который вы не можете контролировать (вы должны делать это по-своему). Лучшее решение - решить основную причину (то есть то, что с вами обращаются как ворчание). Второе лучшее (и, по моему опыту, обычное) решение - это выйти.

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

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

В долгосрочной перспективе поговорите со своим боссом. Объясните, как 15-минутное инвестирование может сэкономить часы. Убедитесь, что у вас есть убедительные примеры - не такой, как «если бы я сделал это и то, что здесь, я надеюсь, что я смогу сделать то же самое в следующем году», а, скорее, «посмотрите, вот я это сделал, и потому что из этого мне потребовалось три часа, чтобы найти проблему там; если бы я сделал это так и так, ошибка была бы очевидна сразу ". Предупреждение здесь: хотя элегантный и поддерживаемый код чувствует себя намного лучше и эффективнее, иногда это не так. Бывают ситуации, когда небрежное быстрое исправление вполне оправдано: иногда вы пишете одноразовый код, иногда сохраняете устаревший кусок мусора, ожидая реального; иногда польза от правильного решения не

Если ничего не помогает, найдите другую работу.

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

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

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

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

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

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

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

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

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

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

Я уверен, что есть много инструментов, которые можно бесплатно использовать для анализа php-кода http://en.wikipedia.org/wiki/Code_analysis.

Также, конечно, это http://en.wikipedia.org/wiki/Code_smell

Прочтите это, подытожьте, что вы можете найти в вашем приложении, и, конечно, перечислите альтернативы . Это плохая практика - просто вставать и кричать «Мне не нравится, как это делается», не представляя альтернативного (предпочтительно) лучшего способа сделать это.

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

НТН

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

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

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

Чтобы привести мой пример, я однажды прибыл в середине проекта с приложением Perl / CGI, где весь HTML был в коде. Все приложение было в одном файле без четкой структуры. Ничего не было версионировано. Я начал с настройки репозитория CVS (в то время SVN не был доступен), наложив на него веб-интерфейс для клиента. Сначала я сам обрабатывал коммиты от моих коллег. Затем я разделяю все методы на разные модули (файлы). В этот момент коллеги начали внедрять CVS. Затем я переместил HTML из кода. Затем, каждый раз, когда мне приходилось вносить изменения в какую-то часть кода, я тратил немного времени на его рефакторинг. В итоге скорость разработки настолько возросла, что клиент был очень доволен. Они попросили бы косметическое изменение, и вместо того, чтобы мы сказали им, что это займет 2 дня,

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

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

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