บันทึกของนักพัฒนาส่วนหน้าของ Habr: การปรับโครงสร้างใหม่และการสะท้อนกลับ

ฉันสนใจมาโดยตลอดว่า Habr มีโครงสร้างจากภายในอย่างไร มีโครงสร้างเวิร์กโฟลว์อย่างไร มีโครงสร้างการสื่อสารอย่างไร มาตรฐานใดที่ใช้ และวิธีเขียนโค้ดโดยทั่วไปที่นี่ โชคดีที่ฉันได้รับโอกาสนี้เพราะว่าฉันเพิ่งได้เป็นส่วนหนึ่งของทีมฮาบรา โดยใช้ตัวอย่างการปรับโครงสร้างเล็กน้อยของเวอร์ชันมือถือ ฉันจะพยายามตอบคำถาม: การทำงานในแนวหน้าที่นี่เป็นอย่างไร ในโปรแกรม: Node, Vue, Vuex และ SSR พร้อมซอสจากบันทึกเกี่ยวกับประสบการณ์ส่วนตัวใน Habr

สิ่งแรกที่คุณต้องรู้เกี่ยวกับทีมพัฒนาคือเราตัวเล็ก มีเพียงสามแนวหน้า สองหลัง และเป็นผู้นำทางเทคนิคของฮาเบอร์ - แบกซ์ลีย์ทั้งหมด แน่นอนว่ายังมีผู้ทดสอบ นักออกแบบ วาดิมสามคน ไม้กวาดมหัศจรรย์ นักการตลาด และบัมบูรัมคนอื่นๆ แต่มีเพียงหกผู้มีส่วนร่วมโดยตรงต่อไซต์ของ Habr สิ่งนี้ค่อนข้างหายาก - โครงการที่มีผู้ชมหลายล้านดอลลาร์ซึ่งภายนอกดูเหมือนองค์กรขนาดใหญ่ จริงๆ แล้วเป็นเหมือนการเริ่มต้นที่สะดวกสบายด้วยโครงสร้างองค์กรที่เรียบที่สุด

เช่นเดียวกับบริษัทไอทีอื่นๆ อีกมากมาย Habr ยอมรับแนวคิด Agile, แนวทางปฏิบัติของ CI และนั่นคือทั้งหมด แต่ในความคิดของฉัน Habr เป็นผลิตภัณฑ์ที่มีการพัฒนาเป็นคลื่นมากกว่าอย่างต่อเนื่อง ดังนั้น สำหรับการวิ่งหลายครั้งติดต่อกัน เราเขียนโค้ดบางอย่างอย่างขยันขันแข็ง ออกแบบและออกแบบใหม่ ทำลายบางสิ่งและซ่อมแซม แก้ไขตั๋วและสร้างใหม่ เหยียบคราดแล้วยิงตัวเองตายเพื่อที่จะปล่อยฟีเจอร์ใน อนาคต. และแล้วก็ถึงช่วงสงบ ช่วงเวลาของการพัฒนาขื้นใหม่ ถึงเวลาทำสิ่งที่อยู่ในจตุภาคที่ “สำคัญ-ไม่เร่งด่วน”

นี่เป็นการวิ่ง "นอกฤดู" อย่างแน่นอนซึ่งจะกล่าวถึงด้านล่าง ครั้งนี้ได้รวมการปรับโครงสร้าง Habr เวอร์ชันมือถือใหม่ด้วย โดยทั่วไป บริษัทมีความหวังสูงสำหรับสิ่งนี้ และในอนาคตควรเข้ามาแทนที่สวนสัตว์แห่ง Habr ทั้งหมด และกลายเป็นโซลูชันข้ามแพลตฟอร์มที่เป็นสากล สักวันหนึ่งจะมีรูปแบบที่ปรับเปลี่ยนได้, PWA, โหมดออฟไลน์, การปรับแต่งผู้ใช้ และสิ่งที่น่าสนใจอื่นๆ อีกมากมาย

มากำหนดภารกิจกัน

ครั้งหนึ่ง ในการยืนหยัดตามปกติ แนวหน้าคนหนึ่งพูดถึงปัญหาในสถาปัตยกรรมของส่วนประกอบความคิดเห็นของเวอร์ชันมือถือ ด้วยข้อเสนอแนะนี้ เราได้จัดการประชุมย่อยในรูปแบบของจิตบำบัดแบบกลุ่ม ทุกคนผลัดกันบอกว่าเจ็บตรงไหน บันทึกทุกอย่างลงกระดาษ เห็นอกเห็นใจ เข้าใจ ยกเว้นไม่มีใครปรบมือ ผลลัพธ์คือรายการปัญหา 20 ข้อ ซึ่งทำให้ชัดเจนว่า Habr มือถือยังคงมีเส้นทางสู่ความสำเร็จที่ยาวและยุ่งยาก

ฉันกังวลเรื่องประสิทธิภาพของทรัพยากรเป็นหลักและสิ่งที่เรียกว่าอินเทอร์เฟซที่ราบรื่น ทุกๆ วัน ในเส้นทาง "การบ้าน-ที่ทำงาน-บ้าน" ฉันเห็นโทรศัพท์เครื่องเก่าพยายามอย่างยิ่งที่จะแสดงหัวข้อข่าว 20 รายการในฟีด มันดูเหมือนสิ่งนี้:

อินเทอร์เฟซ Mobile Habr ก่อนการปรับโครงสร้างใหม่

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

โครงการ SSR-CSR แบบเก่า การอนุญาตสามารถทำได้ในขั้นตอน C3 และ C4 เท่านั้น เมื่อ Node JS ไม่ได้ยุ่งอยู่กับการสร้าง HTML และสามารถส่งคำขอพร็อกซีไปยัง API ได้

สถาปัตยกรรมของเราในยุคนั้นได้รับการอธิบายอย่างแม่นยำโดยผู้ใช้ Habr คนหนึ่ง:

เวอร์ชั่นมือถือมันห่วย ฉันกำลังบอกแบบนั้นอยู่นะ การผสมผสานที่น่ากลัวของ SSR ควบคู่ไปกับ CSR

เราถูกบังคับให้ยอมรับสิ่งนี้ ไม่ว่ามันจะเศร้าแค่ไหนก็ตาม

ฉันประเมินตัวเลือกต่างๆ สร้างตั๋วใน Jira พร้อมคำอธิบายที่ระดับ "ตอนนี้มันแย่ ทำให้มันโอเค" และแยกย่อยงานเป็นจังหวะกว้างๆ:

• นำข้อมูลกลับมาใช้ใหม่
• ลดจำนวนการวาดใหม่ให้เหลือน้อยที่สุด
• กำจัดคำขอที่ซ้ำกัน
• ทำให้กระบวนการโหลดชัดเจนยิ่งขึ้น

เรามานำข้อมูลกลับมาใช้อีกครั้ง

ตามทฤษฎีแล้ว การเรนเดอร์ฝั่งเซิร์ฟเวอร์ได้รับการออกแบบมาเพื่อแก้ไขปัญหาสองประการ: ไม่ต้องทนทุกข์ทรมานจากข้อจำกัดของเครื่องมือค้นหาในแง่ของ การจัดทำดัชนีสปา และปรับปรุงตัวชี้วัด FMP (แย่ลงอย่างหลีกเลี่ยงไม่ได้ TTI). ในสถานการณ์สุดคลาสสิกนั้นในที่สุด กำหนดขึ้นที่ Airbnb ในปี 2013 ปี (ย้อนกลับไปที่ Backbone.js) SSR เป็นแอปพลิเคชัน JS แบบ isomorphic เดียวกับที่ทำงานในสภาพแวดล้อมของโหนด เซิร์ฟเวอร์เพียงส่งคืนโครงร่างที่สร้างขึ้นเพื่อตอบสนองต่อคำขอ จากนั้นการคืนสภาพจะเกิดขึ้นที่ฝั่งไคลเอ็นต์ จากนั้นทุกอย่างจะทำงานได้โดยไม่ต้องโหลดหน้าซ้ำ สำหรับ Habr เช่นเดียวกับแหล่งข้อมูลอื่นๆ ที่มีเนื้อหาข้อความ การแสดงเซิร์ฟเวอร์เป็นองค์ประกอบสำคัญในการสร้างความสัมพันธ์ฉันมิตรกับเครื่องมือค้นหา

แม้ว่าจะผ่านไปกว่าหกปีแล้วนับตั้งแต่เทคโนโลยีปรากฏขึ้น และในช่วงเวลานี้ น้ำจำนวนมากได้ผ่านไปใต้สะพานในโลกส่วนหน้า สำหรับนักพัฒนาหลายคน แนวคิดนี้ยังคงถูกปกปิดเป็นความลับ เราไม่ได้ยืนหยัดและเปิดตัวแอปพลิเคชัน Vue ที่รองรับ SSR ในการผลิต โดยขาดรายละเอียดเล็กๆ น้อยๆ อย่างหนึ่ง นั่นคือ เราไม่ได้ส่งสถานะเริ่มต้นไปยังไคลเอนต์

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

ปัญหาหนึ่งที่เกิดขึ้นคือการไม่สามารถแปลงโครงสร้างแบบวนเป็น JSON (การอ้างอิงแบบวงกลม); ได้รับการแก้ไขโดยเพียงแค่แทนที่โครงสร้างดังกล่าวด้วยโครงสร้างแบบเรียบ

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

ลดการวาดใหม่ให้เหลือน้อยที่สุด

ดังที่คุณเห็นจากแผนภาพด้านบน ในกรณีของเรา อินสแตนซ์ Node JS หนึ่งรายการทำหน้าที่สองฟังก์ชัน: SSR และ “พร็อกซี” ใน API ซึ่งจะมีการให้สิทธิ์ผู้ใช้ สถานการณ์นี้ทำให้ไม่สามารถอนุญาตได้ในขณะที่โค้ด JS กำลังทำงานบนเซิร์ฟเวอร์ เนื่องจากโหนดเป็นแบบเธรดเดียว และฟังก์ชัน SSR เป็นแบบซิงโครนัส นั่นคือเซิร์ฟเวอร์ไม่สามารถส่งคำขอถึงตัวเองได้ในขณะที่ Callstack กำลังยุ่งอยู่กับบางสิ่ง ปรากฎว่าเราอัปเดตสถานะ แต่อินเทอร์เฟซไม่ได้หยุดกระตุกเนื่องจากข้อมูลในไคลเอนต์ต้องได้รับการอัปเดตโดยคำนึงถึงเซสชันของผู้ใช้ จำเป็นต้องสอนแอปพลิเคชันของเราให้ใส่ข้อมูลที่ถูกต้องในสถานะเริ่มต้น โดยคำนึงถึงการเข้าสู่ระบบของผู้ใช้

มีเพียงสองวิธีแก้ไขปัญหา:

• เชื่อมโยงข้อมูลการอนุญาตไปยังคำขอข้ามเซิร์ฟเวอร์
• แยกเลเยอร์ Node JS ออกเป็นสองอินสแตนซ์แยกกัน

โซลูชันแรกจำเป็นต้องใช้ตัวแปรร่วมบนเซิร์ฟเวอร์ และโซลูชันที่สองขยายกรอบเวลาในการทำงานให้เสร็จสิ้นอย่างน้อยหนึ่งเดือน

จะต้องเลือกอย่างไร? Habr มักจะเคลื่อนที่ไปตามเส้นทางที่มีการต่อต้านน้อยที่สุด โดยทั่วไปมีความปรารถนาที่จะลดวงจรจากแนวคิดไปสู่ต้นแบบให้เหลือน้อยที่สุด โมเดลทัศนคติที่มีต่อผลิตภัณฑ์นั้นค่อนข้างชวนให้นึกถึงหลักการของ booking.com โดยมีข้อแตกต่างเพียงอย่างเดียวคือ Habr ให้ความสำคัญกับความคิดเห็นของผู้ใช้อย่างจริงจังมากขึ้นและมอบความไว้วางใจในการตัดสินใจดังกล่าวให้กับคุณในฐานะนักพัฒนา

ตามตรรกะนี้และความปรารถนาของฉันเองที่จะแก้ไขปัญหาอย่างรวดเร็ว ฉันจึงเลือกตัวแปรส่วนกลาง และเช่นเดียวกับที่เกิดขึ้นบ่อยครั้ง คุณจะต้องจ่ายเงินไม่ช้าก็เร็ว เราจ่ายเงินเกือบจะในทันที: เราทำงานในช่วงสุดสัปดาห์ เคลียร์ผลที่ตามมา เขียนไว้ การชันสูตรศพ และเริ่มแบ่งเซิร์ฟเวอร์ออกเป็นสองส่วน ข้อผิดพลาดนั้นโง่มากและข้อผิดพลาดที่เกี่ยวข้องนั้นไม่ใช่เรื่องง่ายที่จะทำซ้ำ และใช่ มันเป็นความอัปยศสำหรับสิ่งนี้ แต่ไม่ทางใดก็ทางหนึ่ง PoC ของฉันที่มีตัวแปรทั่วโลกยังคงเข้าสู่การผลิตและทำงานได้ค่อนข้างประสบความสำเร็จในขณะที่รอการย้ายไปยังสถาปัตยกรรม "สองโหนด" ใหม่ โดยสะดุดและเสียงครวญคราง นี่เป็นขั้นตอนสำคัญเพราะบรรลุเป้าหมายอย่างเป็นทางการแล้ว - SSR เรียนรู้ที่จะส่งเพจที่พร้อมใช้งานโดยสมบูรณ์และ UI ก็สงบลงมาก

อินเทอร์เฟซ Mobile Habr หลังจากขั้นตอนแรกของการปรับโครงสร้างใหม่

ในที่สุด สถาปัตยกรรม SSR-CSR ของเวอร์ชันมือถือนำไปสู่ภาพต่อไปนี้:

วงจร SSR-CSR “สองโหนด” Node JS API พร้อมเสมอสำหรับ I/O แบบอะซิงโครนัส และไม่ถูกบล็อกโดยฟังก์ชัน SSR เนื่องจากส่วนหลังอยู่ในอินสแตนซ์ที่แยกต่างหาก ไม่จำเป็นต้องสืบค้นห่วงโซ่ # 3

กำจัดคำขอที่ซ้ำกัน

หลังจากดำเนินการจัดการแล้ว การเรนเดอร์เพจครั้งแรกไม่กระตุ้นให้เกิดโรคลมบ้าหมูอีกต่อไป แต่การใช้ Habr ในโหมด SPA ต่อไปยังคงทำให้เกิดความสับสน

เนื่องจากพื้นฐานของโฟลว์ผู้ใช้คือการเปลี่ยนแบบฟอร์ม รายการบทความ → บทความ → ความคิดเห็น และในทางกลับกัน สิ่งสำคัญคือต้องปรับการใช้ทรัพยากรของห่วงโซ่นี้ให้เหมาะสมตั้งแต่แรก

การกลับไปที่ฟีดโพสต์จะทำให้เกิดคำขอข้อมูลใหม่

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

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

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

หลังจากรวบรวมทุกอย่างที่ฉันจัดการเพื่อค้นหาในหัวข้อนี้แล้ว ฉันจึงกำหนดโครงสร้างสถานะใหม่และนำเสนอต่อเพื่อนร่วมงาน การอภิปรายมีความยาว แต่ท้ายที่สุดแล้ว ข้อโต้แย้งที่สนับสนุนก็มีมากกว่าความสงสัย และฉันก็เริ่มดำเนินการ

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

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

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

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

บทความรายการ นี่เป็นเพียงคลังบทความประเภทหนึ่ง บทความทั้งหมดที่ถูกดาวน์โหลดระหว่างเซสชันผู้ใช้ เราปฏิบัติต่อพวกเขาด้วยความระมัดระวังสูงสุด เนื่องจากนี่คือการจราจรที่อาจถูกดาวน์โหลดที่ไหนสักแห่งในรถไฟใต้ดินระหว่างสถานี และเราไม่ต้องการสร้างความเจ็บปวดนี้ให้กับผู้ใช้อีกอย่างแน่นอนโดยการบังคับให้เขาโหลดข้อมูลที่เขาได้ดาวน์โหลดไปแล้ว . วัตถุ บทความรหัส เป็นเพียงอาร์เรย์ของ ID (เช่น "ลิงก์") ไปยังอ็อบเจ็กต์ บทความ. โครงสร้างนี้ช่วยให้คุณหลีกเลี่ยงการทำซ้ำข้อมูลทั่วไปในเส้นทางและการนำออบเจ็กต์กลับมาใช้ใหม่ บทความ เมื่อแสดงหน้าโพสต์โดยการรวมข้อมูลที่ขยายเข้าไป

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

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

ทำให้การดาวน์โหลดสนุกสนานยิ่งขึ้น

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

กำลังโหลด

สะท้อน

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

หลังจากการเปิดตัวการเปลี่ยนแปลงทั้งหมดนี้ เราได้รับการตอบรับเชิงบวก และมันก็ดีมาก มันเป็นแรงบันดาลใจ ขอบคุณ! เขียนเพิ่มเติม

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

ที่มา: will.com