«Пока это работает» - это норма? [закрыто]

23

Смотрите мой более свежий вопрос: программирование как профессия в гонке на дно?

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

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

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

По сути, мое впечатление таково: программирование сводится к следующему:

  1. Чтение некоторых книг о новейших инструментах / технологиях
  2. Объединение кода на основе этого, избегая написания какого-либо отдельного кода, потому что компания не хочет «поддерживать собственный код»
  3. Показывая это и переходя к следующему, «пока это работает».

Я всегда говорил себе, что на следующей работе я найду лучший магазин. Такого никогда не бывает. Если это так, то я чувствую себя застрявшим. Технологии всегда меняются; если единственное профессиональное развитие здесь - это чтение новейшей книги по технологиям MS Press, то что вы приобрели за 10 лет, но поверхностное знание различных технологий? Я обеспокоен:

  1. Лучший способ иметь профессиональные стандарты
  2. Как развить значимые знания и опыт в этой ситуации
Q303
источник
3
Какая это страна?
3
Неизбежная ссылка Дилберта: runningagile.files.wordpress.com/2007/11/…
nikie
5
<quote> Agile, по сути, означал, что у них вообще не было плана о том, как разрабатывать или управлять своими проектами </ quote> Это не Agile. Это не что-нибудь.
Мартин Йорк
4
@Martin York: Да, но некоторые места, кажется, называют себя Agile, когда у них нет плана или спецификации. Это все равно что играть на виолончели, не зная, где положить левые пальцы на струны, и называть это атональной музыкой.
Дэвид Торнли
2
Я думаю, что люди упускают суть вопроса. Моя точка зрения заключается в том, что динамика, которую я описал здесь, на самом деле не требует навыков и не ведет к развитию навыков разработчиков. Кажется, это ведет к развитию поверхностного уровня знаний, который не терпит. Бухгалтеры, юристы и т. Д. Приобретают опыт, который делает обучение более ценным. Учитывая динамику, которую я видел здесь, я не согласен с этим.
q303

Ответы:

8

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

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

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

c152driver
источник
2
+1 Особенно, для:remember why we're all doing this: to solve our customer's problems.
Джордж Мариан
21

>> На моей предыдущей работе у людей было отношение, пока оно работает, это нормально.

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

  • Проблемы с производительностью
  • Было найдено больше ошибок, чем в любых других частях системы
  • Разработчики проводят больше времени, работая над этой частью.
  • и т.п.
Андрей Таптунов
источник
7
+1I strongly believe that to rewrite something there should be clear evidence why do we need this
Джордж Мариан
3
+1. Большинство программистов, кажется, настолько увлечены кодом , его красотой, чистотой и т. Д., Что они не понимают, что код на самом деле является просто артефактом того, что они должны разработать. В конце концов, все, что имеет значение, это то, что это работает. Это то, о чем заботятся ваши платящие клиенты.
Joonas Pulakka
9
У меня нет проблем с вашим ответом, но такое отношение очень часто используется руководством, чтобы не соглашаться со всеми действительно вескими причинами для переписывания кода - «Это не реальная причина», и они идут дальше.
Николь
4
@ Майкл: Рефакторинг чрезвычайно важен. И так, что код работает. И это так, что это делается быстро, потому что иначе ваши конкуренты победят. Также чрезвычайно важно сделать это с ограниченными ресурсами, потому что там так мало денег и так много других дел. Есть довольно много вещей, которые чрезвычайно важны, и бизнес - это баланс между ними. Задача не из легких, но успешные, такие как Google, неизменно склоняются к позиции « быстрее что-нибудь вытащить, потом отполировать».
Joonas Pulakka
3
@Joonas Pulakka: Это полностью зависит от рынка. Для веб-сайтов быть на первом месте часто важнее, чем иметь лучший продукт, поэтому именно это сделали Google и другие. С другой стороны, если вы попытались «быстро что-то достать, потом отполировать», например, с помощью медицинского оборудования, необходимого для жизни, вы, вероятно, надолго не будете заниматься своим делом.
nikie
14

Agile не несет ответственности за решение человека выпустить ошибочное программное обеспечение; люди есть.

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

Проблема в том, что перфекционизм ведет к прокрастинации, а прокрастинация ведет к посредственности .

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

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

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

Я уверен, что, пытаясь повысить understandих ценность, вы сможете поделиться своей, и это станет началом плодотворного сотрудничества.

И если вы обнаружите, что они не знают, что делают, единственным выходом будет выход .

Джордж Мариан
источник
2
Мне особенно нравится эта строка:The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity.
Джордж Мариан
1
Пьер как Йода этого сайта!
Оз
3

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

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

Как и в случае с большинством технологических ответов ... это зависит.

Джек Маркетти
источник
2

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

Я думаю, что здесь применяется правило 80/20. По сути, вам нужно смириться с дерьмовыми 80% и пробиться к 20%. Однако осознайте, что даже им придется идти на компромиссы. В бизнесе обычно не имеет значения, что вы абсолютно правы. Это важно, что у вас есть это прямо сейчас.

Джордж Мариан
источник
2

если единственное профессиональное развитие здесь - это чтение новейшей книги по технологиям MS Press, то что вы приобрели за 10 лет, но поверхностное знание различных технологий?

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

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

JB King
источник
2

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

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

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

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

Спенсер Рупорт
источник
2
Согласен ... Нет смысла пытаться изменить чье-то мнение в месте, где вы работаете, если вы не были привлечены в качестве старшего / ведущего разработчика, где они ожидают этого от вас. Мне кажется, я работаю в том месте, где вы описали то, над которым вы впервые работали, и я собираюсь перейти с корабля на более экологичные пастбища
programmx10
То же самое; Кажется, я всегда нахожу работу с невежественными коллегами, которые в буквальном смысле неспособны сделать что-то правильно, и когда я пытаюсь объяснить лучшие способы, я просто получаю это "А?" Посмотрите или какое-то оправдание, почему они не могут этого сделать (например, у нас нет времени на рефакторинг кода, это необходимо сделать), поэтому ничего не меняется, и я расстраиваюсь, что приходится иметь дело с плохо написанными материалами.
Уэйн Молина
1

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

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

Торстен Мюллер
источник
1

Напоминает мне моего майора из колледжа. Он брал урок VLSI по дизайну и для своей первой домашней работы придумал компонент шириной порядка микрометров и длиной в милю. Моделирование прошло отлично.

Он ответил своим критикам: «Все, что я знаю, это то, что мое дерьмо работает».

работа
источник
1

Неплохая норма - принцип Парето

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

Термин «принцип Парето» может также относиться к эффективности Парето. Принцип Парето (также известный как правило 80-20, закон жизненного меньшинства и принцип разреженности факторов) гласит, что во многих случаях примерно 80% последствий происходят от 20% причин. Мыслитель по управлению бизнесом Джозеф М. Джуран предложил этот принцип и назвал его в честь итальянского экономиста Вильфредо Парето, который в 1906 году заметил, что 80% земли в Италии принадлежат 20% населения; он развил принцип, наблюдая, что 20% стручков гороха в его саду содержали 80% гороха. Это общее правило в бизнесе; Например, «80% ваших продаж приходится на 20% ваших клиентов». Математически, если что-то распределяется между достаточно большим набором участников, должно быть число k между 50 и 100, так что «k% берется (100 - k)% участников». Число k может варьироваться от 50 (в случае равного распределения, т. Е. 100% населения имеют равные доли) до почти 100 (когда крошечное число участников составляет почти весь ресурс).Нет ничего особенного в математическом числе 80%, но многие реальные системы имеют где-то около этой области промежуточный дисбаланс в распределении. Принцип Парето только косвенно связан с эффективностью Парето, который также был введен тем же экономистом. Парето разработал обе концепции в контексте распределения доходов и благосостояния среди населения.

Ссылка на источник

Амир Резаи
источник
Это здорово, но как это связано с вопросом? Вы хотите сказать, что 20% рабочих мест генерируют 80% плохого программного обеспечения?
Кирк Бродхерст
Нет, если программное обеспечение работает на 80%, это нормально. Принятый уровень ошибок составляет 20%.
Амир Резаи
0

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

Без обид, но как менеджер я прочитал это заявление где-то вроде:

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

Если вы жалуетесь на свой собственный код - вам не на чем стоять.

ОБНОВИТЬ

Я понимаю, что это POV непопулярно. Но я не думаю, что это вообще несовместимо с обязанностями и отношениями профессионального разработчика.

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

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

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

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

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

Марк Брэкетт
источник
2
Обратите внимание, что «по сути, исследуя спецификацию». Если, как менеджер, вы предоставите мне подробную спецификацию, и мне нужно будет переписать, моя вина. Если вы НЕ предоставляете спецификацию и не развиваете ее по мере написания, мне нужно будет провести рефакторинг, потому что я не буду знать все требования в предыдущих частях кода.
q303
8
Я хочу понизить этот ответ так сильно, что это больно. Но я не могу ... это действительно так, как думают менеджеры. Команда разработчиков должна выразить это с точки зрения менеджеров. Сказать «переписать», хотя вещь работает, будет вызывать реакцию Марка каждый раз. Возможно, высказывание «затвердеть» или «стабилизировать» или «закончить» будет менее резким. Менеджеры должны понимать, что они вошли в производство с неполным кодом, и им решать, хотят ли они закончить работу; разработчики должны убедить их в том, что стоит не делать этого.
Джефф Кнехт
1
@jeff - на месте! Один мудрый коллега однажды сказал мне: «Не давай им возможности сказать, все зависит от того, как ты сформулируешь вопрос».
Оз
2
Ваша позиция как менеджера работает, пока оригинальный разработчик не уйдет. Затем кто-то другой должен взять свой код, и либо а) тратит в 10 раз больше времени на работу над изменениями, чем следовало бы, либо б) производит изменения, приводящие к ужасным ошибкам. Тогда это не кодер, жалующийся на его код; это новый разработчик, жалующийся на проблемы, которые вы не смогли решить, поскольку их можно было бы легче исправить. Идея о том, что разработчики являются взаимозаменяемыми «ресурсами», является очень наивной точкой зрения.
Муравей
0

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

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

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

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

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

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

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