Неудобный в сопровождении код позади к нетехническому

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

Почему нетехническому человеку это нужно знать? Поскольку «стиль кода» на самом деле является техническим вопросом, вы не сможете объяснить его, не объяснив некоторые технические детали, стоящие за ним.

Вероятно, самое простое объяснение, которое я могу придумать (но оно не охватывает всех причин, по которым это плохая практика, как раз то, что я считаю наиболее частой причиной):

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

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

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

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

С картинками и рассказами :)

Чтобы не быть слишком бойким, но создайте сценарий на белой доске, где есть простая часть бизнес-функций (изменение пароля пользователя). Изобразите графически, как это выглядит. Теперь разверните его так, чтобы в двух формах нужно было изменить пароль пользователя (admin и user). Двойной код! Объясните DRY. Измените правила сложности пароля, и теперь нам нужно двойное исправление. Реорганизуйте блоки, чтобы переместить код в общую область в том же проекте.

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

Прополощите и повторяйте, пока он не утонет.

Расскажите своим менеджерам о техническом долге (и также здесь )

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

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

ConcernedOfTunbridgeW хорошо объясняет это тем, что руководство хочет услышать. Суть в том, что если сейчас у него есть проблемы, вероятно, это из-за избыточности логики кода. Рефакторинг, который вы хотите провести, устранит это. В конечном итоге это будет стоить немного дороже, но в долгосрочной перспективе позволит сэкономить деньги на техническом обслуживании.

Экономика

3/4 общих затрат жизненного цикла типичного программного приложения составляет обслуживание. Экономя на 1/4 части впереди, вы загружаете 3/4.

Достаточно сэкономить на разработке, и 3/4 станет 19/20. Сделайте это правильно, и ваш проект стоимостью 100 000 долларов будет стоить 400 000 долларов за все время его существования. Пропустите TLC заранее, и вы сэкономите 20 000 долларов, но ваш проект стоит 2 миллиона долларов в течение всего срока его службы.

Если на встрече присутствует финансовый директор, вы можете оставить комментарий примерно следующего содержания:

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

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

Я должен спросить, как и любой другой - почему?

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

Но если это действительно проблема, сосредоточьтесь на том, что волнует нетехнических людей - ОШИБКИ. Они не заботятся о том, чтобы сделать код элегантным или иметь хорошие шаблоны проектирования и т. Д. Все дело в том, работает что-то или нет.

Скажите что-нибудь вроде этого:

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

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

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

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

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

По крайней мере, в этих терминах у вас не будет успеха, объяснив это человеку, не имеющему технических знаний. Это слишком технический момент.

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

На самом деле речь идет о разделении бизнес-уровня (как вещи обрабатываются) и уровня представления (как вещи отображаются).

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