Какие факторы должны влиять на то, как я определяю, когда отказаться от небольшого проекта с другом? [закрыто]

Я оказался в трудном положении в последнее время. Уже почти 8 месяцев работаю над игрой с приятелем по программированию. Мы оба начинали как новички в программировании примерно в августе прошлого года, он студент 2-го курса CS, я специалист по ИТ-поддержке по профессии и программист-самоучка с множеством книг и онлайн-подписок.

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

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

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

У меня есть личный интерес к нашему проекту, однако я не уверен, смогу ли я продолжать работать с моим партнером. Кажется, у меня есть три варианта.

• Прекратите заботиться о кодовой базе, функционирующей после точки компиляции, и просто постарайтесь поддерживать и анализировать поведение, которое едва ли проявляется. Надеясь, что, как только вещи начнут серьезно ломаться, он увидит это и попытается сделать больше, чем просто нанести удар по принципиально некорректному дизайну.
• Продолжайте бесконечные споры по вопросам, которые были выяснены десять лет назад другими, гораздо более способными людьми.
• Прекратите программировать этот проект, оставив почти 10000 строк моего кода и потратив бесчисленные часы на разработку дизайна, и попробуйте найти новый проект самостоятельно.

Какой подход я могу использовать, чтобы определить, стоит ли продолжать этот проект с этим человеком? Или какие факторы должны влиять на мое решение? Мы написали много кода, и я не хочу отказываться от него без необходимости.

Отправленный, несовершенный код лучше, чем совершенный код на доске, которая никогда не доставляется.

Что, как говорится...

Те из вас, у кого больше опыта, или которые были в подобных ситуациях. Что ты сделал? Что бы вы посоветовали мне сделать?

Я хотел бы рассмотреть следующее.

• Какова цель этого проекта? Весело? Деньги? Учить?
  • Вы действительно достигли этой цели?
• Действительно ли этот человек позволяет вам лучше достичь ваших целей?
• Как близко вы на самом деле доставки?
• Эти проблемы мешают запуску? Или это вопрос личной гордости?
• Есть ли преимущества работы с кем-то на добровольной основе, когда это расстраивает?

Прекратите программировать этот проект, оставив почти 10000 строк моего кода и потратив бесчисленное количество часов на разработку дизайна, и попытайтесь найти новый проект самостоятельно.

Примите во внимание вышесказанное, попробуйте продумать дополнительную работу, необходимую

Вы должны выяснить свои приоритеты и определить, стоят ли проблемы, связанные с работой с этим человеком. Мы не можем понять это для вас.

Мой партнер потерял его сегодня вечером и дал понять, что независимо от того, что, независимо от эталона, от обычной практики, от неопровержимых доказательств, его код останется таким, каким он его первым сделал.

Вы знаете, что не хотите работать с таким человеком.

Вы делаете такой проект, предположительно, потому что вы хотите изучить программирование и найти элегантность в самом ремесле.

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

По моему опыту работы с очень умными людьми, если вы скажете им, что то, что они делают, не совсем идеально, они либо (1) дадут вам правильную и простую для понимания причину, почему то, что они делают, на самом деле правильно, (2) расскажет Вы, что они знают, что это неправильно, но у них нет времени, чтобы исправить это из-за приоритетов, или (3) спасибо, что указали на это и исправили.

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

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

С другой стороны, рабочий продукт стоит любое количество лет тонко настроенного, элегантного, ясного кода. Сделайте игру, отправьте ее, затем уходите - оставьте его, чтобы он поддерживал ее и не работал на v2.

Вот некоторые идеи, даже если некоторые из них являются взаимоисключающими.

• Отдельные источники ответственности. Если вы работаете над модулем A, а он над модулем B, вы можете соревноваться с разными стилями. Он часто выпускает рабочие функции? Достигает ли он точки, когда ему нужно переписать свой код с нуля? Рефакторинг кода из ваших модулей и не трогайте его,

• Пусть он сделает обслуживание своего худшего кода. Если он делает это успешно, вы избежали ужасной задачи. Если он не в состоянии, он почувствует боль.

• Рассмотрим это с точки зрения пользователя или бизнеса. В некоторых случаях вам нужен только жизнеспособный продукт, который может купить Google или Microsoft. В других случаях вы запускаете продукт на рынок, и поддержка тысяч клиентов с ошибочным или взломанным кодом будет адом. Не то же самое, если ваш код контролирует дронов с ядерными ракетами или делает счастливые видео для подростков.

• Он делает уроки, вы делаете тесты. Рефакторинг кода с помощью тестов проще и безопаснее. Таким образом, вам не нужно заглядывать внутрь кода только в панель Junit. Это предполагает, что A) вы программируете тесты, B) код вашего коллеги тестируемый. Если вам сложно построить тесты на этапе кодирования, последний будет хуже.

• Идите вместе на тренировки или мероприятия. Когда вы не знаете правильный путь, это вполне естественно, используйте единственный способ, которым вы знаете. Просмотр чужого кода может решить не все, но попытка не помешает.

• Найдите свои дополнительные сильные стороны. Рефакторинг иногда может быть веселым. Если он пишет вещи, которые хотя бы работают, вы можете выполнить рефакторинг. Он может делать шипы, чтобы исследовать решения, которые не заканчиваются в производственном коде.

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

• Используйте правило бойскаута . Оставляйте вещи нетронутыми, если вам не нужно над этим работать. Если модуль плохо написан, но работает и не нуждается в замене, оставьте его таким. Если вам нужно исправить ошибку или завершить функцию, немного улучшите ее. Через некоторое время 20% классов, которые вы меняете 80% времени, улучшатся. Больше островов качества.

Мы не можем предложить лучшее решение, не зная вас обоих. Удачи.

Хорошо, вот ответ, который вам, вероятно, не понравится.

Не «исправляйте» код, если он не может реализовать эту функцию.

Вот мои рассуждения. Вы, вероятно, пытаетесь заработать деньги. Чтобы заработать деньги, вы должны быстро отправить завершенные функции. Никто не заплатит вам больше за «хорошо закодированную» компьютерную игру.

У большинства компаний такая же проблема. Рефакторинг существующего кода, чтобы сделать его «лучше», иногда даже объективно лучше с точки зрения скорости или надежности ИЛИ писать новые функции.

99% времени они выбирают написание новых функций, потому что это результат простого анализа затрат и выгод.

Мне нравятся все ответы до сих пор. Взяв один из пунктов ответа Эндерланда :

Есть ли преимущества работы с кем-то на добровольной основе, когда это расстраивает?

Я хотел бы воспользоваться этим временем, чтобы подключиться к обмену стеками обзора кода . Это прекрасное место, где вы можете получить критику своего кода профессионалами. И, честно говоря, многие обзоры кода очень полезны для тех, кто в них участвует - для тех, кто спрашивает, кто отвечает, и тех, кто спотыкается и читает их. Вы редко получаете такие полезные отзывы в профессиональной обстановке (что может иметь место только в тех местах, где я работал по любой причине).

Мой совет - выложить часть кода для проверки. Я бы не советовал использовать его как боеприпасы, чтобы доказать, что этот парень не прав - я сомневаюсь, что он примет это близко к сердцу - но вы можете получить очень полезную информацию как о написанном вами коде, так и о коде, который он написал. Я бы порекомендовал представить фрагменты кода, которые вы оба сражаетесь больше всего. По всей вероятности, вы оба в какой-то степени неправы, и вы можете использовать обзор как способ заставить объективную третью сторону вмешаться. Это позволит выполнить несколько вещей:

• Вы можете отключиться от эмоциональной напряженности ситуации.

• Вы получите профессиональную консультацию в реальном времени. Большой импульс к тому, что вы изучаете.

• Кто-то скажет вам, что вы не правы. Это хорошо, потому что любой, кто занимается программированием в течение любого промежутка времени, услышит это. Вы можете справиться с этим плохо, как этот парень, с которым вы работаете, или вы можете научиться справляться с этим.

Я думаю, что если вы правильно используете рецензии кода, вы сможете получить много пользы, имея дело с этим крайне разочаровывающим человеком. И это гораздо более интерактивно, чем книга или веб-сайт, на котором написано: «Делай это, потому что в большинстве случаев это правильный путь».

Точно так же есть обмен стека разработчиков игр . Не столько место, чтобы опубликовать код для обзора, но чтобы спросить о концепциях / идеях, с которыми вы боретесь. Опять же, это место очень полезно для всех участников.

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

Это звучит довольно безнадежно. Я бы, наверное, сдался и пошел дальше, если бы чувствовал к этому то же самое, что и вы; определенно наступает время, чтобы уйти, и вы можете быть там.

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

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

приятель: это нормально, как это.

Дуглас: То есть вы говорите, что мы должны изменить правила?

приятель: нет, я просто думаю, что это нормально, как это.

Дуглас: Так, каковы рекомендации?

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

Дуглас: Какие руководящие принципы вы бы написали?

приятель: я бы не стал писать рекомендации Это пустая трата времени.

Дуглас: Значит, мы должны просто выбросить руководящие принципы и написать какую-нибудь ерунду, о которой мы думаем в то время?

приятель: это не дерьмо.

Дуглас: Это идеально? Это идеально?

приятель: он выполняет свою работу; давайте перейдем к следующей функции.

Дуглас: Есть ли что-то, с чем мы можем согласиться, что X - это хороший код, а Y - плохой код?

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

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

Дуглас: Что ты хочешь?

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

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

приятель: я горжусь своим кодом.

Дуглас: Вот функция, которой я горжусь - что вы об этом думаете?

приятель: Ну, все в порядке, но вы не должны пересчитывать X внутри цикла; это неэффективно.

Дуглас: Так вы говорите, что мы всегда должны вычислять постоянные значения вне циклов?

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

Дуглас: Как вы думаете, это должно быть в наших рекомендациях?

приятель: конечно.

Дуглас: Хорошо, я добавлю его в наши правила и обновлю свой код ...

Дуглас: Как это сейчас?

приятель: хорошо.

Теперь Бадди вносит свой вклад в руководство (хотя и косвенно), и поэтому у него есть чувство причастности. Возможно - просто возможно - он начнет относиться к ним более серьезно. Я думаю, что я был бы склонен вытереть планшет и начать все сначала с инструкций, позволяя сначала большинству или всем из них прийти от Бадди. Идите вперед и напишите код дерьма, чтобы он почувствовал необходимость добавить к руководству; пусть они исходят от него. Может быть, тогда он начнет понимать причину их.

Но если вы предпочитаете сдаться и двигаться дальше - это может быть не таким уж плохим вариантом.

Предполагая, что вы решили отказаться от проекта:

• Форк код и рефакторинг, используя его в качестве элемента портфеля «до / после»
• Поскольку целью было (в основном или частично) научиться программированию, а изучение чего-либо занимает в 2-4 раза больше времени, чем то, что вы уже знаете, эта работа на самом деле не тратится впустую.
• «Потеря вложенных затрат» (инвестиции, которые вы уже вложили в предприятие до того, как узнали, что это плохая идея), является одной из самых распространенных человеческих ошибок при принятии решений.
• Чтобы сохранить дружбу, сформулируйте свое решение как расстановку приоритетов над кодированием

ТЛ; Др, вы, вероятно, должны отказаться от проекта.

Не зная больше об этом, чем вы сказали нам, я бы предположил, что трение, которое вы испытываете, связано с опытом.

Несмотря на то, что вы не программист по профессии, как ИТ-профессионал, вы, вероятно, с трудом научились правильно делать все с первого раза, но ваша ссылка на себя в будущем указывает на то, что вы его облажали в прошлом и научились не для.

Ваш студент 2-го курса CS, даже если он достаточно одарен, вероятно, не имеет возможности сделать это (если вы, как я, неоднократно :).

Он / она никогда не поверит в ценность исправления вещей, пока вы идете, пока у него / нее не появятся ожоговые шрамы от невыполнения этого требования или его наставничество в культуре с исключительной инженерной дисциплиной или обоими.

Этот человек может быть вашим партнером по программированию, но не вашим партнером по проекту, поэтому выполнение этой игры как однорангового проекта, скорее всего, потеряно. Если вы не готовы просто съесть будущую стоимость. Может быть, отношения достаточно ценны для вас. В этом случае дайте ему / ей достаточно веревки, чтобы повеситься и вмешайтесь, чтобы помочь навести порядок, когда этот человек вынужден признать проблему.

В противном случае внесите залог и сделайте проект с пэром, или сделайте проект наставника / ученика, где это динамично с самого начала.

Чтобы добавить дополнительные очки ко всем отличным ответам:

• Сколько еще усилий потребуется для завершения проекта? Обратите внимание, что завершение «последних 10%» занимает гораздо больше времени, чем ожидают люди. Это включает в себя тестирование / настройку игры, исправление юзабилити, работу с различными целевыми платформами, выпуск, ... Если это игра для iOS, то есть подписание кода и прохождение обзора Apple. Честно говоря, отделка может занять столько же, сколько и первые «90%». И будет очень сложно, если код будет таким плохим, как вы предлагаете. (Можете ли вы начать играть в тестирование сейчас?)
• Реально, насколько вероятно, что люди будут наслаждаться вашей игрой?
• Остерегайтесь " эвристики затонувших затрат ". Оцените эти 10000 вложенных строк кода в свете общей картины, оглядываясь на готовый продукт и без излишнего оптимизма.
• Можете ли вы продолжать идти, если это займет еще 3 года? У вас двоих разные стили разработки (плохой командный матч). Звучит так, словно вы уже на пороге терпения, и если вы продолжите идти, может быть трудно оставаться друзьями.

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

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

Жалуйтесь только как пользователь, если он работает, не жалуйтесь.

Не сдавайся, важно привыкнуть к людям, которые отличаются от тебя, что случится на реальной работе.