Як зупинити вічні рішення тимчасових рішень?

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

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

Напишіть тест, який не вдається зламати.

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

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

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

Стратегія 2a: Те саме, що і стратегія 2, за винятком того, що насправді є помилки. Однак та сама проблема.

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

Стратегія 4: Зачекайте перезапису. Продовжуйте чекати. Рано чи пізно (можливо, пізніше), комусь доведеться переписати річ. Можливо, зробіть це прямо тоді.

Ось чудова стаття на тему технічному боргу .

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

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

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

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

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

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

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

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

[Редагувати]

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

ВИ НЕ РОБИТЕ ПРОМІСНІ РІШЕННЯ.

Іноді я думаю, що це просто потрібно сказати програмістам.

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

Перестаньте залишати мені свій дерьмовий код для обслуговування. Просто ЗАВЖДИ КОДУЙТЕ ПРАВО. Незалежно від того, скільки часу це займе і хто на вас кричить.

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

Навіть якщо ви не вважаєте себе чудовим програмістом, завжди прагніть робити якнайкраще, ніколи не використовуйте ярлики - це не коштує вам БУДЬ-ЯКОГО часу, щоб зробити це правильно. Я можу виправдати це твердження, якщо ви мені не вірите.

Раптом ти виявляєш, що витратив п’ять років, використовуючи менш ідеальне рішення, лаявши його.

Якщо ви його лаєте, чому це внизу списку TODO?

• Якщо це не впливає на вас, чому ви це проклинаєте?
• Якщо це впливає на вас, то це проблема, яку потрібно виправити ЗАРАЗ.

• Я переконуюсь, що проголошую пріоритет довгострокового виправлення, ОСОБЛИВО після того, як короткострокове виправлення з’явилося.
• Я детально описую причини, чому це хакерство, а не хороше довгострокове рішення, і використовую їх, щоб зацікавлені сторони (менеджери, клієнти тощо) зрозуміли, чому це потрібно виправляти
• Залежно від випадку, я можу навіть внести туди трохи найгіршого сценарію страху. "Якщо ця безпечна лінія зафіксується, весь міст може зруйнуватися!"
• Я несу відповідальність за розробку довгострокового рішення та переконуюсь, що воно буде розгорнуто

Це важкий дзвінок. Я робив хаки особисто, іноді у вас МАЄТЬСЯ , щоб отримати цей продукт з дверей і в руки клієнтів. Однак я дбаю про це - це просто робити.

Скажіть керівнику проекту або вашому начальнику, або замовнику: Є кілька місць, які потрібно очистити та краще закодувати. Для цього мені потрібен тиждень, і це буде коштувати дешевше, щоб зробити це зараз, тоді це буде робити це через 6 місяців, коли нам потрібно буде впровадити розширення до підсистеми.

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

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

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

Удачі. З мого досвіду цього майже неможливо досягти.

Як тільки ви спуститесь по слизькому схилу, щоб здійснити хакерство, бо на вас чинять тиск, ви можете звикнути жити з ним протягом усього часу. Майже НІКОЛИ не вистачає часу на те, щоб переробити те, що вже працює, як би погано це не було впроваджено внутрішньо. Що змушує вас думати, що у вас чарівним чином буде більше часу "на якийсь пізніший термін", щоб виправити хакерство?

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

Я намагаюся побудувати хакерське рішення, щоб його можна було перенести на тривалий шлях якомога безболісніше. Скажімо, у вас є хлопець, який створює базу даних на SQL Server, тому що це його найсильніша БД, але вашим корпоративним стандартом є Oracle. Створіть базу даних із якомога меншою кількістю непередаваних функцій (наприклад, типів даних Bit). У цьому прикладі не складно уникнути бітових типів, але це спрощує подальший перехід.

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

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

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

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

Ми використовуємо Java та Hudson для постійної інтеграції. "Проміжні рішення" повинні коментуватися:

// TODO: Better solution required.

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

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

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

Звичайно, це може взагалі не стосуватися вашого робочого середовища :(

Це нагадує мені історію "CTool". На початку CTool був висунутий одним із наших розробників, я буду називати його Дон, як один із можливих способів вирішити проблему, яку ми мали. Будучи серйозним працьовитим типом, Дон підключився і поставив робочий прототип. Ви знаєте, куди я йду з цим. За одну ніч CTool став частиною робочого циклу компанії, де цілий відділ залежав від цього. На другий-третій день через недоліки CTool почали надходити гіркі скарги. Користувачі ставили під сумнів компетентність, відданість та рівень IQ Дона. Протести Дона щодо того, що це ніколи не повинно було бути виробничим додатком, натрапили на глухі вуха. Це тривало роками. Нарешті, хтось зібрався переписати програму, і вже після того, як Дон пішов. На той час до назви CTool прикріпилося стільки ненависті, що про її присвоєння версії 2 CTool не могло бути й мови. Існував навіть офіційний похорон CTool, який чимось нагадував сцену виконання копію (чи це був принтер?) В Office Space .

Хтось може сказати, що Дон заслужив стропи та стрілки за те, що не змусив їх виправитись, щоб виправити CTool. Єдина моя думка: твердження, що ніколи не потрібно зламати рішення, є, мабуть, невиправданим у реальному світі. Але якщо ти будеш це робити, ступай обережно.

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

• Зробіть це видимим для користувачів. Чим помітніше це, тим менше шансів, що люди забудуть повернутися назад і робити це правильно, коли криза закінчиться.

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

Ви подаєте другу дуже описову помилку проти власного "виправлення" і ставите коментар до завдань прямо в постраждалих областях, який говорить: "Ця область потребує багато роботи. Див. Дефект № 555" (звичайно, використовуйте правильну кількість) . Люди, які говорять "не вкладайте хак", схоже, не розуміють питання. Припустимо, у вас є система, яка повинна бути запущена зараз, ваше не-хакерське рішення - це 8 днів роботи, ваш хак - 38 хвилин роботи, хакер - це для того, щоб купити час для роботи і не втратити гроші, поки ти робиш це.

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

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

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

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

Дуже ідеалістичний підхід.

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

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

Деякі рішення, які я бачив у минулому:

• Позначте це коментарем HACKу коді (або подібною схемою, такою якXXX )
• Запропонуйте автоматичний запуск звіту та щотижня надсилайте по електронній пошті тим, хто піклується, який підраховує кількість разів HACK з’являються коментарі
• Додайте новий запис до вашої системи відстеження помилок із номером рядка та описом правильного рішення (щоб знання, отримані в результаті дослідження перед написанням хаку, не були втрачені)
• написати тест, який демонструє, як зламати (якщо це можливо), і перевірити його у відповідний набір тестів (тобто, щоб він видавав помилки, які хтось з часом захоче очистити)
• як тільки хакер буде встановлений і тиск знижений, негайно починайте правильне рішення

Це відмінне запитання. Одне я помітив, коли отримую більше досвіду: хаки приносять вам дуже короткий проміжок часу і часто коштують вам величезної суми. Тісно пов’язане «швидке виправлення», яке вирішує проблему, на вашу думку, лише тоді, коли підривається, з’ясовується, що це зовсім не проблема.

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

Неприємна частина проста: нехай вона видає попередження кожного разу, коли ви виконуєте загрозу.

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

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

Спробуйте пояснити вартість хакерства для бізнесменів. Тоді вони можуть прийняти зважене рішення в будь-якому випадку.

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

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

Сповідь:

Я використовував '#define private public' в C ++ для того, щоб читати дані з якогось іншого рівня коду. Він пішов як хакерство, але працює добре, і виправлення цього ніколи не ставало пріоритетом. Зараз 3 роки потому ...

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

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

1. Тестова розробка

2. Невеликі одиниці рефакторингу

3. Постійна інтеграція
4. Хороше управління конфігурацією
5. Швидкі методи баз даних / рефакторинг баз даних

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