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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет никогда.

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

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

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

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

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

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

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

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

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

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

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

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