Проект майже завершений, але процедурний код спагетті. Я переписую чи просто намагаюся надсилати його? [зачинено]

Я початківець веб-розробник (один рік досвіду).

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

Коккі, як я тоді був, отримавши диплом з інформатики, я прийняв пропозицію, думаючи, що я можу побудувати що завгодно.

Мені дзвонили постріли. Після деяких досліджень я влаштувався на PHP, і почав із звичайного PHP, ніяких об’єктів, просто потворний процедурний код. Через два місяці все стало безладним, і важко було досягти прогресу. Веб-додаток величезний. Тому я вирішив перевірити рамку MVC, яка полегшила б мені життя. Ось де я натрапив на класного малюка у спільноті PHP: Laravel. Мені це сподобалось, це було легко дізнатися, і я почав кодувати відразу. Мій код виглядав чистішим, організованішим. Це виглядало дуже добре.

Але знову веб-додаток було величезним. Компанія тиснула на мене, щоб поставити першу версію, яку вони хотіли розгорнути, і, очевидно, і почати шукати клієнтів.

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

Тому я почав працювати над невеликими проектами вночі, читаючи про методології та найкращу практику. Я переглянув ООП, перейшов до об'єктно-орієнтованого проектування та аналізу та прочитав книгу « Чистий код дядька Боба» .

Це допомогло мені зрозуміти, що я насправді нічого не знаю. Я не знав, як створити програмне забезпечення ПРАВИЛЬНИЙ ШЛЯХ. Але в цей момент було вже пізно, і зараз я майже закінчився. Мій код зовсім не чистий, просто код спагетті, справжній біль, щоб виправити помилку, вся логіка в контролерах, і мало об’єктно-орієнтована конструкція.

У мене така наполеглива думка, що мені доведеться переписати весь проект. Однак я не можу цього зробити ... Вони постійно запитують, коли це все буде зроблено.

Я не уявляю, як цей код розгорнутий на сервері. Плюс досі я нічого не знаю про ефективність коду та продуктивність веб-додатків.

З одного боку, компанія чекає товару і більше не може чекати. З іншого боку, я не можу бачити себе далі з фактичним кодом. Я міг би закінчити, завершити і розгорнути, але Бог знає лише, що може статися, коли люди почнуть його використовувати.

Чи потрібно переписувати, чи просто намагаюся надсилати, чи є інший варіант, який я пропустив?

Ви натрапили на ахілесову п’ятку більшості освітніх програм CS: вони навчають вас інструментів і прийомів, але не торгівлі. Побудова програмного забезпечення - це ремесло, яке ви набуваєте лише за роки практики та досвіду використання свого програмного забезпечення (користувачі набагато суворіші критики, ніж викладачі). Будівництво програмного забезпечення також часто є бізнесом, де бізнес-цілі можуть перевершити технічні амбіції.

Перш за все, корабель. Якщо ви покажете власнику бізнесу програмне забезпечення, і він вважає, що він готовий до доставки, тоді відправляйте його. Якщо це не до того, але закрити, закінчіть його. Єдине важливе програмне забезпечення - це те, що фактично використовується. Єдиний програмний бізнес, який заробляє гроші, - це той, який має продукт.

По-друге, ви дізналися багато цінних речей, тому вам слід цінувати досвід за те, чого він вас навчив :

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

Ось ще кілька порад для вас, як діяти далі:

1. Спілкуватися, спілкуватися, спілкуватися. Ви повинні бути дуже відкритими та відвертими щодо стану проекту та своїх уявлень про те, як далі діяти, навіть якщо ви не впевнені та бачите кілька шляхів. Це залишає власнику бізнесу вибір, що робити. Якщо ви зберігаєте знання для себе, ви позбавляєте їх вибору.
2. Втримайтеся від спокуси повного перепису. Поки ви переписуєте, у бізнесу немає продукту. Також переписування рідко виходить таким хорошим, як ви це собі уявляли. Замість цього виберіть архітектуру та перемістіть до неї кодову базу поступово. Навіть жахливу кодову базу можна врятувати таким чином. Читайте книги про рефакторинг, щоб допомогти вам.
3. Дізнайтеся про автоматичне тестування / тестування одиниць . Ви повинні наростити довіру до коду, а спосіб зробити це - покрити його автоматизованими тестами. Це йде рука об руку з рефакторингом. Поки у вас немає тестів, тестуйте вручну і всебічно (намагайтеся зламати код, тому що ваші користувачі будуть це робити). Запишіть усі знайдені помилки, щоб ви могли встановити пріоритети та виправити їх (у вас не буде часу на виправлення всіх помилок, жодне програмне забезпечення не реалізовує помилок у реальному світі).
4. Дізнайтеся, як розгорнути веб-додаток і продовжувати його працювати. Книга Веб-операції: Зберігання даних про час - хороший початок.

Це звучить, як і будь-яка інша система, яку на мене кинули, щоб виправити.

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

На мою думку, ви повинні прийти чистими. Це не буде весело. Скажіть їм, що ви зробили все можливе, це спрацьовує (здебільшого), але ви переживаєте, що це може не працювати добре і що буде багато помилок ( помилок завжди є ). Його потрібно переглянути старшим програмістом, і вони повинні мати можливість виправити будь-які яскраві проблеми з продуктивністю / безпекою досить швидко. Або вони можуть розгорнути його і схрестити пальці. Це або піде нормально, або підніметься. Можливо, ви зможете виправити проблеми, коли вони з’являються. Якщо у вас є велика база користувачів, можливо, ні.

Або ви могли б зробити те, що робить більшість людей у ​​цій ситуації: візьміть гроші, зникніть і нехай розбираються. Я покладу на вас, щоб розібратися, що таке етичний вибір.

Редагувати (оскільки це питання має багато голосів, я можу також додати ще трохи вмісту)

Частина радостей бути програмістом полягає в тому, що люди, які не є технічними (можливо, ваш менеджер, безумовно, решта бізнесу), не мають уявлення, чим займаєтесь. Це і добре, і погано. Частина поганого полягає в тому, що вам доведеться постійно пояснювати, як працюють проекти з розробки програмного забезпечення. Планування, вимоги, огляд коду, тестування, розгортання та виправлення помилок. Це ваша робота , щоб пояснити важливість тестування і виділити час для тестування. Ви повинні вистояти тут. Люди не зрозуміють важливості ( "чи не можемо ми просто почати її використовувати?"), але як тільки вони почнуть тестувати (не в прямому середовищі!), вони швидко зрозуміють переваги. Однією з причин, по якій вони найняли вас, є те, що вони нічого не знають про розробку програмного забезпечення, тому ви навчите їх. Тут потрібно підкреслити важливість тестування та виправлення помилок - пам’ятайте, що вони не програмісти, вони не знають різниці між діленням на нуль та зламаним html-тегом.

Часто багато проблем, які виникають, насправді не є помилками. Це питання щодо юзабіліті, пропущені вимоги, вимоги, які змінилися, очікування користувачів (чому я не можу використовувати це на своєму мобільному телефоні?), А потім фактичні реальні помилки. Це потрібно випрасувати, перш ніж виходити наживо - часто багато помилок можна обробити чи виправити через кілька днів. Якщо люди очікують досконалої системи, вони будуть сильно боліти. Якщо вони очікують помилок, ваше життя стане набагато легшим протягом наступних двох тижнів.

О, і не плутайте тестування користувачів ні з тестуванням одиниць, ні з тестуванням системи.

• Тестування блоку - чи повертає моя функція коду потрібне значення
• Тестування системи - чи видає це помилку, коли натискаю на X
• Тестування прийняття користувача (UAT) - чи відповідає програма вимогам? Чи робить це те, що вони попросили вас зробити? Чи можна йти наживо?

Якщо ви ще не записали вимоги того, що вони вас попросили зробити, UAT буде набагато набагато складніше. Тут багато людей падають. Наявність того, що вони хотіли, щоб система записала на папері, значно полегшить ваше життя. Вони скажуть "Чому це не робиться X?" і ви можете сказати "Ви сказали мені, щоб це зробити Y". Якщо програма неправильна, виправте її. Якщо вимоги неправильні, виправте документ, попросіть додатковий день чи два (ні, наполягайте на цьому), внесіть зміни, оновіть документацію та повторно випробуйте.

Пройшовши цей процес кілька разів, ви можете почати шукати Agile .. але це інший світ :)

TL; DR Тестування добре

Щоразу, коли ви починаєте з нуля, ви майже напевно будете робити однакову кількість помилок або більше завдяки синдрому Другої системи . Ваші нові помилки будуть різними, але кількість часу, необхідного для налагодження, буде аналогічним, і таким чином відчайдується, наскільки це не дуже добре. Це також затримає розгортання у виробництві або розгортання нових функцій, якщо буде розгорнута перша версія, що буде серйозною проблемою для компанії. Джоел Спольський називає це "єдиною найгіршою стратегічною помилкою" , яку може допустити будь-яка компанія чи розробник.

Рекомендований підхід полягає в тому, щоб очищати початковий безлад по шматочках під час обслуговування. І навіть не намагайтеся переробляти це лише заради цього. Крім того, менеджери зазвичай бачать, що це трата грошей (що це часто є), і це несе зайвий ризик введення нових помилок. Після того, як ви болісно налагодили код, він може бути не дуже гарним, але він спрацює. Тож нехай це стосується, поки вам не доведеться доторкатися до нього з інших причин (будь то виправлення помилок, нова функція або просто зміна, про яку вимагає маркетинг). Потім очистіть деталі, які найскладніше відрегулювати. Це часто називають хлопчиковим скаутським правилом .

І в цей момент вам не доведеться сперечатися з менеджером. Просто включіть мінімальний бажаний рефакторинг в оцінку для запиту. Ви дізнаєтесь з досвіду, коли ви можете дозволити собі трохи поступитися, тому що компанія дійсно виправлена, і коли ви не хочете створювати проблем у майбутньому і просто не допускаєте жодної можливості швидкого злому.

Останнє, ще одне рекомендоване читання: Великий бал бруду .

Я забуваю, де вперше це прочитав, але мені просто хотілося повторити, дещо сильніше, те, що сказали інші люди:

Доставка - особливість.

Немає нічого гіршого, ніж той хлопець, який продовжує "прибирати" існуючий (можливо, хакі, некрасивий, брудний) код, який ідеально працює , вводячи нові помилки і т. Д. Що в реальному світі важливо - це зробити вашу роботу. Ви зробили це. Корабель. Не загубіться у дизайні проекту, який ідеально працює, навіть якщо він некрасивий під кришкою. Коли ви виправите це, зробіть це поступово, і зробіть собі хороший тестовий набір, щоб у вас було якомога менше регресій.

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

Досконалий - ворог добра.

Для клієнта завжди краще мати хороше програмне забезпечення, ніж ідеальне програмне забезпечення, яке ніколи не вийде.

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

Я [...] читав чистий код дядька Боб.

У мене така наполеглива думка, що мені доведеться переписати весь проект.

У цій книзі є дуже підходящий розділ під назвою "Великий перепроект у небі".

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

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

Ти робиш добре.

Ви кажете, що ваш код працює, і він майже готовий до відправки, правда? І ви вважаєте, що ваш код може бути значно вдосконалений. Добре.

Ваша дилема мені дуже нагадує мій перший досвід роботи з фрілансінгу (прийняття на роботу під час 2-го курсу в університеті для створення багатомовної POS-системи). Я пройшов нескінченні запитання, оскільки мене ніколи не влаштовував код, хотів масштабування, хотів винаходити кращі колеса ... Але я просто затримав проект (наприклад, приблизно на 12 місяців) і ... що? Після того, як ви розгорнете річ, вона все ще потребує великої перевірки, тестування, виправлення тощо.

Чи маєте ви досвід роботи з професійними базами коду? Багато баз кодів наповнені химерними, важкими для підтримки кодом. Альтернативою виявленню складності програмного забезпечення шляхом спроби самостійно створити велику програму було б підтримання / розширення однаково брудного коду, написаного іншими людьми.

Єдиний випадок, коли я бачив, як цілі переписування приносять багато користі, - це коли команда одночасно прийняла новий ланцюжок інструментів / рамок.

Якщо основна логіка (що робить програма, а не як вона викладається як функції, класи тощо) є здоровою, вона буде працювати так само добре, тож ви думаєте, що це код спагетті, це не означає не слід розгортати.

Вам потрібно дозволити своєму клієнту щось, що він може використовувати. Тоді, коли вони попросять вас покращити / додати функціональність, ви вирішите, чи потрібен рефактор, і це добре, щоб повідомити вашому клієнту про те, що "потрібна деяка технічна робота для інтеграції зазначеної нової функції". З допомогою якого вони зрозуміють, що це коштуватиме їм більше грошей, і їм доведеться чекати довше. І вони зрозуміють (або можна витягнути).

Кращий час переписати все було б тоді, коли інший клієнт попросить вас створити щось подібне.

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

Більшість того, що я сказав би у відповідь на ваше запитання, сказали інші. Прочитайте "Речі, які ти ніколи не повинен робити, частина I" Джоела Спольського (разом з деякими його іншими публікаціями про "космонавтів архітектури"). Пам’ятайте, що «досконалий - ворог добра». Навчіться рефактор поступово. Важлива доставка тощо.

Що я хотів би додати, це таке: вам поставили перед собою завдання щось, що вважалося можливим одним свіжим випускником, який працює з невеликим початковим бюджетом / часовим рамком. Вам не потрібно нічого більш складного, ніж добре, структуроване, процедурне програмування. (І, FYI, "процедурне програмування" - це не погане слово. У більшості випадків це є потребою на певному рівні, і цілком достатньо для багатьох цілих проектів.)

Просто переконайтеся, що ви фактично виконуєте структуроване, процедурне програмування. Повторення у вашому коді не обов'язково є ознакою того, що вам потрібні грандіозні, поліморфні структури. Це може бути просто ознакою того, що вам потрібно взяти повторний код і ввести його в підпрограму. Контрольний потік спагетті може бути просто можливістю позбутися глобального.

Якщо є аспекти проекту, які законно вимагають поліморфізму, успадкування впровадження тощо, я б припустив, що, можливо, розмір проекту був занижений.

Якщо вас справді цікавить дилема, ви також повинні прочитати "Lean Startup". Дуже багато порад, які вам дають тут, більше відгукнуться з вами, якщо ви прочитаєте цю книгу. По суті, швидкість спалювання ресурсів - ваш найгірший ворог, і для вас і вашої організації немає нічого більш цінного, ніж відгуки кінцевих споживачів / клієнтів. Отже, доведіть продукт до життєздатного стану (мінімальний життєздатний продукт - або MVP), а потім відправте його у двері (незалежно від того, як виглядає код насправді). Нехай ваші клієнти диктують ваші майбутні набори змін та версій, а не навпаки. Якщо ви зосередитесь на такому підході, і ви, і ваш начальник у довгостроковій перспективі будуть щасливішими.

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

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

Тести для одиниць і автоматизовані випробування вищого рівня - це чудово, і це те, що ви повинні мати стільки, скільки зможете, перш ніж спробувати перефактурувати (або переписати) цю програму. Але зараз вам в основному потрібно протестувати його, навіть якщо вам доведеться запускати кожен тест «від руки» і підтверджувати правильність функціонування «на очі». Якщо згодом ви зможете розібратися, як автоматизувати ці тести, це допоможе, коли настав час розпочати роботу над наступною версією продукту.

Деякі люди вміють сидіти перед новим програмним проектом як користувача альфа-тесту і робити щось не так. Тобто вони добре ламають речі. Якщо вам пощастило, щоб з вами працював такий талановитий чоловік, дозвольте їм спершу спробувати додаток, щоб ви мали змогу виправити будь-які очевидні помилки рано. Якщо ви повинні виконати це завдання самостійно, то:

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

У вашому запитанні сказано: "Почали неправильно, чи варто починати з початку", а в додатковому тексті насправді сказано: "Готовий проект, але зробив це неправильно, чи варто починати з початку". Один лише заголовок питання: Якщо кількість виконаних вами програм програмування невелика порівняно із загальною необхідною роботою, то починати все буде мати сенс. Це трапляється багато, коли проблема є складною і погано зрозумілою, і досить багато часу витрачається на з'ясування того, у чому проблема. Немає сенсу продовжувати поганий старт, якщо відкинути його і почати все спочатку, на цей раз з хорошим розумінням проблеми, означає, що ви дійсно закінчите швидше.

Це я би робив особисто:

1. Киньте, виправдайтеся і відмовтеся (навіть можете повернути частину своєї зарплати, щоб ви не виглядали погано)
2. Чистіть код якомога більше
3. Складіть документацію на всі хороші частини вашої роботи, як ваш гарний дизайн, хороші ідеї тощо ...

Чому я пропоную вам усе це?

Тому що думайте про майбутнє. У майбутньому буде час, коли певні люди отримають цей код. Вони будуть приймати всілякі припущення і судження про вас і ваші здібності. Їм не байдуже, коли ти це написав, їх не хвилює обставина. Вони хочуть лише побачити в ньому те, що хочуть бачити, щоб підтвердити все, що вони хочуть підтвердити.

Вас називатимуть якоюсь поганою назвою, термін, який вони можуть придумати, щоб негативно вплинути на вас. І хоча ви в майбутньому може бути абсолютно різними в плані технічних можливостей, навичок, знань, стилю і ситуація буде настільки різною, цей код буде застосовуватися проти вас усіма можливими способами. Це як суд, де вони можуть сказати всі погані речі про вас і ваш код та дизайн, і ви навіть цього не знаєте, щоб ви могли пояснити та захистити себе. (і ви можете дуже часто дізнаватися, що вони багато разів помиляються). Тому не робіть цього. Здаватися.

Повірте мені, є люди, які зробили багато припущень щодо вас, тому що ви зробили щось з будь-якою метою в будь-який момент. Для них, якщо ви зробили це в ситуації А, ви зробите це в ситуації Б. Вони думають дуже просто.

Ще дві пропозиції, я ставлю на обмін принаймні одну з них, яку ви ще не зробили.

1) Поставте на місце трекер помилок і навчіть свого начальника користуватися ним. Це може бути частиною розмови про те, як ви накрутили, навчилися краще і збираєтесь це виправити плановим чином

2) Почніть використовувати контроль над версіями, хоча, сподіваємось, ви це вже робите.

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

редагувати

Ого, комусь справді це не сподобалось - прапорець І видалити прапор? Чому?

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

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

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

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

Ви початковий веб-розробник, не маючи доброго розробника, який би вам порадив, ваш начальник найняв вас, знаючи це добре. Я думаю, що ти робиш так само добре, як хто-небудь міг очікувати від тебе. Власне, те, що ти маєш уявлення про те, що робота могла бути кращою, і що ти насправді навчився речам, які дозволять тобі зробити це краще, означає, що ти робиш краще, ніж більшість. Пам’ятайте на власну думку про те, що версія вас, яка розпочала роботу, не могла зробити її краще. Хтось досвідченіший (і, отже, краще оплачуваний), або ви з одним проектом, вартим досвіду, могли зробити це краще.

Що робити зараз : Будь щасливим, що ти кращий розробник, ніж рік тому. Наступний проект ви зробите краще (і наприкінці ви знову будете досвідченішими і не задоволені тим, що зробили; це нормально). Зміна або перезапис останнього проекту дасть бізнесу дуже мало користі для витрат. Що ви можете зробити, це замінити поганий код хорошим кодом, коли вам потрібно вносити зміни; це має сенс, оскільки змінити погано підтримуваний код може бути складніше, ніж замінити його хорошим кодом. А якщо ви допоможете новому недосвідченому розробнику на допомогу, скажіть їм, що цей код не є прикладом, який вони повинні копіювати.