Naciśnij to: unikanie zabijającego czas zadłużenia technologicznego w kompilacjach WordPress z Jonem Martinem

Witamy w Press This, podkaście społeczności WordPress firmy WMR. Tutaj gospodarz David Vogelpohl siada z gośćmi z całej społeczności, aby porozmawiać o największych problemach, przed którymi stoją programiści WordPress. Poniżej znajduje się transkrypcja oryginalnego nagrania.

Obsługiwane przez RedCircle

David Vogelpohl: Witam wszystkich i zapraszam do Press This, podcastów społeczności WordPress na temat WMR. To jest twój gospodarz, David Vogelpohl, wspieram społeczność WordPressa poprzez moją rolę w WP Engine i uwielbiam przedstawiać to, co najlepsze w społeczności, co tydzień w prasie to jako przypomnienie, możesz mnie znaleźć na Twitterze @wpdavidv lub możesz zasubskrybować, aby nacisnąć ten przycisk w iTunes, iHeartRadio, Spotify lub pobrać najnowsze odcinki z wmr.fm. W tym odcinku porozmawiamy o jednym z moich ulubionych tematów, a mianowicie o unikaniu zabijania długów technologicznych w kompilacjach WordPress. Dołączając do nas w tej rozmowie, chciałbym powitać Jona Martina. Jon, witaj w Press This.

Jon Martin: Dziękuję bardzo, dobrze być tutaj.

DV: Wiesz, że ćwiczę wymawianie Hallum przed występem, ale oczywiście na samym początku wszystko popsułem. John przepraszam za to. Niesamowite, więc dla tych, którzy słuchają Johna, podzielą się swoimi przemyśleniami na temat wpływu długu technologicznego na zespoły programistów WordPress, na przykład co to znaczy mieć dług technologiczny i jak to wpływa na ciebie? Jak możesz myśleć o zmniejszeniu zadłużenia technologicznego przy każdym projekcie. A potem, dlaczego masz obowiązek dzielić się uwagami dotyczącymi zadłużenia technologicznego ze swoimi klientami?

JM: jeśli pracujesz jako freelancer. Więc uwielbiam zabijać dług technologiczny. Uwielbiam to eliminować, to jeden z moich ulubionych tematów.

DV: Przejdziemy do przemyśleń Johna na ten temat, ale zanim zaczniemy, John, zadam ci to samo pytanie, które zadawałem każdemu gościowi. Opowiedz mi krótko o swojej historii pochodzenia WordPressa. Kiedy po raz pierwszy użyłeś WordPressa

JM: więc na początku 2010 roku nie byłbym pewien, jaka jest poprawność wyrażenia dla tego okresu. Tak więc właściwie zacząłem sam i byłem dyrektorem generalnym tego, jak założyliśmy agencję w 2008 roku. W tamtym czasie WordPress wciąż był platformą do blogowania. Tworzyliśmy strony internetowe, które zawierają wiele bogatych treści. To trochę brzydkie słowo, ale używaliśmy wtedy Joomla. Ale wtedy raczej niż

DV: Joomla to brzydkie słowo. Osobiście lubię wszystkie CMS typu open source.

JM: Tak, chcielibyśmy powiedzieć, że to świetny projekt. Myślę, że kluczową rzeczą dla nas jest to, że z biegiem czasu Joomla była naprawdę silna, gdy WordPress wprowadził obsługę niestandardowej witryny postów. To wtedy naprawdę zmieniło się wszystko w WordPressie, który przeniósł go z tego, co było znane jako platforma blogowa, do bycia pełnoprawnym CMS-em, w którym możesz robić wszelkiego rodzaju witryny, niezależnie od tego, czy jest dla Ciebie, naprawdę mały jednoosobowa firma, freelancer lub cokolwiek innego, aż do ogromnych, złożonych witryn internetowych klasy korporacyjnej. I myślę, że naprawdę, naprawdę dla mnie, była to zabójcza decyzja z ich strony, ponieważ jest to jeden z powodów, dla których WordPress jest teraz tak popularny. Więc tak, więc to było wtedy, kiedy zaczęła tutaj używać. Sasha, poprzednia historia, to tak naprawdę ja, a teraz dyrektor generalny tego, jak byliśmy razem w zespole. I mamy świetny pomysł na myślenie: Cóż, wiesz co, to jest niesamowite, bardziej równy czas w trasie i naprawdę ciężko jest uzyskać czas wolny od mojej obecnej pracy. Pomyśleliśmy więc: Wiesz co, załóżmy agencję i zostańmy programistami internetowymi, ponieważ to naprawdę pomoże odzyskać cały ten czas. To była świetna decyzja. Bardzo się z tego cieszę, ale z pewnością jest to również naiwna decyzja, ponieważ myślenie, że praca dla siebie daje więcej czasu, było zdecydowanie błędem, który myślę, że trochę później rozpoznamy. A wcześniej, wiecie, wiedziałem trochę o SQL i budowałem komputery od tego czasu, właściwie od czasu, gdy karta graficzna bardzo wspiera kolory. Więc dla każdego, kto wie, co to jest CGA, pomoże ci dowiedzieć się, ile mam lat. Ale tak, tak naprawdę, to było wtedy, gdy pojawiły się CPT. Ten tłuszcz zmienił dla nas wszystko. I właściwie z dnia na dzień zaczęliśmy używać WordPressa, który stał się naszym wybranym CMS-em i od tego czasu nie oglądaliśmy się wstecz i, wiesz,

DV: ze wszystkich osób, które zadałem ci to pytanie, bardzo niewielu faktycznie miało pojęcie o tym, jak istotne są typy niestandardowych postów w stosunku do ich historii pochodzenia WordPress. I to jest zabawne. Mam podobną historię. Założyłem agencję w 2010 roku. Trochę po wszystkim, ale kiedy pojawił się niestandardowy post. Zaczęliśmy budować z Joomla i przełączyć się na WordPressa z podobnych powodów, ale to były te niestandardowe typy postów i niestandardowa meta pola, z którymi się zgadzam i faktycznie przedstawiłem w ten sposób różne formaty, jest to, że był to taki moment, kiedy WordPress naprawdę stał się prawdziwym CMS-em. Rok po tym, jak powstał WooCommerce powstał WP Engine, wiele innych marek przestrzeni WordPress, to taki czas transformacji. Interesujące jest usłyszeć od Ciebie rodzaj odniesienia, który jest źródłem Twojej historii pochodzenia. Mówili mi jednak o tym, jak hm, i wiesz, moment założycielski, jeśli chcesz, ale czy mógłbyś mi pokrótce opowiedzieć o tym, jak hm, i co to robisz?

JM: Tak, jasne. Więc właściwie, ta agencja, którą odkryliśmy, nie była tak, jak my później napędzaliśmy. Dobrze, dobrze. Cóż, głównym powodem tego jest to, że w tamtych czasach istniała bardzo wyraźna różnica między, wiesz, budujemy strony internetowe, a robimy SEO i tym podobne. I tak naprawdę nie było tak wielu na całym świecie zintegrowanego podejścia i myślenia o takich rzeczach, jak doświadczenie użytkownika i jak to działa z SEO i rozwojem, tego typu rzeczy. Więc to jest powód, dla którego później się połączyliśmy, z Allen Milanem od około 20 lat, a nasz założyciel zaczął działać na samym początku, kiedy SEO zaczęło stawać się rzeczą. Więc tak, więc połączyliśmy dwie agencje. Sześć, siedem lat temu, może trochę dłużej. Muszę przyznać, że moja pamięć do danych nie jest świetna. A potem I wtedy naprawdę, tak, stało się to naszym podejściem, czy jest to w pełni zintegrowane podejście do mieszania wszystkich tych różnych dyscyplin razem, aby pomóc ludziom dostrzec linię? Więc teraz zajmujemy się PPC, SEO, cyfrowym PR, oczywiście projektowaniem stron internetowych i jest rozciąganie marki, strategia cyfrowa i wszystkie tego rodzaju rzeczy, wszystkie te dyscypliny, których naprawdę potrzebujesz, aby mieć dobrą, silną obecność w internecie w dzisiejszych czasach. Jaka jest twoja rola w firmie? Więc mój tytuł zawodowy to dyrektor techniczny. Więc będę szczery, tak naprawdę nie obejmuje wszystkiego, co robię. Od dłuższego czasu prowadzę zespół programistów. Więc wszystko, co będzie WordPress, było pod moim kierownictwem. Z przyjemnością mogę powiedzieć, że mamy w zespole o wiele lepszych programistów niż my wtedy, kiedy Julio i ja pracowaliśmy, kiedy zaczynaliśmy, co jest powodem, dla którego obecnie radzimy sobie znacznie lepiej. I trochę bardziej rozumiemy rzeczy. Więc prowadzę zespół programistów przez długi okres czasu, ostatnio również na koszt zespołu danych. To oznacza, że ​​mogę bawić się uczeniem maszynowym, Python i Bartek i inni, chociaż muszę sobie to wszystko wyobrazić.

DV: Robienie fajnych oddzielnych klientów spowoduje po drodze pewien dług technologiczny. Dlatego jestem ciekaw, jak myślisz, jakie są najczęstsze rodzaje zadłużenia technologicznego i może specyficzne dla WordPressa. To na chwilę, ale na przykład, jak myślisz o tym, gdy myślisz, wiesz, jak i jak wszyscy zarządzacie swoim długiem technologicznym, tak jak zablokowaliście go w typy za pomocą wbudowanego WordPressa?

JM: Tak, mamy. To znaczy nie. Niekoniecznie. Używamy języka, w którym niekoniecznie kategoryzujemy rzeczy lub przechodzimy przez proces okręgowy w celu kategoryzacji, ale tak naprawdę można je podzielić na trzy różne wiadra. Jednym z nich jest tworzenie złego kodu na podstawie istniejących kodów, a może to wynikać z tego, że w przeszłości popełniałeś błędy, które mogą być problemem ze stron internetowych Heritage i kogoś innego, bez względu na przyczynę, więc to jest rodzaj pierwszego wiadra. Drugi to budowanie kodu, który nie jest potrzebny, a może po prostu nie jest potrzebny w tej chwili. Wiesz, jestem pewien, że wszyscy otrzymaliśmy prośby o nowe funkcje od klientów i marek, z którymi współpracujemy, tam, gdzie naprawdę są zainteresowani konkretną rzeczą, ale w rzeczywistości może to nie być właściwe, jeśli chodzi o uzyskanie rzeczywistej wartości dla klientów. A potem trzeci, który jest największym, jaki widzimy, to budowanie funkcji, które naprawdę powinny być na innej platformie. Więc zrozumienie tego rodzaju architektonicznego elementu o ok, jakie są różne elementy, które tutaj podłączamy, to CRM, tutaj jest strona internetowa, która zasadniczo dotyczy marketingu firmy. Oto Twoja platforma do realizacji zamówień, wszystkie inne.

D V: Pozwól, że zapytam, pozwól, że zadam Ci podstawowe pytanie, tak jak wymieniłeś trzy rodzaje dźwięków, takie jak te, które są trzema rodzajami długu technologicznego, których chcesz się pozbyć pisz zły kod na złym kodzie kod, to nie są niezbędne funkcje, które można wykonać na innej platformie. Na przykład, czy nie ma czwartego wiadra, takich jak funkcje, które są cenne, a zatem technologia, która może być w tym przypadku dobra? Czy to sprawiedliwe? To czwarte wiadro.

JM: Tak. Mam na myśli 100%, nie wszystkie zadłużenie techniczne jest złe. Musisz zaakceptować, że prawie każda funkcja, którą zamierzasz zbudować, spowoduje naliczenie pewnego rodzaju długu technicznego i musisz zadzwonić, czy ten dług techniczny jest dobry, czy nie. Niektóre są dobre, inne złe i naprawdę zależy od tego, czy słowo kluczowe, które powiedziałem wcześniej, dotyczy wartości. Czy uzyskasz wartość, której potrzebujesz do tej rzeczy? Co ważniejsze, czy klient jest klientem ostatecznym, a nie twoim klientem, ale są jego klientami? Czy dostaną za to wartość? To zwykle całkiem niezłe światło przewodnie, czy zaakceptować ten dług techniczny.

DV: Tak, chcę trochę głębiej zagłębić się w to, jak myślisz o tym cytacie, warty tego wzór na to, kiedy można go zaakceptować, czy nie, ale dobrze jest pomyśleć o tym, aby dobrze zrozumieć, jak myślisz różne rodzaje długu technologicznego, a zwłaszcza te, które możesz chcieć zoptymalizować, aby je usunąć. To, co chciałbym teraz zrobić, to zrozumieć, czy to było coś, co doprowadziło cię do skoncentrowania się na tym obszarze, ale zrobimy pierwszą przerwę i zrobimy zaraz wracam. Czas na przerwę na reklamy. Bądź na bieżąco, aby uzyskać więcej naciśnięć przez chwilę. Witam wszystkich. Witamy ponownie, aby nacisnąć ten podcast społeczności WordPress na W EMR. To jest twój gospodarz, David Vogel. Paweł. Przeprowadzam wywiad z Johnem Martinem na temat uśmiercania czasu zabijania zmarłych techników. John tuż przed przerwą wyjaśniałeś, że sposób, w jaki myślisz o trzech rodzajach zadłużenia technologicznego, które możesz chcieć wyeliminować, to budowanie złego kodu na złym kodzie, tworząc kod, który nie jest konieczny dla sukcesu witryny, nad którą pracujesz. A potem może stworzyć kod dla funkcji, które mogą być lepiej obsługiwane na innej platformie. Zanim jednak przejdziemy do formuły cytatu, warto. Zastanawiałem się, czy był jakiś konkretny czas, którego nie znam, a twoja podróż jest szczególnym przykładem zadłużenia technologicznego, że tego rodzaju powierzchnia jest dla ciebie głównym obszarem zainteresowania, w jaki sposób?

JM: Tak, absolutnie. Jest jeden naprawdę przełomowy projekt, który zaczął mnie skłaniać do myślenia o tym jakieś cztery czy pięć lat temu. Widziałem wiele innych przypadków. Aby firmy gromadziły czas przez cały czas, nie tylko dzięki WordPressowi poprzez wszelkiego rodzaju rzeczy, w rzeczywistości firmy zyskują go również poprzez swoje procesy operacyjne. Jeśli musisz być techniczną rzeczą, kiedy tworzysz tę talię. Jedna, ta jedyna historia, która naprawdę wyróżnia mnie bardziej niż jakakolwiek jest klient, pracujemy ze stosunkowo małą firmą, dla której wykonaliśmy dużo płatnej pracy w mediach. Sprzedawanie polega głównie na sprzedawaniu rzeczy online. To był biznes eCommerce. Mieli tradycyjny rodzaj sprzedaży wysyłkowej, ale dużo ich pracy i próbowali zwiększyć ruch online, więc nie musieli przechodzić przez sprzedaż wysyłkową, będzie zarządzana przez stronę internetową i przyszli do nas, ponieważ zbudowałem dla nich witrynę, która jest całkowicie zindywidualizowana. I w tym momencie istnieją już od około 10 lat. Więc robiło się dość stare, zaczynało się trochę pełzać. Wiesz, standardy i idź dalej. Technologia ruszyła naprzód, czas trochę przemyśleć. Więc klient usiadł z nami, zaczął opisywać różne rzeczy, które robili na stronie internetowej. I bardzo szybko stało się dla mnie jasne, że w witrynie internetowej wbudowano wszelkiego rodzaju logikę biznesową i biznesowe elementy operacyjne. I to była logika, która prowadzi do zamówień i jest dość specyficzna dla sposobu, w jaki pracują dostawcy. Nie będę więc wchodził w szczegóły, ale mam dość skomplikowane ustalenia między dostawcami i tym, jak realizują zamówienia i czy dotarły do ​​ich sklepu przed wysłaniem tego rodzaju rzeczy. Więc to wszystko jest dość skomplikowane. Teraz właściciel firmy i poprzedni o tym, jak działają, w końcu zbudowali system, który w zasadzie zarządza całą tą sprawą, był w tamtym czasie naprawdę dobrym systemem i naprawdę pomógł tej firmie masowo się rozwijać. To, o czym tak naprawdę nie pomyśleli, to to, że wszystkie strony internetowe mają w końcu okres trwałości, który w pewnym momencie wejdą w życie, tak jak każde oprogramowanie w świecie marketingu. Ten okres trwałości jest naprawdę stosunkowo krótki w porównaniu do, na przykład, jeśli zainwestujesz w CRM, ponieważ firma normalnie będzie się kręcić przez jakiś czas, teraz to około 10 lat, jeśli nie więcej stron internetowych. Ogólnie rzecz biorąc, od dwóch do pięciu lat okazuje się, że co najmniej duże marki mają tendencję do odbudowy co trzy lata. Problem polegał na tym, że wbudowali całą tę skomplikowaną logikę w istniejącą witrynę internetową i musieli przebudować całą witrynę. I nagle trzeba również odbudować całą tę logikę biznesową. Teraz kosztowaliśmy projekt i w zasadzie skończyło się na około połowie rocznego obrotu, aby odbudować to, co już mieliśmy. I to naprawdę zaczęło mnie skłaniać do myślenia o tym, że no dobrze, jeśli początkowo podchodzą do problemu w inny sposób, na przykład pomyślmy o różnych rzeczach, które próbujemy osiągnąć na stronie internetowej. Wiesz, to z marketingu było to do sprzedaży produktów. To jest do realizacji zamówień, to jest najlepsze do zarządzania moim procesem biznesowym z dostawami wszystkich tych rzeczy i pomyślałem o tym w sposób bardziej modułowy, wtedy byłaby znacznie inna sytuacja dla tego klienta, że ​​tam była . To był dla nich prawdziwy problem, ponieważ mieli stronę internetową, na której zasadniczo zarabiali pieniądze. Dosyć trzeszczało, bo jest dość stare. Ale jednocześnie przebudowa całej strony internetowej i bardzo, bardzo skomplikowała projekt, kosztowała tak wiele. Udało nam się znaleźć całkiem sprytną, ale też niezbyt przyjemną pracę do końca, aby spróbować wykorzystać to, co już mieli i zintegrować to, ale nie możemy cytować, ale wiecie, ostatecznie okazało się, że było to znacznie bardziej bolesne, znacznie wolniejsze i znacznie więcej drogie niż było. Jeśli pierwotnie myślano o tej architekturze.

DV: Mam tyle projektów, że chcę o tym zapomnieć. Były takie po prostu i mogę to sobie wyobrazić, teraz cofam się w czasie. Więc jak dla mnie, brzmi to całkiem jasno, myślę, że bardzo ważną lekcją jest zastanowienie się nad rodzajem kosztów dla biznesu w stosunku do refaktora, który planujesz. Dla mnie brzmiało to tak, jakby jasna odpowiedź była taka, że ​​musisz zaprojektować to inaczej. I to może być wyraźniejsza ścieżka, jeśli chcesz polubić to, co powinieneś zrobić. Ale myślę, jak wiele zespołów, kiedy myślą o długu technologicznym, to tak, jakby myślały: „Ok, cóż, fajnie byłoby to zrobić, ale czy warto?

JM: Czy warto, żebym to z czasem utrzymywał? Więc jestem po prostu ciekaw, jak myślisz o tej formule

D V: kiedy, jak, kiedy można wprowadzić dług technologiczny? A ile właściwie myślisz o tej formule?

JM: Tak, dotknąłeś naprawdę ważnej kwestii, że wiesz, myślisz o naturze programistów, deweloperzy się w to angażują, ponieważ uwielbiają robić fajne rzeczy. I to jest, wiesz, dużą częścią naszej motywacji jest nauczenie się, jak robić nowe rzeczy, nową technologię, wiesz, nowe frameworki JavaScript, cokolwiek to jest, i to naturalnie daje nam motywację, która staje się do tworzenia fajnych rzeczy, ale niekoniecznie myślimy o tym długoterminowo, wiesz, nadal będziemy to utrzymywać. Wiesz, moja żona chciałaby mieć wannę z hydromasażem w moim domu, ale wiem, że ktoś to posprząta i będę szczery, nie wierzę, że ktokolwiek, kto to czyści, i tak myśli tego typu. Więc to naprawdę, naprawdę, naprawdę dobre pytanie do przemyślenia, czy naprawdę warto to zrobić, a jeśli trochę to podzielimy, jest kilka różnych rzeczy, o których możesz pomyśleć, po pierwsze, myśląc długo termin, jaki jest całkowity koszt posiadania i zbudowania tej rzeczy polegającej na testowaniu jej i utrzymaniu, a następnie porównaj to z wartością, którą otrzymujemy? Na przykład może istnieć naprawdę prosty sposób rozwiązania tego problemu. używając arkuszy kalkulacyjnych lub używając nieco innych rzeczy architektonicznych, gdzie być może ktoś wewnętrznie w firmie zarządza tym przez krótki okres czasu. A zrobienie tego byłoby tańsze i bardziej efektywne niż zbudowanie tej naprawdę skomplikowanej funkcji. Ale kiedy faktycznie spojrzysz na całkowity koszt posiadania, będzie to kosztować więcej niż dla kogoś, kto spędza kilka godzin tygodniowo na robieniu określonej rzeczy. Nie zrozum mnie źle. Jestem wielkim zwolennikiem automatyzacji. technologie powinny być jak najbardziej zautomatyzowane, aby uniknąć tego rodzaju administratora, ale

DV: rejestrujesz się i używasz takich podejść, jak w tym podręczniku, aby spróbować czegoś przed zakodowaniem, aby upewnić się, że będzie tam wartość. To znaczy, wpadam na pomysł uproszczenia tego czynnika, na przykład, czy zamiast tego możemy to zrobić ręcznie? Po prostu ciekaw, czy kiedykolwiek podchodziłeś do tego z perspektywy testowania, aby polubić, czy ostateczny zwrot jest tego wart?

JM: Tak. 100%. Więc jestem wielkim zwolennikiem metodologii Agile. Zasadniczo jedną z głównych zasad Agile jest to, że budujesz właściwą rzecz we właściwym czasie. A Ty skupiasz się na jak najszybszym zdobyciu wartości. Więc chcesz zbudować minimalny opłacalny produkt. Oznacza to, że w tym momencie niekoniecznie masz coś, co jest w pełni funkcjonalne. Ale daje ci platformę, na której możesz zacząć ją testować, wiesz, czy rzeczywiście otrzymujesz z tego rzeczy, których chcesz? Czy Twoi użytkownicy na to reagują? W sposób, jakiego oczekujesz, każdy, kto pracował w UX lub web dev, będzie wiedział, że dość często otrzymuje prośby od klientów, ponieważ myślą, że są to ich klienci, ale czy naprawdę tego chcą? Więc to jest kolejne naprawdę dobre pytanie, które należy zadać, gdy pomyślisz o tym długoterminowym spojrzeniu, czy ludzie będą korzystać z witryny, czy wiemy, że ktoś z niej korzysta, czy też musimy przetestować, aby zobaczyć, czy chcą z niego korzystać? A kiedy już wykonasz ten test, możemy ustalić, o co nie powinniśmy byli prosić i czy powinniśmy się wycofać i faktycznie umieścić naszą inwestycję gdzie indziej.

DV: Brzmi to jak podsumowanie tych przemyśleń i podobał mi się twój pomysł spojrzenia na całkowity koszt posiadania w perspektywie długoterminowej. zespoły myślą, ile godzin lub tygodni, rozpiętości, punktów lub cokolwiek ma to zrobić, aby zbudować. Ale wiesz, musisz wziąć pod uwagę, że wiesz, ile godzin lub tygodni lub spreadów lub punktów zajmie utrzymanie, a następnie użyj tej równowagi w stosunku do wartości, którą uzyskujesz z utrzymania tę działalność. Jesteś oczywiście rozsądną radą. Ale wtedy też myślisz: Cóż, czy jest coś, co mogę zrobić, aby to przetestować, aby sprawdzić, czy moje założenia są poprawne? Czy to brzmi trafnie?

JM: Tak. Absolutnie. Absolutnie. Jedyny fragment, którego nie poruszyliśmy, to ten, o którym mówiliśmy trochę wcześniej, czyli o architekturze, czy istnieje lepszy sposób na ustrukturyzowanie tego, aby było lepiej, a tym razem na programowanie obiektowe i takie tam o którym prawdopodobnie poruszę trochę później.

DV: Tak, również względy architektoniczne, tak jakbym spisał, jaki byłeś, czy jest sposób, abyśmy mogli zmienić specyfikacje? Czy to jest tak, jak w moim szkoleniu dla interesariuszy lub rozmowach, o których często mówię, wiesz, specyfikacja, aby złożyć prawo? Zapytaj o to, czego naprawdę potrzebujesz do złożenia. A więc pytanie o to będzie kłamać i będzie naprawdę potrzebne, a co z tym? Pytania okazały się bardzo krytyczne. Wygląda na to, że to kluczowa część tego, jak o tym myślisz.

JM: Tak, ponieważ każda minuta tworzenia tej strony to minuta, w której nie zyskuje ona wartości w oczach klientów. I to jest prosty sposób myślenia o tym. Chcesz zacząć działać tak szybko, jak to tylko możliwe. A potem testuj, monitoruj, iteruj, ucz się, wiesz, zobacz, dokąd się udajesz, ale tylko dlatego, że robisz to na podstawie rzeczywistych danych, a nie tego, co uważasz za słuszne. Ponieważ dość często nie są takie same.

DV: Tak, uwielbiam ten punkt. Co minutę. Jest w dev, czy nie jest to chwila, w której jej nie używasz, zorientuj się, a ja powiem powiązania z innymi powiązaniami z inną mantrą, którą mam, oraz zarządzaniem projektami i zarządzaniem interesariuszami, co jest dwoma najlepszymi słowami i uzyskanie projektu na naszej twarzy do napisania. Jak możesz mówić tak, uwielbiam to, że kiedy mam do czynienia z interesariuszami lub kiedy mam interesariusza, jest to potężna, potężna część. Ok spoko. Um, porozmawiajmy teraz o tym, co zespoły mogą zrobić, aby zmniejszyć dług technologiczny. Ale zanim to zrobimy, zrobimy ostatnią przerwę. Czas na przerwę na reklamy. Bądź na bieżąco, aby uzyskać więcej naciśnięć za chwilę. Wszyscy witamy z powrotem, aby nacisnąć ten podcast społeczności WordPress na W EMR. To jest twój gospodarz David mobile Paul, jestem w środku rozmowy z Johnem Martinem o unikaniu czasu zabijania długu technologicznego o tym, jak John tuż przed przerwą rozmawialiśmy trochę o twojej formule wartej tego, naprawdę podobały mi się twoje poglądy na temat zmniejszania okular. I myślenie o całkowitym koszcie posiadania i przyjmowanie iteracyjnego podejścia do testowania. Ale przyjrzyjmy się teraz, co zespoły mogą właściwie zrobić, aby zmniejszyć swój dług technologiczny i kompilacje WordPress. Jakie są twoje ulubione techniki zmniejszania zadłużenia technologicznego?

JM: Więc jest wiele technik technicznych, których możesz użyć, a niektóre z nich znasz, tak że nie będziesz, ale właściwie punktem wyjścia jest dla mnie dużo bardziej miękkie podejście do rozmowy do swoich klientów. I musisz pamiętać, że ostatecznie Twoimi klientami są te marki, które przychodzą do nas, ponieważ jesteśmy ekspertami. Potrzebują naszej rady i dość łatwo jest wpaść w pułapkę, że, wiesz, jesteśmy tam, aby robić to, co chcą, to, co jesteśmy, aby robić to, czego chcą, ale w rzeczywistości jesteśmy tam kwestionować to, co chcą robić i próbować to ulepszać. Więc pierwszą rzeczą, którą możesz zrobić, to porozmawiać z nimi o tym i wyjaśnić, w porządku, jeśli to zrobimy, będzie to długofalowy efekt. Wiesz, testowanie zajmie nam dodatkowy dzień. Za każdym razem, gdy tworzymy wydanie, doda to kilka godzin lub dwie za każdym razem, gdy będziemy potrzebować utrzymać witrynę i zaktualizować wszystkie wtyczki lub cokolwiek to jest. Ale podnosząc tę ​​świadomość, prowadzimy z nimi te rozmowy. Możesz sprawić, by klient był częścią tej dyskusji. A potem w końcu stają się częścią rozwiązywania problemów, z czym dobrze, musimy cały czas edukować naszych klientów, po prostu dlatego, że nie wiedzą niektórych rzeczy, które robimy. Gdyby tak było, w ogóle nie stałyby się narzędziami. Więc właściwie to jest punkt wyjścia. Uważa, że ​​pamiętaj o tym i upraszczaj rzeczy. Ponownie, ludzie niekoniecznie są tak techniczni jak my. Więc używaj analogii, aby o tym porozmawiać. Zawsze uważam, że domy to świetna energia. Wszyscy mieszkają w domu. Większość ludzi ma pewne doświadczenie w robieniu jakiegoś rodzaju remontu domu. Więc dość łatwo było wykorzystać tę energię do naprawienia rzeczy. Więc to jest pierwszy punkt, który naprawdę polega na tym, aby zdobyć klienta lub cykliczne rozmowy. Następną rzeczą, którą poruszyliśmy wcześniej, była długoterminowa perspektywa lub całkowity koszt posiadania. I zadawaj sobie te pytania i kwestionuj każdą prośbę o nową funkcję. Ale będąc trochę bardziej technicznym i jak byś to zrobił w pracy. Proste rzeczy, z których korzystasz, standardy WordPressa, które znasz, istnieją standardy, które tam są. Istnieją z jakiegoś powodu. Teraz pomogą nam deweloperowi i może pracujesz nad projektem, który odkładasz na rok lub dwa, a potem wracasz do niego. Musisz odświeżyć swoją pamięć i wrócić do miejsca, w którym byłeś, kiedy po raz pierwszy go zbudowałeś, używając standardów. Pomogą też innym ludziom. Więc jeśli nie byłeś w zespole, oznacza to, że masz ten wspólny język, z którego każdy może operować, a który jest naprawdę, bardzo przydatny pod względem wydajności i pomocy w dokumentacji i innych tego typu rzeczach. Jest to więc rodzaj łagodniejszego sposobu na zmniejszenie długu technicznego poprzez posiadanie standardów, które każdy może zastosować. Pomaga również wiedzieć, że może nadejść czas, w którym inni programiści WordPress będą pracować nad tym projektem. I pomaga im myśleć o tym jako o sposobie spłacenia społeczności i ułatwieniu innym programistom. Więc to jest, no wiesz, dobry punkt wokół pewnych standardów i ułatwienie sobie i innym. Kolejny jest bardziej o wielkim. Świetny kodeks branżowy, czule znany jako Wujek Bob, który wiele lat temu napisał wspaniałą książkę zatytułowaną Czysty koder. Gorąco polecam każdemu programiście przeczytanie tej książki, ponieważ jej nie przeczytali. Właściwie uczyniłem to obowiązkową lekturą dla zespołu programistów, dla każdego, kto dołączył do zespołu, głównie dlatego, że ma tak dobre podejście do tego, że mówi o testach jednostkowych, wszystkie tego rodzaju rzeczy, ale zasadniczo, dużo tego dotyczy tego, jak pisać kod w sposób, który czyni go elastycznym, dzięki czemu można bardzo szybko iterować, zmieniać i dodawać do niego dodatkowe bity. Jedną z głównych kwestii, o których mówi, jest częsta refaktoryzacja, a najważniejszą rzeczą, jaką należy z tego wyciągnąć, jest to, że piszesz fragment kodu, który niekoniecznie oznacza, że ​​ten fragment kodu jest skończony. Są rzeczy, które możesz zrobić, aby zoptymalizować go, aby był bardziej przenośny, aby był bardziej modułowy lub ulepszyć test, niezależnie od tego, co musisz zrobić, aby poświęcić czas na refaktoryzację kodu. To może być naprawdę, naprawdę trudne do zrobienia, gdy jesteś przeciwko temu lub wiesz, może to jeden przedział czasowy dla budżetu. Ale ostatecznie jest to rodzaj rzeczy, które powstrzymają cię od narastania długu technicznego i właściwie, zwykle w ten sposób, jak widzę, jest to wymuszane, ale jako ostateczny termin projektu musisz go dotrzymać. Absolutnie. Musisz to uderzyć, ale lepiej jest nagiąć zakres, niż pisać zły kod, który potem zrobisz,

DV: Myślę, że o tym też należy edukować tych klientów, bo tak jakbym nigdy nie spotkał dewelopera, który nie chciałby refaktoryzacji. Kod. To zawsze jest oś czasu. To jest przeciwko temu. Um, okej, więc oto ostatnia rzecz, jestem po prostu ciekawa, czy nas lubisz, jeśli myślisz o rzeczach takich jak odciążanie i używanie gotowych wtyczek, to kolejny sposób na uniknięcie technologii lub inny sposób na uniknięcie zadłużenia technologicznego. Czy to również znajduje się na twojej liście?

JM: Tak. 100% Więc to dobry sposób, ale jest to dobry sposób na zrobienie obu rzeczy, możesz uniknąć długu technicznego. Ale możesz też i wiesz, WordPress jest jedną z form BMC. Jest tak aktywny, że może być jego największym wrogiem. Jest wtyczka, która robi wszystko. Istnieje również wiele wtyczek, które zostały zbudowane w bardzo konkretnym celu, ale niekoniecznie pasują do twoich własnych wtyczek. Tak więc widziałem to szczególnie u niektórych programistów, którzy lubią budować witryny za pomocą wtyczek i bardziej wskaż i kliknij, zamiast kodować je od zera. Ludzie mają tendencję do rzucania wtyczek na różne rzeczy. Pracowaliśmy ze stronami internetowymi, które mają ponad 100 wtyczek, a kilka z nich nie jest już obsługiwanych. Wszędzie są kwestie bezpieczeństwa. Próbujesz i robisz tempo uwalniania. Spędzasz dosłownie cztery dni testując go, podczas gdy mogłeś to zrobić w kilka godzin. Więc wtyczki mogą być dobre lub złe. Właściwa wtyczka we właściwym czasie była cudowną, cudowną rzeczą. Największe atuty WordPressa, ale niewłaściwa wtyczka w nieodpowiednim czasie może być również bardzo szkodliwa. I faktycznie może być jednym z tych największych źródeł kapitału, które

DV: Na pewno miałem taki projekt. Cóż, John, to było niesamowicie wnikliwe. Dziękuję bardzo za przyłączenie się do nas dzisiaj.

JM: Z przyjemnością.

DV: Super. Jeśli chcesz dowiedzieć się więcej o tym, czym jest Jon, odwiedź hallam.co.uk. Dziękujemy wszystkim za wysłuchanie prasy podcastów społeczności WordPress na WMR. Ponownie, to był twój gospodarz David Vogelpohl. Wspieram społeczność WordPressa w ramach mojej roli w WP Engine i uwielbiam przedstawiać to, co najlepsze w społeczności tutaj na Press This.