Tekan Ini: Menghindari Hutang Teknologi yang Membunuh Waktu di WordPress Dibuat dengan Jon Martin

Selamat datang di Press This, podcast komunitas WordPress dari WMR. Di sini, tuan rumah David Vogelpohl duduk bersama tamu dari seluruh komunitas untuk membicarakan masalah terbesar yang dihadapi pengembang WordPress. Berikut ini adalah transkripsi dari rekaman aslinya.

Didukung oleh RedCircle

David Vogelpohl: Halo semuanya dan selamat datang di Press This podcast komunitas WordPress di WMR. Ini adalah tuan rumah Anda, David Vogelpohl, saya mendukung komunitas WordPress melalui peran saya di WP Engine, dan saya senang membawa yang terbaik dari komunitas untuk Anda dengar setiap minggu di pers ini sebagai pengingat, Anda dapat menemukan saya di Twitter @wpdavidv , atau kamu bisa berlangganan tekan ini di iTunes, iHeartRadio, Spotify, atau download episode terbaru di wmr.fm. Dalam episode ini kita akan berbicara tentang salah satu topik favorit saya, dan itu adalah menghindari waktu membunuh hutang teknologi di WordPress build. Dan bergabung dengan kami untuk percakapan ini, saya ingin menyambut Jon Martin. Jon, selamat datang di Press This.

Jon Martin: Terima kasih banyak, senang berada di sini.

DV: Saya tahu saya berlatih mengucapkan Hallum sebelum pertunjukan, tetapi tentu saja saya mengacaukannya di awal, John, maaf tentang itu. Luar biasa jadi bagi mereka yang mendengarkan John's akan membagikan pemikirannya tentang dampak utang teknologi bagi tim pengembangan WordPress seperti apa artinya memiliki utang teknologi dan bagaimana pengaruhnya terhadap Anda? Bagaimana Anda dapat berpikir untuk mengurangi utang teknologi Anda di setiap proyek. Lalu mengapa Anda memiliki tanggung jawab untuk berbagi pertimbangan utang teknologi dengan klien Anda

JM: jika Anda bekerja dalam kapasitas agensi freelancer. Jadi saya suka membunuh utang teknologi. Saya suka menghilangkannya adalah salah satu topik favorit saya.

DV: Kita akan membahas pemikiran John tentang topik tersebut, tetapi sebelum kita memulainya, John, saya akan menanyakan pertanyaan yang sama yang saya tanyakan kepada setiap tamu. Ceritakan secara singkat tentang cerita asal WordPress Anda. Kapan pertama kali Anda menggunakan WordPress

JM: jadi saya akan berada di awal 2010-an tidak begitu yakin ekspresi yang benar untuk periode waktu itu. Jadi saya benar-benar memulai sendiri dan saya telah menjadi CEO dari bagaimana kami memulai sebuah agensi pada tahun 2008. Dan pada saat itu, WordPress masih merupakan platform blogging. Kami sedang membangun situs web yang memiliki banyak konten kaya di dalamnya. Jadi ini agak kotor, tapi kami menggunakan Joomla saat itu. Tapi kemudian daripada

DV: Joomla adalah kata kotor. Saya suka semua CMS open source secara pribadi.

JM: Ya, kami ingin mengatakan bahwa ini adalah proyek yang hebat. Saya pikir kuncinya bagi kami adalah seiring waktu, di mana Joomla benar-benar sangat kuat ketika WordPress mengeluarkan dukungan situs pos kustom. Saat itulah hal-hal yang benar-benar berubah di WordPress bagi saya yang mengangkatnya dari yang dikenal sebagai platform blogging menjadi CMS yang sepenuhnya matang sehingga Anda dapat melakukan semua jenis situs apakah itu untuk Anda tahu, sangat kecil bisnis satu orang atau pekerja lepas atau apa pun, hingga situs web kompleks kelas perusahaan besar. Dan saya pikir sangat, sangat bagi saya, itu adalah keputusan yang mematikan di pihak mereka karena itu adalah bagian dari alasan mengapa WordPress begitu populer sekarang. Jadi ya, jadi saat itulah dia mulai menggunakannya di sini. Sasha cerita sebelum itu benar-benar saya dan sekarang CEO tentang bagaimana kami berada di sebuah band bersama. Dan kami memiliki ide cemerlang untuk berpikir, Nah, tahukah Anda, ini adalah waktu yang sama di jalan yang lebih mengagumkan dan sangat sulit untuk mendapatkan waktu libur dari pekerjaan saya saat ini. Jadi kami berpikir, Anda tahu, mari kita mulai agensi dan menjadi pengembang web karena itu akan sangat membantu mendapatkan semua waktu itu, itu adalah keputusan yang bagus. Saya benar-benar sangat senang dengan itu, tetapi dia juga tentu saja merupakan keputusan yang naif karena berpikir bahwa bekerja untuk diri sendiri memberi Anda lebih banyak waktu jelas merupakan kesalahan yang saya pikir kita sadari sedikit di kemudian hari. Dan sebelum itu, Anda tahu, saya tahu sedikit tentang SQL dan saya telah membangun komputer sejak lama, sebenarnya sejak kartu grafis sangat mendukung warna. Jadi bagi siapa saja yang tahu apa itu CGA, akan membantu Anda mengetahui berapa umur saya. Tapi ya, sungguh, saat itulah CPT keluar. Lemak itu mengubah segalanya bagi kami. Dan kami mulai menggunakan WordPress hampir dalam semalam, sebenarnya, yang menjadi CMS pilihan kami dan kami belum pernah melihat ke belakang sejak itu dan, Anda tahu,

DV: dari semua orang yang saya ajukan pertanyaan ini kepada Anda, sangat sedikit yang benar-benar mengetahui bagaimana jenis posting kustom materi relatif terhadap cerita asal WordPress mereka. Dan itu lucu. Saya punya cerita serupa. Saya mendirikan sebuah agensi pada tahun 2010. Jadi sedikit setelah Anda semua tetapi ketika pos kustom itu sudah masuk. Kami mulai membangun dengan Joomla dan beralih ke WordPress untuk alasan yang sama, tetapi jenis posting kustom dan meta kustom ini bidang yang saya setuju dan saya benar-benar disajikan dengan cara ini berbagai format adalah saat seperti inilah WordPress benar-benar menjadi CMS sejati. Setahun setelah itu WooCommerce muncul WP Engine muncul, banyak merek lain dari ruang WordPress, ini adalah waktu yang sangat transformatif. Sangat menarik untuk mendengar Anda jenis referensi yang merupakan akar dari cerita asal Anda. Mereka memberi tahu saya, tentang bagaimana um, dan Anda tahu, momen pendirian di sana jika Anda mau, tetapi bisakah Anda memberi tahu saya sedikit tentang bagaimana um, dan apa yang Anda lakukan?

JM: Ya, tentu. Jadi sebenarnya, badan yang kami temukan itu bukan bagaimana kami nanti motor. Baiklah baiklah. Nah, alasan utamanya sebenarnya adalah karena, Anda tahu, di masa lalu, ada perbedaan yang sangat mencolok antara, Anda tahu, kami membangun situs web versus kami melakukan SEO dan semua hal semacam itu. Dan tidak terlalu banyak pendekatan terintegrasi di seluruh dunia dan benar-benar memikirkan hal-hal seperti pengalaman pengguna, dan bagaimana cara kerjanya dengan SEO dan pengembangan, semua hal semacam itu. Jadi, itulah sebenarnya mengapa kami akhirnya bergabung kemudian, dengan Allen Milan telah ada selama sekitar 20 tahun dan pendiri kami mendirikan cukup banyak sejak awal ketika SEO mulai menjadi sesuatu. Jadi ya, jadi kami menggabungkan dua agensi. Enam, tujuh tahun yang lalu, mungkin sedikit lebih lama. Memori saya untuk data tidak bagus, harus saya akui. Dan kemudian, ya, itulah yang menjadi pendekatan kami. Apakah ini pendekatan terintegrasi penuh tentang menggabungkan semua disiplin ilmu yang berbeda ini bersama-sama untuk membantu orang melihat garisnya? Jadi sekarang kami melakukan PPC, SEO, PR digital, tentu saja, desain web dan ada peregangan merek, strategi digital, dan semua hal semacam ini, semua disiplin ilmu ini yang Anda perlukan untuk memiliki kehadiran digital yang baik dan kuat akhir-akhir ini. Apa peran Anda di sana, perusahaan? Jadi saya, jabatan saya adalah direktur teknis. Jadi saya akan jujur, tidak benar-benar cukup menutupi semua yang saya lakukan. Saya menjalankan tim pengembangan untuk jangka waktu yang lama. Jadi semua WordPress akan berada di bawah kepemimpinan saya. Saya senang untuk mengatakan bahwa kami memiliki pengembang yang jauh lebih baik dalam tim daripada Julio dan saya pernah bekerja ketika kami pertama kali memulai, itulah alasan mengapa kami melakukan jauh lebih baik akhir-akhir ini. Dan kami lebih memahami banyak hal. Jadi saya menjalankan tim pengembangan untuk jangka waktu yang lama baru-baru ini dengan biaya tim data juga. Jadi itu berarti saya bisa bermain dengan pembelajaran mesin, Python dan Bartek dan lainnya bermain meskipun saya harus membayangkan semua ini bermain.

DV: Melakukan klien terpisah yang keren akan menghasilkan beberapa hutang teknologi di sepanjang jalan. Jadi saya ingin tahu seperti apa pendapat Anda tentang, apa jenis hutang teknologi yang umum dan dan mungkin khusus untuk WordPress. Itu sebentar, tapi seperti, bagaimana Anda memikirkannya saat Anda memikirkan, Anda tahu, bagaimana dan bagaimana Anda mengelola utang teknologi Anda, seperti Anda telah menguncinya ke dalam tipe-tipe dengan WordPress yang dibangun?

JM: Ya, kami lakukan. Maksudku, tidak. Belum tentu. Kami melakukan jenis bahasa yang kami tidak perlu mengkategorikan sesuatu atau melalui proses distrik untuk mengkategorikan, tapi sungguh, mereka jatuh ke dalam tiga ember yang berbeda. Salah satunya adalah ketika Anda membuat kode yang buruk di atas kode yang ada, dan itu mungkin karena Anda mungkin membuat beberapa kesalahan di masa lalu yang mungkin merupakan masalah dari situs web Heritage dan orang lain apa pun alasannya, jadi itulah semacam ember pertama. Yang kedua adalah membangun kode yang tidak perlu, dan mungkin tidak diperlukan saat ini. Anda tahu, saya yakin kita semua pernah berada di ujung permintaan fitur dari klien dan merek yang bekerja sama dengan kita di mana mereka benar-benar tertarik untuk hal tertentu, tetapi sebenarnya mungkin bukan hal yang benar, dalam hal mendapatkan nilai aktual untuk pelanggan. Dan kemudian yang ketiga, yang merupakan yang terbesar yang kami lihat sebenarnya adalah membangun fitur yang seharusnya benar-benar berada di platform yang berbeda. Jadi memahami bagian arsitektur semacam itu tentang oke, apa saja bagian berbeda yang kami masukkan di sini adalah CRM di sini adalah situs webnya, yang pada dasarnya adalah tentang pemasaran bisnis. Inilah platform pemenuhan pesanan Anda, semuanya berbeda.

D V: Izinkan saya bertanya, izinkan saya mengajukan pertanyaan mendasar di sini seperti Anda telah membuat daftar tiga jenis suara seperti ini adalah tiga jenis hutang teknologi yang ingin Anda singkirkan menulis kode buruk pada kode buruk kode, itu tidak perlu fitur yang bisa dilakukan di platform lain. Seperti tidakkah ada ember keempat seperti fitur yang Anda inginkan yang berharga dan oleh karena itu teknologi yang mungkin bagus dalam kasus itu? Apakah itu adil untuk dikatakan? Itu ember keempat.

JM: Ya. 100% Maksud saya, tidak semua hutang teknis buruk. Ada Anda harus menerima bahwa hampir semua fitur yang akan Anda bangun akan menimbulkan beberapa jenis utang teknis dan Anda harus membuat panggilan tentang apakah utang teknis itu baik atau tidak. Beberapa baik, beberapa buruk dan sangat bergantung pada kata kunci yang saya katakan sebelumnya adalah tentang nilai. Apakah Anda akan mendapatkan nilai yang Anda butuhkan untuk hal itu? Lebih penting lagi, apakah pelanggan, pelanggan utama, bukan klien Anda, tetapi mereka adalah pelanggan mereka? Apakah mereka akan mendapatkan nilai untuk itu? Itu biasanya Cahaya Pemandu yang cukup bagus mengenai apakah akan menerima utang teknis itu.

DV: Ya, saya ingin sedikit menyelami Anda tahu, bagaimana pendapat Anda tentang kutipan itu, formula yang layak untuk kapan boleh menerima atau tidak, tetapi ada baiknya untuk memikirkan untuk mendapatkan pemahaman yang baik tentang bagaimana Anda memikirkannya berbagai jenis utang teknologi, dan khususnya yang mungkin ingin Anda optimalkan untuk dihapus. Apa yang ingin saya lakukan selanjutnya, adalah memahami seperti, apakah ada hal semacam itu yang mendorong Anda ke tepi untuk fokus di area ini, tetapi kami akan mengambil istirahat pertama kami dan kami akan segera kembali. Saatnya masuk ke jeda iklan. Nantikan yang lebih mendesak ini sebentar lagi. Halo semuanya. Selamat datang kembali untuk menekan ini podcast komunitas WordPress di W EMR Ini adalah tuan rumah Anda, David Vogel. Paulus. Saya mewawancarai John Martin tentang membatalkan waktu membunuh teknologi mati. John tepat sebelum jeda, Anda menjelaskan bahwa cara Anda memikirkan tiga jenis utang teknologi yang mungkin ingin Anda hilangkan adalah membangun kode yang buruk pada kode yang buruk. Membuat kode yang tidak diperlukan untuk keberhasilan situs yang sedang Anda kerjakan. Dan kemudian mungkin membangun kode untuk fitur yang dapat disajikan dengan lebih baik di platform lain. Sebelum kita masuk ke formula kutipan yang layak. Saya bertanya-tanya, apakah ada waktu tertentu yang saya tidak tahu dan perjalanan Anda adalah contoh tertentu dari hutang teknologi sehingga permukaan seperti itu bagi Anda adalah area fokus utama untuk bagaimana?

JM: Ya, tentu saja. Ada satu proyek penting yang membuat saya berpikir tentang ini sekitar empat atau lima tahun yang lalu. Saya telah melihat banyak kasus lain. Untuk bisnis memperoleh waktu, setiap saat, tidak hanya melalui WordPress melalui segala macam hal, sebenarnya bisnis memperolehnya melalui proses operasional mereka juga. Jika Anda harus menjadi hal teknis di mana Anda membuat dek itu. Satu, Satu cerita yang benar-benar menonjol di benak saya lebih dari apa pun adalah klien, kami bekerja dengan perusahaan yang relatif kecil, kami melakukan banyak pekerjaan media berbayar untuk mereka. Menjual pada dasarnya menjual barang secara online. Itu adalah bisnis eCommerce. Dan mereka memiliki jenis pesanan surat tradisional tetapi banyak pekerjaan mereka dan mereka mencoba untuk mengarahkan lebih banyak lalu lintas online sehingga mereka tidak harus melalui surat pesanan akan dikelola melalui situs web dan mereka datang kepada kami karena mereka telah memiliki situs yang dibangun untuk mereka sepenuhnya dipesan lebih dahulu. Dan mereka sudah ada selama sekitar 10 tahun pada saat itu. Jadi sudah cukup tua mulai merayap sedikit. Anda tahu, standar dan lanjutkan. Teknologi telah berkembang, saatnya untuk berpikir ulang. Jadi klien duduk bersama kami, mereka mulai menanyakan semua hal berbeda yang mereka lakukan di situs web. Dan menjadi sangat jelas dengan sangat cepat bagi saya bahwa ada semua jenis logika bisnis dan hal-hal operasional bisnis yang telah dibangun ke dalam situs web. Dan itu adalah logika yang mengarah pada pesanan dan sangat spesifik dengan cara mereka bekerja dengan pemasok. Jadi saya tidak akan membahas detailnya tetapi saya memiliki pengaturan yang cukup rumit antara pemasok dan bagaimana mereka memenuhi pesanan dan apakah itu dikirim ke toko mereka sebelum mengirimkan semua barang semacam ini. Jadi semuanya cukup rumit. Sekarang pemilik bisnis dan sebelumnya tentang bagaimana mereka bekerja, akhirnya membangun sebuah sistem yang cukup banyak mengatur bahwa semuanya adalah sistem yang sangat, sangat bagus pada saat itu dan benar-benar membantu bisnis itu tumbuh secara besar-besaran. Sekarang, apa yang belum benar-benar mereka pikirkan adalah bahwa semua situs web pada akhirnya memiliki masa simpan yang akan menjadi kehidupan di beberapa titik, sama seperti perangkat lunak apa pun dan di dunia pemasaran. Umur simpan itu benar-benar relatif singkat dibandingkan dengan, Anda tahu, misalnya, jika Anda berinvestasi dalam CRM karena bisnis biasanya akan memiliki waktu yang cukup lama sekarang sekitar 10 tahun, jika tidak lebih banyak situs web. Secara umum antara dua hingga lima tahun, kami menemukan paling tidak merek besar cenderung membangun kembali setiap tiga tahun atau lebih. Jadi masalahnya adalah mereka membangun semua logika rumit ini ke dalam situs web yang ada, dan mereka harus membangun kembali seluruh situs web. Dan tiba-tiba Anda harus membangun kembali semua logika bisnis ini juga. Sekarang, kami menghitung biaya proyek dan pada dasarnya berakhir menjadi sekitar setengah dari omset tahunan sebagai dasar hanya untuk membangun kembali apa yang sudah kami miliki. Dan yang benar-benar mulai membuat saya berpikir tentang hal ini adalah baik, oke, jika mereka mendekati masalah dengan cara yang berbeda pada awalnya, misalnya, mari kita pikirkan hal-hal berbeda yang coba kita capai di sebuah situs web. Anda tahu, ini dari pemasaran adalah ini untuk menjual produk. Ini untuk pemenuhan pesanan, ini yang terbaik untuk mengelola proses bisnis saya dengan memasok semua hal itu, dan memikirkan sedikit lebih banyak cara modular tentang itu, maka situasinya akan jauh berbeda untuk klien ini, bahwa dia ada di sana . Itu adalah masalah nyata bagi mereka karena mereka memiliki situs web yang pada dasarnya adalah tempat mereka menghasilkan uang. Itu berderit cukup banyak karena sudah cukup tua. Tetapi pada saat yang sama, akan menghabiskan banyak biaya untuk membangun kembali seluruh situs web itu dan membuat proyek menjadi sangat, sangat rumit. Kami berhasil menemukan beberapa pekerjaan yang cukup pintar tetapi juga tidak bagus sampai akhir untuk mencoba dan menggunakan apa yang sudah mereka miliki dan mengintegrasikannya tetapi kami tidak dapat mengutip tetapi Anda tahu, akhirnya menjadi jauh lebih menyakitkan jauh lebih lambat dan lebih banyak lagi mahal dari yang seharusnya. Jika arsitektur itu telah dipikirkan pada awalnya.

DV: Saya memiliki begitu banyak proyek yang ingin saya lupakan. Kami hanya seperti itu, dan saya dapat membayangkannya sekarang, saya membawa saya kembali ke masa lalu. Jadi seperti saya yang terdengar seperti cukup jelas itu sangat, saya pikir, dalam pelajaran penting untuk berpikir tentang jenis biaya untuk bisnis relatif terhadap refactor yang Anda rencanakan. Dan bagi saya, sepertinya jawaban yang jelas adalah Anda perlu merancangnya secara berbeda. Dan itu mungkin jalan yang lebih jelas jika Anda ingin menyukai apa yang harus Anda lakukan. Tapi saya pikir seperti banyak tim ketika mereka berpikir tentang utang teknologi, sepertinya mereka berpikir seperti, Oke, well, itu keren untuk melakukan hal ini, tapi apakah itu sepadan?

JM: Apakah layak saya mempertahankan hal ini dari waktu ke waktu? Jadi saya hanya ingin tahu bagaimana pendapat Anda tentang formula itu

D V: kapan, seperti, Kapan boleh memperkenalkan utang teknologi? Dan seberapa jauh menurut Anda tentang formula itu?

JM: Ya, Anda menyentuh poin yang sangat penting, Anda tahu, Anda berpikir tentang sifat pengembang, pengembang melakukan ini karena mereka suka melakukan hal-hal keren. Dan itulah, Anda tahu, sebagian besar motivasi kami adalah untuk belajar bagaimana melakukan hal-hal baru, teknologi baru, Anda tahu, kerangka kerja JavaScript baru, apa pun itu, dan itu secara alami memberi kami motivasi untuk membangun hal-hal keren, tapi kami tidak serta merta berpikir jangka panjang tentang itu, Anda tahu, kami masih akan mempertahankannya. Anda tahu, istri saya ingin mandi air panas di rumah saya, tetapi saya tahu bahwa seseorang akan membersihkannya dan saya akan jujur, saya tidak percaya siapa pun yang membersihkannya, adalah tipe pemikiran seperti itu. Jadi ini adalah pertanyaan yang sangat, sangat, sangat bagus untuk dipikirkan, apakah itu benar-benar layak dilakukan dan jika kita menguraikannya sedikit, ada beberapa hal berbeda yang dapat Anda pikirkan, pertama-tama, berpikir panjang istilah, berapa total biaya kepemilikan dan membangun benda itu untuk menguji dan memeliharanya, dan kemudian menimbangnya dengan nilai yang kita dapatkan? Jadi misalnya, mungkin ada cara yang sangat sederhana untuk menyelesaikan masalah itu. menggunakan spreadsheet atau menggunakan hal-hal arsitektur yang sedikit berbeda di mana mungkin seseorang secara internal di perusahaan mengelolanya untuk waktu yang singkat. Dan akan lebih murah untuk melakukan itu dan lebih efektif untuk melakukannya daripada membangun fitur yang sangat rumit ini. Tetapi ketika Anda benar-benar melihat total biaya kepemilikan, biayanya akan lebih mahal daripada seseorang yang menghabiskan beberapa jam seminggu untuk melakukan hal tertentu. Jangan salah paham. Saya sangat percaya pada otomatisasi. teknologi harus diotomatisasi sebanyak mungkin untuk menghindari admin semacam itu tetapi

DV: Anda mendaftar dan Anda menggunakan pendekatan manual seperti ini untuk menyukai mencoba sesuatu sebelum Anda membuat kode untuk memastikan nilai itu akan ada di sana. Maksud saya, saya mendapatkan ide untuk menyederhanakan faktor ini, seperti, Bisakah kita melakukannya secara manual? Hanya ingin tahu apakah Anda pernah mendekatinya dari seperti perspektif pengujian hingga suka, lihat apakah pengembalian pamungkasnya sepadan?

JM: Ya. 100%. Jadi saya sangat percaya pada metodologi Agile. Dan pada dasarnya, salah satu prinsip utama Agile adalah Anda membangun hal yang benar pada waktu yang tepat. Dan Anda fokus untuk mendapatkan nilai secepat mungkin. Jadi, Anda ingin membangun produk minimum yang layak. Sekarang, itu berarti Anda belum tentu memiliki sesuatu yang sepenuhnya kaya fitur pada saat itu. Tapi itu memberi Anda platform di mana Anda kemudian dapat mulai mengujinya, Anda tahu, apakah Anda benar-benar mendapatkan hal-hal yang Anda inginkan dari itu? Apakah pengguna Anda menanggapinya? Dengan cara yang Anda harapkan, siapa pun yang bekerja di UX atau pengembang web akan tahu bahwa cukup sering akan mendapatkan permintaan dari pelanggan karena mereka berpikir bahwa pelanggan mereka, tetapi sebenarnya apakah mereka benar-benar menginginkannya? Jadi, pertanyaan lain yang sangat bagus untuk diajukan adalah, setelah Anda memikirkan pandangan jangka panjang itu, apakah orang-orang yang akan menggunakan situs web apakah kami tahu bahwa seseorang menggunakannya atau apakah kami perlu mengujinya untuk melihat apakah mereka mau untuk menggunakannya? Dan kemudian setelah Anda melakukan tes itu, kami dapat mencari tahu apa yang seharusnya tidak kami minta dan apakah kami harus mundur dan benar-benar menempatkan investasi kami di tempat lain.

DV: Jadi sepertinya semacam rekap pemikiran ini dan saya menyukai ide Anda untuk melihat total biaya kepemilikan jangka panjang, Anda tahu, saya pikir sering kali tim berpikir bahkan orang yang Anda kenal, mengutip, memesan layanan dari tim berpikir berapa jam atau minggu atau spread atau poin atau apa pun yang akan dibangun. Tapi kemudian, Anda tahu, Anda perlu memperhitungkan bahwa Anda tahu, berapa jam atau minggu atau spread atau poin yang diperlukan untuk mempertahankan dan kemudian menggunakan keseimbangan itu terhadap nilai yang Anda dapatkan dari mempertahankan aktivitas itu. Anda jelas itu adalah nasihat yang bagus. Tapi kemudian Anda juga berpikir seperti, Nah, apakah ada yang bisa saya lakukan untuk menguji ini untuk melihat apakah asumsi saya benar? Apakah itu terdengar akurat?

JM: Ya. Sangat. Sangat. Dan satu-satunya hal yang tidak kami sentuh adalah yang telah kami bicarakan sebelumnya, yaitu tentang arsitektur, apakah ada cara yang lebih baik untuk membuat struktur ini menjadi lebih baik dan waktu untuk menolak pemrograman dan sebagainya yang mungkin akan saya bahas nanti.

DV: Ya, pertimbangan arsitektur juga, seperti yang saya tuliskan seperti apa Anda, apakah ada cara kami dapat mengubah spesifikasi? Apakah seperti dalam pelatihan atau pembicaraan pemangku kepentingan saya, saya sering mengatakan Anda tahu, spek untuk mengajukan kan? Mintalah apa yang benar-benar Anda butuhkan untuk menginap. Jadi menanyakan itu akan berbohong dan benar-benar dibutuhkan dan bagaimana dengan ini? Pertanyaan telah saya temukan sangat kritis. Jadi sepertinya itulah bagian penting dari cara Anda memikirkan hal ini.

JM: Ya, karena setiap menit situs itu dalam pengembangan adalah menit yang tidak mendapatkan nilai di depan pelanggan. Dan itulah cara mudah untuk memikirkannya. Anda ingin diluncurkan secepat mungkin. Dan kemudian uji, pantau, ulangi, pelajari, Anda tahu, lihat ke mana Anda pergi dari sana, tetapi hanya karena Anda melakukannya berdasarkan data aktual daripada apa yang menurut Anda benar. Karena seringkali mereka tidak sama.

DV: Ya, saya suka poin itu. Setiap menit. Ada di dev, bukankah semenit Anda tidak menggunakannya cari tahu dan saya akan mengatakan ikatan kembali ke jenis ikatan kembali ke mantra lain yang saya miliki dan manajemen proyek dan manajemen pemangku kepentingan, yang merupakan dua kata terbaik dan mendapatkan proyek di wajah kita untuk menulis. Bagaimana Anda bisa berbicara ya, saya suka itu ketika saya berurusan dengan pemangku kepentingan, atau ketika saya memiliki pemangku kepentingan adalah bagian yang kuat dan kuat. Oke, keren. Um, mari kita bicara selanjutnya tentang apa yang dapat dilakukan tim untuk mengurangi utang teknologi. Tapi sebelum kita melakukan itu, kita akan istirahat terakhir. Saatnya masuk ke jeda iklan. Menantikan untuk lebih menekan ini hanya dalam beberapa saat. Semuanya dipersilakan kembali untuk menekan podcast komunitas WordPress ini di W EMR. Ini adalah tuan rumah Anda David mobile Paul, saya sedang berbicara tentang menghindari waktu membunuh hutang teknologi dengan John Martin tentang bagaimana John tepat sebelum jeda, kami berbicara sedikit tentang formula nilai Anda Saya sangat menyukai gagasan Anda tentang pengurangan spesifikasi. Dan berpikir tentang TCO dan, dan mengambil pendekatan pengujian berulang. Tapi mari kita gali sekarang apa yang sebenarnya bisa dilakukan tim untuk mengurangi utang teknologi dan pembangunan WordPress mereka. Apa saja teknik favorit Anda untuk mengurangi utang teknologi?

JM: Jadi ada semua jenis teknik teknis yang dapat Anda gunakan dan Anda tahu beberapa di antaranya akan Anda ketahui sehingga Anda tidak akan melakukannya, tetapi sebenarnya titik awalnya bagi saya adalah, pendekatan yang lebih lunak terhadap pembicaraan. kepada klien Anda. Dan Anda harus ingat bahwa pada akhirnya, klien Anda adalah merek-merek ini yang datang kepada kami karena kami ahlinya. Mereka membutuhkan saran kita dan cukup mudah untuk jatuh ke dalam perangkap bahwa, Anda tahu, kita di sana hanya untuk melakukan apa yang mereka inginkan, apa yang kita lakukan di sana untuk melakukan apa yang mereka ingin kita lakukan, tetapi sebenarnya, kita ada di sana untuk menantang apa yang ingin mereka lakukan dan mencoba serta memperbaikinya. Jadi hal pertama yang dapat Anda lakukan adalah membicarakannya dengan mereka dan menjelaskannya dengan baik, jika kita melakukannya, ini akan menjadi efek jangka panjangnya. Anda tahu, itu akan membawa kita satu hari ekstra untuk pengujian. Setiap kali kami melakukan rilis, itu akan menambah beberapa atau dua jam setiap kali kami perlu memelihara situs web dan memperbarui semua plugin atau apa pun itu. Tetapi dengan meningkatkan kesadaran itu, kami melakukan percakapan itu dengan mereka. Anda bisa mendapatkan klien untuk menjadi bagian dari diskusi itu. Dan akhirnya mereka menjadi bagian dari pemecahan masalah dengan baik, kami harus mendidik klien kami sepanjang waktu, hanya karena mereka tidak tahu beberapa hal yang kami lakukan. Jika mereka melakukannya, mereka tidak akan menjadi alat sejak awal. Jadi sebenarnya, itulah titik awalnya. Dia pikir ingat itu serta menyederhanakan hal. Sekali lagi, orang tidak selalu teknis seperti kita. Jadi gunakan analogi untuk membicarakannya. Saya selalu menemukan bahwa rumah adalah energi yang besar. Semua orang tinggal di rumah. Kebanyakan orang memiliki pengalaman melakukan semacam perbaikan rumah. Jadi cukup mudah menggunakan energi itu untuk memperbaiki keadaan. Jadi itulah jenis poin pertama yang sebenarnya adalah mendapatkan klien atau memutar percakapan itu. Hal berikutnya yang telah kami sentuh sebelumnya adalah memiliki pandangan jangka panjang atau total biaya kepemilikan. Dan tanyakan pada diri Anda pertanyaan-pertanyaan itu dan pertanyakan setiap permintaan fitur. Tetapi menjadi sedikit lebih teknis dan bagaimana Anda akan melakukan ini di tempat kerja. Hal sederhana yang Anda gunakan standar WordPress lho, ada standar yang ada. Mereka memang ada karena suatu alasan. Sekarang, mereka akan membantu kami sebagai pengembang dan mungkin Anda mengerjakan proyek yang Anda letakkan selama satu atau dua tahun dan kemudian Anda kembali ke sana. Anda harus menyegarkan ingatan Anda dan kembali ke tempat Anda saat pertama kali membangunnya menggunakan standar akan membantu. Mereka juga akan membantu orang lain. Jadi jika Anda tidak berada di dalam tim, itu berarti Anda memiliki bahasa umum yang dapat digunakan oleh semua orang yang sangat, sangat berguna dalam hal efisiensi dan, dan membantu dengan dokumentasi dan semua hal semacam ini. Jadi itu semacam cara yang lebih lembut untuk mengurangi hutang teknis Anda dengan memiliki standar yang bisa dikerjakan siapa saja. Ini juga membantu Anda mengetahui, saatnya mungkin tiba di mana beberapa pengembang WordPress lain sedang mengerjakan proyek itu. Dan itu membantu mereka untuk menganggapnya sebagai cara membayar kembali komunitas dan mempermudah sesama pengembang Anda. Jadi, itulah, Anda tahu, poin bagus seputar jenis standar dan membuatnya mudah untuk diri sendiri dan orang lain. Yang berikutnya lebih tentang hebat. Kode industri yang hebat, yang dikenal sebagai Paman Bob, yang menulis buku luar biasa berjudul The clean coder bertahun-tahun yang lalu. Saya akan sangat menyarankan pengembang mana pun untuk membaca buku itu karena mereka belum membacanya. Faktanya, saya telah menjadikannya bacaan wajib untuk tim pengembangan, untuk siapa saja yang bergabung dengan tim, terutama karena dia memiliki pendekatan yang baik untuk itu berbicara tentang pengujian unit, semua hal semacam ini, tetapi pada dasarnya, banyak dari itu ada di sekitar bagaimana Anda menulis kode dengan cara yang membuatnya fleksibel sehingga Anda dapat dengan cepat mengulangi dan mengubah dan menambahkan bit ekstra ke dalamnya. Salah satu poin besar yang dia bicarakan adalah tentang refactoring sering, dan ini adalah hal utama untuk mengambil dari itu adalah bahwa Anda menulis sepotong kode yang tidak berarti bahwa potongan kode selesai. Ada beberapa hal yang dapat Anda lakukan untuk mengoptimalkannya agar lebih portabel untuk membuatnya lebih modular atau atau membuat pengujian lebih baik, apa pun hal khusus yang perlu Anda lakukan untuk menghabiskan waktu memfaktorkan ulang kode. Ini bisa sangat, sangat sulit dilakukan ketika Anda menghadapinya atau Anda tahu, mungkin itu satu kerangka waktu untuk anggaran. Tetapi pada akhirnya, itu adalah jenis hal yang akan menghentikan Anda dari hutang teknis dan sebenarnya, biasanya itulah cara yang saya lihat dipaksakan, tetapi sebagai tenggat waktu proyek, Anda harus mencapai tenggat waktu itu. Sangat. Anda harus melakukannya, tetapi lebih baik melenturkan cakupan daripada menulis kode buruk yang akan Anda lakukan,

DV: Saya kira, beri tahu klien itu tentang itu juga, karena seperti saya belum pernah bertemu pengembang yang tidak ingin melakukan refactor. Kode. Itu selalu timeline. Ini menentangnya. Um, oke, jadi inilah bagian terakhir. Saya hanya ingin tahu apakah Anda menyukai kami, jika Anda memikirkan hal-hal seperti membongkar muatan dan menggunakan plugin yang tersedia adalah cara lain untuk membantu menghindari teknologi atau cara lain untuk menghindari utang teknologi. Apakah itu ada dalam daftar Anda juga?

JM: Ya. 100% Jadi itu cara yang baik, tapi itu cara yang baik untuk melakukan keduanya sebenarnya, Anda dapat menghindari hutang teknis. Tapi Anda juga bisa dan ini lho, WordPress adalah salah satu bentuk BMC. Ini sangat aktif, sama-sama, itu juga bisa menjadi musuh terburuknya. Ada plugin yang melakukan segalanya. Dan ada juga banyak plugin yang dibuat untuk tujuan yang sangat spesifik, tetapi tidak selalu cocok dengan plugin Anda sendiri. Jadi saya telah melihat ini terutama dengan beberapa pengembang yang suka membangun situs menggunakan plugin dan lebih banyak pendekatan titik dan klik terhadap berbagai hal daripada mengkodekannya dari sudut pandang awal. Orang cenderung membuang plugin pada sesuatu. Kami telah bekerja dengan situs web yang memiliki lebih dari 100 plugin dan banyak di antaranya tidak dikelola lagi. Ada masalah keamanan di mana-mana. Anda mencoba dan melakukan tingkat rilis. Anda benar-benar menghabiskan empat hari untuk mengujinya ketika Anda bisa melakukannya dalam beberapa jam. Jadi plugin bisa bagus atau bisa buruk. Colokan yang tepat pada waktu yang tepat adalah hal yang luar biasa dan luar biasa. Kekuatan terbesar WordPress, tetapi plug in yang salah pada waktu yang salah juga bisa sangat merusak. Dan sebenarnya bisa menjadi salah satu sumber modal terbesar yang

DV: Saya pasti punya proyek seperti itu. Yah, John, ini sangat berwawasan luas. Terima kasih banyak telah bergabung dengan kami hari ini.

J M: Dengan senang hati.

DV: Luar biasa. Jika Anda ingin mempelajari lebih lanjut tentang Jon, Anda dapat mengunjungi hallam.co.uk. Terima kasih, semuanya telah mendengarkan press podcast komunitas WordPress ini di WMR. Sekali lagi, ini telah menjadi tuan rumah Anda David Vogelpohl. Saya mendukung komunitas WordPress sebagai bagian dari peran saya di WP Engine dan saya senang membawa komunitas terbaik di Press This.