Які фактори повинні впливати на те, як я визначаю, коли відмовитись від невеликого проекту з другом? [зачинено]


30

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

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

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

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

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

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

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


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

25
Четвертий варіант (якщо він має дозвільну ліцензію): роздрібніть код і продовжуйте працювати самостійно.
Роберт Харві

4
Як ліцензується код? Чи можете ви розпрощатись і продовжувати роботу з кимось іншим?
Джейді

14
Як згадує @enderland у своїй відповіді, в написаному вами написанні є абсолютно масивний червоний прапор: "Мій партнер втратив його сьогодні вночі, і дав зрозуміти, що незалежно від того, що б, не залежно від еталону, незалежно від загальної практики, незалежно від того, незаперечне підтвердження, його код залишиться таким, яким він вперше це зробив ». Якщо ви можете піти від цього, зробіть це. Той, з ким справді варто попрацювати, матиме смирення визнати, що іноді вони розберуться не так.
Річард Дж. Фостер

3
Незалежно від того, що ви вирішили, 10-ти рядкових рядків коду не втрачаються: подумайте, чого ви навчилися писати; подумайте про насолоду, яку ви отримали під час кодування; і, застосувавши те, що ви дізналися на (вимушеному) третьому / четвертому / n + 1-й ітераціях, це навіть може зробити його краще, ніж у поточній версії. Крім того, якщо ви знаєте, що написати 10k рядків коду, ви можете написати 10k рядків за порівняно короткий час; Часто це знання, що писати, щоб справи працювали - це те, що займає найбільше часу.
Каспер ван ден Берг

Відповіді:


26

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

Це сумно...

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

Я б розглядав наступне.

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

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

Враховуючи сказане, спробуйте продумати необхідну додаткову роботу.

Вам потрібно розібратися у своїх пріоритетах та визначити, чи варті проблеми, пов’язані з роботою з цією людиною. Ми не можемо це зрозуміти для вас.

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

Ви знаєте, що не хочете працювати з таким типом людини.

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


1
Дякую за відповідь Я досягаю мети розважатися (коли не воювати) та вчитися. Погода будь-які гроші робити - це зовсім інша історія. Він допомагає у досягненні моїх цілей, проте я вважаю, що все-таки можу досягти їх самостійно, він допомагає в мотивації. Гра є чудовим прикладом повзучості функцій, я, чесно кажучи, не маю уявлення, коли вона може відправлятися. Мій партнер вже кілька місяців намагається просунути перехід від 2D до 3D, я відмовляюся, оскільки ми вже давно перевищили сферу нашої діяльності.
Дуглас Гаскелл

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

1
найшвидший спосіб втратити друга - це працювати з ними як рівний!

58

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

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

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


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

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

Що ж, здається, що часовий тиск не є причиною відмовлятися від змін.
gnasher729

1
Це чудова відповідь. Ви не можете змусити когось змінити свій шлях! Однак, це здається, що в проект вкладається багато часу та зусиль, як і у вас. Моя думка, можливо, він може не захотіти змінювати свій код, тому що він не розуміє так, як ви вважаєте, що це слід зробити. Або це, або він з головою, але якщо він це не розуміє, спробуйте пам’ятати, що він може розчаруватися і подумайте, що ви «розмовляєте» з ним, хоч ви це дуже добре маєте на увазі. Моя порада - спробуйте поговорити з ним, коли ви обидва до цього.
zfrisch

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

12

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

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


2
Дякую за відповідь Смішно, що ви згадуєте свій перший пункт. Він намагається знайти та залучити початківця програміста, якого він може навчити допомагати в проекті. Я могла очікувати, що це жахливо виявиться, якщо там, де двоє людей, що слідують за одним стилем, зламають і забудуть. Мені подобається другий варіант, зробіть його, відвантажте, а потім залиште. Проблема, з якою я можу зіткнутися, полягає в тому, що ми перебуваємо в дорозі, хоча і робимо ТОВ, щоб у нас було ім'я для надсилання нашої гри. Обидва користувачі матимуть 50% частку курсу. Однак я міг би просто закінчити це, а потім рухатися далі. Проект великий, це може зайняти деякий час.
Дуглас Гаскелл

20
Ви ні за яких обставин не бажаєте вступати в юридично обов'язкові ділові відносини з такою людиною.
gnasher729

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

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

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

9

Ось кілька ідей, навіть якщо деякі з них є взаємовиключними.

  • Окремі обов'язки щодо джерела. Якщо ви працюєте над Модулем A і ним над Модулем B, ви можете конкурувати з різними стилями. Він часто випускає робочі функції? Чи досягає він точки, коли йому потрібно переписати свій код з нуля? Refactor код від ваших модулів і не торкайтеся його,

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

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

  • Він робить заняття, ви робите тести. Код рефакторингу тестами простіший та безпечніший. Таким чином, вам не потрібно буде заглядати всередину коду лише на панель Junit. Це передбачає, що A) ви програмуєте тести, B) код вашого колеги перевіряється. Якщо вам важко побудувати тести під час фази кодування, остання буде гіршою.

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

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

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

  • Використовуйте правило хлопчика-розвідника . Не залишайте речі недоторканими, якщо вам не потрібно працювати над цим. Якщо модуль написаний погано, але він працює і його не потрібно змінювати, залиште його так. Якщо вам потрібно виправити помилку або доповнити функцію, трохи її вдосконаліть. Через деякий час покращиться 20% занять, які ви змінюєте 80% часу. Більше острівців якості.

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


4

Гаразд, ось відповідь, яка вам, мабуть, не сподобається.

Не «виправляйте» код, якщо він не реалізує функцію.

Ось мої міркування. Ви, мабуть, намагаєтеся заробити гроші. Щоб заробити гроші, вам доведеться швидко відправляти готові функції. Ніхто не збирається платити вам більше за «добре кодовану» комп'ютерну гру.

У більшості компаній однакові проблеми. Рефактор існуючого коду, щоб зробити його "кращим", іноді навіть об'єктивно кращим з точки зору швидкості чи надійності АБО записати нові функції.

99% часу вони вирішують написати нові функції через результат простого аналізу витрат та вигод.


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

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

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

хе, ю! але також здається, що вартість внесення змін дуже висока. У своїй відповіді я намагаюся дати мета: "ти в цьому за гроші?" відповідь, плюс мій суб'єктивний погляд на те, де лежить баланс вірогідності
Еван

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

3

Мені подобаються всі відповіді досі. Беручи один із пунктів відповіді Ендерленда :

Чи є користь працювати з кимось на громадських засадах, коли це засмучує?

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

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

  • Ви можете відключитись від емоційного напруження ситуації.

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

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

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

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

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


2

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

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

Дуглас: Я хочу змінити це, тому що X, що знаходиться тут у наших рекомендаціях.

приятель: Чудово, як це.

Дуглас: Отже, ви кажете, що ми повинні змінити правила?

приятель: Ні, я просто думаю, що це добре, як це.

Дуглас: Тож для чого вказівки?

приятель: Я не знаю - ви їх написали.

Дуглас: Які настанови ви б написали?

приятель: Я б не писав настанов. Це марна трата часу.

Дуглас: Отже, ми повинні просто відкинути настанови і написати будь-яке лайно, про яке ми думали в той час?

приятель: Це не лайно.

Дуглас: Це ідеально? Це ідеально?

приятель: це робить роботу; перейдемо до наступної функції.

Дуглас: Чи можна погодитись, що X - хороший код, а Y - поганий?

приятель: Залиш мене в спокої; Я просто хочу кодувати!

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

Дуглас: Що ти хочеш?

приятель: Я просто хочу кодувати.

Дуглас: Я теж хочу кодувати, але хочу почуватись гордим свого коду.

приятель: Я пишаюся своїм кодом.

Дуглас: Ось функція, якою я пишаюся - що ви думаєте про це?

приятель: Добре, але ви не повинні перераховувати X всередині циклу; це неефективно.

Дуглас: Отже, ви кажете, що ми повинні завжди обчислювати постійні значення за межами циклів?

приятель: Ну, да!

Дуглас: Ви вважаєте, що це повинно бути в наших рекомендаціях?

приятель: Звичайно.

Дуглас: Добре, я додам його до наших рекомендацій, і я оновлю код ...

Дуглас: Як зараз?

приятель: Чудово.

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

Але якщо ви краще відмовитеся і рухаєтесь далі - це теж не може бути поганим варіантом.


2

Припустимо, що ви вирішили відмовитися від проекту:

  • Розпакуйте код і перефактуруйте його, використовуючи його як позицію "до / після"
  • Оскільки метою було (головним чином або частково) навчитися програмуванню, а оскільки вчитися чомусь займає 2-4 рази до тих пір, як робити те, що ви вже знаєте, ця робота насправді не витрачається даремно.
  • "Притягнута вартість" (інвестиція, яку ви вже зробили в підприємстві, перш ніж дізнатися, що це була погана ідея) - одна з найпоширеніших помилок людини при прийнятті рішень.
  • Щоб зберегти дружбу, визначте своє рішення пріоритетним для дружби над кодуванням

1

tl; dr. Ви, безперечно, повинні відмовитися від проекту.

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

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

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

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

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

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


1

Щоб додати додаткові бали до всіх чудових відповідей:

  • Скільки більше зусиль буде потрібно для завершення проекту? Зауважте, що закінчення "останніх 10%" займає набагато більше часу, ніж люди очікують Це включає тестування / налаштування ігор, виправлення зручності користування, подолання різноманітних цільових платформ, випуск, ... Якщо це гра на iOS, то підписування коду та перегляд Apple. Чесно кажучи, оздоблення може зайняти стільки, скільки перші "90%". І буде дуже складно, якщо код буде таким же поганим, як ви пропонуєте. (Чи можете ви почати грати тестувати його зараз?)
  • Реально, наскільки ймовірно, що люди сподобаються вашій грі?
  • Остерігайтеся " евристичних витрат ". Оцініть, що 10 000 лінійних кодів інвестицій у світлі великої картини, озираючись на готовий продукт і без зайвого оптимізму.
  • Чи можете ви продовжувати, якщо це займе ще 3 роки? Ви маєте різні стилі розвитку (не дуже хороший матч команди). Це здається, що ви закінчилися терпінням, і якщо ви продовжуватимете, залишатись друзями може бути важко.

3
"Останні 10%" займають набагато більше часу, якщо 90% коду є сміттям :-(
gnasher729

0

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

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

Поскаржись лише як користувач, якщо він працює, не скаржись.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.