Демонстрировать плохой код для клиента?

Клиент попросил меня сделать редизайн своего веб-сайта, приложения ASP.NET Webforms, разработанного другим консультантом. Это казалось довольно простой задачей, но, посмотрев на код, ясно, что это не так.

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

Моя задача - просто обновить HTML и CSS, но большая часть HTML создается в бизнес-логике и будет кошмаром для сортировки. Моя оценка по редизайну длиннее, чем клиент стремился. Они спрашивают, почему так долго.

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

Обновление

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

128 голосов | спросил 3 revs, 2 users 84%
jtiger
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

14 ответов


145

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

  

Я ожидал, что это изменение будет одним словом в одном файле. Наиболее вероятно   место для его изменения, казалось, было здесь, но когда я изменил его там, он   работал только в одном месте, и он сломал эти 7 других мест. Когда я   фиксированный, он сломал еще два места, вызывая эффект домино, поэтому   изменение, я думал, должно было занять 10 минут, закончив тем, что занял 2 часа.   Это всего лишь один пример. Есть гораздо более неожиданные задачи на 2 часа.

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
87

Структура кода, стиль, технический долг - это одна вещь, которая, по крайней мере, изначально, пока клиент не доверяет вам, вам придется жить.

Уязвимости безопасности - это еще одно дело.

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
76

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

Основной красный флаг здесь!

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

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

Вы можете потерять гораздо больше, чем вы можете выиграть.

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
30

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

Будьте благосклонны к своему предшественнику
Это не значит притворяться, что ошибок там нет, но если вы встретите снисходительность, вы потеряете доверие. Не говорите ни слова о программисте, кроме, возможно, чтобы дать ему преимущество в сомнении. Сосредоточьтесь на коде, а не на кодере. Заставляя их чувствовать, что вы «хороший парень», даст вам гораздо больше свободы на переговорах. И «хорошие парни» никогда не говорят ничего. Объясняя существующие ошибки безопасности (например, уязвимости SQL-инъекций) для клиента, я предпочитаю говорить что-то вроде этого:

  

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

Там мы идем. Ни слова зла не говорили о разработчике; он просто «большинство программистов», что означает, что он в хорошей компании. И теперь вы продемонстрировали, что вы являетесь not «большинством программистов», которые дают вам немного больше доверия и, возможно, являются причиной для того, чтобы они заплатили вам больше денег.

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

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
19

Я начал это как комментарий, потому что сначала я думал, что это в стороне, но, вероятно, это действительно не так.

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

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

Конечно, вы можете указать на исходный код исходного кода, который вы унаследовали, если он когда-либо случится, но будет гораздо проще указать на этот документ и сказать более профессионально: «Видите? . "

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
14

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

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
7

Мне нравится использовать аналогию, к которой может относиться клиент. Объем работы, которую я поставил перед собой, выиграв работу, будет зависеть от суммы денег, которую клиент намеревался потратить (100 долларов США намного отличаются от 20 000 долларов США). Заметьте, я сказал «намереваясь». Ваша личная оценка значимости не означает многого, если вы не получите то, что вы просите.

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

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

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
6

Как я могу объяснить моему клиенту, насколько плохо этот код?

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

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

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

Это сложная и очень распространенная проблема. Удачи вам.

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
6

Быть честным и быть прямым.

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
3

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

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

  

"См. эту штуковину здесь, которая анализирует почтовые переменные и затем отправляет   этот компонент вниз кроличьи отверстия if-elses? Существует не только один   из них, есть одна из них на каждой странице (или что-то еще), некоторые из них   они дезинфицируют ввод, а некоторые - нет (или все не делают) и без   читая всю вещь, я не могу знать, что ».

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
2

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

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

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
0

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

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

Я просто говорю,

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
0

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

Тем не менее, я постараюсь решить проблемы до вас по пунктам:

  • SQL-инъекции . ОК, поэтому я предполагаю, что программист использовал конкатенации строк вместо параметризованных запросов и /или хранимой процедуры. Это очень легко исправить, особенно в ADO.NET ... Я лично упомянул об этом клиенту, но не делал из него слишком многого.
  • HTML создается в бизнес-логике и будет кошмаром для сортировки . Хорошо, чувак, это один из тех, где вы даете мне более подробную информацию. Если вы не используете MVC, это будет иметь тенденцию ... но это не обязательно плохо ... это одна из тех вещей, которые большинство программистов скажут: « goto плохо, никогда не используйте это ", но знаете что? Я использовал goto , где это имело смысл! Итак, уверены ли вы, что они не используют вспомогательные классы, которые используют одно и то же пространство имен, например, для DLL бизнес-кода? Опять же, это не так сложно изолировать.
  • бизнес-логика распространяется по всему приложению, существует много дублирования и тупиковый код, который ничего не делает. . А также? Клиент просто просит вас изменить HTML /CSS. Зачем вам все эти вопросы?
  • он продолжает бросать исключения, которые затупляются, поэтому сайт работает плавно . Опять же, очень расплывчато. Исключения являются нормальными в любых приложениях, поэтому у нас есть пункты try /catch в нашем коде. Если они не взорвутся в пользовательском интерфейсе и не разрушат пользовательский интерфейс (например, отображать HTTP 500 без необходимости), я не думаю, что это то, о чем вы должны заботиться, либо ..

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

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

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02
-1

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

ответил jwenting 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2016 14:16:02 +0300 2016, 14:16:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132