Zademonstrować zły kod klientowi?

Klient poprosił mnie o przeprojektowanie swojej witryny - aplikacji ASP.NET Webforms opracowanej przez innego konsultanta. Wydawało się, że jest to stosunkowo prosta praca, ale po zapoznaniu się z kodem widać, że tak nie jest.

Ta aplikacja nie została dobrze napisana. W ogóle. Jest bardzo podatny na ataki typu SQL injection, logika biznesowa jest rozłożona na całą aplikację, jest dużo duplikacji, a kod ślepy zaułek nic nie robi. Co więcej, wciąż zgłasza wyjątki, które są tłumione, więc strona wydaje się działać płynnie.

Moim zadaniem jest po prostu aktualizacja HTML i CSS, ale większość HTML jest generowana w logice biznesowej i byłoby koszmarem do uporządkowania. Moje oszacowanie dotyczące przeprojektowania jest dłuższe niż oczekiwał klient. Pytają dlaczego tak długo.

Jak mogę wyjaśnić mojemu klientowi, jak zły jest ten kod? Ich zdaniem aplikacja działa świetnie, a przeprojektowanie powinno być szybkie. To moje słowo w stosunku do poprzedniego konsultanta. Jak mogę podać proste, konkretne przykłady, które zrozumie klient nietechniczny?

Aktualizacja

Dziękuję za wszystkie odpowiedzi. Demonstracja ataku iniekcyjnego SQL ma sens i pokażę to w środowisku testowym. To tylko część wielu problemów w tej aplikacji. Szukałem sposobów wyjaśnienia, dlaczego inne części (takie jak HTML generowane w warstwie danych) powinny zostać zastąpione lepszymi praktykami, aby aktualizacja HTML i CSS mogła mieć miejsce. Jest tu wiele dobrych sugestii, które poskładam, kiedy rozmawiam z moim klientem.

Non-technicy nie są idiotami (w przeważającej części). Rozumieją argument techniczny, jeśli utrzymasz go na wysokim poziomie. Wybierz zadanie, które Twoim zdaniem powinno być proste, i opowiedz im, dlaczego tak nie jest.

Spodziewałem się, że ta zmiana będzie jednym słowem w jednym pliku. Wydawało się, że to najbardziej prawdopodobne miejsce, w którym można to zmienić, ale kiedy to zmieniłem, działało tylko w jednym miejscu i złamało te 7 innych miejsc. Kiedy naprawiłem jedno, zepsuło jeszcze dwa miejsca, powodując efekt domina, więc zmiana, którą, jak sądzę, powinna zająć 10 minut, skończyła się 2 godzinami. To tylko jeden przykład. Tam jest o wiele więcej nieoczekiwanych 2 godzinnych zadań.

Struktura kodu, styl, zadłużenie techniczne to jedna rzecz, z którą - przynajmniej na początku, dopóki klient ci nie zaufa - będziesz musiał z tym żyć.

Luki w zabezpieczeniach to inna sprawa.

Osobiście dokonałbym oszacowania na podstawie pracy wymaganej przy użyciu istniejącej struktury i stylu, jednocześnie wyjaśniając, że istnieją poważne problemy z bazą kodu. Osobno poruszyłbym implikacje dotyczące bezpieczeństwa: zrób demonstrację włamania do bazy danych, aby doprowadzić punkt do domu podczas spotkania.

Miałem wielką radość, robiąc to z poprzednim klientem z systemem kart podarunkowych lojalnościowych, kiedy położyłem 5000 funtów na „mojej” karcie i kazałem mu sprawdzić kartę przy kasie.

Kilka świetnych sugestii na temat tego, jak przekazać to i przekazać klientowi. Mam nadzieję, że się za ciebie opłacą.

Ważna czerwona flaga tutaj!

Jeśli klient prosi, aby nie wprowadzać żadnych zmian innych niż te, na które wyraziłeś zgodę (HTML i CSS), przekażę ten projekt i wycofam moją ofertę.

Nawet przy pisemnym i dobrze komunikowanym przeglądzie wszystkich wad i problemów związanych z bezpieczeństwem, potencjalna odpowiedzialność jest dla mnie zbyt wielka, aby się z nią czuć komfortowo. Nawet jeśli klient nigdy nie podjął żadnych działań prawnych ani nie zażądał poprawek po włamaniu lub naruszeniu; twoje imię i reputacja są nadal związane z pracą!

Możesz równie dobrze stracić znacznie więcej, niż możesz zyskać.

Wyjaśnij i ewentualnie zademonstruj wadę.
Jeśli to twoje słowo przeciwko niemu, wszystko, co mówisz, może być tylko gorącym powietrzem. Gdy pokażesz im, w jaki sposób można nadużyć ich aplikacji za pomocą wstrzyknięcia SQL, nagle stajesz się osobą godną zaufania. Będziesz potrzebować wiarygodności, aby renegocjować. I to wystarczy do zmiany gry, aby ci ją dać.

Bądź miłosierny w stosunku do swojego poprzednika.
To nie znaczy udawać, że nie ma tam błędów, ale jeśli spotkasz się z protekcjonizmem, stracisz wiarygodność. Nie mów ani słowa o programatorze, chyba że po to, by dać mu wątpliwości. Skoncentruj się na kodzie, a nie na kodzie. Sprawiając, że poczują się jak „dobry facet”, da ci dużo więcej swobody w negocjacjach. A „dobrzy ludzie” nigdy nie mówią złych rzeczy. Podczas wyjaśniania klientowi istniejących błędów bezpieczeństwa (takich jak luki w zabezpieczeniach związanych z wstrzykiwaniem SQL) wolę powiedzieć coś takiego:

Bezpieczeństwo aplikacji internetowych to szybko ewoluująca dziedzina. Wiele narzędzi i technik programistycznych, których ludzie uczą się nawet dzisiaj, ewoluowało, zanim większość z tych exploitów została dobrze poznana. Aby wyprzedzać rozwój bezpieczeństwa, musisz bardzo uważnie śledzić działania, a czasem nawet zmieniać cały styl programowania. Większość programistów tego nie robi.

No to jedziemy. Ani słowa zła nie mówiły o deweloperze; jest po prostu „większością programistów”, co oznacza, że ​​jest w całkiem dobrym towarzystwie. A teraz już pokazały, że jesteś nie „większość programistów”, który daje nieco większą wiarygodność i być może powód, żeby płacić więcej pieniędzy.

Negocjuj nowe porozumienie
Gdy klient zrozumie, że jego aplikacja jest otwarta na nadużycia ze strony społeczeństwa, będzie chciał, aby została naprawiona. Prawdopodobnie jesteś osobą, którą poprosi o naprawę. Możesz lub nie chcesz tej pracy, więc zastanów się nad nią przed rozmową.

Przynajmniej chcesz więcej czasu na dokończenie pracy, którą ci już dali. Wystarczająco mało ich zdziwiłeś dzięki materiałom podatnym na zagrożenia, które prawdopodobnie nie utrzymają cię w pierwotnej ocenie. Ale upewnij się, że klient wie, kim jesteś i nie będziesz naprawiać w ramach tego porozumienia.

Zazwyczaj programista (ty) wolałby przerobić całość od zera. W takich przypadkach może to być nawet opcja. Ale nawet wtedy klient będzie chciał czegoś, co utrzyma jego działalność do czasu zbudowania nowej aplikacji. Oznacza to, że nawet jeśli zaczynasz od nowa, prawdopodobnie nadal będziesz musiał trochę zaktualizować starą aplikację.

Zacząłem to od komentarza, ponieważ początkowo myślałem, że to bok, ale prawdopodobnie tak naprawdę nie jest.

Chciałbym w pełni udokumentować wszystko, co według ciebie powinno zostać przeprojektowane, i dlaczego (co się stanie, jeśli nie dokonają zmiany), a także oszacowanie dotyczące rozwiązania problemu. Byłbym szczególnie skrupulatny w odniesieniu do wszystkiego, co postrzegasz jako zagrożenie bezpieczeństwa.

Zrobiłbym to przed dotknięciem dowolnego kodu i upewnij się, że twój klient ma kopię tego raportu, najlepiej z jakimś znacznikiem czasu. Może to zająć trochę czasu, ale obejmie cię również, jeśli którekolwiek z tych zagrożeń bezpieczeństwa kiedykolwiek się spełni. Jeszcze lepiej, jeśli uda ci się podpisać coś, co mówi, że otrzymali dokument.

Jasne, możesz wskazać kontrolę źródła oryginalnego kodu, który odziedziczyłeś, jeśli tak się stanie, ale o wiele łatwiej będzie wskazać ten dokument i powiedzieć w bardziej profesjonalny sposób: „Widzisz? Tak ci mówiłem”.

Ten dokument może być punktem wyjścia do dalszych dyskusji, a nawet może zostać wykorzystany przez twojego klienta, aby uzyskać „odpowiednich ludzi”, którzy pozwolą na wprowadzenie niektórych lub wszystkich zmian.

Biorąc to pod uwagę, gdy klient nie zrozumie ryzyka, uśmiechnij się i zrób to, jeśli powiedzą, że i tak wykonują pracę lub odejdą.

Pamiętaj, że klient zwraca się do Ciebie o pomoc w utrzymaniu aplikacji. Twoim zadaniem jako profesjonalisty jest wskazanie wszelkich problemów związanych z ich aplikacją. Klient prawdopodobnie nie ma pojęcia, że ​​te problemy istnieją, i należy o nich poinformować. Wyjaśnij te kwestie w sposób dla nich zrozumiały i pozwól im zdecydować, jak chcą postępować.

Użyj przykładów ze świata rzeczywistego, aby zilustrować te problemy, takie jak awaria samochodu lub pralka wymagająca naprawy. Chodzi o to, aby użyć przykładów, które już znają. Aby wyjaśnić zastrzyk SQL, po prostu zademonstruję, co to jest i dlaczego jest to problem.

Na koniec chcesz przekazać, że zależy ci na sukcesie aplikacji, nad którą prosi się cię o pracę.

Lubię korzystać z analogii, z którymi może odnosić się klient. Ilość pracy, którą włożyłam z góry w wygraną, zależeć będzie od kwoty, którą klient zamierzał wydać (100 USD jest bardzo różne od 20 000 USD). Zauważ, że powiedziałem „zamierzam”. Twoje osobiste oszacowanie wartości nie ma większego znaczenia, jeśli nie dostaniesz tego, o co pytasz.

W twojej sytuacji - znowu w zależności od pieniędzy - mógłbym narysować pudełko z jedną linią wychodzącą z każdej strony i powiedzieć klientowi „W ten sposób wizualizujesz oprogramowanie teraz. Dane idą na jednym końcu, a wychodzą na drugim, wszystkie wygląda ładnie, czysto i prosto ". „Tak myślisz, jak wygląda oprogramowanie wewnątrz”, a następnie narysuj trzecią linię łączącą dwie linie wewnątrz pudełka.

Następnie narysowałem kolejne pole, tak jak pierwsze, z liniami wejściowymi i wyjściowymi na zewnątrz, z tym wyjątkiem, że powiedziałbym „Oto, jak oprogramowanie naprawdę teraz wygląda w środku”. a następnie, aby połączyć dwie linie, tym razem narysuję losowy stos spaghetti, prawdopodobnie z przerwami, połączeniami i bazgrołami.

Na koniec powiedziałbym: „Teraz to, o co mnie prosisz, to…” i narysuj prosty kształt w pierwszym polu, być może małe półkole dotykające linii, a następnie powiedz „ale żeby to zrobić, ja” muszę to zrobić… ”i narysować wokół linii tornado przypominający spiralny kształt i kontynuować…”, aby obejść to wszystko… ”i wskazać spaghetti w drugim pudełku.

Sądzę, że doprowadziłoby to do sedna sprawy za około 2 minuty. Jeśli mimo to nalegają, abyś to zrobił, udokumentuj to tak, jak wspominają inni powyżej.

Jak mogę wyjaśnić mojemu klientowi, jak zły jest ten kod?

Być może możesz użyć analogii, takiej jak hydraulika w domu, który z czasem, po naprawach i przebudowach, staje się tak kapryśny i sprzężony, że przy naprawianiu jednej rzeczy wpływa na coś, co następnie wymaga naprawy, i prawdopodobnie go psuje, i po prostu nie ma sposobu, abyś wiedział wszystkie miejsca, w których to nastąpi.

To moje słowo w stosunku do poprzedniego konsultanta, więc jak mogę podać proste, konkretne przykłady, które zrozumiałby klient nietechniczny?

Masz rację, to słowo przeciwko wszelkim obrazom, które poprzedni konsultant stworzył w ich głowach. Moja sugestia to robienie tego, o co prosisz, dawanie prostych, konkretnych przykładów. Ponieważ jest to przeprojektowanie, pokaż, w jaki sposób fragment HTML zdefiniowany w skompilowanym kodzie jest wyświetlany wraz z resztą strony HTML, oraz jak zmiana, która wpływa lub nie wpływa, na resztę strony. Być może ten sam skompilowany kod wyświetla znaczniki po zastosowaniu reguły „biznesowej”. Pokaż różnicę.

Jest to trudny i BARDZO powszechny problem. Powodzenia z tym.

Bądź szczery i bezpośredni.

Ale co najważniejsze, nie podejmuj pracy, która nie spełni twoich oczekiwań. Większość ludzi nie zdaje sobie sprawy, że kontrahent może zwolnić klienta, może i powinien, jeśli praca jest bardziej kłopotliwa niż warta.

Oto analogia, której użyłem (choć nie gwarantujemy jej skuteczności): Wyobraź sobie, że ich strona internetowa jest maszyną fizyczną, jak mechaniczna prasa drukarska, która w jakiś sposób przyjmuje dane wejściowe.

Prawdopodobnie myślą o maszynie jako o komponencie, który robi X, a innym, który ma Y. W rzeczywistości jest to około 20 podobnych maszyn. Niektórzy z nich już nic nie robią, wszyscy próbują wykonać funkcje, które inni już wykonują i nikt oprócz poprzedniego konsultanta nigdy wcześniej nie widział czegoś dokładnie takiego jak oni.

„Widzisz to gizmo, które analizuje zmienne pocztowe, a następnie wysyła ten komponent do króliczej dziury if-elses? Nie ma tylko jednego z nich, jest jeden z nich na każdej stronie (lub czymkolwiek), niektóre z nich dezynfekują dane wejściowe, a niektórzy nie (lub wszyscy nie) i bez przeczytania całej rzeczy nie wiem, która ”.

Jedną z kwestii, o których jeszcze nie wspomniano, jest to, że w tym przypadku możesz po prostu przekraczać oczekiwania klienta. Przepracowanie jest świetne i może zapewnić wiele satysfakcji z pracy. Ale jeśli klient po prostu nie dba o to, uważa, że ​​obecna wydajność jest „wystarczająco dobra” i chce tylko drobnych aktualizacji, może nie być w stanie przekonać ich do dokonania dużej inwestycji w ciebie, aby dokonać przeglądu bazy kodu.

W tym momencie prawdopodobnie będziesz musiał zdecydować, czy postąpić zgodnie z zasadami i odmówić podjęcia pracy, która zmusiłaby cię do przywiązania twojego dobrego imienia do zawstydzającego bałaganu kodowego lub czy możesz przytrzymać nos, wejść, wykonać zadanie z taśmą klejącą i wyjdź z płatnością.

Jeśli jednak zdecydujesz się na pracę z taśmą klejącą, upewnij się, że dokumentujesz, dokumentujesz, dokumentujesz i zachowujesz jak najbardziej przejrzystość. Ostatnią rzeczą, jakiej chcesz, to obwinianie się za coś, co pójdzie nie tak w przyszłości, co jest wynikiem wady aplikacji, przed którą ostrzegałeś klienta, ale że klient uznał, że nie był wystarczająco ważny, aby sobie z tym poradzić.

Jeśli chodzi o ryzyko związane z iniekcją SQL, inni mówili, że powinieneś być w stanie wykazać się niebezpieczeństwami w sposób pokazujący ryzyko bez faktycznego niszczenia produkcji. Ale znowu, jeśli widzą to i nie dbają o to, by to naprawić, dołożyłeś starań w dobrej wierze w tej sprawie.

To sos Noob, który przyszedł do projektu i zasugerował, żeby najpierw napisać od nowa, wykonać niewielki podzbiór modyfikacji i użyć ich, aby zilustrować, o ile prostsze i tańsze mogłoby być. Następnie możesz udowodnić, dlaczego zwiększony koszt czystszego programowania doprowadzi do niższych kosztów konserwacji i szybszego rozwoju w dłuższej perspektywie, biorąc pod uwagę niewielki koszt uboczny czcionki.

Nigdy nie zapominaj, że zasadniczo prosisz ich, aby zapłacili ci za ułatwienie życia, ich zdaniem wystarczy znaleźć „faceta”, który może X cechować się kosztem Y i zwiększyć złożoność twojego projektu, może po prostu wyeliminować okazję dla Was. To trudna droga, gdy miesiąc dzieli Cię od przepisywania i spotykasz się z oryginalnym programistą, aby zdać sobie sprawę, że cała aplikacja została napisana w bardzo zakontraktowanym oknie przez programistę, który w pełni zrozumiał wszystkie poczynione kompromisy. Jeśli aplikacja wygląda okropnie, ale zewnętrznie działa dobrze, jak mówisz, jest bardzo prawdopodobne, że tak będzie. Często zadłużenie techniczne w bazie kodu wynika z ograniczeń zasobów, w których został opracowany kod, a jeśli nie budują zespołu, a zamiast tego zlecają coś innym ...

Po prostu mówię'

Będę tu grał w adwokata diabła (nieco zgodnie z tym, co mówi @khrome: „nie płacisz klientom, aby ułatwić ci życie”). Chciałbym nawet posunąć się nawet do stwierdzenia, że ​​przedstawiony przypadek jest zbyt jednostronny, ponieważ opisałeś sprawę w sposób ogólny. Większość przybywających konsultantów do nowego projektu rzuciłaby złe światło na poprzedni ... Nie mówię, że robisz to tutaj, ale dopóki nie zobaczymy przykładów, nie mogę po prostu uwierzyć ci na słowo.

To powiedziawszy, postaram się rozwiązać problemy punkt po punkcie:

• Zastrzyki SQL . OK, więc myślę, że programista używał konkatenacji łańcuchów zamiast sparametryzowanych zapytań i / lub procedury składowanej. Jest to bardzo łatwe do naprawienia, szczególnie w ADO.NET ... Osobiście wspomniałbym o tym klientowi, ale nie robiłem z tego zbyt wielkiej sprawy.
• HTML jest generowany w logice biznesowej i byłoby koszmarem do uporządkowania . OK, stary, to jeden z tych, w których podajesz mi więcej szczegółów. O ile nie korzystasz z MVC, taka tendencja się zdarza ... ale niekoniecznie jest to zła rzecz ... to jedna z tych rzeczy, w których większość programistów powiedziałaby: „ goto jest zły; nigdy go nie używaj”, ale wiesz co? Użyłem goto tam, gdzie to miało sens! Jesteś pewien, że nie używają klas pomocniczych, które dzielą tę samą przestrzeń nazw, co biblioteka DLL kodu biznesowego? Znowu nie jest to takie trudne do izolacji.
• logika biznesowa jest rozłożona na całą aplikację, jest dużo powielania, a kod ślepy zaułek nic nie robi. . I? Klient prosi tylko o zmianę HTML / CSS. Dlaczego w ogóle miałbyś przejmować się tymi problemami?
• wciąż zgłasza wyjątki, które są tłumione, więc strona wydaje się działać płynnie . Znowu bardzo niejasne. Wyjątki są normalne w każdej aplikacji, dlatego w naszym kodzie mamy klauzule try / catch. O ile nie pojawią się one w interfejsie użytkownika i nie zrujnują interfejsu użytkownika (jak niepotrzebne wyświetlanie HTTP 500), nie sądzę, że jest to coś, o co powinieneś się martwić.

Krótko mówiąc, radziłbym, abyś wybrał wysoką drogę. Jeśli uważasz, że to nie jest warte twojego czasu i chcesz przepisać go na koszt klienta, odejdź od pracy. Poważnie, na koniec klient płaci za twój czas, aby wszystko działało przy jak najmniejszej ilości $$$.

Dzięki wieloletniemu doświadczeniu w tej dziedzinie zawsze mówię, że najlepszymi programistami, z którymi się spotkałem, są ci, którzy mogą ustabilizować system, pisząc najmniej kodu , a nie przepisując całość .

Edycja: Już widzę, że moja odpowiedź nie jest najpopularniejsza (już się tego spodziewałam), ale podtrzymuję swoją odpowiedź. Zredagowałem to, aby było mniej snarky. ;-)

Z pewnością pierwszeństwo miały ataki polegające na wstrzykiwaniu SQL i inne wady funkcjonalne aplikacji, ale można również „wykazać” złą jakość kodu i praktyki. Za pomocą narzędzi metryki kodu możesz wyraźnie zademonstrować, jak zły jest kod i pokazać mu, ile to będzie kosztowało wszelkie przyszłe zmiany i naprawy błędów. Nie jestem zaznajomiony ze środowiskiem .net, ale jestem pewien, że jest ich kilka.