วิธีที่ถูกต้องในการจัดการสคริปต์นักพัฒนาซอฟต์แวร์คืออะไร?

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

วิธีที่ดีที่สุดในการจัดการพวกเขาคืออะไร? หากต้องการใส่ไว้ในไดเรกทอรี (อาจจะ /scripts) และตรวจสอบพวกเขาใน Git? เพื่อรักษาแยกในไฟล์เซิร์ฟเวอร์บาง?

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

นักพัฒนาสคริปต์ยังเข้าไปในการควบคุมเวอร์ชันเพราะโดยปกติสคริปต์เหล่านี้ยังขึ้นอยู่กับรายการในการควบคุมเวอร์ชันเช่นพา ธ ไฟล์

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

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

นอกจากคำตอบของ @ simon

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

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

เครื่องมือ / สคริปต์เหล่านี้มีผลข้างเคียงที่เป็นบวกอื่น ๆ

1. ผลผลิต
2. ถ่ายทอดความรู้
3. เอกราช(สำหรับผู้มาใหม่)

ดังนั้นใช่สคริปต์ควรอยู่ใน SCM และควรเป็นอีกเครื่องมือหนึ่งในกล่องเครื่องมือของผู้พัฒนา

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

สิ่งที่ต้องพิจารณาก่อนตรวจสอบสคริปต์ใน SCM

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

• ตรวจสอบให้แน่ใจว่าสคริปต์ไม่ได้ทำสิ่งแปลก ๆ กับระบบเช่นเพื่อดำเนินการคำสั่งที่ไม่สามารถเลิกทำได้ (โดยทั่วไปrm -rf)

• เนื่องจากสิ่งเหล่านี้กลายเป็นส่วนหนึ่งของแหล่งที่มาของโครงการเอกสารจึงได้รับการชื่นชมอย่างมาก

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

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

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

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

มีข้อควรพิจารณาเพิ่มเติมหลายประการที่ใช้กับสคริปต์ได้มากกว่าซอฟต์แวร์:

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

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