การสร้างกรอบการทำงานของคุณเองจะดีกว่าการใช้โครงร่างที่มีอยู่เมื่อใด [ปิด]

ฉันอยากรู้ว่าทำไมคุณถึงตัดสินใจสร้างกรอบการทำงานของคุณเองใน บริษัท ของคุณ

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

ดังนั้นทำไมคุณไม่สร้างกรอบการทำงานของคุณเอง? คุณจะให้เหตุผลกับคนที่จ้างคุณได้อย่างไร คุณวัดผลกระทบทางบวกและลบของมันหรือไม่?

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

ตอบทำไม:

• ปัญหาใบอนุญาต
• ข้อกำหนดเฉพาะของ บริษัท ที่ไม่มีอยู่ในกรอบงานปัจจุบัน
• บริษัท ต้องการที่จะควบคุมการสนับสนุนและการบำรุงรักษากรอบ
• สถาปนิกไม่รู้ดีกว่า! เขา / เธอไม่รู้เกี่ยวกับเฟรมเวิร์กเฉพาะที่มีอยู่ดังนั้นพวกเขาจึงตัดสินใจคิดค้นล้อ

ปรับปรุง:

องค์กรต้องการสร้างล้อแทนที่จะใช้กรอบ "เล็ก" โดยขนาดเล็กฉันหมายถึงกรอบที่อาจมีอนาคตไม่แน่นอน สำหรับกรอบงาน. NET นั้นมีความปลอดภัยมากกว่าเลือกสำหรับองค์กรมากกว่ากรอบงานที่สร้างขึ้นโดยชุมชนเล็ก ๆ องค์กรต้องการความปลอดภัยเนื่องจากแอปพลิเคชั่นจำนวนมากมีความสำคัญต่อธุรกิจและมีอายุการใช้งานยาวนาน. ค่าใช้จ่ายในการปรับแต่งล้ออาจมีมากขึ้นในระยะเวลาอันสั้น แต่ค่าใช้จ่ายอาจจะมากกว่านี้หากเฟรมเวิร์กที่ใช้ในแอปพลิเคชัน บริษัท เลิกใช้แล้วและไม่ได้รับการสนับสนุนอีกต่อไป ที่นี่ บริษัท อาจต้องทิ้งกรอบการทำงานปัจจุบันและใส่ในกรอบอื่น Visual Basic เป็นตัวอย่างที่ดีของภาษาที่ Microsoft ไม่สนับสนุนอีกต่อไป และ บริษัท ต้นทุนนี้มีมูลค่านับพันล้านเนื่องจากพวกเขาต้องเริ่มต้นด้วยการพัฒนาใหม่

สร้างของคุณเองทำไม

1. เพราะมันไม่เคยถูกสร้างมาก่อน (หายาก แต่ก็มีความเป็นไปได้อยู่ดี)
2. เพราะคุณต้องการการควบคุมอย่างเต็มที่
3. เพราะคุณต้องการฟังก์ชั่นเล็กน้อยเพื่อที่จะสร้างมันเองได้ราคาถูก

ทำไมไม่สร้างของคุณเอง?

1. คุณไม่มีเวลาทำเช่นนั้น
2. มันอาจถูกกว่ามากถ้าคุณซื้อเฟรมเวิร์กที่มีอยู่
3. คุณประหยัดเวลาได้มากและทำงานได้เร็วขึ้นมาก

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

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

เหตุผลที่แท้จริงเพียงข้อเดียวคือ:

1. เฟรมเวิร์กที่มีอยู่ได้รับการดูแลอย่างดีเหมาะสมกับงานของคุณอย่างเต็มที่และจะนำไปสู่อนาคต

2. นี่เป็นเพียงกรณีของโรค' Not Invented Here '

3. การตั้งค่าปัจจุบันของคุณจะไม่สามารถสร้างเฟรมเวิร์กนี้ได้สำเร็จภายในระยะเวลาที่เหมาะสมในราคาที่สมเหตุสมผล

Joel Spolsky เขียนบทความที่ดีมากเกี่ยวกับเรื่องนี้: ในการป้องกันโรคที่ไม่ได้คิดค้นที่นี่

โดยทั่วไปเมื่อคุณใช้งานของผู้อื่นคุณเพิ่มพวกเขาเป็นนายจ้างที่มองไม่เห็นหรือ "มือเสริม"

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

คำหลักคือการทำให้กรอบงานชนิดถอดเปลี่ยนได้โดยการเข้ารหัสไปยังอินเทอร์เฟซ อินเทอร์เฟซที่เข้มงวดที่สุดในโลกของ Java คือข้อกำหนดของ Sun ซึ่งพิสูจน์ได้โดย servlet API

จากนั้นฉันจะไม่พิจารณาว่ามีเหตุผลใดที่ไม่ใช้กรอบงาน

เรามีกรอบการทำงานที่ค่อนข้างเป็นผู้ใหญ่ที่ฉันทำงานอยู่ นี่คือสรุปพื้นฐานของมูลนิธิ

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

(มุมมองของฉันเองไม่ใช่ของนายจ้างเป็นต้น)

ฉันทำเช่นนั้นหลายครั้งเพื่อให้เป็นไปตามข้อกำหนดที่ไม่ครอบคลุมโดยเฟรมเวิร์กที่มีอยู่ (ย้อนหลัง)

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

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