Каковы барьеры на пути принятия лучших практик? Как они могут быть преодолены? [закрыто]

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

Самый очевидный ответ (для меня) - «невежество», но я уверен, что это не единственная причина. Какие еще есть? Что мы можем сделать, чтобы преодолеть искушение написать плохой код?

Устойчивость к изменению.

Это главная причина невежества, плохого управления и т. Д.

Глава 30 Peopleware 2-е издание посвящена этой теме. И это цитаты из книги другого довольно известного консультанта, написанного чуть раньше:

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

Никколо Макиавелли: принц (1513)

Демарко и Листер продолжают излагать мантру, которую нужно помнить, прежде чем просить людей измениться:

Фундаментальный ответ на изменения не логичный, а эмоциональный.

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

С терпением и настойчивостью, в конечном итоге команда прибывает из Хаоса на следующий этап, Практика и интеграция. Люди, хотя и не совсем знакомые с новыми инструментами / процессами, начинают осваивать их. Могут быть положительные "ага" переживания. И постепенно команда достигает нового статус-кво.

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

Для справки, описанные выше фазы были первоначально определены в модели изменения Сатира (названной в честь Вирджинии Сатир ).

Петер Тёрёк прав, но упустил один важный и оптимистичный момент:

• людям могут нравиться изменения, в которые они вовлечены, но им почти никогда не нравятся изменения, которые просто «происходят» с ними

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

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

Время кажется большим, когда я работаю.

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

(Это явно не хорошо кончается)

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

Несмотря на массивные доказательства обратного, люди обычно являются очень рациональными существами. Причина, по которой люди не принимают лучшие практики, такие как, например, 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 часов в неделю, чтобы отсрочить время бега здесь и там любыми необходимыми средствами, потому что вы прошли точку, когда уже слишком поздно перепроектируйте что-то, что не будет выполнено вовремя для вашего следующего выпуска, вы не собираетесь продвигаться очень далеко.

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

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

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

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

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

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

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