กดปุ่มนี้: หลีกเลี่ยงหนี้เทคโนโลยีที่ฆ่าเวลาบน WordPress บิวด์ด้วย Jon Martin

ยินดีต้อนรับสู่ Press This พอดคาสต์ชุมชน WordPress จาก WMR โฮสต์ David Vogelpohl อยู่ที่นี่พร้อมกับแขกจากทั่วชุมชนเพื่อพูดคุยเกี่ยวกับปัญหาที่ใหญ่ที่สุดที่นักพัฒนา WordPress กำลังเผชิญ ต่อไปนี้เป็นการถอดความจากการบันทึกต้นฉบับ

ขับเคลื่อนโดย RedCircle

David Vogelpohl: สวัสดีทุกคนและยินดีต้อนรับสู่ Press This the WordPress community podcasts on WMR นี่คือโฮสต์ของคุณ David Vogelpohl ฉันสนับสนุนชุมชน WordPress ผ่านบทบาทของฉันที่ WP Engine และฉันชอบที่จะนำเสนอสิ่งที่ดีที่สุดของชุมชนให้คุณได้ยินทุกสัปดาห์ในการกดนี้เพื่อเป็นการเตือนความจำ คุณสามารถหาฉันได้บน Twitter @wpdavidv หรือสมัครรับข่าวสารทาง iTunes, iHeartRadio, Spotify หรือดาวน์โหลดตอนล่าสุดได้ที่ wmr.fm ในตอนนี้ เราจะพูดถึงหนึ่งในหัวข้อที่ฉันโปรดปราน และนั่นคือการหลีกเลี่ยงเวลาที่จะทำลายหนี้เทคโนโลยีบน WordPress builds และขอต้อนรับ Jon Martin ในการเข้าร่วมการสนทนาครั้งนี้ จอน ยินดีต้อนรับสู่ Press This

Jon Martin: ขอบคุณมาก ดีใจที่ได้มาอยู่ที่นี่

DV: ฉันรู้ว่าฉันฝึกออกเสียง Hallum ก่อนการแสดง แต่แน่นอนว่าฉันทำมันพังในตอนแรก John ขอโทษเกี่ยวกับเรื่องนั้น ยอดเยี่ยม สำหรับผู้ที่ฟังด้วย John's จะมาแบ่งปันความคิดของเขาเกี่ยวกับผลกระทบของหนี้เทคโนโลยีต่อทีมพัฒนา WordPress เช่น การมีหนี้เทคโนโลยีหมายความว่าอย่างไร และสิ่งนี้ส่งผลต่อคุณอย่างไร คุณคิดอย่างไรเกี่ยวกับการลดหนี้ด้านเทคโนโลยีในทุกโครงการ แล้วทำไมคุณถึงมีความรับผิดชอบในการแบ่งปันข้อพิจารณาเกี่ยวกับหนี้ด้านเทคโนโลยีกับลูกค้าของคุณ

JM: ถ้าคุณทำงานในหน่วยงานอิสระ ดังนั้นฉันชอบที่จะฆ่าหนี้เทคโนโลยี ฉันชอบที่จะกำจัดมันเป็นหนึ่งในหัวข้อที่ฉันชอบ

DV: เราจะลงลึกถึงความคิดของ John ในหัวข้อนี้ แต่ก่อนที่เราจะเริ่มต้นนั้น John ฉันจะถามคำถามเดียวกับคุณที่ฉันถามแขกทุกคน บอกฉันสั้น ๆ เกี่ยวกับเรื่องราวที่มาของ WordPress ของคุณ คุณใช้ WordPress . ครั้งแรกเมื่อใด

JM: ดังนั้นฉันจะอยู่ในช่วงต้นปี 2010 ไม่แน่ใจว่านิพจน์ที่ถูกต้องสำหรับช่วงเวลานั้นเป็นอย่างไร จริงๆ แล้วฉันเริ่มต้นตัวเองและเป็น CEO ของวิธีที่เราเริ่มต้นเอเจนซี่ในปี 2008 และในขณะนั้น WordPress ยังคงเป็นแพลตฟอร์มการเขียนบล็อกเป็นอย่างมาก เรากำลังสร้างเว็บไซต์ที่มีเนื้อหามากมาย ดังนั้นจึงเป็นคำสกปรกเล็กน้อย แต่ตอนนั้นเราใช้ Joomla แต่แล้วมากกว่า

DV: Joomla เป็นคำสกปรก ฉันชอบโอเพ่นซอร์ส CMS ทั้งหมดเป็นการส่วนตัว

JM: ใช่ เราอยากจะบอกว่ามันเป็นโครงการที่ยอดเยี่ยม ฉันคิดว่าสิ่งสำคัญสำหรับเราคือเมื่อเวลาผ่านไป ซึ่ง Joomla นั้นแข็งแกร่งมากเมื่อ WordPress ให้การสนับสนุนไซต์โพสต์ที่กำหนดเอง นั่นคือตอนที่สิ่งต่าง ๆ เปลี่ยนไปจริงๆใน WordPress สำหรับฉันที่ยกระดับจากสิ่งนี้จากที่รู้จักกันในชื่อแพลตฟอร์มบล็อกเป็น CMS ที่มีคุณสมบัติครบถ้วนซึ่งคุณสามารถทำไซต์ได้ทุกประเภทไม่ว่าจะเป็นสำหรับคุณหรือไม่ก็ตาม ธุรกิจคนเดียวหรือนักแปลอิสระหรืออะไรก็ตาม จนถึงระดับองค์กรขนาดใหญ่ เว็บไซต์ที่ซับซ้อน และฉันคิดว่าจริงๆ แล้ว สำหรับฉัน นั่นเป็นการตัดสินใจที่ร้ายกาจสำหรับพวกเขา เพราะมันเป็นส่วนหนึ่งของเหตุผลว่าทำไม WordPress จึงเป็นที่นิยมในตอนนี้ ใช่แล้ว นั่นคือตอนที่เธอเริ่มใช้ที่นี่ Sasha เรื่องราวก่อนหน้านั้นคือตัวฉันจริงๆ และตอนนี้เป็น CEO ว่าเราอยู่ในวงดนตรีด้วยกันได้อย่างไร และเรามีความคิดที่เฉียบแหลมในการคิด คุณรู้อะไรไหม มันยอดเยี่ยมมากที่มีเวลาเท่าเทียมกันบนท้องถนน และมันยากมากจริงๆ ที่จะได้พักจากงานปัจจุบันของฉัน ดังนั้นเราจึงคิดว่า คุณรู้อะไรไหม เรามาเริ่มต้นเอเจนซี่และเป็นนักพัฒนาเว็บกันเถอะ เพราะนั่นจะช่วยให้ย้อนเวลากลับไปได้จริงๆ นั่นเป็นการตัดสินใจที่ยอดเยี่ยม ฉันพอใจจริงๆ กับเรื่องนี้ แต่เขาก็เป็นการตัดสินใจที่ไร้เดียงสาเช่นกัน เพราะการคิดว่าการทำงานให้ตัวเองให้เวลาคุณมากขึ้นนั้นเป็นความผิดพลาดที่ฉันคิดว่าเราจำได้ในภายหลัง และก่อนหน้านั้น คุณก็รู้ ฉันรู้เรื่อง SQL มาบ้างแล้ว และฉันก็ได้สร้างคอมพิวเตอร์ขึ้นมาตั้งแต่นั้นเป็นต้นมา เนื่องจากการ์ดกราฟิกรองรับสีได้ดีมาก ดังนั้นสำหรับใครก็ตามที่รู้ว่า CGA คืออะไร จะช่วยให้คุณรู้ว่าฉันอายุเท่าไหร่ แต่ใช่ จริงๆ แล้ว เมื่อ CPTs ออกมา ไขมันนั้นเปลี่ยนทุกอย่างสำหรับเรา และเราเริ่มใช้ WordPress เกือบชั่วข้ามคืน อันที่จริง นั่นกลายเป็น CMS ที่เราเลือก และเราไม่ได้มองย้อนกลับไปตั้งแต่นั้นเป็นต้นมา และคุณก็รู้

DV: ในบรรดาคนที่ฉันถามคำถามนี้กับคุณ มีเพียงไม่กี่คนที่รู้จริง ๆ ว่าประเภทโพสต์ที่กำหนดเองของวัสดุนั้นสัมพันธ์กับเรื่องราวที่มาของ WordPress อย่างไร และมันก็ตลก ฉันมีเรื่องที่คล้ายกัน. ฉันก่อตั้งเอเจนซี่ขึ้นในปี 2010 หลังจากนั้นไม่นาน แต่เมื่อโพสต์แบบกำหนดเองก็มีเข้ามาแล้ว เราเริ่มสร้างด้วย Joomla และเปลี่ยนไปใช้ WordPress ด้วยเหตุผลที่คล้ายกัน แต่เป็นประเภทโพสต์ที่กำหนดเองและเมตาที่กำหนดเอง ด้านที่ข้าพเจ้าเห็นด้วยและข้าพเจ้าได้นำเสนอในรูปแบบต่างๆ เช่นนี้ คือ ช่วงเวลาเช่นนี้เองที่ WordPress กลายเป็น CMS ที่แท้จริง หนึ่งปีหลังจากที่ WooCommerce เกิดขึ้น WP Engine ก็เกิดขึ้น พื้นที่ WordPress แบรนด์อื่น ๆ มากมาย เป็นช่วงเวลาแห่งการเปลี่ยนแปลง เป็นเรื่องที่น่าสนใจที่จะได้ยินข้อมูลอ้างอิงของคุณซึ่งเป็นรากฐานของเรื่องราวต้นกำเนิดของคุณ พวกเขากำลังบอกฉันว่า อืม และคุณรู้ไหม ช่วงเวลาที่ก่อตั้งที่นั่น ถ้าคุณต้องการ แต่คุณช่วยบอกฉันหน่อยได้ไหมว่า อืม เป็นอย่างไร และคุณทำอะไร

J M: ใช่ แน่นอน อันที่จริงแล้ว เอเจนซี่นั้นที่เราพบว่าไม่ใช่วิธีที่เราใช้ขับเคลื่อนในภายหลัง ตกลงตกลง. เหตุผลหลักสำหรับเรื่องนั้นจริงๆ ก็เพราะว่า ย้อนกลับไปในสมัยก่อนนั้น มีความแตกต่างค่อนข้างชัดเจนระหว่าง คุณรู้ไหม เราสร้างเว็บไซต์กับเราทำ SEO และสิ่งต่างๆ เหล่านี้ และไม่ใช่ว่าหลายๆ คนทั่วโลกผสมผสานวิธีการและการคิดจริงๆ เกี่ยวกับสิ่งต่างๆ เช่น ประสบการณ์ของผู้ใช้ และการทำงานร่วมกับ SEO และการพัฒนา อะไรทำนองนั้น นั่นคือเหตุผลที่เราลงเอยด้วยการควบรวมในภายหลัง โดยที่ Allen Milan อยู่มาประมาณ 20 ปีแล้ว และผู้ก่อตั้งของเราตั้งขึ้นค่อนข้างมากในตอนเริ่มต้นเมื่อ SEO เริ่มกลายเป็นสิ่งหนึ่ง ใช่ ดังนั้นเราจึงรวมสองเอเจนซี่เข้าด้วยกัน หก เจ็ดปีที่แล้ว อาจจะนานกว่านี้หน่อย หน่วยความจำข้อมูลของฉันไม่ดีฉันต้องยอมรับ แล้วที่จริง นั่นคือแนวทางของเรา นั่นคือแนวทางแบบบูรณาการเต็มรูปแบบ เกี่ยวกับการผสมผสานศาสตร์ต่างๆ เหล่านี้เข้าด้วยกัน เพื่อช่วยให้ผู้คนเห็นแนวทางหรือไม่ ดังนั้นตอนนี้เราทำ PPC, SEO, ประชาสัมพันธ์ดิจิทัล, แน่นอน, การออกแบบเว็บและมีการขยายแบรนด์, กลยุทธ์ดิจิทัล, และสิ่งเหล่านี้ทั้งหมด, สาขาวิชาเหล่านี้ทั้งหมดที่คุณต้องมีตัวตนดิจิทัลที่ดีในปัจจุบัน คุณมีบทบาทอะไรที่นั่น บริษัท? ดังนั้นตำแหน่งงานของฉันคือผู้อำนวยการด้านเทคนิค พูดตามตรง ไม่ได้ครอบคลุมทุกสิ่งที่ฉันทำจริงๆ ฉันบริหารทีมพัฒนามาเป็นเวลานาน ดังนั้น WordPress ทั้งหมดจะอยู่ภายใต้การดูแลของฉัน ฉันดีใจที่จะบอกว่าเรามีนักพัฒนาในทีมที่ดีกว่าเรามากในตอนนั้น Julio และฉันก็เคยทำงานตั้งแต่เริ่มต้น ซึ่งเป็นเหตุผลว่าทำไมเราถึงทำได้ดีกว่านี้มากในทุกวันนี้ และเราเข้าใจสิ่งต่าง ๆ มากขึ้นเล็กน้อย ดังนั้นฉันจึงบริหารทีมพัฒนาเป็นเวลานานเมื่อเร็ว ๆ นี้ด้วยต้นทุนของทีมข้อมูลเช่นกัน นั่นหมายความว่าฉันได้เล่นด้วยแมชชีนเลิร์นนิง Python และ Bartek และคนอื่นๆ กำลังเล่นอยู่ แม้ว่าฉันจะจินตนาการถึงการเล่นทั้งหมดนี้

DV: การทำลูกค้าแยกกันที่ยอดเยี่ยมจะส่งผลให้เกิดหนี้เทคโนโลยีบางส่วนไปพร้อมกัน ดังนั้นฉันจึงอยากรู้ว่าคุณคิดอย่างไร หนี้เทคโนโลยีประเภทใดทั่วไป และอาจเฉพาะเจาะจงสำหรับ WordPress สิ่งเหล่านั้นสักครู่ แต่เช่น คุณคิดอย่างไรเกี่ยวกับสิ่งนั้น ขณะที่คุณคิด คุณรู้ วิธีและวิธีจัดการหนี้เทคโนโลยีของคุณ เหมือนกับที่คุณล็อกไว้เป็นประเภทด้วย WordPress ที่สร้างขึ้น

JM: ใช่เราทำ ฉันหมายความว่าไม่ ไม่จำเป็น. เรากำลังใช้ภาษาที่เราไม่จำเป็นต้องจัดหมวดหมู่ของสิ่งของต่างๆ หรือผ่านกระบวนการของเขตเพื่อจัดหมวดหมู่ แต่จริงๆ แล้ว พวกมันแบ่งออกเป็นสามกลุ่มที่แตกต่างกัน หนึ่งในนั้นคือเมื่อคุณสร้างโค้ดที่ไม่ถูกต้องทับโค้ดที่มีอยู่ และนั่นอาจเป็นเพราะคุณอาจทำผิดพลาดในอดีตซึ่งอาจเป็นปัญหาจากเว็บไซต์เฮอริเทจและคนอื่นไม่ว่าจะด้วยเหตุผลใดก็ตาม นั่นคือ ประเภทของถังแรก อันที่สองคือการสร้างโค้ดที่ไม่จำเป็น และอาจไม่จำเป็นในตอนนี้ รู้ไหม ฉันแน่ใจว่าเราทุกคนต่างได้รับคำขอคุณลักษณะจากลูกค้าและแบรนด์ที่เราทำงานด้วยซึ่งพวกเขากระตือรือร้นในสิ่งใดสิ่งหนึ่งเป็นพิเศษ แต่จริงๆ แล้วอาจไม่ใช่สิ่งที่ถูกต้องในแง่ของการได้รับมูลค่าที่แท้จริง สำหรับลูกค้า แล้วอันที่สาม ซึ่งเป็นส่วนที่ใหญ่ที่สุดที่เราเห็นคือ การสร้างคุณลักษณะที่จริงๆ แล้วควรจะอยู่บนแพลตฟอร์มอื่น ดังนั้นการทำความเข้าใจเกี่ยวกับสถาปัตยกรรมประเภทนั้นเกี่ยวกับโอเค ส่วนต่าง ๆ ที่เรากำลังเชื่อมต่อในที่นี้คือ CRM ที่นี่คือเว็บไซต์ ซึ่งโดยพื้นฐานแล้วเป็นเรื่องเกี่ยวกับการตลาดของธุรกิจ นี่คือแพลตฟอร์มการปฏิบัติตามคำสั่งซื้อของคุณ ทั้งหมดนั้นแตกต่างกัน

D V: ให้ฉันถามคุณ ให้ฉันถามคุณด้วยคำถามพื้นฐานที่นี่ เหมือนที่คุณระบุเสียงสามประเภทเช่นหนี้เทคโนโลยีสามประเภทที่คุณต้องการกำจัดการเขียนโค้ดที่ไม่เหมาะสมบนโค้ดที่ไม่ดี รหัสนั่นไม่ใช่คุณสมบัติที่จำเป็นที่สามารถทำได้บนแพลตฟอร์มอื่น ชอบไม่มีถังที่สี่เช่นคุณสมบัติที่คุณต้องการที่มีคุณค่าและดังนั้นเทคโนโลยีที่อาจดีในกรณีนั้น? มันยุติธรรมไหมที่จะพูด? นั่นคือถังที่สี่

JM: ครับ ฉันหมายถึง 100% ไม่ใช่หนี้ทางเทคนิคทั้งหมดที่ไม่ดี คุณต้องยอมรับว่าฟีเจอร์ใดๆ ที่คุณจะสร้างจะสร้างหนี้ทางเทคนิคบางประเภท และคุณต้องโทรไปสอบถามว่าหนี้ทางเทคนิคนั้นดีหรือไม่ บางอย่างดี บางอย่างไม่ดี และขึ้นอยู่กับว่าคีย์เวิร์ดที่ฉันพูดก่อนหน้านี้เกี่ยวกับค่า คุณจะได้รับคุณค่าที่คุณต้องการสำหรับสิ่งนั้นหรือไม่? ที่สำคัญกว่านั้นคือลูกค้า ลูกค้าคนสุดท้าย ไม่ใช่ลูกค้าของคุณ แต่เป็นลูกค้าของพวกเขาใช่หรือไม่ พวกเขาจะได้รับความคุ้มค่าหรือไม่? ซึ่งมักจะเป็นแนวทางที่ดีทีเดียวว่าจะรับหนี้ทางเทคนิคนั้นหรือไม่

DV: ใช่ ฉันอยากจะลงลึกในสิ่งที่คุณรู้ว่าคุณคิดอย่างไรเกี่ยวกับคำพูดนั้น สูตรที่คุ้มค่าสำหรับเวลาที่มันโอเคที่จะยอมรับหรือไม่ แต่มันก็ดีที่จะคิดเกี่ยวกับความเข้าใจที่ดีว่าคุณคิดอย่างไร หนี้เทคโนโลยีประเภทต่างๆ และโดยเฉพาะอย่างยิ่งที่คุณอาจต้องการเพิ่มประสิทธิภาพเพื่อลบ สิ่งที่ฉันต้องการจะทำต่อไปคือ ทำความเข้าใจกับสิ่งที่ชอบ ว่ามีสิ่งหนึ่งที่ผลักดันให้คุณมุ่งความสนใจไปที่บริเวณนี้ แต่เรากำลังจะพักครั้งแรกแล้วเราจะ เดี๋ยวกลับมา. ถึงเวลาเสียบเข้ากับช่วงพักโฆษณา คอยติดตามการกดเพิ่มเติมนี้สักครู่ สวัสดีทุกคน. ยินดีต้อนรับกลับมากดพอดคาสต์ชุมชน WordPress บน W EMR นี่คือโฮสต์ของคุณ David Vogel พอล. ฉันกำลังสัมภาษณ์ John Martin เกี่ยวกับการสละเวลาฆ่าเทคโนโลยีที่ตายแล้ว จอห์นก่อนจะหยุดพัก คุณได้อธิบายว่าวิธีที่คุณคิดเกี่ยวกับหนี้เทคโนโลยีสามประเภทที่คุณอาจต้องการกำจัดคือการสร้างโค้ดที่ไม่ถูกต้องบนโค้ดที่เสียหายซึ่งสร้างโค้ดที่ไม่จำเป็นสำหรับความสำเร็จของไซต์ที่คุณกำลังดำเนินการอยู่ และจากนั้นอาจสร้างโค้ดสำหรับคุณลักษณะที่สามารถให้บริการได้ดียิ่งขึ้นบนแพลตฟอร์มอื่น ก่อนที่เราจะเข้าสู่สูตรอ้างอิงที่คุ้มค่า ฉันสงสัยว่ามีบางอย่างที่ฉันไม่รู้เวลาหรือไม่และการเดินทางของคุณเป็นตัวอย่างหนึ่งของหนี้ด้านเทคโนโลยีที่ทำให้สิ่งนี้เป็นประเด็นหลักสำหรับคุณ

JM: ใช่อย่างแน่นอน มีโครงการสำคัญแห่งหนึ่งที่ทำให้ฉันคิดถึงเรื่องนี้เมื่อสี่หรือห้าปีก่อน ฉันเคยเห็นกรณีอื่น ๆ มากมาย สำหรับธุรกิจที่ต้องใช้เวลา ตลอดเวลา ไม่ใช่แค่ผ่าน WordPress ผ่านทุกสิ่ง แต่จริงๆ แล้ว ธุรกิจต่างๆ ก็สะสมเวลาผ่านกระบวนการปฏิบัติงานเช่นกัน ถ้าคุณต้องเป็นสิ่งที่ทางเทคนิคที่คุณสร้างสำรับนั้น หนึ่ง เรื่องราวหนึ่งที่โดดเด่นในใจฉันมากกว่าเรื่องใดๆ เลยคือลูกค้า เราทำงานกับบริษัทที่ค่อนข้างเล็ก และทำงานด้านสื่อที่ต้องเสียค่าใช้จ่ายเป็นจำนวนมากสำหรับพวกเขา ขายของออนไลน์เป็นหลัก มันเป็นธุรกิจอีคอมเมิร์ซ และพวกเขามีการสั่งซื้อทางไปรษณีย์แบบเดิม แต่มีงานเยอะมาก และพวกเขากำลังพยายามเพิ่มปริมาณการใช้งานออนไลน์ ดังนั้นพวกเขาจึงไม่ต้องสั่งซื้อทางไปรษณีย์จะได้รับการจัดการผ่านเว็บไซต์และพวกเขามาหาเราเพราะพวกเขา มีไซต์ที่สร้างขึ้นสำหรับพวกเขาโดยเฉพาะ และอยู่มาประมาณ 10 ปี ณ จุดนั้น ดังนั้นมันจึงค่อนข้างเก่าเริ่มคืบคลานเล็กน้อย คุณรู้มาตรฐานและก้าวต่อไป เทคโนโลยีก้าวไปข้างหน้า ถึงเวลาต้องคิดใหม่อีกครั้ง ดังนั้น ลูกค้าจึงนั่งลงกับเรา พวกเขาเริ่มซักถามถึงสิ่งต่าง ๆ ทั้งหมดที่พวกเขาทำบนเว็บไซต์ และสำหรับฉันมันชัดเจนมากอย่างรวดเร็วว่ามีตรรกะทางธุรกิจและการดำเนินธุรกิจทุกประเภทที่สร้างขึ้นในเว็บไซต์ และนั่นเป็นตรรกะที่นำไปสู่คำสั่งซื้อและค่อนข้างเฉพาะเจาะจงเกี่ยวกับวิธีการทำงานของซัพพลายเออร์ ดังนั้นฉันจะไม่ลงรายละเอียด แต่ฉันมีข้อตกลงที่ค่อนข้างซับซ้อนระหว่างซัพพลายเออร์และวิธีที่พวกเขาปฏิบัติตามคำสั่งซื้อและไม่ว่าจะได้รับการจัดส่งไปยังร้านค้าของพวกเขาก่อนที่จะส่งออกสิ่งเหล่านี้ทั้งหมดหรือไม่ มันเลยค่อนข้างซับซ้อน ตอนนี้เจ้าของธุรกิจและคนก่อน ๆ เกี่ยวกับวิธีการทำงานของพวกเขา ในที่สุดก็สร้างระบบที่จัดการได้เกือบทั้งหมดว่าเป็นระบบที่ดีจริงๆ ในขณะนั้น และช่วยให้ธุรกิจนั้นเติบโตอย่างหนาแน่นอย่างแท้จริง ตอนนี้ สิ่งที่พวกเขาไม่ได้คิดจริงๆ คือ เว็บไซต์ทั้งหมดมีอายุยืนยาว ซึ่งพวกเขาจะใช้งานได้จริงในบางจุด เช่นเดียวกับซอฟต์แวร์ใดๆ และในโลกการตลาด อายุการเก็บรักษานั้นค่อนข้างสั้นเมื่อเทียบกับที่คุณทราบ ตัวอย่างเช่น หากคุณลงทุนใน CRM เนื่องจากธุรกิจมักจะประสบปัญหาดังกล่าวมาระยะหนึ่งแล้ว ตอนนี้ก็ประมาณ 10 ปี หากไม่มีเว็บไซต์เพิ่มขึ้น โดยทั่วไปแล้วในช่วงสองถึงห้าปี เราพบว่าอย่างน้อยที่สุดแบรนด์ใหญ่มักจะสร้างใหม่ทุกๆ สามปีหรือมากกว่านั้น ดังนั้น ปัญหาก็คือพวกเขาสร้างตรรกะที่ซับซ้อนทั้งหมดนี้ลงในเว็บไซต์ที่มีอยู่ และพวกเขาต้องสร้างเว็บไซต์ใหม่ทั้งหมด และในทันใด คุณต้องสร้างตรรกะทางธุรกิจทั้งหมดนี้ขึ้นมาใหม่ด้วย ตอนนี้ เราทุ่มทุนสร้างโปรเจ็กต์ และโดยพื้นฐานแล้วมันก็เหลือเพียงครึ่งหนึ่งของมูลค่าการซื้อขายประจำปี เพื่อสร้างสิ่งที่เรามีอยู่แล้วขึ้นมาใหม่ และนั่นทำให้ฉันคิดเกี่ยวกับสิ่งนี้จริงๆ ก็คือ โอเค ถ้าพวกเขาแก้ปัญหาด้วยวิธีที่ต่างไปจากเดิม ตัวอย่างเช่น ลองคิดถึงสิ่งต่าง ๆ ที่เราพยายามทำให้สำเร็จที่เว็บไซต์ คุณรู้ไหม นี่คือการตลาดจากการขายผลิตภัณฑ์ นี่คือการปฏิบัติตามคำสั่ง ซึ่งดีที่สุดสำหรับการจัดการกระบวนการทางธุรกิจของฉันด้วยการจัดหาสิ่งเหล่านั้นทั้งหมด และคิดแบบโมดูลาร์เพิ่มเติมเล็กน้อยเกี่ยวกับสิ่งนั้น มันจะเป็นสถานการณ์ที่แตกต่างกันมากสำหรับลูกค้ารายนี้ ที่เธออยู่ที่นั่น . มันเป็นปัญหาที่แท้จริงสำหรับพวกเขา เพราะพวกเขามีเว็บไซต์ที่เป็นแหล่งทำเงิน มันลั่นมากเพราะมันค่อนข้างเก่า แต่ในขณะเดียวกัน จะต้องเสียค่าใช้จ่ายมากในการสร้างเว็บไซต์ใหม่ทั้งหมด และทำให้โครงการซับซ้อนมาก เราจัดการเพื่อค้นหาสิ่งที่ค่อนข้างฉลาด แต่ก็ไม่ได้ดีในตอนท้ายเพื่อลองใช้สิ่งที่พวกเขามีอยู่แล้วและรวมเข้าด้วยกัน แต่เราไม่สามารถอ้างอิงได้ แต่คุณก็รู้ ในที่สุดมันก็เจ็บปวดกว่ามาก ช้ากว่ามาก และอีกมากมาย ราคาแพงกว่าที่ควรจะเป็น หากว่าสถาปัตยกรรมนั้นคิดแต่เดิม

DV: ฉันมีโครงการมากมายที่ฉันอยากจะลืม เคยเป็นแบบนั้น และฉันก็นึกภาพออก ตอนนี้ฉันกำลังพาย้อนเวลากลับไป สำหรับผม ที่ฟังดูชัดเจนว่าเป็นบทเรียนสำคัญ ผมคิดว่าในบทเรียนสำคัญที่ต้องคิดถึงต้นทุนของธุรกิจที่สัมพันธ์กับการปรับโครงสร้างใหม่ที่คุณวางแผนไว้ และสำหรับฉัน ดูเหมือนคำตอบที่ชัดเจนคือคุณต้องสร้างโครงสร้างให้แตกต่างออกไป และนั่นอาจเป็นแนวทางที่ชัดเจนกว่านี้หากคุณต้องการทำในสิ่งที่คุณควรทำ แต่ผมคิดเหมือนหลายๆ ทีมเวลาที่พวกเขาคิดเกี่ยวกับ Tech Debt เหมือนกับว่าพวกเขาคิดว่า โอเค ก็ดี จะทำสิ่งนี้ได้เจ๋ง แต่มันคุ้มไหม?

JM: ฉันควรรักษาสิ่งนี้ไว้ตลอดเวลาหรือไม่? เลยอยากรู้ว่าคิดยังไงกับสูตรนั้น

D V: เมื่อไหร่ เมื่อไหร่ เมื่อไหร่ที่จะแนะนำหนี้เทคโนโลยี? และคุณคิดอย่างไรเกี่ยวกับสูตรนั้น?

JM: ใช่ คุณสัมผัสได้ถึงประเด็นที่สำคัญจริงๆ นั่นคือ คุณคิดเกี่ยวกับธรรมชาติของนักพัฒนา นักพัฒนาซอฟต์แวร์เข้ามามีส่วนร่วมเพราะพวกเขาชอบทำอะไรเจ๋งๆ และนั่นคือ ส่วนใหญ่ในแรงจูงใจของเรา คือการเรียนรู้วิธีการทำสิ่งใหม่ เทคโนโลยีใหม่ เฟรมเวิร์ก JavaScript ใหม่ ไม่ว่าสิ่งนั้นจะเป็นอะไร และนั่นทำให้เรามีแรงจูงใจที่จะสร้างสิ่งที่ยอดเยี่ยมโดยธรรมชาติ แต่เราไม่จำเป็นต้องคิดในระยะยาวเกี่ยวกับเรื่องนั้น เรายังคงจะรักษามันไว้ คุณก็รู้ ภรรยาของฉันชอบอาบน้ำอุ่นที่บ้าน แต่ฉันรู้ว่ามีคนมาทำความสะอาด และบอกตามตรง ฉันไม่เชื่อว่าใครซักคนล้างอ่างจะเป็นคนคิดแบบนั้นอยู่ดี เป็นคำถามที่ดีจริงๆ ที่ควรลองคิดดู ว่าคุ้มไหมตั้งแต่แรก และถ้าเราแยกแยะให้ละเอียดหน่อย มีหลายสิ่งที่คุณอาจคิดได้ ก่อนอื่น ให้คิดยาว ระยะ ต้นทุนรวมในการเป็นเจ้าของและการสร้างสิ่งที่ทดสอบและบำรุงรักษา แล้วชั่งน้ำหนักเทียบกับมูลค่าที่เราได้รับคืออะไร ตัวอย่างเช่น อาจมีวิธีง่ายๆ ที่คุณสามารถแก้ปัญหานั้นได้ โดยใช้สเปรดชีตหรือใช้สถาปัตยกรรมที่แตกต่างกันเล็กน้อย ซึ่งอาจมีคนภายในบริษัทจัดการสิ่งนั้นในช่วงเวลาสั้นๆ และการทำเช่นนั้นจะถูกกว่าและมีประสิทธิภาพมากกว่าที่จะสร้างคุณลักษณะที่ซับซ้อนจริงๆ แต่เมื่อคุณดูต้นทุนรวมของการเป็นเจ้าของจริง ๆ แล้ว มันจะมีค่าใช้จ่ายมากกว่าที่จะเป็นสำหรับคนที่ใช้เวลาสองสามชั่วโมงต่อสัปดาห์เพื่อทำสิ่งใดสิ่งหนึ่งโดยเฉพาะ อย่าเข้าใจฉันผิด ฉันเชื่อมั่นในระบบอัตโนมัติ เทคโนโลยีควรทำงานอัตโนมัติให้มากที่สุดเพื่อหลีกเลี่ยงผู้ดูแลระบบประเภทนั้น แต่

DV: คุณกำลังสมัครใช้งาน และคุณใช้เหมือนคู่มือนี้เพื่อลองทำอะไรบางอย่างก่อนที่คุณจะเขียนโค้ดเพื่อให้แน่ใจว่าค่านั้นจะอยู่ที่นั่น ฉันหมายถึง ฉันมีความคิดที่จะลดความซับซ้อนของปัจจัยนี้ เช่น เราทำสิ่งนี้ด้วยตนเองแทนได้ไหม แค่สงสัยว่าคุณเคยเข้าใกล้มันจากมุมมองการทดสอบไปจนถึงชอบหรือไม่ ดูว่าผลตอบแทนสูงสุดคุ้มไหม?

JM: ครับ 100%. ดังนั้น ฉันจึงเป็นผู้ศรัทธาที่ยิ่งใหญ่ในระเบียบวิธีแบบ Agile และโดยพื้นฐานแล้ว หลักการสำคัญประการหนึ่งของ Agile ก็คือ คุณจะต้องสร้างสิ่งที่ถูกต้องในเวลาที่เหมาะสม และคุณมุ่งเน้นไปที่การเพิ่มมูลค่าให้เร็วที่สุด ดังนั้น คุณต้องการสร้างผลิตภัณฑ์ที่ทำงานได้ขั้นต่ำ นั่นหมายความว่าคุณไม่จำเป็นต้องมีสิ่งที่มีคุณสมบัติครบถ้วนในขณะนั้น แต่มันทำให้คุณมีแพลตฟอร์มที่คุณสามารถเริ่มทดสอบได้ คุณรู้ไหม คุณได้รับสิ่งที่คุณต้องการจากสิ่งนั้นจริง ๆ หรือไม่? ผู้ใช้ของคุณตอบสนองหรือไม่? ในแบบที่คุณคาดหวังให้ใครก็ตามที่ทำงานใน UX หรือ Web dev จะรู้ว่ามักจะได้รับคำขอจากลูกค้าเพราะพวกเขาคิดว่าลูกค้าของตน แต่จริงๆ แล้วพวกเขาต้องการหรือไม่? อีกคำถามหนึ่งที่ดีจริงๆ ก็คือ เมื่อคุณได้คิดเกี่ยวกับมุมมองระยะยาวนั้นแล้ว คนที่จะเข้าใช้เว็บไซต์เรารู้หรือไม่ว่าใครจะใช้งาน หรือเราต้องทดสอบดูว่าพวกเขาต้องการหรือไม่ ที่จะใช้มัน? และเมื่อคุณทำการทดสอบเสร็จแล้ว เราก็สามารถหาสิ่งที่เราไม่ควรขอ และเราควรถอยออกมาและลงทุนไปที่อื่นจริง ๆ หรือไม่

DV: ดังนั้น มันจึงดูเหมือนเป็นการสรุปความคิดนี้ และฉันชอบความคิดของคุณในการดูต้นทุนรวมของการเป็นเจ้าของในระยะยาว ฉันคิดว่าหลายครั้งที่ทีมคิดว่าแม้แต่คนที่คุณรู้จัก เสนอราคา สั่งซื้อบริการจาก ทีมคิดว่ากี่ชั่วโมงหรือหลายสัปดาห์หรือกระจายหรือคะแนนหรืออะไรก็ตามที่จะสร้างสิ่งนี้ แต่คุณต้องคำนึงด้วยว่า ต้องใช้กี่ชั่วโมงหรือหลายสัปดาห์ หรือสเปรด หรือแต้มเพื่อรักษา แล้วจึงใช้ยอดคงเหลือนั้นเทียบกับมูลค่าที่คุณได้รับจากการรักษาไว้ กิจกรรมนั้นๆ เห็นได้ชัดว่าคุณเป็นคำแนะนำที่ดี แต่คุณก็คิดเหมือนกันว่า มีบางอย่างที่ฉันสามารถทำได้เพื่อทดสอบสิ่งนี้เพื่อดูว่าสมมติฐานของฉันถูกต้องหรือไม่ เสียงนั้นถูกต้องหรือไม่?

JM: ครับ อย่างแน่นอน. อย่างแน่นอน. สิ่งเดียวที่เราไม่ได้พูดถึงคือที่เราพูดถึงก่อนหน้านี้เล็กน้อย ซึ่งเกี่ยวกับสถาปัตยกรรม มีวิธีที่ดีกว่าที่เราจะจัดโครงสร้างนี้เพื่อให้ดีขึ้น และเวลานั้นเพื่อคัดค้านการเขียนโปรแกรมและสิ่งต่างๆ ที่ฉันอาจจะสัมผัสได้ในภายหลัง

DV: ใช่ ข้อพิจารณาด้านสถาปัตยกรรมเช่นกัน อย่างที่ฉันเขียนลงไปว่าคุณเป็นอย่างไร มีวิธีใดบ้างที่เราจะเปลี่ยนข้อกำหนดได้ เหมือนกับในการฝึกอบรมผู้มีส่วนได้ส่วนเสียของฉันหรือการเจรจาที่ฉันมักจะพูดว่าคุณรู้ spec ที่จะยื่นใช่ไหม? ขอสิ่งที่คุณต้องการจริงๆ แล้วการถามพวกนั้นจะเป็นการโกหกและมีความจำเป็นจริงๆ แล้วเรื่องนี้ล่ะ? ฉันพบว่าคำถามสำคัญมาก ดูเหมือนว่านั่นเป็นส่วนสำคัญในการคิดของคุณเกี่ยวกับเรื่องนี้

JM: ใช่ เพราะทุกนาทีที่เว็บไซต์นั้นกำลังอยู่ในระหว่างการพัฒนา คือนาทีที่มันไม่ได้รับความคุ้มค่าต่อหน้าลูกค้า และนั่นเป็นวิธีคิดที่ง่าย คุณต้องการเปิดตัวให้เร็วที่สุดเท่าที่จะทำได้ จากนั้นทดสอบ ตรวจสอบ ทำซ้ำ เรียนรู้ ดูว่าคุณจะไปที่ไหนจากที่นั่น แต่เพียงเพราะคุณกำลังทำสิ่งนั้นโดยอิงจากข้อมูลจริงมากกว่าสิ่งที่คุณคิดว่าถูกต้อง เพราะมักจะไม่เหมือนเดิม

DV: ใช่ ฉันชอบจุดนั้น ทุกนาที. มันอยู่ใน dev ไม่ใช่นาทีที่คุณไม่ได้ใช้มันคิดออกและฉันจะบอกว่าความสัมพันธ์กลับไปสู่มนต์อื่นที่ฉันมีและการจัดการโครงการและการจัดการผู้มีส่วนได้ส่วนเสียซึ่งเป็นคำที่ดีที่สุดสองคำและ รับโครงการบนใบหน้าของเราที่จะเขียน คุณพูดได้ยังไง ฉันชอบเวลาที่ฉันต้องติดต่อกับผู้มีส่วนได้ส่วนเสีย หรือเมื่อฉันมีผู้มีส่วนได้ส่วนเสียเป็นส่วนที่ทรงพลังและทรงพลัง โอเคเย็น อืม มาคุยกันต่อไปว่าทีมจะทำอะไรได้บ้างเพื่อลดหนี้เทคโนโลยี แต่ก่อนที่เราจะทำอย่างนั้น เราจะพักครั้งสุดท้าย ถึงเวลาเสียบเข้ากับช่วงพักโฆษณา คอยติดตามการกดเพิ่มเติมนี้ในอีกสักครู่ ยินดีต้อนรับทุกคนกลับมากดพอดคาสต์ชุมชน WordPress บน W EMR นี่คือโฮสต์ของคุณ David มือถือ Paul ฉันกำลังพูดถึงการหลีกเลี่ยงเวลาที่จะฆ่าหนี้เทคโนโลยีกับ John Martin ว่า John เป็นอย่างไรก่อนพัก เราได้พูดคุยกันเล็กน้อยเกี่ยวกับสูตรที่คุ้มค่าของคุณ ฉันชอบความคิดของคุณในการลด ข้อมูลจำเพาะ และการคิดเกี่ยวกับ TCO และวิธีการทดสอบแบบวนซ้ำ แต่มาเจาะลึกกันว่าตอนนี้ทีมสามารถทำอะไรได้บ้างเพื่อลดหนี้ด้านเทคโนโลยีและ WordPress บิวด์ เทคนิคที่คุณชื่นชอบในการลดหนี้ด้านเทคโนโลยีมีอะไรบ้าง?

JM: มีเทคนิคทางเทคนิคทุกประเภทที่คุณสามารถใช้ได้ และคุณรู้ว่าบางเทคนิคที่คุณคุ้นเคยแต่จริงๆ แล้ว จุดเริ่มต้นสำหรับฉันคือ เป็นวิธีที่นุ่มนวลกว่ามากในการพูดคุย ให้กับลูกค้าของคุณ และคุณต้องจำไว้ว่าในท้ายที่สุด ลูกค้าของคุณคือแบรนด์เหล่านี้ที่มาหาเราเพราะเราเป็นผู้เชี่ยวชาญ พวกเขาต้องการคำแนะนำของเรา และมันค่อนข้างง่ายที่จะตกหลุมพรางที่ว่า คุณรู้ไหม เราอยู่ที่นั่นเพื่อทำในสิ่งที่พวกเขาต้องการ สิ่งที่เราอยู่ที่นั่นเพื่อทำในสิ่งที่พวกเขาต้องการให้เราทำ แต่จริงๆ แล้ว เราอยู่ที่นั่น เพื่อท้าทายสิ่งที่พวกเขาต้องการทำและพยายามปรับปรุง อย่างแรกที่คุณทำได้คือคุยกับพวกเขาเกี่ยวกับมันและอธิบายว่าโอเค ถ้าเราทำสิ่งนี้จะส่งผลระยะยาวของมัน รู้ไหม เราต้องใช้เวลาอีก 1 วันในการทดสอบ ทุกครั้งที่เราเผยแพร่ จะมีการเพิ่มเวลาสองสามชั่วโมงทุกครั้งที่เราต้องดูแลเว็บไซต์และอัปเดตปลั๊กอินทั้งหมดหรืออะไรก็ตามที่เป็น แต่ด้วยการเพิ่มความตระหนักนั้น เรากำลังสนทนากับพวกเขา คุณสามารถให้ลูกค้าเป็นส่วนหนึ่งของการสนทนานั้นได้ และในที่สุดพวกเขาก็กลายเป็นส่วนหนึ่งของการแก้ปัญหาด้วย เราต้องให้ความรู้ลูกค้าของเราตลอดเวลา เพียงเพราะพวกเขาไม่รู้ว่าบางสิ่งที่เราทำ ถ้าเป็นเช่นนั้น พวกเขาก็จะไม่กลายเป็นเครื่องมือตั้งแต่แรก จริงๆ แล้ว นั่นคือจุดเริ่มต้น เขาคิดว่าจำสิ่งนั้นได้เช่นเดียวกับการทำให้สิ่งต่าง ๆ ง่ายขึ้น อีกครั้งที่ผู้คนไม่จำเป็นต้องเป็นเทคนิคอย่างเรา ดังนั้นใช้การเปรียบเทียบเพื่อพูดคุยเกี่ยวกับเรื่องนี้ ฉันมักจะพบว่าบ้านเป็นพลังงานที่ดี ทุกคนอาศัยอยู่ในบ้าน คนส่วนใหญ่มีประสบการณ์ในการปรับปรุงบ้านบางประเภท ดังนั้นมันจึงค่อนข้างง่ายที่จะใช้พลังงานนั้นเพื่อแก้ไขสิ่งต่างๆ นั่นคือประเด็นแรกจริงๆ คือการหาลูกค้าหรือวนรอบการสนทนาเหล่านั้น สิ่งต่อไปที่เราได้สัมผัสก่อนหน้านี้คือการมีมุมมองระยะยาวหรือต้นทุนการเป็นเจ้าของทั้งหมด และถามตัวเองด้วยคำถามเหล่านั้นและตั้งคำถามกับทุกคำขอคุณสมบัติ แต่ต้องใช้เทคนิคนิดหน่อยและคุณจะทำสิ่งนี้กับงานได้อย่างไร สิ่งง่ายๆ ที่คุณใช้มาตรฐาน WordPress คุณรู้ว่ามีมาตรฐานอยู่ที่นั่น พวกเขามีอยู่ด้วยเหตุผล ตอนนี้ พวกเขาจะช่วยเรานักพัฒนา และบางทีคุณอาจทำงานในโครงการที่คุณวางไว้เป็นเวลาหนึ่งปีหรือสองปีแล้วค่อยกลับมาทำใหม่ คุณต้องรีเฟรชหน่วยความจำและกลับไปยังตำแหน่งที่คุณอยู่เมื่อสร้างครั้งแรกโดยใช้มาตรฐานจะช่วยได้ พวกเขาจะช่วยเหลือคนอื่นด้วย ดังนั้น หากคุณไม่อยู่ในทีม หมายความว่าคุณมีภาษากลางที่ทุกคนสามารถใช้งานได้ ซึ่งมีประโยชน์จริงๆ ในแง่ของประสิทธิภาพ และการช่วยเหลือด้านเอกสารและสิ่งต่างๆ เหล่านี้ นั่นเป็นวิธีที่นุ่มนวลกว่าในการลดหนี้ทางเทคนิคของคุณ โดยมีมาตรฐานที่ใครๆ ก็ทำงานได้ นอกจากนี้ยังช่วยให้คุณทราบด้วยว่าอาจถึงเวลาที่นักพัฒนา WordPress คนอื่น ๆ กำลังทำงานในโครงการนั้น และช่วยให้พวกเขาคิดว่ามันเป็นวิธีตอบแทนชุมชนและทำให้นักพัฒนาคนอื่นๆ ของคุณง่ายขึ้น นั่นคือ เป็นจุดที่ดี เกี่ยวกับมาตรฐานและทำให้ง่ายสำหรับตัวคุณเองและผู้อื่น ต่อไปเป็นเรื่องใหญ่มากขึ้น รหัสที่ดีของอุตสาหกรรมที่รู้จักกันอย่างเสน่หาในชื่อลุงบ๊อบ ผู้เขียนหนังสือที่ยอดเยี่ยมชื่อ The clean coder เมื่อหลายปีก่อน ฉันอยากจะแนะนำให้นักพัฒนาทุกคนอ่านหนังสือนั้นเพราะพวกเขายังไม่ได้อ่าน อันที่จริง ฉันได้กำหนดให้ต้องอ่านสำหรับทีมพัฒนา ใครก็ตามที่เข้าร่วมทีม ส่วนใหญ่เป็นเพราะเขามีวิธีที่ดีในการพูดคุยเกี่ยวกับการทดสอบหน่วย อะไรพวกนี้ แต่โดยพื้นฐานแล้ว เยอะมาก อยู่ที่ว่าคุณเขียนโค้ดในลักษณะที่ยืดหยุ่นได้อย่างไร โดยคุณสามารถวนซ้ำ เปลี่ยนแปลง และเพิ่มบิตพิเศษเข้าไปได้อย่างรวดเร็ว ประเด็นสำคัญประการหนึ่งที่เขาพูดถึงคือการ refactoring บ่อยๆ และนี่เป็นสิ่งสำคัญที่ต้องทำคือคุณเขียนโค้ดที่ไม่จำเป็นต้องหมายความว่าโค้ดชิ้นนั้นเสร็จสิ้น มีหลายสิ่งที่คุณสามารถทำได้เพื่อเพิ่มประสิทธิภาพเพื่อให้พกพาสะดวกยิ่งขึ้นเพื่อให้เป็นแบบแยกส่วนหรือทำการทดสอบได้ดีขึ้น สิ่งที่คุณต้องทำเพื่อใช้เวลาในการจัดโครงสร้างโค้ดใหม่ มันอาจจะยากจริงๆ ที่จะทำเมื่อคุณต่อต้าน หรือบางทีอาจเป็นกรอบเวลาเดียวสำหรับงบประมาณ แต่ท้ายที่สุด นั่นคือสิ่งที่จะหยุดคุณไม่ให้ก่อหนี้ทางเทคนิค และจริงๆ แล้ว นั่นเป็นวิธีที่ฉันเห็นว่ามันถูกบังคับ แต่เมื่อถึงเส้นตายของโครงการ คุณต้องถึงเส้นตายนั้น อย่างแน่นอน. คุณต้องตีให้ได้ แต่การดิ้นขอบเขตนั้นดีกว่าการเขียนโค้ดเสียที่คุณกำลังจะทำ

DV: ฉันเดาว่า ให้ความรู้แก่ลูกค้าเหล่านั้นเกี่ยวกับเรื่องนั้นด้วย เพราะฉันไม่เคยพบนักพัฒนาซอฟต์แวร์ที่ไม่ต้องการปรับโครงสร้างใหม่ รหัส. มันเป็นไทม์ไลน์เสมอ มันต่อต้านมัน อืม เอาล่ะ นี่เป็นเรื่องสุดท้าย ฉันแค่อยากรู้ว่าคุณชอบเราไหม ถ้าคุณคิดว่าการขนถ่ายและการใช้ปลั๊กอินนอกชั้นวางเป็นอีกวิธีหนึ่งในการช่วยหลีกเลี่ยงเทคโนโลยีหรือวิธีอื่นๆ ในการหลีกเลี่ยงหนี้เทคโนโลยี อยู่ในรายการของคุณด้วยหรือไม่

JM: ครับ 100% นั่นเป็นวิธีที่ดี แต่เป็นวิธีที่ดีในการทำทั้งสองอย่าง จริงๆ แล้ว คุณสามารถหลีกเลี่ยงหนี้ทางเทคนิคได้ แต่คุณก็ทำได้ และคุณก็รู้ WordPress เป็นรูปแบบหนึ่งของ BMC มันมีการเคลื่อนไหวอย่างเท่าเทียมกันที่สามารถเป็นศัตรูตัวร้ายได้ มีปลั๊กอินที่ทำทุกอย่าง และยังมีปลั๊กอินจำนวนมากที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะ แต่ก็ไม่จำเป็นต้องตรงกับปลั๊กอินของคุณเองเสมอไป ดังนั้นฉันจึงได้เห็นสิ่งนี้โดยเฉพาะกับนักพัฒนาบางคนที่ชอบสร้างไซต์โดยใช้ปลั๊กอิน และประเภทของการชี้และคลิกเข้าหาสิ่งต่าง ๆ มากกว่าที่จะเขียนโค้ดจากมุมมองเริ่มต้น ผู้คนมักจะโยนปลั๊กอินใส่สิ่งของ เราได้ทำงานกับเว็บไซต์ที่มีปลั๊กอินมากกว่า 100 รายการและปลั๊กอินบางตัวไม่ได้รับการดูแลอีกต่อไป มีปัญหาด้านความปลอดภัยทั่วทุกแห่ง คุณลองทำอัตราการปล่อย คุณใช้เวลาสี่วันในการทดสอบเมื่อคุณทำได้ภายในสองสามชั่วโมง ดังนั้นปลั๊กอินจะดีหรือไม่ดีก็ได้ การเสียบปลั๊กที่ถูกต้องในเวลาที่เหมาะสมเป็นสิ่งมหัศจรรย์และมหัศจรรย์ จุดแข็งที่ยิ่งใหญ่ที่สุดของ WordPress แต่เสียบผิดเวลาก็สามารถสร้างความเสียหายอย่างร้ายแรงได้เช่นกัน และแท้จริงแล้วสามารถเป็นหนึ่งในแหล่งทุนที่ใหญ่ที่สุดเหล่านั้นได้

DV: ฉันมีโครงการแบบนั้นแน่นอน จอห์น นี่มันฉลาดมาก ขอบคุณมากสำหรับการเข้าร่วมกับเราในวันนี้

J M: ด้วยความยินดี

DV: ยอดเยี่ยม หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่จอน สามารถเยี่ยมชมได้ที่ hallam.co.uk ขอบคุณทุกคนที่ฟังกดพอดคาสต์ชุมชน WordPress บน WMR อีกครั้ง นี่คือโฮสต์ของคุณ David Vogelpohl ฉันสนับสนุนชุมชน WordPress โดยเป็นส่วนหนึ่งของบทบาทของฉันที่ WP Engine และฉันชอบที่จะนำเสนอสิ่งที่ดีที่สุดของชุมชนที่นี่ใน Press This