Честно говоря, вы предпочитаете ковбойское кодирование? [закрыто]

66

Большинство программистов, защищающих методологии, политически корректны, такие как Agile, Waterfall, RUP и т. Д. Некоторые из них следуют методологии, но не все. Честно говоря, если вы можете выбрать методологию, вы, безусловно, перейдете к господствующим «правильным» методологиям или предпочтете «более простую» методологию, например ковбойское программирование? Почему?

Я знаю, это зависит Пожалуйста, объясните, когда вы будете использовать тот или иной. Скажите, пожалуйста, какие преимущества вы видите в кодировании Cowboy?

Смотрите о Ковбойском кодировании в Википедии

Maniero
источник
13
Эксперимент был проведен один раз с двумя группами людей, которых попросили делать глиняные горшки в установленные сроки. Группе 1 было приказано приготовить горшок самого высокого качества, какой они могли, группе 2 сказали, что они будут измерены по весу всех произведенных горшков. Качество заключительных горшков группы 2 было выше, чем горшков группы 1. Увы, мне не удалось найти первоначальный источник этого эксперимента, но главное - «чем больше число итераций, тем лучше качество». Были ли ковбои 2 группы? Вероятно.
чеснок
3
«Ковбойское кодирование» - ужасный выбор слов, если не сказать больше. Когда используется для обозначения людей в команде, «ковбой» часто означает что-то вроде «человека, который просто делает свое дело и не заботится о том, что это значит для остальной команды». Но вопрос о значении «меньше структуры» является хорошим.
МВД
4
Я думаю, что вы должны поместить свое определение ковбойского программирования (непосредственно) в свой вопрос, так как и страница википедии, и ответчики кажутся смешанными в том, что действительно является ковбойским кодированием. Вы имеете в виду просто не использовать какую-либо методологию? Потому что многие люди думают, что ковбойское кодирование вообще не делает дизайн. По крайней мере, для меня это просто означало отсутствие формального процесса - не то, что вы сразу переходите от кодирования. Я думаю, так как вы задаете вопрос, вы должны определить его в соответствии с тем, что вы хотели знать.
n1ckp
@ n1ck: Спасибо. Некоторые люди просто прыгают в ответах, не понимая вопроса. Сейчас уже слишком поздно, изменить это может привести к аннулированию некоторых ответов. К сожалению, какой-то пользователь не получил вопрос. Ты понял.
Маньеро
Разве этот человек не использует какую-либо систему контроля версий или просто отказывается использовать компанию?
Томас

Ответы:

202

Я думаю, что почти каждый опытный программист прошел три этапа, а некоторые прошли четыре:

  1. Ковбойские кодеры или самородки почти ничего не знают о дизайне и рассматривают его как ненужную формальность. Если работать над небольшими проектами для нетехнических заинтересованных сторон, такое отношение может какое-то время служить им; он добивается цели, это впечатляет босса, заставляет программиста чувствовать себя хорошо и подтверждает идею, что он знает, что он делает (даже если он этого не делает).

  2. Архитектура Астронавты стали свидетелями неудач своих первых проектов по созданию клубка пряжи для адаптации к меняющимся обстоятельствам. Все должно быть переписано, и чтобы избежать необходимости в следующем переписывании в будущем, они создают внутренние платформы и тратят 4 часа в день на поддержку, потому что никто не понимает, как их правильно использовать.

  3. Квазиинженеры часто принимают себя за настоящих , обученных инженеров, потому что они действительно компетентны и понимают некоторые инженерные принципы. Они знают о базовых инженерных и бизнес-концепциях: риск, рентабельность инвестиций, UX, производительность, ремонтопригодность и так далее. Эти люди видят проект и документацию как континуум и обычно способны адаптировать уровень архитектуры / дизайна к требованиям проекта.

    В этот момент многие влюбляются в методологии, будь то Agile, Waterfall, RUP и т. Д. Они начинают верить в абсолютную непогрешимость и даже необходимость этих методологий, даже не осознавая, что в реальной области разработки программного обеспечения они просто инструменты , а не религии. И, к сожалению, это мешает им когда-либо дойти до финальной стадии, а именно:

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

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

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

Если вы ковбой, то вы не знаете другого пути.

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

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

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

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

Aaronaught
источник
27
Красиво сформулированный.
Брэндон
4
+1 за хороший вклад, несмотря на противоречие. Вы сказали, что квазиинженер делает осознанный выбор, когда это необходимо. Много раз опытные программисты со знаниями должны выбирать, нарушать правила, которые он знает и которым он верит из-за некоторых ограничений. Конечно, если программист чертовски хорош и быстр в своей работе, ему не нужно выбирать, но немногие профессионалы обладают таким качеством. Во всяком случае, вопрос провокационный.
Маньеро
14
Проблема в том, что слишком много людей хотят быть программистами на магнитных лентах, не будучи сначала астронавтами по архитектуре, а затем квазиинженерами, а это значит, что они всегда ковбои. Итак, я думаю, что могу указать на этот список и сказать «это похоже на карьерный рост» ... очень плохо, что типы управления считают, что AA - это вершина.
МВД
19
Я даже не знаю, где я нахожусь в этом списке: S Иногда я могу услышать о проекте и сразу узнать, как я собираюсь его построить, например 4, и тогда я перенесу серьезный паралич анализа и передумаю архитектуру, ну 2, тогда я рассматриваю YAGNI, думаю о ценности бизнеса и пытаюсь быть прагматичным, чувствую себя как «а» 3, и в итоге я создаю беспорядок как 1.
Карсон Майерс
14
Я должен дать вам -1 за то, что вы подразумеваете, что высокооплачиваемый консультант находится на уровне навыка программиста на магнитной ленте (подсказка: большинство из них не, даже близко). Но я все равно дал тебе +1.
Сокол
47

Да.

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

Я не считаю, что запланированные заранее каникулы - это надлежащие каникулы, еда, которую едят с мыслью о правильном питании, или отдых на известных тропах.

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

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

Shog9
источник
У меня проблема +1 для «старых упаковщиков закусок, моя раковина полна грязной посуды, и [самое главное] моя кровать не заправлена». Какого черта, +1, потому что острые ощущения от ковбойского кодирования и дискомфорт от неуверенности в том, что вы сможете это сделать, слишком открыты для того, чтобы тратить время на глупый UML, дизайн и спецификации. Они пишут свои спецификации из моей реализации, НИКОГДА не наоборот. :: сарказм
Крис
31

Вы совершенно правы. Этот подход «ковбойского программирования» может быстрее вывести первую версию кода, но эта экономия времени будет более чем потеряна благодаря:

  • Дополнительные ошибки
  • Требуется дополнительное время, чтобы найти ошибки, которые у вас были бы в любом случае
  • Необходимость перепроектировать ваш код, чтобы вспомнить, что вы сделали, когда вам нужно внести изменения в течение шести месяцев
  • Дополнительное время потрачено на обучение дополнительных разработчиков, которым нужно работать над вашим кодом
  • Отсутствие журнала изменений, к которому можно вернуться, когда вы вносите изменения, которые что-то ломают
  • Не имея модулей, вы можете легко использовать их в последующих проектах
  • И так далее

Как упоминал Нейл Баттерворт в своем ответе, иногда ты должен делать то, что должен. Однако, как правило, нет, набрасывать код как можно быстрее, не тратя время на контроль исходного кода, шаблоны, документацию и т. Д., - очень плохая привычка.

Хорошо для анализа ваших коллег и рассмотрения того, полезны ли они или вредны их привычки, а не слепо, как они.

Уоррен Пена
источник
6
Всегда есть исключения. Некоторые программисты могут быть гениями, иметь фотографическую память, но мало терпения. Другие не такие быстрые, но настойчивые; они решают задачу по одному байту за раз, пока она не станет их сукой. Есть много способов быть хорошим программистом. Возможно, ковбойское программирование работает для нее. Это может не сработать для спрашивающего или многих других. Однако зачем поручать, КАК кто-то должен работать, когда главное - это скорость и качество результатов. Зачем принимать закон, запрещающий 12-цилиндровые двигатели, когда вы можете просто вознаграждать более высокие мили на галлон через налоговый кредит?
Работа
@Job: я согласен. У каждого свой процесс; этот процесс обычно не успешен, но может быть. Я, например, известный пользователь Алгоритма Фейнмана , и я делаю шаг 3 как можно быстрее, пока я все еще в зоне.
Джон Перди
3
@Job - иногда бывают исключения. Проценты в конечном итоге вступят во владение. Могут быть исключения при оценке в отрыве от идеального кода (без ошибок, без проблем и т. Д.), Но в конечном итоге привычки ковбойских кодеров окажутся в ее компании (и ее команде, и ей) в заднице. Вы можете выиграть в русскую рулетку пять раз подряд, но продолжайте играть, и мои деньги на пуле.
Томас
2
@Job: Да, я вроде согласен, до определенного момента. Но отказ от рассмотрения чего-либо еще (что = отказ от обучения) и отказ от использования системы контроля версий - это два больших красных флажка, которые говорят мне: «Быть ​​быстрым, но очень опасным тупиком».
quick_now
1
Следование формальному процессу - не единственный способ написания качественного кода, и в любом случае он не гарантирует качественный код. Формальный процесс менее важен, если работа людей "слабо связана" с работой других людей. Тем не менее, контроль версий становится более важным, поскольку процесс становится более неформальным. На «отказе учиться» - сколько плохого опыта у этого человека было с плохими процессами и плохими системами в прошлом? Вывод несовершенен, но в основном это единственный способ понять что-либо за пределами наших собственных голов и с правильным (или, скорее, неправильным) опытом ...
Steve314
29

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

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

То есть они хотят просить, чтобы что-то было сделано, и чтобы кто-то запрыгнул на него, выполнил это и получил это там. Нет управления проектами, встреч, конференций или форм. Просто сделай это. У меня никогда не было клиента, который говорил: «Эй, это было сделано слишком быстро для нашего вкуса, мы будем благодарны, если в следующий раз вы добавите туда небольшой водопад или что-то в этом роде».

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

Успешные «ковбои», с которыми я работал, способны:

  • Определите самый простой способ быстро реализовать что-либо
  • Знать, в какой момент оно сломается
  • Пишите чистый, читаемый и понятный код
  • Предсказать, как пользователи будут его использовать, злоупотреблять им и ломать его
  • Масштабируйте / абстрагируйте его в нужных местах, и не переходите на него астронавтом архитектуры
  • Знать, где и как обрабатывать крайние случаи и исключения

Такие люди дают действительно отличные результаты с минимальными затратами на управление и структуру, но они редки.

Brandon
источник
9
Я действительно не назвал бы ваш окончательный список "ковбойским" кодированием. Это больше походит на типичного "программиста клейкой ленты", прославленного Спольским. Разница в том, что ковбойский кодер просто начинает объединять код, не обращая внимания на общий дизайн; «программист на клейкой ленте» вроде как придумывает, как он идет, но у него все еще есть план; он просто выполняет большую часть проектной работы на интуитивном (а иногда итеративном) уровне.
Ааронаут
3
Покупателям не обязательно нужен ковбойский стиль, они просто хотят дешево и быстро. Это зависит от нас, чтобы доставить.
@ user1249: Это напоминает мне треугольник управления проектами: дешево, быстро, хорошо - выбери два.
DanMan
Предположение о том, что клиенты являются профессиональным авторитетом , смешно. Конечно, я хочу, чтобы вещи обрабатывались в ковбойском стиле, поэтому я хочу, чтобы моя машина делалась быстро и грязно, мой дом строили новички, которые могут просто приклеивать цемент по-настенному, и моя еда должна быть приготовлена теми, кто игнорирует риск для здоровья в пользу того, что я ем раньше ...
Генри Алони
13

РЕДАКТИРОВАТЬ: Для дальнейшего использования, мой ответ для другого вопроса, который был объединен в этот. Здесь совершенно неуместно, но это был не мой звонок.


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

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

Но главное: сколько времени занимает управление версиями?
Если она не может быть убеждена в том, чтобы время от времени тратить эти 5 секунд, вы должны передать ее боссу. Контроль версий не является обязательным. Полная остановка.

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

back2dos
источник
2
Иногда правда причиняет боль простым и
ясным
+1 за то, что сказать, что совместная работа с такими эгоистичными людьми невозможна. Даже если они гениальны, ковбои не являются командными игроками; они - главное шоу, и мы - группа поддержки
Mawg
11

Это полностью зависит от того, работаю ли я в одиночку или в команде.

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

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

  • Классическая механика? Ковбой Исаак Ньютон, позже дополнения от Лейбница, Лагранжа, Гамильтона.
  • Самолет? Ковбои Райт.
  • Теория относительности? Ковбой Альберт Эйнштейн.
  • Фундаментальная наука о компьютерах? Ковбой Алан Тьюринг.
  • Транзистор? Ковбои Вальтер Браттен и Джон Бардин.

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

Joonas Pulakka
источник
Я заметил, что вы упомянули некоторые известные успехи ковбоев, когда проходили мимо гораздо более многочисленных ковбойских неудач.
Mawg
7

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

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

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

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

кодировщик
источник
9
В вашем ответе полностью пропущена наиболее значительная часть вопроса «У меня есть программист, который быстро кодирует, отказываясь от контроля версий ...». Любой, кто отклоняет контроль версий и распространяет это мнение среди младших сотрудников, является преступником.
1
@ Джаррод: или нет. Там нет никакого смысла в совершении неполного / дисфункционального кода.
Дени де Бернарди
1
@ Денис - это в основном то, для чего нужна ветка. История решений, изменений, ошибок, тупиков и т. Д. При разработке неполного / неработающего кода является IMO частью документации этого кода и очень важна при обслуживании. Более простое ветвление и слияние - это хорошая причина для замены Subversion на распределенную VCS.
Steve314
@steve: Это предполагает, что вы просматриваете журналы, прежде чем редактировать строку кода. Честно говоря, я знаю очень мало кодеров, которые на самом деле это делают ... И даже тогда (как и я ...) их гораздо меньше интересует, почему это / то было совершено, чем это, чем то, почему это было изменено. из оригинального кода.
Дени де Бернарди
@steve: для простых функций проще использовать одиночный коммит с комментарием «Добавлена ​​функция, которая вычисляет параметры ускорения», чем иметь комитеты: «Скелет PaternX», «Добавлена ​​первая строка кода», «Исправлена ​​ошибка», «Исправлена ​​другая» ошибка». Проще отслеживать глобальные изменения проекта, если меньше «шумовых» коммитов. И есть полки, которые можно использовать для неполного кода, чтобы избежать потери данных.
Кодер
6

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

Нил Баттерворт
источник
Как использовать ваш СВИНЬЯ? Какой язык для описания диалогов?
Работа
@Job Это еще не готово.
Нил Баттерворт
В вашем ответе полностью пропущена наиболее интересная часть вопроса: «У меня есть программист, который быстро кодирует , отказываясь от контроля версий ...» Я уверен, что в вашем примере они не отклонили контроль версий, управление
@Jarrod Контроль версий. Ну, у нас был RC. Управление выпуском? Это был инвестиционный банк! Вы толкаете вещи за дверь так же быстро, как пишете.
Нил Баттерворт
Добро пожаловать назад.
П Швед
5

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

Jojo
источник
2
За счет создания большого шара грязи (мой собственный ответ ;-))
Дени де Бернарди
4

Я думаю, что один из комментаторов был прав - все дело в результатах.

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

GrandmasterB
источник
4

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

Как вы заметили, сэкономленное время на проектирование, организацию и контроль теряется при отладке. И часто при поиске того, какой выпуск кода был фактически отправлен. Если вы можете найти это вообще!

Я считаю, что такие люди слишком замкнуты в себе, думают, что они слишком хороши, чтобы работать с «ограничениями», от которых должны страдать другие, и поэтому не беспокоиться о них, а это теряет еще больше времени, чем у остальных команда должна убирать за ними. Они также не слишком вовлечены в процесс исправления ошибок (это задача разработчика технического обслуживания, намного превосходящая навыки и талант программиста 1333 года).

Таким образом, это может быть общий подход в другом месте, но у меня (и я старший программист, который имеет склонности к этому подходу, хм) мы не терпим этого. Дело не в том, что нам требуется куча процессов и процедур, но мы настаиваем на минимальной организации, контроле исходного кода (что, честно говоря, чертовски восточно и чертовски полезно!)

Кент Бек и др. - все профессионалы, которые видели, что старые процессы, нагруженные процессами, были плохими сами по себе, поэтому они создали новые методологии для организации кодирования, сохраняя при этом его ориентацию на ремесло, а затем рассказали об этом всем остальным - издавая книги ( как еще ты делал это тогда до интернета?)

Похоже, у вас все правильно - не принимайте плохую практику только потому, что кто-то другой не может ее взломать Ваш лидер команды или менеджер должны сильно упасть на эту «рок-звезду», но если они не… ну, это все равно не помешает вам поступить правильно. Только не принимайте от нее дрянную практику, если она облажается (и она это сделает!), Тогда дайте ей почистить ее. Вы придерживаетесь хороших практик (и знаете, что они собой представляют), не позволяя им перейти в ущерб вашей производительности кодирования, и вы будете хороши в будущем.

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

gbjbaanb
источник
+1 К сожалению, «хакер» изменил это значение. Краткая история хакерства
Gyan aka Gary Buyn
4
Я бы сказал «взломать» вместо «хакер».
Майк Шеррилл 'Cat Recall'
2
Они ковбой, как заявил ОП, не путайте, кто такой хакер. Оставьте это СМИ.
ocodo
это может быть программист "рок-звезды" ... слишком полные эго и таланта, чтобы беспокоиться о "мелочах". Теперь, где моя ванна, полная синей миссис? Я хочу сейчас!
gbjbaanb
3

Единственный важный факт - это долгосрочные результаты работы команды.

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

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

Если команда с ковбоем не может навести порядок (документировать, отладить, интегрировать, поддерживать) в беспорядке даже после многих человеко-месяцев / лет, тогда любой прогресс, достигнутый ковбоем, не дал команде преимущество в долгосрочной перспективе.

Решите, какой, и оптимизировать состав команды.

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

hotpaw2
источник
4
Существует утверждение, что команда, включающая одного великого программиста (или более), будет давать лучшие результаты, чем команда с еще большим числом средних программистов, кодирующих со средней скоростью - до тех пор, пока великий программист не уйдет и не займет свое седло, лошадь и твой код с ними. Насколько хороши эти результаты?
Томас
Предположение не обязательно верно. Соблюдение сроков проведения конференции или другого показа вашего продукта также может быть чрезвычайно важным.
1
@ Томас: Факторы риска сокращают оба пути. Парень, финансирующий все зарплаты, может выйти из следующего раунда финансирования, когда даже взломанное доказательство концепции не появится достаточно скоро. Насколько хорошо сейчас выглядят твои медленные лошади? Все инженерные решения - азартные игры. Поместите свои фишки.
hotpaw2
@ hotpaw2 - азартная игра заключается в том, удастся ли (потенциально терминальные) расходы от кодирования ковбоя до того, как вы сможете получить финансирование. В общем, моя ставка против ковбойского кодирования (и это займет больше времени). О, вы можете победить меня 1/10 раз или даже 1/5. Но в целом год за годом, когда шансы накапливаются, ковбойские кодеры будут стоить вам дороже, чем вы.
Томас
1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - Здесь есть еще одна динамика. Кодер, который готов использовать рискованные методы, даже если они не активно используют рискованные методы, даже если эти риски не нужны, в целом собирается сделать более рискованный выбор в другом месте. То есть, их выбор против контроля над источниками свидетельствует о более рискованной модели поведения, которая в конечном итоге укусит их и их компанию. Даже в азартных играх иногда вы можете выиграть у дома, но в конечном итоге вас сбивают проценты.
Томас
3

Возможно, вы найдете понимание в моем ответе Фрэнки, вы предпочитаете ковбойское кодирование? Проблема в том, что «ковбойское кодирование» означает разные вещи для разных людей, и для неопытного глаза не сразу очевидно, какую версию вы видите.

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

Или это может быть признаком звания любителя.

Я скажу вам одну вещь: отказ от использования контроля версий или написания тестов, потому что они слишком «академичны», определенно не является «старшим» или даже дистанционно профессиональным подходом. Вы никогда и никогда не увидите, чтобы такого рода вещи совершались в крупных магазинах программного обеспечения, таких как Microsoft или Google, и, вероятно, не увидите этого в большинстве стартапов или в достаточно зрелых корпоративных командах.

Риски слишком велики. Что если ваш компьютер умрет за одну ночь? До свидания 3 года производительности. Итак, вы делаете резервные копии; что произойдет, когда вы внесете существенное изменение, поймете, что оно совершенно неверно, и вам придется отменить его? Это происходит даже с самыми опытными и талантливыми разработчиками, потому что требования неверны. Если вы не используете какой-либо контроль версий, вы просто будете крутить колеса в грязи. Я был там однажды и никогда не вернусь.

Этому просто нет оправдания - установка репозитория занимает 10 минут, а фиксация - 10 секунд. Это может составлять 1% от общего времени разработки. Тесты, если вы спешите, могут быть легко сокращены до 20-30 минут в день и при этом могут быть достаточно полезными.

Я не фанат Agile (обратите внимание на заглавную A) методологий, но иногда вам действительно нужно просто засучить рукава и начать писать этот чертов код. Я видел людей и команды с «параличом анализа», и производительность действительно получает заметный удар. Но увольнение основных инструментов нашей торговли, таких как контроль версий и тесты, действительно является решающим для меня; этот человек не принадлежит на руководящей должности.

Aaronaught
источник
2

Да, но вы должны признать, когда НЕ делать этого.

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

Я также думаю, что вы обязательно должны продумать ответ Аарона. Ковбой означает разные вещи для разных людей.

Билл
источник
2

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

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

Другими словами, есть вещи, которые вам нужно сделать в очень большом проекте, и есть вещи, которые вам нужно сделать в небольших проектах, и есть вещи, которые вы делаете в обоих.

Например, у меня не было бы больше, чем самые простые журналы для проекта, над которым я работаю сам ... Это был бы просто список дел. Если нас будет двое, я бы, вероятно, поделился этим списком, но в очень простом формате (вероятно, просто записка, хранящаяся в нашем хранилище кода). Когда у меня будет 3 или 4, я ищу какую-то систему рабочих элементов.

MIA
источник
1

Только при прототипировании очень простых функций.

Затем, когда все сделано и обдумано правильно, я угробил код и стал серьезным.

Klaim
источник
1

Однажды я сделал это на реальном проекте (в то время, когда мы назвали его «Программирование самураев», после серии набросков «Самурай портной» в Saturday Night Live), и, к моему большому изумлению, это сработало хорошо. Конечно, то, с чего я начал, было мусором, поэтому было немного риска сделать его еще хуже.

Тем не менее, я «аккуратный» в глубине души и не люблю стиль «стреляй из бедра».

С другой стороны, сильно загруженный процессом modus operandi мне тоже не по вкусу. Мне просто нравится планировать, прежде чем действовать.

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

Рэндалл Шульц
источник
2
Часто вам нужно решить проблему, чтобы понять, как ее решить ...
1

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

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

В подобных случаях, что часто является целесообразным является productizing библиотеки , чтобы сделать такие задачи , как это легко. При этом интерфейсный код часто становится настолько тривиальным, что написание (или изменение) кода для выполнения того, что вы хотите, становится проще, чем разбираться в том, как заставить законченную программу делать то, что вы хотите. Для примера рассмотрим отступ gnu с более чем 50 различными флагами, многие из которых взаимодействуют различными тонкими способами, поэтому единственными разумными вариантами являются: 1) не использовать его вообще или 2) решить, что ему нравится вместо того, чтобы пытаться получить то, что вы изначально хотели.

Джерри Гроб
источник
1

Похоже, есть два лагеря - те, кто поддерживает результаты, и те, кто поддерживает принципы. Я впадаю в последнее.

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

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

sunwukung
источник
Да, и это возможно (вероятно?) Для некоторых ковбойских кодеров, чтобы поставить не очень хороший код.
Бернард Ди
1

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

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

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

Отсутствие формального подхода к дизайну - это не «ковбойское кодирование» в моей книге (хотя и не использование контроля версий). Для этого нужно использовать опыт - чтобы сократить время, необходимое для «достаточно хорошего» решения. Помните, что вы должны решить проблемы, которые у вас есть в настоящее время, и упростить изменение кода, а не разрабатывать его для будущих сценариев, которые могут никогда не произойти. С опытом вы получаете представление о том, как сделать это очень быстро.

Эран Гальперин
источник
0

Нет никогда.

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

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

CesarGon
источник
-1: Вы также должны действовать в интересах тех, кто пишет вашу зарплату.
Джим Г.
@Jim: я пишу зарплату. Вот почему у меня есть прерогатива увольнять членов команды. Может быть, ваш голос был немного поспешным. :-)
CesarGon
Мы являемся инженерами и несем ответственность перед заказчиком и пользователями. - Иногда клиент требует быстрой даты отгрузки. Акцент: иногда быстрая дата отправки не подлежит обсуждению.
Джим Г.
@Jim: Я знаю это очень хорошо, после того, как основал три компании. Тем не менее, никакого ковбойского кодирования никогда не было, большое спасибо. Как я уже сказал, мы несем ответственность перед заказчиками и пользователями, и мне всегда удавалось сопоставить это обязательство с разумной инженерной практикой и без ковбоев.
CesarGon
0

Я не думаю, что ковбойское кодирование является старшим подходом.

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

Однако, да, есть исключения, подобные той, о которой упоминает Нил Баттерворт. И в этих ситуациях я бы предпочел, чтобы опытный старший разработчик занимался ковбойским кодированием.

Бернард Ди
источник
0

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

Разница между мной и человеком, на которого вы жалуетесь, заключается в том, что я обычно вскоре осознаю, что мог бы сделать это лучше и сделать его более понятным, и это обычно побуждает меня учиться больше и совершенствовать свои навыки (читая книги / статьи на тема). Когда я возвращаюсь к отладке некоторых из этих взломанных решений, я обычно нахожу это болью, и это еще больше способствует моему желанию научиться делать это «правильным способом». Я думаю, что этот человек, которого вы описываете, в основном застрял на инфантильном уровне саморефлексии, и это позволяет его собственному эго мешать совершенствованию своих навыков как разработчика программного обеспечения, не похоже на человека, с которым я бы хотел работать.

programmx10
источник
0

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

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

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

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

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