Проект почти готов, но процедурный код спагетти. Я переписываю или просто пытаюсь отправить его? [закрыто]

Я начинающий веб-разработчик (один год опыта).

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

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

Я звонил выстрелы. После некоторых исследований я остановился на PHP и начал с простого PHP, без каких-либо объектов, только с некрасивым процедурным кодом. Два месяца спустя все стало грязно, и было трудно добиться какого-либо прогресса. Веб-приложение огромно. Поэтому я решил проверить среду MVC, которая облегчит мою жизнь. Вот где я наткнулся на крутого парня из сообщества PHP: Laravel. Мне понравилось, это было легко учиться, и я сразу начал программировать. Мой код выглядел чище, более организованным. Это выглядело очень хорошо.

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

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

Поэтому я начал работать над небольшими проектами ночью, читая о методологиях и лучших практиках. Я вновь OOP, перешел на объектно-ориентированное проектирование и анализ, и читать Дядя Боб книгу Чистого кода .

Это помогло мне понять, что я действительно ничего не знал. Я не знал, как создавать программное обеспечение ПРАВИЛЬНЫМ СПОСОБОМ. Но в этот момент было слишком поздно, и теперь я почти закончил. Мой код совсем не чистый, просто код спагетти, реальная боль в исправлении ошибки, вся логика в контроллерах и мало объектно-ориентированного дизайна.

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

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

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

Я переписываю, или просто продолжаю пытаться отправить, или есть другой вариант, который я пропустил?

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

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

Во-вторых, вы узнали много ценных вещей, поэтому вы должны оценить опыт за то, что он научил вас :

1. Слинг-код без плана или архитектуры - рецепт катастрофы
2. В программировании гораздо больше, чем написание кода
3. Владельцы нетехнических предприятий часто не понимают влияния технических решений (например, кого нанимать), и разработчики сами должны им что-то объяснять.
4. Большинство проблем уже решены гораздо лучше, чем вы бы их решали, в существующих рамках. Стоит знать, какие рамки существуют и когда их использовать.
5. Люди, только что вышедшие из школы и назначенные на большой проект с небольшим руководством, как правило, создают миску с кодом спагетти. Это нормально.

Вот еще несколько советов о том, как действовать:

1. Общайтесь, общайтесь, общайтесь. Вы должны быть очень откровенны и откровенны в отношении состояния проекта и ваших идей о том, как действовать, даже если вы не уверены и видите несколько путей. Это оставляет владельцу бизнеса выбор, что делать. Если вы храните знания при себе, вы лишаете их выбора.
2. Не поддавайтесь искушению полностью переписать. Пока вы переписываете, у бизнеса нет продукта. Кроме того, переписывание редко получается так хорошо, как вы себе это представляли. Вместо этого выберите архитектуру и постепенно переносите кодовую базу в нее. Таким образом можно спасти даже ужасную кодовую базу. Читайте книги о рефакторинге, чтобы помочь вам в этом.
3. Узнайте об автоматическом тестировании / модульном тестировании . Вы должны укрепить доверие к коду, и способ сделать это - покрыть его автоматизированными тестами. Это идет рука об руку с рефакторингом. Пока у вас нет тестов, тестируйте вручную и всесторонне (попробуйте взломать ваш код, потому что ваши пользователи будут делать это). Записывайте все найденные ошибки, чтобы вы могли расставить приоритеты и исправить их (у вас не будет времени на исправление всех ошибок, ни одно программное обеспечение не поставляется без ошибок в реальном мире).
4. Узнайте, как развернуть веб-приложение и поддерживать его в рабочем состоянии. Книга « Веб-операции: хранение данных в срок» - хорошее начало.

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

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

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

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

Изменить (так как этот вопрос имеет много голосов, я мог бы также добавить еще немного контента)

Частично радость быть программистом заключается в том, что люди, не являющиеся техническими специалистами (вероятно, ваш менеджер, определенно весь остальной бизнес), понятия не имеют, чем вы занимаетесь. Это и хорошо, и плохо. Часть плохого в том, что вы должны постоянно объяснять, как работают проекты по разработке программного обеспечения. Планирование, требования, обзоры кода, тестирование, развертывание и исправление ошибок. Это ваша работа , чтобы объяснить важность тестирования и выделить время для тестирования. Вы должны стоять здесь на своем. Люди не поймут важность ( «мы не можем просто начать использовать это?») но как только они начнут тестировать (а не в реальной среде!), они быстро поймут преимущества. Одна из причин, по которой они вас наняли, заключается в том, что они ничего не знают о разработке программного обеспечения, поэтому вы должны их обучить. Здесь необходимо подчеркнуть важность тестирования и исправления ошибок - помните, что они не программисты, они не знают разницы между делением на ноль и сломанным HTML-тегом.

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

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

• Модульное тестирование - возвращает ли моя функция кода правильное значение
• Тестирование системы - выдает ошибку, когда я нажимаю на X
• Пользовательское приемочное тестирование (UAT) - соответствует ли программа требованиям? Делает ли это то, что они просили вас сделать? Это может пойти жить?

Если вы не записали требования того, что вас попросили сделать, UAT будет намного, намного сложнее. Это где многие люди падают. Наличие того, что они хотели, чтобы система записала на бумаге, сделает вашу жизнь намного проще. Они скажут: «Почему это не делает X?» и вы можете сказать: «Вы сказали мне, чтобы сделать это Y». Если программа неверна, исправьте ее. Если требования неверны, исправьте документ, попросите дополнительный день или два (нет, настаивайте на этом), внесите изменения, обновите документацию и повторите тестирование.

Пройдя несколько раз через этот процесс, вы можете начать изучать Agile ... но это другой мир :)

TL; DR тестирование это хорошо

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

Рекомендуемый подход состоит в том, чтобы вместо этого чистить начальный беспорядок во время обслуживания. И даже не пытайтесь рефакторировать это просто ради этого. Кроме того, менеджеры обычно считают это пустой тратой денег (что часто и бывает), и это создает ненужный риск появления новых ошибок. После того, как вы мучительно отлаживаете код, он может не быть красивым, но он будет работать. Так что пусть будет, пока вам не понадобится коснуться его по другим причинам (будь то исправление ошибки, новая функция или просто изменение, запрошенное маркетингом). Затем очистите детали, которые сложнее всего отрегулировать. Это часто называют правилом бойскаута .

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

И наконец, еще один рекомендуемый текст: Большой шарик грязи .

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

Доставка это особенность.

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

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

Совершенный враг хорошего.

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

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

Я [...] прочитал чистый код Дяди Боба.

У меня настойчивая мысль, что я должен переписать весь проект.

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

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

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

У тебя все хорошо.

Вы говорите, что ваш код работает, и он почти готов к отправке, верно? И вы понимаете, что ваш код может быть значительно улучшен. Хороший.

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

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

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

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

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

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

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

Большинство из того, что я бы сказал в ответ на ваш вопрос, было сказано другими. Прочитайте «То, что вы никогда не должны делать, часть I» Джоэла Спольски (вместе с некоторыми другими его постами об «астронавтах архитектуры»). Помните, что «совершенство - враг хорошего». Учитесь рефакторингу постепенно. Доставка важна и т. Д.

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

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

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

Если вы действительно заинтересованы в вашей дилемме, вам также следует прочитать «Lean Startup». Множество советов, которые вам даются здесь, больше откликнутся у вас, если вы прочитаете эту книгу. По сути, скорость выгорания ресурсов - ваш злейший враг, и нет ничего более ценного для вас и вашей организации, чем отзывы конечных пользователей / клиентов. Итак, приведите ваш продукт в жизнеспособное состояние (Minimum Viable Product - или MVP), а затем отправьте его за дверь (независимо от того, как на самом деле выглядит код). Пусть ваши клиенты диктуют ваши будущие изменения и версии, а не наоборот. Если вы сосредоточитесь на этом подходе, то и вы, и ваш начальник будете счастливее в долгосрочной перспективе.

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

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

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

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

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

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

Вот что я бы сделал лично:

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

Почему я предлагаю все это вам?

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

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

Поверьте мне, есть люди, которые сделали много предположений о вас, потому что вы сделали что-то для любой цели в любой момент. Для них, если вы сделали это в ситуации A, вы сделаете это в ситуации B. Они думают очень просто.

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

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

2) Начните использовать контроль версий, хотя, надеюсь, вы уже это делаете.

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

редактировать

Ух ты, кому-то это действительно не понравилось - понизить голос и удалить флаг? Почему?

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

Чтобы ответить на ваш вопрос: как многие другие сказали, нет. Поставьте его и почистите постепенно, в процессе исправления ошибок.

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

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

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

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