Як ви справляєтесь з некрасивим кодом, який ви написали? [зачинено]

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

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

Знайдіть іншу роботу і дозвольте іншим людям цим займатися. Muahahahhahahaa.

.....

Просто жартую. :)

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

Ще одна (споріднена) порада: Завжди оцінюйте, здавалося б, крихітні, без завдань, що стосуються мозків, до блоку гідного розміру. Скажімо, наприклад, - предмет, який ви майже впевнені, буде простою зміною в один рядок 30 секунд - дайте йому 1 годину (або, можливо, найнижчий часовий блок у вашому графіку часу або системі CR, наприклад, 15 хвилин / 0,25 години) . І надайте блоки на півдня або на 1 день для дещо більших, але все ще відносно тривіальних предметів.

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

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

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

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

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

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

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

З усіма коментарями щодо переоцінки я думаю, що пропущено скромну кількість балів (ну можливість).

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

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

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

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

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

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

1) Правильний контроль змін - ваш друг

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

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

2) Рефакторинг повинен бути зроблений таким, що забезпечує справжню довгострокову вигоду для клієнта

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

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

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

У базі коду, над яким я зараз працюю, у мене є такий коментар:

/*
 * Every time I see this function, I want to take a shower.
 */

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

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

Я вважаю за краще уникати такої ситуації.

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

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

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

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

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

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

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

Зробіть це частиною вашого процесу, я називаю це "екстремальним рефакторингом", і це буде великим! ;) Просто виконайте роботу швидко та коли буде додано достатньо нових функцій, що є рубцева тканина, відновлюйте її. Постійно запитуйте себе: "Якщо б я почав з нуля, як би я це зробив"

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

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

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

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

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

Покладайтеся на вищу силу

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

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

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

Запропонуйте людині на початку вдосконалити та заморозити специфікацію та застосувати її згодом.

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

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

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

Початковий належний дизайн не може уникнути проблеми. І майже неможливо (або дуже-дуже важко) розглянути всі майбутні "можливо" вимоги. Тож через деякий час прийде Великий Ре-факторинг. І найкраще рішення - переписати все.

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

Вбити його вогнем.

Aka refactor якнайшвидше: наприклад, коли неприємний код приходить з поспіхом на кінцевий термін, я б рефактор після закінчення цього терміну, оскільки ви не можете (або не повинні принаймні) додавати більше функцій, поки існуючий код не стане ремонтом, інакше це зробить набагато складніше налагодження майбутніх кодів.

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

Найпростіша відповідь. Я б припинив кодування будь-якого виду, поки у нього немає остаточної характеристики того, що він / вона хоче відтепер.

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

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

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

Скажіть їм, коли у вас є остаточний список, що ви будете робити подальші модифікації, як вони бажають, але потрібно зосередитись на вершині 15/20, яку вони повинні мати зараз.

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

Після прийняття остаточного рішення щодо того, що робити для поточної версії, всі дискусії / ідеї / пропозиції повинні бути припинені на 100%.

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

Якщо вони продовжують витрачати ваш час, продовжуйте передумувати. Тоді я просто перестав би працювати над проектом та працювати над іншими проектами, поки вони не остаточно допрацюють свої рішення.

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

З точки зору проекту:

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

З точки зору розвитку:

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

З точки зору планування:

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