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

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

ฉันแน่ใจว่ามีความแตกต่างระหว่างการพัฒนาเฟรมเวิร์กหรือไลบรารีและแอปพลิเคชัน

ก่อนอื่นนี่คือกฎ 2 ข้อของฉันที่จะหลีกเลี่ยงกลุ่มอาการของเสียกรอบ:

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

หลังจากที่คุณผ่านสิ่งเหล่านี้ให้ลองดู:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

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

2) เอกสาร, เอกสาร, เอกสาร

3) เอกสาร, เอกสาร, เอกสาร

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

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

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

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

3) กำหนดโครงการโดยย่อสำหรับตัวคุณเองพร้อมกับสิ่งที่คุณต้องการให้กรอบงานบรรลุเป้าหมายที่เป็นจริงและลำดับความสำคัญโดยรวม

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

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

ฉันไม่เห็นด้วยกับสิ่งที่ถูกพูดออกมามากมายและฉันรู้สึกว่าถูกทิ้งไว้มากขึ้นดังนั้นฉันจะเริ่มจากศูนย์

ระเบียบวิธีเปรียว

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

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

ถูกตัอง. ฉันว่าฟังก์ชั่นมีความสำคัญมากกว่าเอกสาร โปรดทราบว่า "การแถลงความคล่องตัว" ระบุว่าการจัดลำดับความสำคัญทางด้านขวายังคงมีความสำคัญน้อยกว่าทางด้านซ้าย

การสื่อสาร

ใครก็ตามที่ทำกรอบต้องรู้:

1. จะใช้งานอย่างไร: แอปพลิเคชันเป้าหมาย
2. ปัญหาอะไรที่มีไว้เพื่อแก้ไข: ปัญหาเป้าหมาย
3. ใครจะใช้มัน: กลุ่มเป้าหมาย

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

สไตล์

จำเป็นต้องพูดสร้างสไตล์ / รูปแบบการเขียนโปรแกรมและติดกับมัน

ของ E

1. Modularity : ใช้รหัสซ้ำโดยทางโปรแกรมไม่ใช่ตัวอักษร
2. ประสิทธิภาพ : รหัสของคุณมีไว้เพื่อนำมาใช้ซ้ำ สิ่งที่ทำให้ความเร็วเพิ่มทวีคูณ
3. การบำรุงรักษา : คุณต้องการให้สามารถแก้ไขเฟรมเวิร์กเพื่ออัพเดตหลายโปรแกรมโดยไม่ต้องแก้ไขโปรแกรมดังกล่าว
4. การใช้งาน : แอพพลิเคชั่นสามารถใช้งานกรอบงานของคุณได้จริงหรือไม่
5. การปฏิบัติจริง : อย่าประดิษฐ์ล้อเลื่อนหากคุณไม่จำเป็นต้องทำเช่นนั้น กรอบงานของคุณสามารถขึ้นอยู่กับกรอบงานอื่น ๆ
6. ความซ้ำซ้อน : ตรวจจับข้อยกเว้น / ข้อผิดพลาด ทุกที่. จัดการกับพวกเขา ทุกที่. อย่าเชื่อถือรหัสใด ๆ แต่อยู่ในขอบเขตภายในเพื่อจัดการข้อผิดพลาดแม้ว่าคุณจะรู้ว่ามันเป็นเช่นนั้น

ฉันแน่ใจว่ามีความแตกต่างระหว่างการพัฒนาเฟรมเวิร์กหรือไลบรารีและแอปพลิเคชัน

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

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

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

ฉันจะให้คำแนะนำกับRyan Hayes เป็นครั้งที่สองในการอ่านแนวทางการออกแบบ Frameworkแม้ว่าหนังสือจะมุ่งพัฒนากรอบงานที่ใช้. NET เพราะคำแนะนำทั่วไปนั้นสามารถใช้ได้โดยไม่คำนึงถึงเทคโนโลยีการใช้งานเฉพาะที่คุณอาจเลือกใช้

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