มีอะไรบ้างที่ต้องระวังเมื่อเตรียมพร้อมที่จะส่งมอบโครงการ?

ฉันเป็นผู้พัฒนา / สถาปนิก แต่เพียงผู้เดียวของแอปพลิเคชันเว็บที่ค่อนข้างใหญ่ (ASP.NET MVC stack, โค้ดประมาณ 150K + บรรทัด) และจุดสิ้นสุดของการพัฒนาอยู่บนขอบฟ้า ด้วยเหตุนี้ฉันจึงเริ่มคิดถึงสิ่งที่ต้องทำเพื่อให้พ้นมือของโครงการและฉันต้องการทำให้แน่ใจว่าฉันจะทำสิ่งที่ถูกต้องสำหรับทุกคนที่ต้องดูแลโครงการในอนาคต

มีอะไรบ้างที่ต้องระวังเมื่อเตรียมพร้อมที่จะส่งมอบโครงการให้กับผู้พัฒนารายอื่นหรือทีมผู้พัฒนาบำรุงรักษา

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

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

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

อะไรที่เหนือกว่าคำแนะนำสองข้อข้างต้นนั้นอาจจะเป็นน้ำเกรวี่ แต่ IMHO ทั้งสองข้อนี้จำเป็นสำหรับโครงการที่ใหญ่กว่า "Hello World" เกือบทั้งหมด

แก้ไข:

ในหัวข้อเอกสารประกอบ ...

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

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

นี่คือเหตุผลว่าทำไมความคิดเห็นที่ไม่ได้กลิ่นรหัส นี่คือสาเหตุที่เราควรจัดทำเอกสารรหัสของเรา

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

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

โชคดี!

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

ฉันไม่สามารถโหวตคำตอบได้มีอะไรบ้างที่ต้องระวังเมื่อเตรียมพร้อมที่จะส่งมอบโครงการ? พอฉันต้องเขียนมันอีกครั้ง

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

นอกจากนั้นฉันเพิ่ม README.txt ไปยังไดเรกทอรีรากซึ่งอธิบายการออกแบบโดยรวมส่วนที่ซับซ้อนและสภาพแวดล้อมของโครงการ (ในแง่ของการสื่อสารกับแผนกหรือบุคคลอื่น ๆ )

ฉันพยายามทำให้ README.txt นี้มีขนาดเล็กเพราะไม่มีใครอ่านเอกสารข้อกำหนดมากกว่า 200 หน้าหากสิ่งที่คุณต้องการทำคือแก้ไขข้อผิดพลาดรวบรวมและทำแพ็กเกจ รายละเอียดการติดตั้งใช้งานได้รับการบันทึกไว้ในการทดสอบหน่วยดังนั้นจึงไม่จำเป็นต้องเขียนลงไปอีกในหนังสือ ...

รายการตรวจสอบแฮนด์ออฟเริ่มต้นของฉัน:

1. ตรวจสอบสำเนาที่สะอาดจาก VCS
2. ทดสอบการสร้างทดสอบการใช้งาน
3. เปลี่ยนชื่อ repo Maven เป็น repo-back-up
4. ทดสอบการสร้างอีกครั้ง
5. ติดตั้งสำเนาแอปเซิร์ฟเวอร์สดจาก zip
6. ตรวจสอบการตั้งค่าเซิร์ฟเวอร์หมายเหตุ
7. ทดสอบการใช้งานอีกครั้ง
8. ตรวจสอบว่าไม่มีการทดสอบหน่วยถูกปิดใช้งาน
9. สแกนความคิดเห็นสำหรับคำที่เป็นตัวอักษรสี่ตัวลบออก

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