คำถามติดแท็ก front-end

8
นักพัฒนาควรทำเลียนแบบ UI หากไม่มีผู้ออกแบบในโครงการหรือไม่
ฉันทำงานกับทีมเล็ก ๆ ที่สร้างเว็บแอปพลิเคชั่นที่เป็นกรรมสิทธิ์และ UX ไม่ได้ให้ความสำคัญมากนักเพราะคนของเราจะเป็นคนที่ทำงานอยู่ แต่เราพยายามทำให้งานของพวกเขาง่ายขึ้น ในฐานะนักพัฒนาฉันควรสร้างการจำลองแบบ UI ก่อนที่ฉันจะเริ่มสร้างหน้าจอใหม่หรือไม่ ไม่มีอะไรแฟนซีเกินไปส่วนใหญ่เป็นเค้าโครงทั่วไปเพื่อพูดคุยกับเพื่อนร่วมงานและมีแบบจำลองอ้างอิง ฉันเปรียบเทียบกับการสร้างไดอะแกรม UML ก่อนที่จะทำการเขียนโค้ดแบบสุ่มสี่สุ่มห้า เพื่อนร่วมงานคนหนึ่งของฉันบอกว่าสิ่งนี้น่ารังเกียจและไม่ใช่หน้าที่ของฉันที่จะทำเช่นนั้น

7
ทำไมไม่ฝังสไตล์ / สคริปต์ใน HTML แทนที่จะเชื่อมโยง?
เราเชื่อมไฟล์ CSS และ JavaScript เข้าด้วยกันเพื่อลดจำนวนคำขอ HTTP ซึ่งช่วยเพิ่มประสิทธิภาพ ผลที่ได้คือ HTML ดังนี้ <link rel="stylesheet" href="all-my-css-0fn392nf.min.css"> <!-- later... --> <script src="all-my-js-0fn392nf.min.js"></script> หากเรามีตรรกะฝั่งเซิร์ฟเวอร์ / บิลด์เพื่อทำสิ่งนี้ให้กับเราทำไมไม่ลองอีกขั้นหนึ่งแล้วฝังสไตล์และสคริปต์ที่ต่อกันเหล่านั้นลงใน HTML <style>.all{width:100%;}.my{display:none;}.css{color:white;}</style> <!-- later... --> <script>var all, my, js;</script> นั่นเป็นคำขอ HTTP ที่น้อยลงสองคำขอ แต่ฉันไม่เคยเห็นเทคนิคนี้มาก่อน ทำไมจะไม่ล่ะ?

1
เหตุใดฉันจึงควรใช้ Bower [ปิด]
ฉันสามารถชื่นชมประโยชน์ของผู้จัดการแพ็คเกจอย่าง Python pip, Node npmหรือ Ruby Gems เนื่องจากพวกเขากำลังทำมากกว่าการเพิ่มไฟล์ในเส้นทางแอปพลิเคชันของคุณ บางทีฉันหายไปจุดหรือฉันเป็นป้าน แต่ที่นี่เป็นเชิงลบฉันสามารถดู: แยกขั้นตอนเมื่อสร้างโครงการ แยกการติดตั้งผ่านตัวจัดการแพ็คเกจอื่น (yo dawg) ความยุ่งเหยิงมากขึ้นในโครงการรากด้วยbower.jsonและ / หรือ.bowerrc เชื่อมั่นในรีจิสทรีที่ทันสมัยถูกต้องและพร้อมใช้งาน การนำเข้า / การอ้างอิงถึงสิ่งต่าง ๆ เช่นรูปภาพจะไม่ทำงาน ทับซ้อนขนาดใหญ่ที่มี npm และมักจะไม่ชัดเจนว่าจะใช้ทรัพยากรใดเมื่อใด บวกฉันสามารถเห็นเหล่านี้: ฉันไม่ต้องดาวน์โหลดการอ้างอิงด้วยตนเอง เลือกติดตั้งแพคเกจเป็นส่วนหนึ่งของนั่งร้านขึ้นอยู่กับผู้ใช้แจ้งหรือไม่ชอบ ฉันอยากรู้ถึงผลประโยชน์ใด ๆ ที่ฉันไม่รู้และฉันควรจะบอกว่าฉันไม่ได้พยายามยั่วยุฉันอยากรู้อย่างแท้จริง

2
วิธีการแยกส่วนหน้าและส่วนหลังด้วยจาวาสคริปต์แบบเต็ม?
สมมติว่าฉันมีส่วนหน้าซึ่งส่วนใหญ่เป็นแอปพลิเคชันหน้าเดียวที่เขียนโดยใช้เชิงมุมเสียงฮึดฮัดและความโกลาหล และสมมติว่าฉันมีแบ็กเอนด์ซึ่งส่วนใหญ่เป็นเพียง REST API นั่งอยู่ด้านบนของ ORM ซึ่งเก็บ / ดึงวัตถุจากฐานข้อมูลโดยใช้สิ่งต่าง ๆ เช่นเสียงฮึดฮัดแสดงและต่อเนื่อง แอปพลิเคชันเชิงมุมทำสิ่งที่เป็นภาพทั้งหมดที่ผู้ใช้เห็น แต่ทำได้ด้วยการเป็น GUI เหนือบริการที่จัดทำโดยแบ็คเอนด์ มันจะเป็นที่พึงปรารถนาที่จะแยกสิ่งเหล่านี้ออกเป็นสอง codebases ที่แตกต่างกันเพื่อให้เกิดการพัฒนาที่เป็นอิสระการกำหนดเวอร์ชันการรวมอย่างต่อเนื่องการผลักดันการพัฒนาเป็นต้น คำถามของฉันคือมีวิธีการอะไรบ้างสำหรับการทำสิ่งนี้อย่างหมดจด? มีแนวทางปฏิบัติที่ดีที่สุดสำหรับจาวาสคริปต์แบบเต็มสแต็คหรือไม่? ตัวเลือก # 1 ดูเหมือนจะเป็นหินใหญ่ก้อนเดียวเช่น "อย่าแยกพวกมันออก" โปรคือห่วงโซ่การสร้างนั้นง่ายและทุกอย่างอยู่ในที่แห่งเดียว - แต่ดูเหมือนจะมีข้อเสียมากมาย เวอร์ชันที่ยากขึ้นไปอีกส่วนด้านหน้าที่หักหมายถึงส่วนที่ไม่สามารถปรับใช้ได้และอื่น ๆ ตัวเลือก # 2 ดูเหมือนจะเป็นแบบโมโนลิ ธ ที่ซึ่งฟลูเอ็นด์บิลด์ส่วนหน้ามีผลในการเขียนไฟล์จำนวนมากไปยังแบ็คเอนด์ distไดเรกทอรีบน front-end จะอ้างถึงไดเรกทอรีบางอย่างเกี่ยวกับ back-end เพื่อเป็นหลักเมื่อ minifies ปลายด้านหน้า uglifies ฯลฯ ก็ลงท้ายเผยแพร่ไปยัง back-end ซึ่งจะทำงานทุกอย่าง ตัวเลือก # …

8
ส่วนหน้าสุดก่อนหรือหลังสุดก่อน ในสองข้อไหนที่เป็นระบบการออกแบบที่ดี?
ฉันมีลูกค้าตอนนี้ต้องการให้ฉันพัฒนาระบบการลงทะเบียนของโรงเรียน ตอนนี้เป็นครั้งแรกที่ฉันมีความท้าทายแบบนี้ ซอฟต์แวร์ที่ผ่านมาส่วนใหญ่ที่ฉันสร้างไม่ซับซ้อน ฉันรู้ว่าพวกคุณส่วนใหญ่ได้สร้างซอฟแวร์ที่ซับซ้อนฉันแค่ต้องการคำแนะนำของคุณเกี่ยวกับเรื่องนี้ ฉันควรออกแบบส่วนหน้าหรือส่วนหลังก่อนหรือไม่ ขอบคุณ! นี่คือข้อสรุปของบทความที่ฉันพบในอินเทอร์เน็ตเมื่อไม่นานมานี้ แค่ต้องการแบ่งปัน http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 นักพัฒนา Front-End และ Back-End (ใช้ของฉัน) ส่วนตัวของฉัน เป็นเรื่องของการฝึกอีกครั้งการสรุปทั่วไปของโรคหลอดเลือดสมองในวงกว้าง: นักพัฒนาส่วนหน้า โดยทั่วไปแล้วจะไม่มีระดับ CS หรือมีระดับ CS จากโรงเรียนชั้นที่ 3 ทำงานในภาษาที่คล้ายกับพื้นฐาน (ดู PHP เป็นพื้นฐาน) มีทักษะการมองเห็นในการแปลงเอกสาร Photoshop เป็น CSS / HTML / ฯลฯ มีความอดทนสูงสำหรับการเขียนโปรแกรมซ้ำเนื่องจากภาษาฟรี นักพัฒนาส่วนหลัง มีระดับ CS หรือมีประสบการณ์มากมาย ทำให้ฉันเป็นระบบมากขึ้นในวิธีการแก้ปัญหาของพวกเขา อย่ารังเกียจที่จะใช้เวลาหลายวันเพื่อค้นหาวัตถุชิ้นหนึ่งที่รั่ว ลองและสร้างเครื่องมือเพื่อแก้ปัญหา

4
วิธีการพัฒนาส่วนหน้า (UI) สำหรับเว็บไซต์ Django ของฉัน
ฉันกำลังเรียนรู้ Django และใหม่ต่อการพัฒนาเว็บ โปรดขอโทษด้วยถ้าคุณพบว่าคำถามนี้โง่เกินไป ดังนั้นฉันกำลังสร้างแอปพลิเคชัน Facebook โดยใช้ Django ซึ่งฉันต้องการโฮสต์ใน Google App Engine โครงการจะเน้นที่การอ่านฟีด RSS / Atom ของเว็บไซต์ใด ๆ (นั่นคือทั้งหมดที่ฉันสามารถพูดได้ตอนนี้) ฉันมั่นใจในการประมวลผลไฟล์ RSS / Atom แต่ฉันกังวลเกี่ยวกับส่วนหน้า (ส่วนต่อประสานผู้ใช้) - "ส่วนการออกแบบ" ฉันไม่ทราบว่า HTML / CSS / JavaScript (ฉันสามารถจัดการกับสิ่ง HTML ง่ายๆ แต่ไม่นำไปสู่สิ่งที่ออกแบบ) ก่อนอื่นฉันคิดว่าการใช้เครื่องมืออย่าง Dreamweaver หรือซอฟต์แวร์ที่เทียบเท่ากันสำหรับการออกแบบ UI แต่เมื่อฉันเริ่มเรียนรู้ django และเริ่มเข้าสู่มันดูเหมือนว่าจะเป็นสิ่งที่ "เป็นไปไม่ได้" ดังนั้น, ฉันจะออกแบบส่วน UI ของเว็บไซต์ได้อย่างไร ฉันไม่สามารถใช้เครื่องมืออย่าง …

3
เป็นการออกแบบปกติหรือไม่ที่จะแยกแบ็กเอนด์และส่วนหน้าเว็บแอปพลิเคชันอย่างสมบูรณ์และอนุญาตให้พวกเขาสื่อสารกับ (JSON) REST API ได้หรือไม่?
ฉันกำลังสร้างเว็บแอปพลิเคชันธุรกิจใหม่และฉันต้องการบรรลุ: ใช้เทคโนโลยีที่ดีที่สุดจากอาณาจักรที่เกี่ยวข้อง ฉันต้องการกรอบแบ็กเอนด์ที่เชื่อถือได้ด้วย ORM ที่มั่นคง และฉันต้องการเฟรมเวิร์ก SPA (แอปพลิเคชันหน้าเดียว) ที่ทันสมัยที่สุดด้วยการใช้คุณสมบัติ HTML และ Javascript ล่าสุดสำหรับแอปพลิเคชันส่วนหน้า เปิดเผยเอนทิตีแบ็กเอนด์และบริการธุรกิจสำหรับการใช้งานจากแอพพลิเคชั่นประเภทต่าง ๆ เช่นเว็บแอพพลิเคชั่นมือถือ (Android) และประเภทอื่น ๆ (อุปกรณ์สมาร์ทเป็นต้น) ดังนั้น - เพื่อตอบสนองความต้องการทั้งสองอย่างฉันมีแนวโน้มที่จะแยกแอปพลิเคชันของฉันออกอย่างสมบูรณ์ในแอปพลิเคชันส่วนหลังและส่วนหน้าและจัดการการสื่อสารระหว่างกันโดยใช้ REST API (JSON) เสียงนี้เข้าใกล้หรือไม่? การแยกดังกล่าวไม่ใช่โซลูชันการออกแบบที่ชัดเจนเนื่องจากเทคโนโลยีเว็บแอปพลิเคชันจำนวนมากได้รวมเลเยอร์มุมมองไว้ซึ่งแอปพลิเคชันฝั่งเซิร์ฟเวอร์จะควบคุมการสร้างมุมมองมากขึ้นหรือน้อยลงและจัดการการตอบสนองจากมุมมองบางส่วน layer, Java JSF / Facelets จะบันทึกสถานะของส่วนประกอบบนเซิร์ฟเวอร์อย่างสมบูรณ์) ดังนั้น - มีเทคโนโลยีมากมายที่เสนอการมีเพศสัมพันธ์ที่แข็งแกร่งมากขึ้นและให้สัญญาว่าจะพัฒนาได้เร็วขึ้นและมีเส้นทางการเดินทางที่เป็นมาตรฐานมากขึ้น ดังนั้น - ฉันต้องระวังเมื่อเริ่มใช้เทคโนโลยีในลักษณะที่ไม่ได้ใช้กันอย่างแพร่หลาย ตามที่ฉันเข้าใจแล้วส่วนหน้าของ SPA ที่แยกจากกันอย่างสมบูรณ์มักเกิดจากความจำเป็นในการใช้ API ของบุคคลที่สาม แต่การออกแบบเสียง decoupling ดังกล่าวเมื่อทั้งสองแบ็กเอนด์และส่วนหน้าได้รับการพัฒนาโดย บริษัท หนึ่ง? …

2
เมื่อใดจึงเหมาะสมที่จะทำการคำนวณในส่วนหน้า
ทีมของฉันกำลังพัฒนาแอพพลิเคชั่นทางการเงินบนเว็บและมีข้อโต้แย้งกับเพื่อนร่วมงานที่จะทำการคำนวณ - แบ็คเอนด์หมดจดหรือเก็บฟรอนท์เอนด์ไว้บ้างไหม? คำอธิบายสั้น ๆ : เราใช้ Java (ZK, Spring) สำหรับ front-end และ Progress 4gl สำหรับ back-end การคำนวณที่เกี่ยวข้องกับคณิตศาสตร์ไม่ยอมใครง่ายๆ & ข้อมูลจากฐานข้อมูลจะถูกเก็บไว้ในส่วนท้ายดังนั้นฉันไม่ได้พูดถึงพวกเขา ฉันกำลังพูดถึงสถานการณ์ที่ผู้ใช้ป้อนค่า X จากนั้นจะเพิ่มค่า Y (แสดงในหน้าจอ) และผลลัพธ์จะปรากฏในฟิลด์ Z การดำเนินการ jQuery-ish ที่เรียบง่ายและบริสุทธิ์ฉันหมายถึง ดังนั้นสิ่งที่จะเป็นแนวปฏิบัติที่ดีที่สุดที่นี่: 1) เพิ่มค่าด้วย JavaScript ที่บันทึกจากการไปที่ส่วนหลังและส่วนหลังจากนั้นตรวจสอบความถูกต้องที่ส่วนท้าย "ในการบันทึก"? 2) รักษาตรรกะทางธุรกิจทั้งหมดไว้ในที่เดียวกัน - นำค่าไปยังส่วนหลังและทำการคำนวณที่นั่น? 3) ทำการคำนวณในส่วนหน้า; จากนั้นส่งข้อมูลไปยังส่วนหลังตรวจสอบความถูกต้องที่นั่นทำการคำนวณอีกครั้งและหากผลลัพธ์นั้นถูกต้องและเท่าเทียมกันแสดงให้ผู้ใช้เห็นหรือไม่ 4) มีอะไรอีกไหม? หมายเหตุ: เราทำการตรวจสอบความถูกต้องเบื้องต้นใน Java แต่ส่วนใหญ่ยังอยู่ใน back-end …

5
คำว่า 'Front-End' ตรงกันกับ 'ฝั่งไคลเอ็นต์' หรือไม่ ถ้าเป็นเช่นนั้นเป็นเช่นนี้เสมอหรือไม่
ในฐานะนักพัฒนาเว็บที่ค่อนข้างใหม่ (เรียนรู้ด้วยตนเอง) ฉันเคยได้ยินคำว่าfront-end , ฝั่งไคลเอ็นต์ , back-endและฝั่งเซิร์ฟเวอร์ค่อนข้างบ่อย สำหรับฉัน front-end และ back-end นั้นมีความหมายเหมือนกันกับฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ตามลำดับ อย่างไรก็ตามในขณะที่ฉันเริ่มทำงานกับกรอบ MVC เช่น CodeIgniter ฉันได้เจออินสแตนซ์ของการอ้างอิงถึงอะไรก็ตามที่ผู้ใช้เห็น (โดยรวมถึงโค้ดฝั่งเซิร์ฟเวอร์) ในขณะที่แบ็คเอนด์ได้อ้างถึงสิ่งใด ผู้ใช้ปลายทางไม่เห็น (รวมถึง CMS) สำหรับฉันฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์นั้นมีความหมายที่เป็นรูปธรรมมากขึ้น พวกเขามีเส้นที่แตกต่างกันมากแยกพวกเขา ส่วนหน้าและส่วนหลังในทางกลับกันอย่าทำเช่นนั้น ในการสนทนาฉันจำได้ว่ามีนักพัฒนาเว็บคนอื่นเขาเรียก CodeIgniter (อย่างครบถ้วน) ว่าเป็น front-end และสิ่งนี้ทำให้ฉันสับสน ฉันไม่แน่ใจว่าจะแก้ไขให้ถูกต้องและพูดว่า CodeIgniter เป็นส่วนท้ายของฉันหรือถ้าคำจำกัดความของคำศัพท์ทั้งสองนั้นผิดไปทั้งหมด การค้นหาคำจำกัดความของ front-end-back-end ทำให้ฉันสับสนมากขึ้นในบางประเด็นแม้ว่าพวกเขาจะอธิบายบางสิ่ง ฉันแค่อยากจะรู้ว่าเส้นไหนถูกลากระหว่างคำศัพท์ทั้งสี่นี้และวิธีที่พวกเขารวมเข้าด้วยกันในบริบทของการพัฒนาเว็บ (โดยเฉพาะในกองไฟ LAMP)

4
นักพัฒนาส่วนหน้าควรระบุรูปแบบ JSON สำหรับนักพัฒนาส่วนหลังหรือไม่
ฉันใช้บทบาทส่วนหน้าในโครงการ ฉันควรระบุเพื่อนร่วมทีม back-end ของฉันในรูปแบบที่แน่นอนของ JSON ที่ PHP ของพวกเขากลับไปที่ JavaScript ของฉันหรือไม่ ตัวอย่างเช่นฉันควรบอกพวกเขาว่าพวกเขาควรใช้รูปแบบคล้ายกับที่อธิบายไว้ที่นี่: วิธีที่เหมาะสมในการจัดโครงสร้าง JSON สำหรับการใช้งานส่วนหน้า หรือฉันควรจะรักษาบทบาทของตัวเองให้ปลอดเชื้อมากที่สุดและอธิบายด้วยคำพูดที่ว่าอินพุตและเอาท์พุตที่ฉันต้องการจากอินเทอร์เฟซส่วนหลัง (แน่นอนถ้าเกิดเหตุการณ์นี้มันอาจเป็นเรื่องยากสำหรับฉันในการจัดการรูปแบบโครงสร้างข้อมูลที่แตกต่างกัน)

4
เหตุใด XSLT จึงไม่ค่อยถูกใช้บนเว็บ? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา XSLT เป็นมาตรฐานที่ผู้ใหญ่ยอมรับอย่างกว้างขวาง มันสามารถใช้ในเบราว์เซอร์ (แม้แต่ใน IE เก่า) และบนฝั่งเซิร์ฟเวอร์ (nginx มีโมดูล XSLT ซึ่งสามารถใช้ได้จากภาษาการเขียนโปรแกรมแน่นอน) การใช้งานของมันจะรวบรวมและดังนั้นควรจะเร็วกว่า Python หรือ JS การติดตั้ง JS Saxon JS สามารถใช้อย่างน้อยเป็นทางเลือก จินจา, เชิงมุม, รูบี้ของ Slim, ASP และ PHP เทมเพลตยังไม่ได้ใกล้เคียง เท็มเพลต XSL สามารถตรวจสอบได้ง่ายใน IDE IDEs สามารถช่วยกับ Jinja หรือ Angular ได้กี่ตัว ดูเหมือนว่าเป็นความคิดที่สมบูรณ์แบบในการแยกส่วน UI และข้อมูลด้วย XSLT เป็นที่ยอมรับการใช้งานสามารถให้ผลลัพธ์ที่แตกต่างในบางกรณีมุม …

1
รหัสซ้ำซ้อนส่งไปป์ที่มีส่วนหน้าแบบไมโคร
ความเข้าใจของฉันเกี่ยวกับ Micro-frontends คือปัญหาสำคัญที่พวกเขาแก้ปัญหาคือการช่วยให้องค์กรมีทีมที่แตกต่างกันหลายทีมที่เป็นไปได้ทำงานกับแต่ละองค์ประกอบ / แอพขนาดเล็กที่จะใช้ในการเขียนเว็บแอปพลิเคชันขนาดใหญ่ นี่คือปัญหาสำคัญที่ต้องแก้ไขคือความสามารถของหลาย ๆ ทีมในการทำงานอย่างอิสระและยังสามารถสร้างคอมโพสิตขนาดใหญ่ ปัญหาคือไม่ได้เกี่ยวกับการมีกำปล่อยลีนสำหรับผู้ใช้ปลายทาง ความเข้าใจนั้นถูกต้องหรือไม่ เป็นความจริงหรือไม่ว่าหากเรามีแอปขนาดเล็กหลายตัวที่ใช้ในการเขียนแอปพลิเคชันเว็บขนาดใหญ่เราอาจมีแอพขนาดเล็กหลายตัวที่ส่งไลบรารี่ Javascript เดียวกัน ( เช่น Lodash ) ลงไปยังเบราว์เซอร์ของผู้ใช้ปลายทาง การรวมกลุ่มของผู้จัดจำหน่ายแต่ละรายซึ่งนำไปสู่รหัสซ้ำซ้อน / ซ้ำซ้อนจำนวนหนึ่งที่ถูกส่งไปยังผู้ใช้ นี่ไม่ใช่ความกังวลที่เราควรกังวลในขณะที่ออกแบบแอปพลิเคชันส่วนหน้าใช่ไหม


2
ส่วนหน้าเขียนด้วยภาษาที่ใช้สำหรับแบ็กเอนด์! [ปิด]
ปิด คำถามนี้ต้องการรายละเอียดหรือความคมชัด ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ เพิ่มรายละเอียดและชี้แจงปัญหาโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา จากประสบการณ์ของฉันในการพัฒนาเว็บไซต์ฉันรู้ว่ามีการใช้ภาษาอย่าง PHP, Java, Python..etc สำหรับการพัฒนาแบ็กเอนด์ (ซอฟต์แวร์ที่ทำงานบนเซิร์ฟเวอร์) และสำหรับภาษาส่วนหน้าใช้ JS / HTML / CSS แต่ฉันเห็นหลาย บริษัท บอกว่าพวกเขาใช้เช่น PHP สำหรับการพัฒนาส่วนหน้าและไพ ธ อนสำหรับแบ็คเอนด์ นั่นหมายความว่า PHP เป็นส่วนหน้าสำหรับการเรียกบริการอื่น ๆ ที่เขียนเป็นภาษาอื่น ๆ ผ่าน REST, RPC .. เป็นต้น?

1
การควบคุมเวอร์ชันของเว็บไซต์: ไฟล์ dev / production front-end
ฉันพยายามคิดถึงวิธีที่ดีกว่าในการควบคุมเวอร์ชันโครงการเว็บไซต์ของเรา โปรดทราบว่าฉันเป็นเพียงส่วนหนึ่งของส่วนหน้าดังนั้นฉันจึงไม่มีความรู้ที่ลึกซึ้งเกี่ยวกับ VCS เวิร์กโฟลว์กำลังเปลี่ยนแปลงและพฤติกรรมการควบคุมเวอร์ชันที่ผ่านมาล้าสมัย ปัญหาหลักคือมี 2 อาร์เรย์ของไฟล์ส่วนหน้าสำหรับแต่ละเว็บไซต์ สภาพแวดล้อม dev (ไฟล์น้อยลง js ที่ไม่บีบอัดรูปภาพ ฯลฯ ) สภาวะแวดล้อมบิลด์ "gulpified" (ทุกสิ่งถูกบีบอัดและไม่สามารถอ่านได้โดยมนุษย์) แต่คุณไม่สามารถขายเว็บไซต์ด้วยไฟล์ต้นฉบับได้ มันรู้สึกไม่ถูกต้อง มีวิธีแก้ปัญหาของการมี 2 repos: หนึ่งบิลด์หนึ่ง dev กับอึกส่งไฟล์ dev เพื่อสร้างไดเรกทอรี แต่มันเป็นเรื่องยุ่งยากที่จะรักษาด้วย บริษัท เล็ก ๆ ฉันไม่คิดว่ามันเยี่ยมขนาดนั้น มันสร้าง repos มากมายและผู้คนต้องจัดการกับ repos หลาย ๆ ครั้งบางครั้งถึงกับ repo svn เพียงตัวเดียวปัญหาก็เกิดขึ้น ดังนั้นยังมีวิธีแก้ปัญหาของการมี 1 repo: ไฟล์ต้นฉบับและไฟล์ prod ใน svn เดียวกัน …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.