ความกลัวของเว็บแอปที่ไม่ได้เป็น "การพิสูจน์ในอนาคต"


106

ฉันเป็นผู้พัฒนาเว็บของแอปพลิเคชันเว็บ SaaS ขนาดเล็กในท้องถิ่น ปัจจุบันมีลูกค้าประมาณครึ่งโหล

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

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

ฉันได้ฝึกงานในฐานะนักพัฒนาเต็มสแต็คในเดือนมกราคมที่ซึ่งฉันจะเริ่มเรียนรู้เฟรมเวิร์กเอนด์ แต่แรงกดดันที่จะทำให้แอพพลิเคชั่นสิ้นสุดลงกำลังจะติดตั้งและฉันกำลังพิจารณาว่า ซึ่งเป็นสิ่งที่ฉันเคยทำมาก่อน แอพนี้ถูกสร้างขึ้นใน PHP และ jQuery (สำหรับการโทร AJAX) และใช้ MySQL สำหรับฐานข้อมูล ความคิดใด ๆ เกี่ยวกับวิธีที่ฉันสามารถเอาชนะบล็อกจิตนี้และเพื่อให้แน่ใจว่าแอปของฉันจะสามารถปรับขนาดได้? ขอบคุณล่วงหน้า.


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

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

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

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

6
@james_pic คุณทำโครงการเว็บโดยไม่มีกรอบพื้นฐาน (พูดว่า asp.net core ใน. NET และอื่น ๆ )? ดังนั้นคุณจึงปรับใช้ตรรกะการจัดเส้นทางและสิ่งอื่น ๆ ทั้งหมดที่อยู่ด้านบนของห้องสมุด http ง่าย ๆ ? ดูเหมือนจะมากเกินไปและฉันไม่เห็นว่าข้อได้เปรียบอะไรที่ควรให้คุณ
Voo

คำตอบ:


201

สมบูรณ์แบบเป็นศัตรูของความดี

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


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

83
YAGNI, ทารก, YAGNI
Kevin

32
อีกกรณีของ " การปรับให้เหมาะสมก่อนกำหนดคือรากของความชั่วร้ายทั้งหมด " อาจจะน่าพูดถึงว่าคุณจะไม่กระโดดจากผู้ใช้ 6 คนเป็นล้านคน หากลูกค้า 6 รายเพียงพอที่จะจ่ายเงินให้นักพัฒนาหนึ่งรายแม้แต่ในเวลาที่คุณเข้าถึงลูกค้า 100 รายรหัสอาจต้องมีโครงสร้างที่แตกต่างกันเพื่อให้ผู้พัฒนาระบบหลายคนทำงานในเวลาเดียวกัน ค่อนข้างแตกต่างจากการเพิ่มประสิทธิภาพและเกิดขึ้นเร็วกว่าการเล่นกลผู้ใช้นับล้าน
R. Schmitz

22
@ R.Schmitz คำพูดเหล่านี้ถูกนำมาใช้ในบริบทที่แตกต่างอย่างสิ้นเชิงกับวิธีที่ Knuth ใช้ในการเขียนโปรแกรมคอมพิวเตอร์เป็นศิลปะ Knuth ต่อต้านทั้งหมด "ตัดสินใจเริ่มโปรแกรมและกังวลเกี่ยวกับการปรับให้เหมาะสมในภายหลัง" สิ่งที่เขาพูดก็คือผู้คนเพิ่มประสิทธิภาพส่วนที่ผิดของรหัสในเวลาที่ผิด นั่นหมายความว่าคุณไม่ควรใช้เวลาคิดเกี่ยวกับสถาปัตยกรรมของคุณเพื่อให้แน่ใจว่ามีประสิทธิภาพก่อนที่คุณจะเริ่มเขียนโค้ด คุณอาจชอบความรู้สึกอื่น ๆ แต่คุณไม่ควรอ้างอิง Knuth ในฐานะผู้พิทักษ์ที่นั่น
Voo

20
@ R.Schmitz ย้อนกลับไปเมื่อ Hoare / Knuth ได้ประกาศว่า "การเพิ่มประสิทธิภาพ" นั้นหมายถึงการนับรอบและสิ่งอื่น ๆ ที่เราไม่ได้ทำในวันนี้อีกต่อไปไม่ "คิดเกี่ยวกับสถาปัตยกรรมที่ดีก่อนที่จะเริ่มเขียนโค้ด" การใช้คำพูดเป็นข้ออ้างที่จะไม่คิดถึงการออกแบบระบบที่ดีไม่ใช่แค่สิ่งที่อยู่ในใจ
Voo

110

ความคิดใด ๆ เกี่ยวกับวิธีที่ฉันสามารถเอาชนะบล็อกจิตนี้และเพื่อให้แน่ใจว่าแอปของฉันจะสามารถปรับขนาดได้?

ปัญหาที่เกิดขึ้นไม่ใช่ความยืดหยุ่น ปมของปัญหาที่คิดว่าคุณจะได้รับมันขวาครั้งแรก

คุณควรเน้นที่การเขียนโค้ดที่สะอาด เพราะโค้ดที่สะอาดจะเพิ่มความสะดวกสบายสูงสุดเมื่อคุณ (อย่างหลีกเลี่ยงไม่ได้) ต้องเปลี่ยนบางอย่างในอนาคต และนั่นคือเป้าหมายที่แท้จริงที่คุณควรมี

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

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

เมื่อแนบไฟล์กับโครงการและรหัสที่ฉันเขียนไปแล้ว

ฉันเห็นอกเห็นใจกับความรู้สึกนี้อย่างแน่นอน แต่การแนบรหัสที่คุณเขียนนั้นเป็นปัญหา

สิ่งเดียวที่ควรจะเป็นคงเป็นความปรารถนาของคุณเพื่อแก้ปัญหาที่เฉพาะเจาะจง วิธีที่คุณจะแก้ปัญหานั้นเป็นเพียงความกังวลรอง

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

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

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

นั่นเป็นปัญหาที่แตกต่างกันไปในแต่ละวัน

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

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

สร้างแอปพลิเคชันแทนและพิสูจน์ว่ามีปัญหาจริงๆ และเมื่อปัญหาชัดเจนแล้วคุณก็เริ่มจัดการกับมัน

เพื่อให้เป็นอีกแนวทางหนึ่ง: Henry Ford ไม่เคยสร้างรถยนต์ที่สอดคล้องกับมาตรฐาน / ความคาดหวังในปี 2018 แต่ถ้าเขาไม่ได้สร้างโมเดล T ซึ่งเป็นรถที่มีข้อบกพร่องตามมาตรฐานสมัยใหม่จะไม่มีใครเริ่มใช้รถยนต์จะไม่มีอุตสาหกรรมรถยนต์และไม่มีใครมีรถที่พวกเขาสามารถลองปรับปรุงได้

ฉันมีนายจ้างถามทางเลือกของฉันในการไม่ใช้เฟรมเวิร์กของเว็บใด ๆ ในระหว่างการสัมภาษณ์ซึ่งทำให้ฉันสงสัยในผลงานก่อนหน้าของฉันเพิ่มเติม

ส่วนสำคัญที่นี่ไม่ใช่กรอบการทำงานที่คุณใช้ (นายจ้างคนใดที่ตัดสินว่าคุณทำงานไม่ถูกต้อง) ส่วนที่สำคัญที่นี่จะรู้ว่าสิ่งที่คุณทำและทำไมคุณกำลังทำมัน

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

คำตอบที่ไม่ดีเพียงอย่างเดียวคือ "ฉันไม่รู้" เพราะมันแสดงให้เห็นถึงการขาดการตัดสินใจอย่างชาญฉลาด นั่นคือธงสีแดงสำหรับนายจ้าง

ฉันไม่รู้โครงร่างเว็บใด ๆ และไม่รู้ว่าจะเริ่มใช้อันไหน

ปัญหาเดียวกันเกิดขึ้นที่นี่ วิธีแก้ปัญหาไม่ได้คิดมาก แต่เป็นการกระทำ:

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

เพื่ออ่านข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้อ่านความคิดทำ> ความคิดความคิด ผู้เขียนอธิบายได้ดีกว่าที่ฉันสามารถ

แต่ความกดดันที่จะทำให้แอพพลิเคชั่นสิ้นสุดลงกำลังจะติดตั้งและฉันกำลังพิจารณาที่จะทำให้แอปพลิเคชันนั้นหมดและเริ่มต้นใหม่

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

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


9
การเริ่มต้นจากศูนย์มักไม่ใช่ทางเลือกที่เหมาะสม: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
Martin Bonner

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

4
@ Flater ฉันเห็นด้วยกับสิ่งที่เขียนส่วนใหญ่ที่นี่ยกเว้นสิ่งหนึ่ง: ถ้าคุณจะเลือกกรอบงานและคุณไม่รู้อะไรเลยเกี่ยวกับพวกเขาคุณสามารถตรวจสอบระดับการยอมรับกรอบงานนั้นได้ ตัวอย่างเช่นมีดาวกี่ดวงบน GitHub? มีปัญหากี่เรื่อง มีผู้สนับสนุนกี่คน เมื่อใดคือการอัปเดตครั้งล่าสุด ตอบคำถามเหล่านี้อย่างน้อยอาจช่วยในการเลือกกรอบงานที่คุณสามารถขอความช่วยเหลือจ้างคนที่รู้ดีกว่า ฯลฯ
Jalayn

@Jalayn One จะสมมติว่าผู้เริ่มต้นที่ไม่มีความรู้ล่วงหน้ามีแนวโน้มที่จะสะดุดกับกรอบที่รู้จักกันดีในการเริ่มต้น
Flater

3
นี่คือคำตอบที่ดีเพราะมันส่งเสริมวิธีการที่มีระเบียบวินัยและมีระเบียบ ฉันใช้เวลาหลายปีกว่าจะได้รับคำแนะนำแบบนี้อย่างเต็มที่!
kashiraja

18

แม้ว่า Facebook และ Google จะใช้เงินจำนวนมหาศาลในการทำการตลาดเพื่อโน้มน้าวคุณเป็นอย่างอื่น แต่เฟรมเวิร์กส่วนหน้ามีอยู่ด้วยสองเหตุผลหลัก:

  • ขั้นแรกการถ่ายโอนฮาร์ดแวร์ / เครือข่ายต้องการการดำเนินงานฝั่งไคลเอ็นต์โดยกำหนดสถานะและตรรกะในไคลเอนต์
  • ประการที่สองเกี่ยวข้องกับตรรกะไคลเอนต์เพิ่มเติมที่จำเป็นเพื่อสนับสนุนจุดแรกพวกเขาให้บริบทการดำเนินการแยกเพื่อให้คุณสามารถอัดโค้ดของคนอื่นลงในหน้าโดยไม่ทำลายอะไรเลย

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

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

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

Vanilla JS และ JQuery ที่มีขอบเขตน้อยกว่า แต่ยังคงสำคัญไม่ได้รับปัญหาเหล่านี้ ด้วยข้อยกเว้นที่น่าสังเกตบางอย่างแอปพลิเคชั่น JQuery + AJAX ที่ไม่ขึ้นอยู่กับพฤติกรรมของเบราว์เซอร์ที่เฉพาะเจาะจงและการพึ่งพาจากภายนอกซึ่งมีเหตุผลสามารถทำงานต่อไปได้อีก 10-15 ปีหลังจากที่เขียนด้วยการเปลี่ยนแปลงเล็กน้อย

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

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

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


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

@fluffy สิ่งใดโดยเฉพาะคุณคิดว่า Angular หรือ React ทำเพื่อคุณซึ่งง่ายกว่าการทำสิ่งเดียวกันใน vanilla JS หรือ JQuery ในปี 2018 บนเบราว์เซอร์ที่ไม่ใช่สำหรับมือถือหรือไม่? FF / Chrome / Edge มีพื้นที่ผิวมากกว่าปกติพอที่จะสร้างแอปพลิเคชันขนาดเล็กที่ใช้งานได้อย่างสมบูรณ์ในวันนี้
Iron Gremlin

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

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

1
ฉันไม่เคยได้ยินเกี่ยวกับการถ่ายซีพียูไปยังไคลเอนต์เป็นเหตุผลในการใช้ JS - ฉันจะบอกว่าแนวโน้มในอดีตของการใช้ JS ในไคลเอนต์แสดงให้เห็นว่า (ฉันไม่ได้บอกเหตุผล (หนึ่งที่เอาชนะ) เหตุผล ชี้แจงแทนนับตั้งแต่ jQuery หั่นผ่าน Gordian Knot เกี่ยวกับความไม่เข้ากันของเบราว์เซอร์
Radarbob

7

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

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

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

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

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

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

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

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

เคล็ดลับคือการลดให้น้อยที่สุดโดยการค้นหาความรู้ที่มีอยู่ล่วงหน้า (กลยุทธ์แนวปฏิบัติที่ดีที่สุดและรหัส / ห้องสมุด / กรอบ) ตลอดทุกขั้นตอนของกระบวนการพัฒนา

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

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


5

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

นี่คือการเปรียบเทียบที่ฉันชอบที่จะใช้:

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

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

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

ส่วนใหญ่ของธุรกิจของฉันในวันนี้คือการช่วยให้ลูกค้ารับมือกับซอฟต์แวร์ที่สร้างขึ้นเมื่อสิบยี่สิบยี่สิบหรือมากกว่าปีที่ผ่านมาโดยใช้เทคโนโลยี "ทันสมัย" ที่มีอยู่ในสมัยนั้น - และสิ่งที่ ahem ฉันจำได้) - และที่ยังคงให้บริการ (!) วันนี้


3

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

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


3

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

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

ในฐานะที่เป็นประเด็นหลักของการรู้กรอบแรกของคุณคือการเรียนรู้ภาษากลางบางทีแค่ลองเรียนรู้สิ่งที่เป็นที่นิยมในหมู่เพื่อนของคุณ คุณอาจลองแก้ไขโครงการง่ายๆที่เขียนในกรอบงาน การเริ่มโครงงานตั้งแต่เริ่มต้นในกรอบที่คุณไม่รู้เป็นวิธีการเรียนรู้ที่ไม่มีประสิทธิภาพมาก

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


2

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

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

ฉันไม่ต้องการบอกคุณว่าการลบรหัสสนุกกว่าเขียน

(เน้นที่เหมือง)

ด้ายบทความเกี่ยวกับข่าว Hackerยังอาจจะมีมูลค่าการอ่าน


-1

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

รักษารหัสของคุณให้สะอาดทำตามหลักการของ SOLID, DRY> google

ใช้ load-balancer โดยเร็วที่สุด

ยืนขึ้นอย่างน้อยสองเว็บเซิร์ฟเวอร์จัดการสถานการณ์จำลองการโหลดในโค้ด

และสุดท้าย แต่ไม่ท้ายสุดมีการจัดการที่ดีกว่าสำหรับผู้ใช้นับล้านคนกว่า LAMP แต่ฉันมั่นใจว่ามันใช้งานได้จริง

กรณีและจุดให้ดูที่: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade คะแนนถูกต้อง แต่ 10gb เป็นเรื่องเล็กน้อย เป็นแบบทดสอบ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.