Каковы барьеры на пути принятия лучших практик? Как они могут быть преодолены? [закрыто]
22
Мы все видели (и большинство из нас написали) множество плохо написанного кода. Зачем? Что заставляет нас принимать плохие методы, а не хорошие?
Самый очевидный ответ (для меня) - «невежество», но я уверен, что это не единственная причина. Какие еще есть? Что мы можем сделать, чтобы преодолеть искушение написать плохой код?
По какой причине вы можете сказать сегодня, что код написан плохо, а не почему?
@ Thorbjørn: извините, я не понимаю вопрос?
Крами восстановит Монику
@ Крамиль, когда ты написал плохо написанный код, ты узнал, что он плохо написан, и если да, то почему ты так написал? Если нет, то что произошло, так как вы можете распознать это сейчас, а не раньше.
4
@Kramii, никакая «лучшая практика» никогда не может заменить рациональную, критическую мысль. Все «лучшие практики» - это не что иное, как инструменты, и слепое их использование было бы просто вредно. Глупо следовать чему-то только потому, что это считается «наилучшей практикой», не понимая причины этого. Но при таком понимании вам не понадобятся ваши «лучшие практики». Поэтому само понятие «наилучшей практики» глубоко ошибочно и по своей природе вредно.
SK-logic
Ответы:
29
Устойчивость к изменению.
Это главная причина невежества, плохого управления и т. Д.
Глава 30 Peopleware 2-е издание посвящена этой теме. И это цитаты из книги другого довольно известного консультанта, написанного чуть раньше:
И следует учитывать, что нет ничего более сложного в обращении, более сомнительного в отношении успеха или более опасного в управлении, чем поставить себя во главе введения новых заказов. Ибо у вступителя есть все те, кто извлекает выгоду из старых порядков как враги, и у него есть теплые защитники во всех тех, кто может извлечь выгоду из новых порядков.
Никколо Макиавелли: принц (1513)
Демарко и Листер продолжают излагать мантру, которую нужно помнить, прежде чем просить людей измениться:
Фундаментальный ответ на изменения не логичный, а эмоциональный.
Процесс изменений редко является прямым и плавным переходом от текущих неоптимальных условий к новому, улучшенному миру. Для любого нетривиального изменения всегда есть период беспорядка и хаоса, прежде чем прийти к новому статус-кво . Изучать новые инструменты, процессы и способы мышления сложно и требует времени. В течение этого переходного периода производительность труда падает, моральный дух страдает, люди могут жаловаться и желать, если только удастся вернуться к старым добрым способам ведения дел. Очень часто они делают, даже со всеми проблемами, потому что они чувствуют, что старые известные проблемы лучше, чем новые, неизвестные, расстраивающие и смущающие проблемы. Это сопротивление, которое нужно тактично и осторожно, но решительно преодолеть, чтобы добиться успеха.
С терпением и настойчивостью, в конечном итоге команда прибывает из Хаоса на следующий этап, Практика и интеграция. Люди, хотя и не совсем знакомые с новыми инструментами / процессами, начинают осваивать их. Могут быть положительные "ага" переживания. И постепенно команда достигает нового статус-кво.
Действительно важно понимать, что хаос является неотъемлемой, неизбежной частью процесса изменений . Без этого знания - и подготовки к нему - можно запаниковать при попадании в фазу Хаоса и принять его за новый статус-кво. Впоследствии процесс изменений прекращается, и команда возвращается в прежнее жалкое состояние, но с еще меньшей надеждой когда-либо что-либо улучшить ...
Для справки, описанные выше фазы были первоначально определены в модели изменения Сатира (названной в честь Вирджинии Сатир ).
Я думаю, что это верно для более авторитетных программистов, но я думаю, что они составляют лишь очень небольшой процент от тех, кто не программирует по наилучшей практике. Весь код, который я видел, который не соответствует передовому опыту, был взят из двух других ответов здесь - нехватка времени и наивность.
AndrewKS
1
@AndrewKS, это касается не только разработчиков, но и менеджеров, и клиентов. В хорошей команде разработчиков и процессах сроки являются реалистичными, и разработчикам не назначают задачи сверх их текущих возможностей - или по крайней мере не без надлежащего наставничества и проверки. Их неудача почти всегда является признаком того, что руководство отказывается от внедрения лучших практик.
Петер Тёрёк
Действительно хороший момент - я не думал о непрограммистах в этой ситуации до сих пор.
AndrewKS
Нежелание часто приводит к определенной лени, которая в конечном итоге порождает невежество.
С.Робинс
23
Петер Тёрёк прав, но упустил один важный и оптимистичный момент:
людям могут нравиться изменения, в которые они вовлечены, но им почти никогда не нравятся изменения, которые просто «происходят» с ними
так что включите их, позвольте им вносить идеи, позвольте им сделать ставку на это, и это не будет таким болезненным
Примечание: это относится к программированию, так как многие технически успешные программные проекты терпят неудачу, потому что пользователи отвергают их .
действительно отличный способ управлять изменениями
Newtopian
Вы должны быть осторожны с велосипедами ! Не позволяйте им вовлекаться!
Шапр
18
Время кажется большим, когда я работаю.
Например, зачем применять модульное тестирование, когда вам нужно написать больше кода, и поэтому для получения выпускаемого продукта требуется больше времени? Клиент Х хочет это сейчас! Код быстрее!
(Это явно не хорошо кончается)
Это также является результатом плохого управления и экономии, когда покупатели не берут достаточно денег, чтобы позволить себе тратить время на все правильно.
Время здесь тоже огромно. Мой начальник на самом деле сказал нам на собрании сотрудников: «Бизнес не платит за большую работу».
Джошуа Смит
@ Джошуа Смит: WFF !? Шутки в сторону? Я не удивлюсь , если они получают именно то , что они делают платить.
Стивен Эверс
2
Я часто видел подход, который мы не можем позволить себе сделать правильно. Но мы можем позволить себе тратить бесконечное время на исправление ситуации. Для консалтинговых компаний, которые оплачивают по часам, какой подход лучше?
BillThor
1
@jwenting: Чтобы поместить мой предыдущий комментарий в контекст, я выступал за юнит-тесты на собрании персонала. В настоящее время только двое из нас пишут юнит-тесты (и мы должны делать это потихоньку). Лично я не считаю юнит-тесты золотой отделкой и бриллиантовыми украшениями.
Джошуа Смит
1
@shapr: Это ужасная вещь, которую можно услышать от компании, которая занимается созданием ракет и ракет. >: P
Мистер JavaScript
11
Несмотря на массивные доказательства обратного, люди обычно являются очень рациональными существами. Причина, по которой люди не принимают лучшие практики, такие как, например, TDD, заключается в том, что они не думают, что это того стоит. Либо они думают, что практика, на самом деле, не самая лучшая; и что это на самом деле будет стоить им больше, чем спасет. Или они считают, что выгода настолько незначительна, что стоимость изменений перевесит крошечную выгоду. Суть в том, что проблема лучших практик - это проблема суть.
Если вы хотите быть агентом изменений, ваша задача - продемонстрировать, что их восприятие нижней строки неверно. Вы должны показать, что лучшая практика действительно лучшая. То, что преимущества немедленными и значительными . Вы должны показать, что кривая обучения достаточно мала, чтобы выдержать, и что по крайней мере некоторые из преимуществ начинаются немедленно.
Как вы это показываете? Приняв лучшую практику самостоятельно! Ничто не служит для того, чтобы убедить других лучше, чем ваше собственное поведение. Если вы будете следовать передовой практике и высказывать свое мнение об этом, другие увидят, что вы провели экономический анализ и приняли противоположное решение. Это заставит их пересмотреть свое решение. Они сделают это в частном порядке, и никогда не признают это сначала. Но каждый, кто увидит, что вы используете эту лучшую практику, пересмотрит свою позицию.
Это лучшее, на что вы можете надеяться. Если лучшая практика является это лучшая практика, то остальное будет следовать автоматически. О, это не будет быстро, и будет много противников. Переход будет медленным и пятнистым; и вы испытаете много разочарований. Но переход также будет неумолимым и неизбежным. Это может занять поколение, но лучшая практика будет выигрывать.
В качестве доказательства, спросите себя, когда вы в последний раз видели, как кто-то использует goto.
Это результат незнания или размышления о том, что человек знает идеальный метод. Люди не хотят писать код плохо; это скорее случай незнания лучшего. « Наивность », в отличие от « невежества », было бы лучшим словом.
Самый простой способ соответствовать хорошей практике - это признать (наиболее вероятно) лучший способ написать код, который вы только что написали, и затем стремиться узнать, каков этот «лучший способ».
+1, и не всем разработчикам дают или занимают достаточно времени, чтобы учиться или исследовать лучшие способы. для многих (менеджмент и разработчики) его откладывают до тех пор, пока он не станет препятствием, которое нельзя игнорировать. Между тем, решения не принимаются эвристически достаточно часто - для многих людей принято вместо этого принять существующее решение или рекомендацию. эта практика включает в себя случайность, приближение и обходит большую часть процесса обучения, что жизненно важно для понимания. в свою очередь, непонимание (неблагоприятно) влияет на способность делать лучший выбор.
Джастин
6
Две причины
Невежество.
Высокомерие.
Как они могут быть преодолены?
Стимулы.
До тех пор, пока менеджеры (то есть люди, покупающие навыки разработчика) не потребуют лучших практик в рамках поставки программного обеспечения, ничего не может измениться. Многие организации явно шизофреники: они обучают разработчиков различным технологиям, а затем требуют непроверенного программного обеспечения или непроверяемого дизайна. Или хуже.
Правда это: особенно смертельно невежественный + высокомерный комбо.
Sklivvz
6
Best Practice for me - это программа, написанная командой из 8 человек. У нас не было письменных требований, обзоров кода, модульных тестов, формата выпуска документов. Никакого тестирования конечного пользователя, ничего из того, что все книги говорят, что мы должны были сделать. Код был поспешным, с ошибками и просто невозможно поддерживать. Это было отменено через 3 года после выпуска, это было так плохо. Так что же было такого замечательного в этом. Через два года после первого релиза владелец компании (который финансировал застройку с помощью ипотеки в собственном доме) ушел с 30–40 миллионами долларов в заднем кармане.
Мы часто упускаем из виду тот факт, что мы (чаще всего) здесь, чтобы делать программное обеспечение, которое зарабатывает деньги для бизнеса. Компании не существуют, чтобы предоставить нам возможность разрабатывать программное обеспечение с использованием «Best Practice», они существуют, чтобы зарабатывать деньги.
Большинство «лучших практик» не улучшают прибыль. Те, которые делают, должны и будут широко приняты. Вот почему «лучшая практика» не практикуется.
Разве вы никогда не рисковали и не играли на чем-то? Время ограничено, поэтому вы заставляете его работать с намерением рефакторинга позже (в отличие от рефакторинга раньше). Это на самом деле считается хорошей практикой для некоторых людей.
В конце концов, вы обожглись достаточно раз и изменили свои пути. Подумайте обо всех «лучших практиках», которые существуют. Можете ли вы следовать за ними все время? Противоречат ли они друг другу? Вы не хотите тратить время на обработку каждого выброса.
Если я пишу плохой код, который работает, и никто никогда не смотрит на него снова, он все еще считается плохим? (Пожалуйста, давайте не будем портить философские дебаты, рассуждая о том, что такое «плохой код».)
+1 за то, что нам платят за то, что мы сначала создаем код. У нас есть дополнительная ответственность (субъективно) сделать его обслуживаемым, во-вторых. В конце концов - я не буду доплачивать садовнику за обслуживание его газонокосилки - это ему решать. Если он хорошо выполнит свою работу, и его снаряжение останется в силе, я приглашаю его обратно и снова передам ему свои дела.
Мистер JavaScript
4
IME это сочетание того, что сказали другие. Невежество («Я когда-либо использовал DataSets, зачем беспокоиться об этом LINQ?», Недостаток времени («Босс хочет, чтобы это было сделано как можно скорее, мы не можем тратить на это много времени»), отсутствие понимания («Что не так с написанием всего моего кода в коде позади?») все вносят свой вклад.
Ирония, которую я вижу, состоит в том, что как только вы начинаете идти по этому пути, вы просто погружаетесь в себя глубже. Если вы сейчас срежете углы и выбросите весь код приложения в файлы ASPX, вы никогда не сможете исправить это позже; новые вещи будут навязываться вам, что будет означать, что вы должны делать их быстро, что означает, что вам нужно просто выбросить весь код в файл ASPX (клянусь, вы это исправите однажды) и т. д. и т. д. это никогда - Завершающая спираль, потому что вы больше не можете останавливать разработку и говорите, что сначала нужно что-то исправить.
Зачастую разработчикам просто не показывают лучшую практику или, что более важно, преимущества использования лучшей практики (я начинаю прекращать использовать термин «лучшие практики» по разным причинам).
Существует теория, что разработчики «намеренно ленивы». Другими словами, они будут склонны выбирать путь наименьшего сопротивления.
Как только вы быстро продемонстрируете им преимущества лучшей практики (например, TDD или, скажем, следования принципам SOLID) и того, что она фактически позволяет им быть лучшим (но все еще «ленивым») разработчиком, вы обнаружите, что сопротивление тает прочь.
Я изучил программирование за короткую сессию (от 2 до 3 часов). (На самом деле несколько сессий на разных языках.) Во время сессий был показан очень хороший код, и была объяснена причина написания кода. Ни один из моих «официальных» языковых курсов никогда не подходил близко к введению хорошего кода.
BillThor
«Наименьшее сопротивление» довольно описательно. Опытные программисты просто лучше понимают, что означает «наименьшее сопротивление» в течение всего срока службы приложения.
4
(Недостаток) Знания и навыки + Время инвестировать
Я удивлен, что никто другой не выпустил это, но, может быть, это очевидно для меня, потому что большая часть моей работы была как программист-одиночка, и некому было заняться (кроме стека), когда я борюсь за что-то. Я знаю «лучшие» методы, такие как TDD, но часто я не понимаю их достаточно хорошо, чтобы использовать их, и мне трудно найти хорошую информацию, которая поможет мне начать их использовать. Опять же, используя TDD в качестве примера, я понимаю его основной смысл - строить тесты, которые утверждают, что ваш код выводит конкретный результат - но на самом деле его реализуете?
Кроме того, что в наши дни XCode имеет встроенное модульное тестирование, я понятия не имею, с чего начать. Утверждаю ли я, что в представлении есть кнопки X после запуска процедуры их создания? Как насчет того, чтобы утверждать, что мои UIViews были правильно переставлены после того, как я вызвал тэг rotate?
Черт возьми, как мне написать модульный тест в XCode? Это то, что мне нужно, чтобы потратить время на обучение.
Да, я согласен, что время и бюджет - это некоторые ограничения, которые не позволяют вам внедрить каждый принцип «лучшего программирования», который вы знаете, в программу.
Вы знаете, что текущая задача может быть выполнена гораздо более надежным способом, если бы у вас было больше времени. Но очень немногие клиенты (особенно если они готовят свое первое приложение для iPhone или свое первое программное обеспечение для бизнес-аналитики) понимают, когда вы говорите, что повторно внедряете что-то уже сделанное, потому что вы нашли лучший способ сделать это.
То же самое для модульных тестов. К сожалению, мне еще предстоит встретить клиента, который готов выделить на это бюджет. Типичный ответ: «Автоматическое регрессионное тестирование. Хорошо, я понимаю, но юнит-тесты? У нас нет времени на это! Мы должны сделать это быстро на рынок! »
Я никогда не прошу клиентов выделять время для модульного тестирования, но считаю, что это часть работы. Привлечение клиентов к участию в модульных тестах просто стимулирует ваших клиентов к микроуправлению вашей работой. Когда вы ремонтируете свой автомобиль, механики не спрашивают вас, какие инструменты он должен использовать, чтобы выполнить работу !! То же самое касается модульных тестов, вы должны оценить правильный баланс тестов, который, по вашему мнению, необходим для правильного выполнения работы.
Newtopian
К сожалению, лучшие методы программирования могут быть быстрее, чем методы, которые вы не можете позволить себе улучшить.
BillThor
2
Две части в большинстве из моего опыта:
время
получить достаточно людей, чтобы договориться о том, какие методы лучше всего подходят для текущей ситуации
«Лучшие практики» ОЧЕНЬ субъективны во многих реальных ситуациях. Если одна половина команды пытается выполнить кучу SOLID & TDD, в то время как другая половина работает по 60 часов в неделю, чтобы отсрочить время бега здесь и там любыми необходимыми средствами, потому что вы прошли точку, когда уже слишком поздно перепроектируйте что-то, что не будет выполнено вовремя для вашего следующего выпуска, вы не собираетесь продвигаться очень далеко.
Даже если вы не испытываете особых разногласий в команде, вам нужно приложить немало усилий, чтобы получить официальное соглашение, документацию и обучение по любой политике, которую вы решите придерживаться. Это большой блок непроизводительного времени с точки зрения бизнеса, который вы должны будете тщательно обосновать.
Иногда вы обнаружите, что привычка также вносит основной вклад в написание ужасного кода.
Вы можете быть очень опытным программистом и знать все о лучших отраслевых практиках. Черт, вы могли бы даже быть экспертом о таких вещах. Опыт подсказывает мне, что такие люди не часто пишут ужасный код, и все же может быть легко вернуться к старым привычкам и сделать то, что, как вы знаете, нарушит правила, просто потому, что это кажется безопасным и удобным. В таких случаях невежество и высокомерие и все другие прилагательные, которые вы можете придумать, не имеют большого значения. Не обязательно, что такие программисты особенно плохи в том, что они делают (хотя это чаще всего так), или даже в том, что они хотят создавать ужасный беспорядок.
К сожалению, я лично был свидетелем того, как это происходило чаще, чем я хотел бы сосчитать, когда некоторые по-настоящему талантливые люди выпускали чистый мусор, потому что их пальцы и мозг работали на автомобиле в течение нескольких месяцев. Чаще всего это место, где вы видите признаки выгорания, горя и накопления стресса. Иногда это просто слепая привычка переносить их через ежедневные движения. Это то, чему я научился внимательно следить за тем, чтобы не рисковать ненужной маркировкой уязвимых людей.
Просто пища для размышлений для тех из нас, кому легче просто сделать негативный вывод ... хотя, к сожалению, вы будете правы чаще, чем нет.
Никто не проявляет интереса к оплате проекта под названием «Рефакторинг». У него должны быть некоторые слова, которые обращаются к бизнес-интересам. Такие слова, как модернизация, восстановление сил, полная переделка, обновление жизненного цикла и т. Д. Работают на моем рабочем месте. Практически во всех из них рефакторинг является основной частью проекта.
К сожалению, благодаря экономическому киллеру, работа происходит только тогда, когда есть оплата. Даже если работа заключается только в том, чтобы спасти бизнес в долгосрочной перспективе.
Ответы:
Устойчивость к изменению.
Это главная причина невежества, плохого управления и т. Д.
Глава 30 Peopleware 2-е издание посвящена этой теме. И это цитаты из книги другого довольно известного консультанта, написанного чуть раньше:
Демарко и Листер продолжают излагать мантру, которую нужно помнить, прежде чем просить людей измениться:
Процесс изменений редко является прямым и плавным переходом от текущих неоптимальных условий к новому, улучшенному миру. Для любого нетривиального изменения всегда есть период беспорядка и хаоса, прежде чем прийти к новому статус-кво . Изучать новые инструменты, процессы и способы мышления сложно и требует времени. В течение этого переходного периода производительность труда падает, моральный дух страдает, люди могут жаловаться и желать, если только удастся вернуться к старым добрым способам ведения дел. Очень часто они делают, даже со всеми проблемами, потому что они чувствуют, что старые известные проблемы лучше, чем новые, неизвестные, расстраивающие и смущающие проблемы. Это сопротивление, которое нужно тактично и осторожно, но решительно преодолеть, чтобы добиться успеха.
С терпением и настойчивостью, в конечном итоге команда прибывает из Хаоса на следующий этап, Практика и интеграция. Люди, хотя и не совсем знакомые с новыми инструментами / процессами, начинают осваивать их. Могут быть положительные "ага" переживания. И постепенно команда достигает нового статус-кво.
Действительно важно понимать, что хаос является неотъемлемой, неизбежной частью процесса изменений . Без этого знания - и подготовки к нему - можно запаниковать при попадании в фазу Хаоса и принять его за новый статус-кво. Впоследствии процесс изменений прекращается, и команда возвращается в прежнее жалкое состояние, но с еще меньшей надеждой когда-либо что-либо улучшить ...
Для справки, описанные выше фазы были первоначально определены в модели изменения Сатира (названной в честь Вирджинии Сатир ).
источник
Петер Тёрёк прав, но упустил один важный и оптимистичный момент:
так что включите их, позвольте им вносить идеи, позвольте им сделать ставку на это, и это не будет таким болезненным
Примечание: это относится к программированию, так как многие технически успешные программные проекты терпят неудачу, потому что пользователи отвергают их .
источник
Время кажется большим, когда я работаю.
Например, зачем применять модульное тестирование, когда вам нужно написать больше кода, и поэтому для получения выпускаемого продукта требуется больше времени? Клиент Х хочет это сейчас! Код быстрее!
(Это явно не хорошо кончается)
Это также является результатом плохого управления и экономии, когда покупатели не берут достаточно денег, чтобы позволить себе тратить время на все правильно.
источник
Несмотря на массивные доказательства обратного, люди обычно являются очень рациональными существами. Причина, по которой люди не принимают лучшие практики, такие как, например, TDD, заключается в том, что они не думают, что это того стоит. Либо они думают, что практика, на самом деле, не самая лучшая; и что это на самом деле будет стоить им больше, чем спасет. Или они считают, что выгода настолько незначительна, что стоимость изменений перевесит крошечную выгоду. Суть в том, что проблема лучших практик - это проблема суть.
Если вы хотите быть агентом изменений, ваша задача - продемонстрировать, что их восприятие нижней строки неверно. Вы должны показать, что лучшая практика действительно лучшая. То, что преимущества немедленными и значительными . Вы должны показать, что кривая обучения достаточно мала, чтобы выдержать, и что по крайней мере некоторые из преимуществ начинаются немедленно.
Как вы это показываете? Приняв лучшую практику самостоятельно! Ничто не служит для того, чтобы убедить других лучше, чем ваше собственное поведение. Если вы будете следовать передовой практике и высказывать свое мнение об этом, другие увидят, что вы провели экономический анализ и приняли противоположное решение. Это заставит их пересмотреть свое решение. Они сделают это в частном порядке, и никогда не признают это сначала. Но каждый, кто увидит, что вы используете эту лучшую практику, пересмотрит свою позицию.
Это лучшее, на что вы можете надеяться. Если лучшая практика является это лучшая практика, то остальное будет следовать автоматически. О, это не будет быстро, и будет много противников. Переход будет медленным и пятнистым; и вы испытаете много разочарований. Но переход также будет неумолимым и неизбежным. Это может занять поколение, но лучшая практика будет выигрывать.
В качестве доказательства, спросите себя, когда вы в последний раз видели, как кто-то использует goto.
источник
Это результат незнания или размышления о том, что человек знает идеальный метод. Люди не хотят писать код плохо; это скорее случай незнания лучшего. « Наивность », в отличие от « невежества », было бы лучшим словом.
Самый простой способ соответствовать хорошей практике - это признать (наиболее вероятно) лучший способ написать код, который вы только что написали, и затем стремиться узнать, каков этот «лучший способ».
источник
Две причины
Невежество.
Высокомерие.
Как они могут быть преодолены?
До тех пор, пока менеджеры (то есть люди, покупающие навыки разработчика) не потребуют лучших практик в рамках поставки программного обеспечения, ничего не может измениться. Многие организации явно шизофреники: они обучают разработчиков различным технологиям, а затем требуют непроверенного программного обеспечения или непроверяемого дизайна. Или хуже.
источник
Best Practice for me - это программа, написанная командой из 8 человек. У нас не было письменных требований, обзоров кода, модульных тестов, формата выпуска документов. Никакого тестирования конечного пользователя, ничего из того, что все книги говорят, что мы должны были сделать. Код был поспешным, с ошибками и просто невозможно поддерживать. Это было отменено через 3 года после выпуска, это было так плохо. Так что же было такого замечательного в этом. Через два года после первого релиза владелец компании (который финансировал застройку с помощью ипотеки в собственном доме) ушел с 30–40 миллионами долларов в заднем кармане.
Мы часто упускаем из виду тот факт, что мы (чаще всего) здесь, чтобы делать программное обеспечение, которое зарабатывает деньги для бизнеса. Компании не существуют, чтобы предоставить нам возможность разрабатывать программное обеспечение с использованием «Best Practice», они существуют, чтобы зарабатывать деньги.
Большинство «лучших практик» не улучшают прибыль. Те, которые делают, должны и будут широко приняты. Вот почему «лучшая практика» не практикуется.
источник
Приемлемый риск
Разве вы никогда не рисковали и не играли на чем-то? Время ограничено, поэтому вы заставляете его работать с намерением рефакторинга позже (в отличие от рефакторинга раньше). Это на самом деле считается хорошей практикой для некоторых людей.
В конце концов, вы обожглись достаточно раз и изменили свои пути. Подумайте обо всех «лучших практиках», которые существуют. Можете ли вы следовать за ними все время? Противоречат ли они друг другу? Вы не хотите тратить время на обработку каждого выброса.
Если я пишу плохой код, который работает, и никто никогда не смотрит на него снова, он все еще считается плохим? (Пожалуйста, давайте не будем портить философские дебаты, рассуждая о том, что такое «плохой код».)
источник
IME это сочетание того, что сказали другие. Невежество («Я когда-либо использовал DataSets, зачем беспокоиться об этом LINQ?», Недостаток времени («Босс хочет, чтобы это было сделано как можно скорее, мы не можем тратить на это много времени»), отсутствие понимания («Что не так с написанием всего моего кода в коде позади?») все вносят свой вклад.
Ирония, которую я вижу, состоит в том, что как только вы начинаете идти по этому пути, вы просто погружаетесь в себя глубже. Если вы сейчас срежете углы и выбросите весь код приложения в файлы ASPX, вы никогда не сможете исправить это позже; новые вещи будут навязываться вам, что будет означать, что вы должны делать их быстро, что означает, что вам нужно просто выбросить весь код в файл ASPX (клянусь, вы это исправите однажды) и т. д. и т. д. это никогда - Завершающая спираль, потому что вы больше не можете останавливать разработку и говорите, что сначала нужно что-то исправить.
источник
Зачастую разработчикам просто не показывают лучшую практику или, что более важно, преимущества использования лучшей практики (я начинаю прекращать использовать термин «лучшие практики» по разным причинам).
Существует теория, что разработчики «намеренно ленивы». Другими словами, они будут склонны выбирать путь наименьшего сопротивления.
Как только вы быстро продемонстрируете им преимущества лучшей практики (например, TDD или, скажем, следования принципам SOLID) и того, что она фактически позволяет им быть лучшим (но все еще «ленивым») разработчиком, вы обнаружите, что сопротивление тает прочь.
Это вопрос образования :)
источник
(Недостаток) Знания и навыки + Время инвестировать
Я удивлен, что никто другой не выпустил это, но, может быть, это очевидно для меня, потому что большая часть моей работы была как программист-одиночка, и некому было заняться (кроме стека), когда я борюсь за что-то. Я знаю «лучшие» методы, такие как TDD, но часто я не понимаю их достаточно хорошо, чтобы использовать их, и мне трудно найти хорошую информацию, которая поможет мне начать их использовать. Опять же, используя TDD в качестве примера, я понимаю его основной смысл - строить тесты, которые утверждают, что ваш код выводит конкретный результат - но на самом деле его реализуете?
Кроме того, что в наши дни XCode имеет встроенное модульное тестирование, я понятия не имею, с чего начать. Утверждаю ли я, что в представлении есть кнопки X после запуска процедуры их создания? Как насчет того, чтобы утверждать, что мои UIViews были правильно переставлены после того, как я вызвал тэг rotate?
Черт возьми, как мне написать модульный тест в XCode? Это то, что мне нужно, чтобы потратить время на обучение.
источник
@ Zues и @ Джошуа Смит
Да, я согласен, что время и бюджет - это некоторые ограничения, которые не позволяют вам внедрить каждый принцип «лучшего программирования», который вы знаете, в программу.
Вы знаете, что текущая задача может быть выполнена гораздо более надежным способом, если бы у вас было больше времени. Но очень немногие клиенты (особенно если они готовят свое первое приложение для iPhone или свое первое программное обеспечение для бизнес-аналитики) понимают, когда вы говорите, что повторно внедряете что-то уже сделанное, потому что вы нашли лучший способ сделать это.
То же самое для модульных тестов. К сожалению, мне еще предстоит встретить клиента, который готов выделить на это бюджет. Типичный ответ: «Автоматическое регрессионное тестирование. Хорошо, я понимаю, но юнит-тесты? У нас нет времени на это! Мы должны сделать это быстро на рынок! »
источник
Две части в большинстве из моего опыта:
«Лучшие практики» ОЧЕНЬ субъективны во многих реальных ситуациях. Если одна половина команды пытается выполнить кучу SOLID & TDD, в то время как другая половина работает по 60 часов в неделю, чтобы отсрочить время бега здесь и там любыми необходимыми средствами, потому что вы прошли точку, когда уже слишком поздно перепроектируйте что-то, что не будет выполнено вовремя для вашего следующего выпуска, вы не собираетесь продвигаться очень далеко.
Даже если вы не испытываете особых разногласий в команде, вам нужно приложить немало усилий, чтобы получить официальное соглашение, документацию и обучение по любой политике, которую вы решите придерживаться. Это большой блок непроизводительного времени с точки зрения бизнеса, который вы должны будете тщательно обосновать.
источник
Иногда вы обнаружите, что привычка также вносит основной вклад в написание ужасного кода.
Вы можете быть очень опытным программистом и знать все о лучших отраслевых практиках. Черт, вы могли бы даже быть экспертом о таких вещах. Опыт подсказывает мне, что такие люди не часто пишут ужасный код, и все же может быть легко вернуться к старым привычкам и сделать то, что, как вы знаете, нарушит правила, просто потому, что это кажется безопасным и удобным. В таких случаях невежество и высокомерие и все другие прилагательные, которые вы можете придумать, не имеют большого значения. Не обязательно, что такие программисты особенно плохи в том, что они делают (хотя это чаще всего так), или даже в том, что они хотят создавать ужасный беспорядок.
К сожалению, я лично был свидетелем того, как это происходило чаще, чем я хотел бы сосчитать, когда некоторые по-настоящему талантливые люди выпускали чистый мусор, потому что их пальцы и мозг работали на автомобиле в течение нескольких месяцев. Чаще всего это место, где вы видите признаки выгорания, горя и накопления стресса. Иногда это просто слепая привычка переносить их через ежедневные движения. Это то, чему я научился внимательно следить за тем, чтобы не рисковать ненужной маркировкой уязвимых людей.
Просто пища для размышлений для тех из нас, кому легче просто сделать негативный вывод ... хотя, к сожалению, вы будете правы чаще, чем нет.
источник
Никто не проявляет интереса к оплате проекта под названием «Рефакторинг». У него должны быть некоторые слова, которые обращаются к бизнес-интересам. Такие слова, как модернизация, восстановление сил, полная переделка, обновление жизненного цикла и т. Д. Работают на моем рабочем месте. Практически во всех из них рефакторинг является основной частью проекта.
К сожалению, благодаря экономическому киллеру, работа происходит только тогда, когда есть оплата. Даже если работа заключается только в том, чтобы спасти бизнес в долгосрочной перспективе.
источник