Як боротися з тимчасовими наборами мислення?

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

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

— Ротіан
джерело

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

— Rig

Ласкаво просимо до розробки програмного забезпечення!

— янніс

@YannisRizos, ні ні ні! ;)

— Ротіан

@Rotian Це майже необхідне читання: joelonsoftware.com/articles/fog0000000332.html . Трохи застарілий, але все-таки чудовий ресурс і, мабуть, вартий як відповідь самостійно.

— К.Штефф

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

— Майкл Скотт Шаппе

Відповіді:

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

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

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

— Майкл Скотт Шаппе
джерело

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

— Ротіан

+1. Будьте тією зміною, яку ви хочете побачити у своїй команді. Встановити стандарт.

— Скотт C Вілсон

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

— Ерік Дітріх

@Rotian Не звичайне ваше середовище, звичайно, але так, я там був, і я це робив. Найгірше було в той час, я навіть зовсім не розумів, як це погано. Я лише знав, що щось глибоко не так на глибокому рівні, і врешті вирішив, що цього достатньо, щоб вийти. Лише за останні роки мені вдалося вказати на конкретні практики, якими вони повинні були (або не повинні) займатися.

— Майкл Скотт Шаппе

Нічого?

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

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

Я б запитав, чому ви робите всі ці швидкі виправлення злому? Це пов'язано з попередніми виправленнями швидкого злому? Тоді досить просто зазначити, що якщо все було зроблено «правильно», в першу чергу ...

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

— Теластин
джерело

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

— 9000

@ 9000: ОП каже, що це призначено для розкладу та управління, тому я здогадуюсь (сподіваюся), що це переважно тиск часу. Недооцінка фактичної роботи, пов'язаної з розробкою програмного забезпечення, не зовсім рідкість.

— Теластин

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

— Майкл Скотт Шаппе

@UncleMikey: Звичайно. Але якщо ваші менеджери занадто неефективні, щоб планувати речі належним чином, ви можете зробити дуже мало.

— Теластин

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

— Ротіан