Чесно кажучи, ви віддаєте перевагу ковбойському кодуванню? [зачинено]

Більшість програмістів, які захищають методології політично коректні, такі як Agile, Waterfall, RUP тощо. Деякі з них дотримуються методології, але не всі вони. Відверто кажучи, якщо ви можете обрати методологію, ви, звичайно, переходите до основних "правильних" методологій або віддаєте перевагу "простішій" методології, як ковбойське програмування? Чому?

Я знаю, це залежить. Поясніть, будь ласка, коли б ви використовували те чи інше. Скажіть, будь ласка, які переваги ви бачите в кодуванні ковбоя.

Дивіться про кодування ковбоя у Вікіпедії

Я думаю, що майже кожен досвідчений програміст пройшов три етапи, а деякі пройшли чотири:

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

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

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

   У цей момент багато хто закохується в методології, будь то Agile, Waterfall, RUP тощо. Вони починають вірити в абсолютну непогрішність і навіть необхідність цих методологій, не усвідомлюючи, що у власне інженерній галузі програмного забезпечення вони просто інструменти , а не релігії. І, на жаль, це заважає їм будь-коли дійти до фінальної стадії, а саме:

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

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

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

Якщо ви ковбойський кодер, то іншого шляху ви не знаєте.

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

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

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

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

Так.

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

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

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

... але більшість часу це просто безвідповідально. Коли танець закінчиться, пайпер заплатить ... Забудьте це за свою небезпеку.

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

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

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

Добре для вас, що ви аналізуєте своїх колег та розглядаєте, чи є їх звички корисними чи шкідливими, а не сліпо робити так, як вони.

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

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

Тобто вони хочуть вимагати, щоб щось було зроблено, а хтось стрибав на нього, виконував це і виймав там. Немає управління проектами, зустрічей, конференц-дзвінків або форм. Просто зроби це. У мене ніколи не було замовника сказати: "Ей, це було зроблено трохи занадто швидко для наших смаків. Ми будемо вдячні, якщо ви наступного разу покладете трохи водоспаду".

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

Успішні "ковбої", з якими я працював, здатні:

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

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

EDIT: Для подальшого ознайомлення моя відповідь - це ще одне питання, яке було об'єднано в це. Тут це зовсім не так, але це був не мій дзвінок.

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

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

Але головний момент: скільки часу займає контроль версій?
Якщо вона не може бути переконана вкладати п'ять секунд раз у раз, ви повинні взяти це до свого начальника. Контроль версій не є обов'язковим. Повна зупинка.

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

Це повністю залежить від того, працюю я сольно, або в команді.

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

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

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

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

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

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

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

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

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

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

Я думаю, хтось із коментаторів мав це правильно - все це стосується результатів.

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

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

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

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

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

Кент Бек та ін., Всі професіонали, які бачили, що старі способи, пов'язані з процесом, були погані самі по собі, тому вони створили нові методики для організації кодування, зберігаючи при цьому більш орієнтовані на ремесло, а потім розповіли всім іншим про це - публікуючи книги ( як ще ти це робив тоді ще до Інтернету?)

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

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

Єдиний важливий факт - це довгострокові результати роботи команди.

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

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

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

Вирішіть, який, та оптимізуйте реєстр команд.

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

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

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

Або це може бути ознакою рангового аматора.

Скажу вам одне: відмовлятися від контролю версій або писати тести, оскільки вони занадто "академічні", це, безумовно, не "старший" або навіть віддалений професійний підхід. Ви ніколи не побачите подібних речей, які робляться у великих магазинах програмного забезпечення, таких як Microsoft чи Google, і, ймовірно, не побачите його також у більшості стартапів чи досить зрілих корпоративних команд.

Ризики занадто великі. Що робити, якщо ваш ПК помре за ніч? До побачення 3 роки продуктивності. Гаразд, значить, ви робите резервні копії; то що відбувається, коли ви зробите серйозні зміни, усвідомлюєте, що це було зовсім неправильно, і вам доведеться його повернути? Це трапляється навіть з найдосвідченішими та талановитішими розробниками, оскільки вимоги неправильні. Якщо ви не керуєте будь-яким контролем версій, ви просто збираєтеся крутити колеса в грязі. Я колись був там, і ніколи не повернусь.

Просто немає виправдання - потрібно 10 хвилин, щоб створити сховище, і 10 секунд, щоб зробити фіксацію. Він складає, можливо, 1% від загального часу вашої розробки. Тести, якщо ви поспішаєте, можна легко знизити до 20-30 хвилин на день і все ще бути корисними.

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

Так, але ви повинні визнати, коли НЕ робити цього.

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

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

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

Принципово, коли я думаю про "Agile", я думаю, що "ви робите те, що вам потрібно зробити, щоб мінімізувати неефективність, яку запровадили кілька людей, що працюють разом". Тож я твердо перебуваю в таборі, що "не існує такого поняття, як " Agile Methodology " , просто набір цінностей та принципів".

Іншими словами, є речі, які потрібно зробити у дуже великому проекті, і є речі, які вам потрібно зробити на малих проектах, і є речі, які ви робите на обох.

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

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

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

Я робив це колись на реальному проекті (у той час, коли ми його називали програмою «Самурайське програмування», після серії ескізів «Самурайський кравець» у суботу ввечері), і, на мій подив, це добре вийшло. Звичайно, з чого я починав, це сміття, тому було мало ризику зробити його гіршим.

Однак я "прихильний" по душі і не люблю стиль розстрілу зі стегна.

З іншого боку, сильно навантажений режим роботи також не на мій смак. Мені просто подобається планувати, перш ніж діяти.

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

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

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

У подібних випадках, що часто є доцільним є productizing бібліотеки , щоб зробити такі завдання , як це легко. З цим часто передній код стає настільки тривіальним, що писати (або змінювати) код, щоб зробити те, що ви хочете, стає простіше, ніж розбирати, як отримати повну програму, щоб робити те, що ви хочете. Розглянемо, для прикладу, gnu відступ з 50+ різними прапорами, багато з яких взаємодіють різними тонкими способами, тому єдиним розумним вибором є 1) не використовувати його взагалі або 2) вирішити, що подобається, що він дає тобі замість того, щоб намагатися отримати те, що ви спочатку хотіли.

Здається, два табори - ті, хто підтримує результати, і ті, хто підтримує принципи. Я впадаю в останню.

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

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

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

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

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

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

Ні ніколи.

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

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

Я не вважаю, що кодування ковбоя - це підхід старшого віку.

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

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

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

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

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

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

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

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

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