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

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

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

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

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

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

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

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

1. Лучший способ иметь профессиональные стандарты
2. Как развить значимые знания и опыт в этой ситуации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОБНОВИТЬ

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

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

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

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

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

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

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

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

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

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

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