Init.js: A Guide to the Why and How of Full-Stack JavaScript

เรื่องราว

คุณและผู้ร่วมก่อตั้งของคุณมีแนวคิดดีๆ สำหรับธุรกิจใช่ไหม

คุณได้เพิ่มคุณสมบัติในใจของคุณ

บ่อยครั้ง คุณถามผู้มีโอกาสเป็นลูกค้าเพื่อขอความคิดเห็น และพวกเขาทุกคนก็ชอบมัน

ตกลงดังนั้นผู้คนต้องการมัน มีแม้กระทั่งเงินที่จะทำ และเหตุผลเดียวที่พวกเขาไม่สามารถมีได้ก็เพราะคุณยังไม่ได้ดำเนินการ—ยัง

ในที่สุด วันหนึ่งคุณนั่งลงและพูดว่า “มาทำกันเถอะ!” ในไม่ช้า คุณกำลังพยายามหาวิธีใช้ตรรกะทางธุรกิจของแอป คุณลักษณะนักฆ่าที่จะขับเคลื่อนผลิตภัณฑ์ไปข้างหน้า: คุณมีแนวคิดเกี่ยวกับวิธีการทำ และคุณรู้ว่าคุณ ทำได้

"เสร็จแล้ว! มันได้ผล!" คุณพูด. การพิสูจน์แนวคิดของคุณประสบความสำเร็จ! เหลือเพียงการจัดแพ็กเกจลงในเว็บแอป

“ตกลง มาสร้างเว็บไซต์กันเถอะ” คุณพูด

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

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

"ฉันรู้สึกท่วมท้น" คุณพูดขณะที่คุณรู้สึกท่วมท้น พลังงานของคุณไม่เหมือนเดิม คุณพยายามปะติดปะต่อสิ่งต่างๆ เข้าด้วยกัน แต่มันก็เป็นงานมากเกินไป

การพิสูจน์แนวคิดของคุณจะค่อยๆ เหี่ยวเฉาและตายไป

ข้อเสนอ

หลังจากละทิ้งความคิดมากมายด้วยวิธีนี้ ฉันก็ตัดสินใจสร้างโซลูชัน ฉันเรียกมันว่าโปรเจ็กต์ 'Init' (หรือ init.js)

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

เพื่อให้บรรลุเป้าหมายนี้ดีที่สุด เราต้องคำนึงถึงแนวคิดสำคัญสองสามข้อ เมื่อพัฒนา Init ฉันคิดว่า:

• ส่วนประกอบ

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

• ง่ายต่อการพัฒนา

  ปัญหาบางอย่าง บางแห่งมีวิธีแก้ปัญหาที่เขียนได้ดีที่สุดใน Brainf*ck แต่การใช้วิธีแก้ปัญหานั้น (ใน Brainfuck) แทบจะเป็นไปไม่ได้เลยที่จะเขียน นับประสาอ่านอย่างเดียว จะทำให้คุณเสียเวลาและความพยายามอย่างมาก โดยทั่วไปแล้ว คุณควรใช้ภาษาและแพลตฟอร์มที่ทำให้การพัฒนาง่ายขึ้น ไม่ใช่ยากขึ้นสำหรับคุณ (หรือใครก็ตามที่อาจใช้งานได้ในภายหลัง)

• ชุมชน

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

เมื่อคำนึงถึงเป้าหมายเหล่านี้ ต่อไปฉันจะแสดงให้คุณเห็นว่าฉันตัดสินใจสร้าง Init อย่างไร

โดยพื้นฐานแล้ว Init ใช้ประโยชน์จากกระบวนทัศน์ 'full-stack JavaScript' (บางคนเรียกมันว่า MEAN Stack หรือบางส่วนของมัน) ด้วยการทำงานร่วมกับสแต็กดังกล่าว Init สามารถใช้เพียงภาษาเดียวในขณะที่สร้างสภาพแวดล้อมที่ยืดหยุ่นและโดดเด่นอย่างเหลือเชื่อสำหรับการพัฒนาเว็บแอป กล่าวโดยย่อ Init ให้คุณใช้ JavaScript ไม่เฉพาะสำหรับการพัฒนาไคลเอนต์และเซิร์ฟเวอร์ แต่ยังสำหรับการสร้าง การทดสอบ การสร้างเทมเพลต และอื่นๆ

แต่ขอให้ช้าลงสักครู่แล้วถามตัวเองว่า ควรใช้ JavaScript หรือไม่

ทำไมฉันถึงเลือกจาวาสคริปต์

ฉันเป็นนักพัฒนาเว็บมาตั้งแต่ปี 1998 ตอนนั้นเราใช้ Perl สำหรับการพัฒนาฝั่งเซิร์ฟเวอร์ส่วนใหญ่ แต่ตั้งแต่นั้นมา เราก็มี JavaScript ในฝั่งไคลเอ็นต์ เทคโนโลยีของเว็บเซิร์ฟเวอร์ได้เปลี่ยนแปลงไปอย่างมากตั้งแต่นั้นมา: เราผ่านคลื่นลูกแล้วคลื่นของภาษาและเทคโนโลยี เช่น PHP, AP, JSP, .NET, Ruby, Python เป็นต้น นักพัฒนาเริ่มตระหนักว่าการใช้สองภาษาที่แตกต่างกันสำหรับสภาพแวดล้อมไคลเอนต์และเซิร์ฟเวอร์นั้นซับซ้อน ความพยายามในขั้นต้นที่จะรวมเป็นหนึ่งเดียวภายใต้ภาษาเดียวพยายามสร้างคอมโพเนนต์ของไคลเอ็นต์บนเซิร์ฟเวอร์และคอมไพล์เป็น JavaScript สิ่งนี้ใช้งานไม่ได้ตามที่คาดไว้และโครงการส่วนใหญ่ล้มเหลว (เช่น: ASP MVC แทนที่เว็บฟอร์ม ASP.NET และ GWT อาจถูกแทนที่ในอนาคตอันใกล้โดย Polymer) แต่โดยพื้นฐานแล้วมันเป็นความคิดที่ดี: ภาษาเดียวบนไคลเอนต์และเซิร์ฟเวอร์ ทำให้เราสามารถนำส่วนประกอบและทรัพยากรมาใช้ซ้ำได้ (นี่คือคำหลัก: ทรัพยากร )

คำตอบนั้นง่าย: วาง JavaScript บนเซิร์ฟเวอร์

จริงๆ แล้ว JavaScript เกิดมาพร้อมกับ JavaScript Server Side ใน Netscape Enterprise Server แต่ภาษานั้นยังไม่พร้อมในขณะนั้น หลังจากลองผิดลองถูกมาหลายปี ในที่สุด Node.js ก็ปรากฏตัวขึ้นซึ่งไม่เพียงแต่วาง JavaScript บนเซิร์ฟเวอร์ แต่ยังส่งเสริมแนวคิดของการเขียนโปรแกรมแบบไม่บล็อก ซึ่งเปลี่ยนวิธีที่เราเขียน "fread" (I/O) ไปตลอดกาล (อ่านที่นี่ เพิ่มเติม)

แต่แนวคิดเหล่านั้นไม่ใช่เรื่องใหม่—เหตุใดจึงเป็นที่นิยมใน Node.js การเขียนโปรแกรมที่เรียบง่ายและไม่ปิดกั้นสามารถทำได้หลายวิธี บางทีวิธีที่ง่ายที่สุดคือการใช้การเรียกกลับและการวนรอบเหตุการณ์ ในภาษาส่วนใหญ่ นั่นไม่ใช่เรื่องง่าย แม้ว่า 'การเรียกกลับ' เป็นคุณลักษณะทั่วไปในภาษาอื่นๆ บางภาษา การวนรอบของเหตุการณ์ไม่ใช่ และคุณมักจะพบว่าตัวเองต้องต่อสู้กับไลบรารีภายนอก (เช่น Python กับ Tornado) แต่ใน JavaScript การเรียกกลับถูกสร้างขึ้นในภาษาเช่นเดียวกับวนรอบเหตุการณ์ และโปรแกรมเมอร์เกือบทุกคนที่เคยใช้งาน JavaScript ก็คุ้นเคยกับพวกเขา (หรืออย่างน้อยก็เคยใช้แม้ว่าพวกเขาจะไม่ค่อยเข้าใจว่าเหตุการณ์คืออะไร วนซ้ำคือ) ทันใดนั้น ทุกการเริ่มต้นใช้งานบน Earth สามารถนำนักพัฒนามาใช้ซ้ำ (เช่น ทรัพยากร) ทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ เพื่อแก้ปัญหาโพสต์งาน "Python Guru Needed"

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

• ฟังก์ชั่นการเขียนโปรแกรม

  JavaScript เป็นภาษาการเขียนโปรแกรมภาษาแรกที่นำกระบวนทัศน์การทำงานมาสู่มวลชน (แน่นอนว่า Lisp มาก่อน แต่โปรแกรมเมอร์ส่วนใหญ่ไม่เคยสร้างแอปพลิเคชันที่พร้อมสำหรับการผลิตโดยใช้ Lisp) Lisp and Self อิทธิพลหลักของ Javascript เต็มไปด้วยความคิดสร้างสรรค์ ความคิดเหล่านั้นสามารถปลดปล่อยความคิดของเราในการสำรวจเทคนิค รูปแบบ และกระบวนทัศน์ใหม่ๆ และพวกเขาทั้งหมดส่งต่อไปยัง JavaScript ดู monads หมายเลข Church หรือแม้กระทั่ง (สำหรับตัวอย่างที่ใช้งานได้จริง) ฟังก์ชันคอลเล็กชันของ Underscore.js ซึ่งสามารถบันทึกบรรทัดและบรรทัดของโค้ดได้

• วัตถุไดนามิกและการสืบทอดต้นแบบ

  Object-Oriented Programming ที่ไม่มีคลาส (และไม่มีลำดับชั้นของคลาสที่ไม่มีที่สิ้นสุด) ช่วยให้พัฒนาได้อย่างรวดเร็ว (สร้างอ็อบเจ็กต์ เพิ่มเมธอด และใช้งาน) แต่ที่สำคัญที่สุดคือ ลดเวลาในการรีแฟคเตอร์ระหว่างงานบำรุงรักษาโดยอนุญาตให้โปรแกรมเมอร์แก้ไขอินสแตนซ์ของอ็อบเจ็กต์แทน ของชั้นเรียน ความเร็วและความยืดหยุ่นนี้ปูทางไปสู่การพัฒนาอย่างรวดเร็ว

• JavaScript คืออินเทอร์เน็ต

  JavaScript ถูกออกแบบมาสำหรับอินเทอร์เน็ต มันอยู่ที่นี่มาตั้งแต่ต้น และจะไม่หายไปไหน ความพยายามทั้งหมดในการทำลายมันล้มเหลว: ดูตัวอย่างเช่นการล่มสลายของ Java Applets การแทนที่ VBScript ด้วย TypeScript ของ Microsoft (ซึ่งรวบรวมเป็น JavaScript) และการตายของ Flash อยู่ในมือของตลาดมือถือและ HTML5 เป็นไปไม่ได้ที่จะแทนที่ Javascript โดยไม่ทำลายหน้าเว็บหลายล้านหน้า ดังนั้นเป้าหมายของเราในภายภาคหน้าคือการปรับปรุงให้ดีขึ้น และงานนี้ไม่มีใครดีไปกว่า Technical Committee 39 จาก ECMA

  โอเค ทางเลือกแทน JavaScript เกิดขึ้นทุกวัน เช่น CoffeeScript, TypeScript และภาษานับล้านที่คอมไพล์เป็น JavaScript ทางเลือกเหล่านี้อาจมีประโยชน์สำหรับขั้นตอนการพัฒนา (ผ่านแผนที่ต้นทาง) แต่จะไม่สามารถแทนที่ JavaScript ในระยะยาวได้ด้วยเหตุผลสองประการ: ชุมชนของพวกเขาจะไม่มีวันใหญ่ขึ้น และสคริปต์ ECMA จะนำคุณลักษณะที่ดีที่สุดมาใช้ (เช่น JavaScript) ). JavaScript ไม่ใช่ภาษาแอสเซมบลี แต่เป็นภาษาการเขียนโปรแกรมระดับสูงที่มีซอร์สโค้ดที่คุณเข้าใจได้ ดังนั้นคุณควรเข้าใจ

JavaScript แบบจุดต่อจุด: Node.js และ MongoDB

นั่นคือเหตุผลที่ใช้ JavaScript ตอนนี้ ฉันจะใช้ JavaScript เป็นเหตุผลในการใช้ Node.js และ MongoDB

• Node.js

  Node.js เป็นแพลตฟอร์มสำหรับสร้างแอปพลิเคชันเครือข่ายที่รวดเร็วและปรับขนาดได้ นั่นคือสิ่งที่ไซต์ Node.js กล่าว แต่ Node.js เป็นมากกว่านั้น: เป็นสภาพแวดล้อมรันไทม์ที่ต้องการสำหรับแอปพลิเคชัน JavaScript ที่มีการเข้าถึง I/O แม้ว่าคุณจะไม่ได้วางแผนที่จะเขียนแอปพลิเคชันเซิร์ฟเวอร์หลักด้วย Node.js คุณก็สามารถใช้เครื่องมือที่สร้างขึ้นบน Node.js เพื่อปรับปรุงกระบวนการพัฒนาของคุณได้ ตัวอย่างเช่น Mocha.js สำหรับการทดสอบหน่วย Grunt.js สำหรับงานบิลด์อัตโนมัติ หรือแม้แต่วงเล็บสำหรับการแก้ไขโค้ดแบบเต็ม

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

• MongoDB

  MongoDB เป็นฐานข้อมูลแบบเอกสาร NoSQL ที่ใช้ JavaScript เป็นภาษาที่ใช้ค้นหา ทำให้ฉันใช้แพลตฟอร์ม JavaScript แบบ end-to-end ได้ แต่นั่นไม่ใช่เหตุผลหลักในการเลือกฐานข้อมูลนี้

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

  

การจัดองค์ประกอบเซิร์ฟเวอร์ด้วย Express.js

การจัดองค์ประกอบฝั่งเซิร์ฟเวอร์ไม่ใช่เรื่องง่าย แต่ด้วย Express.js (และ Connect.js) จึงมีแนวคิดเรื่อง 'มิดเดิลแวร์' ในความคิดของฉัน มิดเดิลแวร์เป็นวิธีที่ดีที่สุดในการกำหนดส่วนประกอบบนเซิร์ฟเวอร์ หากคุณต้องการเปรียบเทียบกับรูปแบบที่รู้จัก ก็ค่อนข้างใกล้กับท่อและตัวกรอง

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

เราเรียก 'ชิ้นส่วนของไปป์ไลน์' เหล่านี้ว่า 'มิดเดิลแวร์' เห็นได้ชัดว่า เราสามารถสร้างมิดเดิลแวร์ได้สองประเภท:

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

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

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

แอปพลิเคชั่นหน้าเดียว

โครงการ Init มุ่งเน้นไปที่การสร้างแอปพลิเคชันหน้าเดียว (SPA) นักพัฒนาเว็บส่วนใหญ่ถูกทดลองมากกว่าหนึ่งครั้งเพื่อลองใช้ SPA ฉันได้สร้างหลายอย่าง (ส่วนใหญ่เป็นกรรมสิทธิ์) และฉันสามารถพูดได้อย่างมั่นใจว่าเป็นเพียงอนาคตของเว็บแอปพลิเคชัน คุณเคยเปรียบเทียบ SPA กับเว็บแอปปกติบนการเชื่อมต่อมือถือหรือไม่? การตอบสนองต่างกันตามลำดับเวลาหลายสิบวินาที

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

MV ฝั่งไคลเอ็นต์* พร้อม Backbone.js, Marionette.js และ Twitter Bootstrap

มีการกล่าวกันมากมายเกี่ยวกับเฟรมเวิร์ก MVC* สำหรับ SPA เป็นตัวเลือกที่ยาก แต่ฉันจะบอกว่าสามอันดับแรกคือ Backbone.js, Ember.js และ Angular.js

ทั้งสามได้รับการยกย่องเป็นอย่างดี แต่อันไหนดีที่สุดสำหรับคุณ?

ขออภัย ฉันต้องยอมรับว่าฉันมีประสบการณ์ที่จำกัดมากกับ Angular.js ดังนั้นฉันจะไม่พูดถึงเรื่องนี้ (สำหรับข้อมูลเพิ่มเติม โปรดดูบทช่วยสอน Angular.js) ตอนนี้ Ember.js และ Backbone.js แสดงถึงสองวิธีที่แตกต่างกันในการโจมตีปัญหาเดียวกัน

Backbone.js นั้นเรียบง่าย เรียบง่าย และให้คุณสร้าง SPA อย่างง่ายได้เพียงพอ ในทางกลับกัน Ember.js เป็นเฟรมเวิร์กที่สมบูรณ์และเป็นมืออาชีพสำหรับการสร้าง SPA มันมีเสียงระฆังและเสียงนกหวีดมากขึ้น แต่ก็มีช่วงการเรียนรู้ที่ใหญ่กว่าด้วย

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

ในกรณีของ Init ฉันต้องการครอบคลุมสถานการณ์ส่วนใหญ่ ดังนั้นฉันจึงเลือก Backbone.js สำหรับการสร้าง SPA ที่ง่ายดาย ด้วย Backbone.Marionette.View สำหรับการจัดองค์ประกอบ ด้วยวิธีนี้ ทุกองค์ประกอบจึงเป็นแอปพลิเคชันที่เรียบง่าย และแอปสุดท้ายอาจซับซ้อนเท่าที่เราต้องการ

การจัดแต่งทรงผมก็เป็นเรื่องที่ท้าทายเช่นกัน แต่เราสามารถวางใจในกรอบการทำงานอีกครั้งเพื่อประกันตัวเราได้ สำหรับ CSS ไม่มีอะไรดีไปกว่า Twitter Bootstrap ซึ่งมีชุดสไตล์ที่พร้อมใช้งานทันทีและปรับแต่งได้ง่าย

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

แนวทางปฏิบัติที่ดีที่สุด: Grunt.js, Mocha.js, Chai.js, RequireJS และ CoverJS

สุดท้ายนี้ เราควรกำหนดแนวทางปฏิบัติที่ดีที่สุดบางส่วนของเรา และดูว่า Init สามารถช่วยคุณดำเนินการและบำรุงรักษาได้อย่างไร โซลูชันของเราเน้นที่เครื่องมือหลายอย่าง ซึ่งอิงจาก Node.js เอง

• Mocha.js และ Chai.js :

  เครื่องมือเหล่านี้ช่วยให้คุณปรับปรุงกระบวนการพัฒนาของคุณโดยใช้ TDD หรือ BDD จัดเตรียมโครงสร้างพื้นฐานเพื่อจัดระเบียบการทดสอบหน่วยของคุณและนักวิ่งเพื่อเรียกใช้โดยอัตโนมัติ

  มีเฟรมเวิร์กการทดสอบหน่วยนับพันสำหรับ JavaScript เหตุใดจึงต้องใช้ Mocha.js คำตอบสั้นๆ คือ มีความยืดหยุ่นและครบถ้วน

  คำตอบยาว: มีคุณลักษณะที่สำคัญสองประการ (อินเทอร์เฟซ นักข่าว) และการขาดงานที่สำคัญ (การยืนยัน) ให้ฉันอธิบาย

  • อินเทอร์ เฟซ : บางทีคุณอาจคุ้นเคยกับแนวคิด TDD ของชุดและการทดสอบหน่วย หรือบางทีคุณอาจชอบแนวคิด BDD เกี่ยวกับข้อกำหนดลักษณะการทำงานด้วย "อธิบาย" และ "ควร" Mocha.js ให้คุณใช้ทั้งสองวิธี

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

  • ไม่มีไลบรารีการยืนยัน : Mocha.js ไม่ได้สร้างปัญหาแต่อย่างใด เพราะได้รับการออกแบบมาเพื่อให้คุณใช้ไลบรารีการยืนยันที่คุณเลือกได้ ทำให้คุณมีความยืดหยุ่นมากขึ้น มีตัวเลือกมากมาย แต่นี่คือจุดเริ่มต้นของ Chai.js

  Chai.js เป็นไลบรารีการยืนยันแบบยืดหยุ่นที่ช่วยให้คุณใช้รูปแบบการยืนยันหลัก ๆ ได้สามแบบ:

  • ยืนยัน : สไตล์การยืนยันคลาสสิกจากโรงเรียน TDD เก่า เช่น:

     assert.equal(variable, ”value”);

  • คาดหวัง : รูปแบบการยืนยันที่เชื่อมโยงได้ มักใช้ใน BDD เช่น:

     expect(variable).to.equal(“value”);

  • ควร : ใช้ใน BDD ด้วย แต่ฉันชอบคาดหวังมากกว่าเพราะว่าควรจะฟังดูซ้ำซากกับข้อกำหนดด้านพฤติกรรม 'มัน (“ควรทำอะไรบางอย่าง..”)' เช่น:

     variable.should.equal(“value”);

  Chai.js ผสมผสานอย่างลงตัวกับ Mocha.js คุณสามารถใช้เพียงสองไลบรารี่นี้เพื่อเขียนการทดสอบของคุณในรูปแบบ TDD, BDD หรือรูปแบบใดก็ได้ตามจินตนาการ

• ฮึก.js :

  Grunt.js อนุญาตให้คุณสร้างงานโดยอัตโนมัติ อะไรก็ได้ตั้งแต่การคัดลอกและวางอย่างง่ายและการต่อไฟล์ ไปจนถึงการรวบรวมเทมเพลตล่วงหน้า ภาษาสไตล์ (เช่น SASS และ LESS) การทดสอบหน่วย (ด้วย mocha.js) linting และ การลดขนาดโค้ด (เช่น ด้วย UglifyJS หรือ Closure Compiler) คุณสามารถเพิ่มงานอัตโนมัติของคุณเองใน Grunt หรือค้นหารีจิสทรีของ Grunt ซึ่งมีปลั๊กอินอยู่หลายร้อยและหลายร้อยรายการ Grunt ยังสามารถติดตามไฟล์ของคุณและทริกเกอร์การดำเนินการเมื่อมีการแก้ไข

• ต้องการJS :

  RequireJS อาจฟังดูเหมือนเป็นอีกวิธีหนึ่งในการโหลดโมดูลด้วย AMD แต่ฉันรับรองได้ว่าคุณมีอะไรมากกว่านั้นมาก เพื่อให้เข้าใจถึงสาเหตุ อันดับแรกเราต้องพูดถึงแนวคิดของเนมสเปซโมดูล (เช่น demo.views.hello) ซึ่งหลีกเลี่ยงการสร้างมลพิษให้กับเนมสเปซส่วนกลางโดยการห่อแต่ละโมดูลในเนมสเปซของตัวเอง ปัญหาคือ โมดูลเหล่านี้ใช้ซ้ำไม่ได้ หากคุณแก้ไขเนมสเปซของ 'อินสแตนซ์' หนึ่งรายการ แสดงว่าคุณกำลังแก้ไขเนมสเปซของ 'อินสแตนซ์' ทั้งหมด ในทางตรงกันข้าม RequireJS ให้คุณกำหนดโมดูลที่นำกลับมาใช้ใหม่ได้ตั้งแต่เริ่มต้น (นอกจากนี้ มันจะช่วยให้คุณยอมรับ Dependency Injection เพื่อหลีกเลี่ยงไม่ให้โมดูลของคุณเข้าถึงตัวแปรส่วนกลาง)

• CoverJS :

  ความครอบคลุมของรหัสเป็นตัวชี้วัดสำหรับการประเมินการทดสอบของคุณ ตามชื่อของมัน มันจะบอกคุณว่าชุดทดสอบปัจจุบันของคุณครอบคลุมรหัสของคุณมากเพียงใด CoverJS วัดความครอบคลุมของรหัสการทดสอบของคุณโดยใช้คำสั่งเครื่องมือ (แทนที่จะเป็นบรรทัดของรหัสเช่น JSCoverage) ในรหัสของคุณและสร้างรหัสเวอร์ชันที่ใช้เครื่องมือ นอกจากนี้ยังสามารถสร้างรายงานเพื่อป้อนเซิร์ฟเวอร์การรวมอย่างต่อเนื่องของคุณ

การใช้สาขาเพื่อสลับคุณสมบัติ

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

โดยพื้นฐานแล้ว แต่ละสาขาแสดงถึงคุณลักษณะหรือฟังก์ชันที่ผู้ใช้อาจต้องการรวมไว้ หากคุณกำลังเริ่มต้นโครงการตั้งแต่เริ่มต้น ให้เริ่มต้นจากสาขาขั้นต่ำที่คุณต้องการ แล้วเพิ่มเทคโนโลยีอื่นๆ โดยผสานเข้ากับสาขาที่ต้องการ ตัวอย่างเช่น สมมติว่าคุณต้องการเริ่มโครงการด้วย Backbone.js และ Marionette.js คุณสามารถเริ่มต้นที่สาขา Backbone.js และรวมเข้ากับสาขา Marionette ต่อไปสำหรับฟังก์ชันการทำงานทุกอย่างที่คุณต้องการเพิ่ม

สำหรับตอนนี้ แนวคิดในการผสานเพื่อเพิ่มฟังก์ชันนี้ใช้ได้กับเทมเพลตเทคโนโลยีเท่านั้น (เช่น Backbone, Node, Express) แต่ในอนาคต คุณจะสามารถสลับไปมาระหว่างแบ็กเอนด์ (เช่น จาก MongoDB เป็น Postgres) และการใช้งานไคลเอนต์ได้

เริ่มโครงการด้วย Init และปรับใช้กับ Heroku วันนี้

ไม่เคยมีวิธีที่ง่ายกว่านี้มาก่อนในการเริ่มโครงการ เพียงไปที่ GitHub repo ตรวจสอบสาขาที่มีการคอมมิตล่าสุด (ตอนนี้เป็นผู้จัดการผู้ใช้ แม้ว่าอาจมีการเปลี่ยนแปลงในอนาคต) จากนั้น:

1. สร้างไดเร็กทอรีสำหรับโครงการของคุณ (หรือใช้ไดเร็กทอรีที่มีอยู่)
2. สร้างที่เก็บของคุณด้วย "git init" (หรือใช้ที่เก็บที่มีอยู่)

3. เพิ่มรีโมทด้วย init

    git remote add init git://github.com/picanteverde/init.git

4. รับสาขาที่ต้องการ

    git pull init usermanager

5. รับไฟล์กระบวนการ Heroku

    git pull init heroku-webprocess

6. เมื่อติดตั้ง Heroku Toolbelt แล้ว ให้สร้างแอป Heroku

    heroku create

7. ผลักดันสาขาหลักของคุณไปที่ Heroku

    git push heroku master

8. เยี่ยมชมแอปของคุณ เปิดใช้งาน Heroku!

ตอนนี้คุณสามารถเริ่มพัฒนาคุณลักษณะนักฆ่าด้วยโค้ดเพียงไม่กี่บรรทัด ไม่เพียงเท่านั้น คุณยังจะได้พัฒนาด้วยเทคโนโลยีล่าสุดและมีประสิทธิภาพสูงสุดในชุดการพัฒนาที่ทำงานอัตโนมัติอย่างที่ควรเป็น

ฉันหวังว่าคุณสามารถใช้ Init เพื่อเริ่มต้นความคิดที่ยิ่งใหญ่ครั้งต่อไปของคุณ อย่าลืมตรวจสอบพื้นที่เก็บข้อมูล Init เพื่อดูการแก้ไขและคุณลักษณะใหม่ ๆ—การพัฒนานั้นใช้งานได้จริง และเราหวังว่าจะได้รับฟังความคิดเห็นของคุณ