ฉันควรเก็บรหัสที่สร้างขึ้นในการควบคุมแหล่งที่มา

นี่เป็นการอภิปรายที่ฉันเข้าร่วมฉันต้องการรับความคิดเห็นและมุมมองเพิ่มเติม

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

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

ฉันอยากได้วิธีตรวจสอบย้อนหลังของรหัสแม้ว่าโดยปกติจะถือว่าเป็นกล่องดำก็ตาม

ข้อโต้แย้งหรือข้อโต้แย้งใด ๆ ?

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

การบันทึกในการควบคุมแหล่งที่มาเป็นปัญหามากกว่าที่จะคุ้มค่า

คุณต้องทำการคอมมิตทุกครั้งที่สร้างเพื่อให้เป็นมูลค่าใด ๆ

โดยทั่วไปเราจะปล่อยรหัสที่สร้างขึ้น (idl, jaxb stuff ฯลฯ ) ไว้นอกการควบคุมแหล่งที่มาที่ฉันทำงานและมันไม่เคยมีปัญหา

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

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

ฉันอยากได้รายการการแก้ไขที่สะอาดกว่าซึ่งรวมเฉพาะการอัปเดตจริงที่ดำเนินการเท่านั้นไม่ใช่การเปลี่ยนแปลงที่สร้างขึ้นโดยอัตโนมัติ

ปล่อยทิ้งไว้และหลังจากสร้างแล้วให้เพิ่ม 'ละเว้น' ในไฟล์ที่สร้างขึ้นแต่ละไฟล์

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

หากคุณต้องการดูเวอร์ชันประวัติของไฟล์ที่สร้างขึ้นคุณสามารถซิงค์กับเวอร์ชันเก่าของแหล่งที่มาและสร้างใหม่ได้

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

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

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

นอกจากนี้คุณอาจหลีกเลี่ยงปัญหาบางอย่างด้วยวิธีนี้ได้เช่นการสร้างโค้ดหยุดลงสักวันหนึ่ง

ไม่ด้วยเหตุผลสามประการ

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

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

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

ฉันไม่คิดว่าคุณควรเช็คอิน

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

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

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

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

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

ตอนนี้คุณต้องตรวจสอบให้แน่ใจว่ามีตัวสร้างโค้ดที่ใช้ในเวอร์ชันที่กำหนด! รุ่นใหม่กว่าสามารถสร้างรหัสที่แตกต่างกัน ...

ปล่อยมันออกไป

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

มันสร้างความปวดหัวให้กับผู้ที่พยายามแก้ไขความแตกต่างค้นหาไฟล์ที่ไม่ได้สร้างขึ้นแล้วลบทิ้ง ฯลฯ

โลกแห่งความเจ็บปวดรอผู้ที่เช็คอินไฟล์ที่สร้างขึ้น!

มีกรณีพิเศษที่คุณต้องการตรวจสอบไฟล์ที่สร้างขึ้น: เมื่อคุณอาจต้องสร้างบนระบบที่ไม่มีเครื่องมือที่ใช้สร้างไฟล์อื่น ๆ ตัวอย่างคลาสสิกของสิ่งนี้และสิ่งที่ฉันใช้คือ Lex และ Yacc code เนื่องจากเราพัฒนาระบบรันไทม์ที่ต้องสร้างและรันบนแพลตฟอร์มและสถาปัตยกรรมที่หลากหลายเราจึงสามารถพึ่งพาระบบเป้าหมายเพื่อให้มีคอมไพเลอร์ C และ C ++ เท่านั้นไม่ใช่เครื่องมือที่จำเป็นในการสร้างโค้ด lexing / parsing สำหรับนิยามอินเทอร์เฟซของเรา นักแปล. ดังนั้นเมื่อเราเปลี่ยนไวยากรณ์ของเราเราจะตรวจสอบโค้ดที่สร้างขึ้นเพื่อแยกวิเคราะห์

มาถึงช้าไปหน่อย ... อย่างไรก็ตาม ...

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

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

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

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

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

หน้าที่ของการจัดการการกำหนดค่า (ซึ่งการควบคุมเวอร์ชันเป็นเพียงส่วนเดียว) คือสามารถทำสิ่งต่อไปนี้ได้:

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

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

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

ซึ่งหมายความว่าคอมไพเลอร์ไลบรารีและอื่น ๆ ของคุณต้องเป็นส่วนหนึ่งของ CM ด้วย

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

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

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

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

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

ฉันไม่ได้แนะนำให้คุณบันทึกหรือไม่บันทึกไฟล์ gen ไม่ว่าคุณจะตัดสินใจด้วยวิธีใดหากคุณไม่เกี่ยวข้องกับ Subject Matter Experts ในการตัดสินใจว่าคุณอาจผิด

สองเซ็นต์ของฉัน

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

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

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

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

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

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

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

โดยพื้นฐานแล้วสิ่งเหล่านี้ล้วนขึ้นอยู่กับความเป็นผู้ใหญ่ของเครื่องมือ - ตัวสร้างโค้ดแอปธุรกิจส่วนใหญ่ไม่ได้ใกล้เคียงกับระดับที่คอมไพเลอร์หรือแม้แต่เครื่องมือระดับ lex / yacc ได้รับมาหลายปี

ทั้งสองฝ่ายมีข้อโต้แย้งที่ถูกต้องและสมเหตุสมผลและเป็นการยากที่จะตกลงกันในเรื่องทั่วไป Version Control Systems (VCSs) ติดตามไฟล์ที่นักพัฒนาใส่เข้าไปและมีข้อสันนิษฐานว่าไฟล์ใน VCS นั้นสร้างขึ้นด้วยมือโดยนักพัฒนาและนักพัฒนาก็สนใจประวัติและการเปลี่ยนแปลงระหว่างการแก้ไขไฟล์ใด ๆ สมมติฐานนี้ทำให้แนวคิดทั้งสองเท่าเทียมกัน "ฉันต้องการรับไฟล์นี้เมื่อฉันชำระเงิน" และ "ฉันสนใจการเปลี่ยนแปลงของไฟล์นี้"

ตอนนี้อาร์กิวเมนต์จากทั้งสองฝ่ายสามารถเปลี่ยนวลีได้ดังนี้:

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

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

สรุป

ฉันจะใช้ git เป็นตัวอย่างหนึ่งเพื่อแสดงให้เห็นว่าฉันหมายถึงอะไร

• git status ไม่ควรแสดงไฟล์ที่สร้างขึ้นตามค่าเริ่มต้น
• git commit ควรรวมไฟล์ที่สร้างขึ้นเป็นสแนปชอต
• git diff ไม่ควรแสดงไฟล์ที่สร้างขึ้นตามค่าเริ่มต้น

ปล

Git hooks สามารถใช้เป็นวิธีแก้ปัญหาได้ แต่จะดีมากถ้า git สนับสนุนโดยกำเนิด gitignoreไม่ตรงตามความต้องการของเราเนื่องจากไฟล์ที่ถูกละเว้นจะไม่เข้าสู่ VCSenter code here

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

นอกจากนี้ยังเป็นส่วนหนึ่งของ "สแนปชอต" ทั้งหมดที่คุณใช้ในที่เก็บซอฟต์แวร์ของคุณ หากเป็นส่วนหนึ่งของซอฟต์แวร์ควรเป็นส่วนหนึ่งของที่เก็บ

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

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

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

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

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

ความยากลำบากประเภทนี้อาจใช้กับโครงการนอกเวลาอาสาสมัครและโครงการโอเพ่นซอร์สมากกว่าโครงการที่ต้องเสียค่าใช้จ่ายซึ่งผู้ที่จ่ายค่าใช้จ่ายสามารถยืนยันในสภาพแวดล้อมการสร้างที่สม่ำเสมอ

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

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

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

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

ฉันจะปล่อยไฟล์ที่สร้างขึ้นจากแผนผังต้นทาง แต่วางไว้ในโครงสร้างการสร้างแยกต่างหาก

เช่นเวิร์กโฟลว์คือ

1. เช็คอิน / ออก / แก้ไข / รวมแหล่งที่มาตามปกติ (ไม่มีไฟล์ที่สร้างขึ้น)
2. ในโอกาสที่เหมาะสมตรวจสอบต้นไม้ต้นทางในโครงสร้างที่สะอาด
3. หลังจากสร้างแล้วให้ตรวจสอบไฟล์ "สำคัญ" ทั้งหมด (ไฟล์ต้นฉบับ "จริง" ไฟล์ปฏิบัติการ + ไฟล์ต้นฉบับที่สร้างขึ้น) ที่ต้องมีเพื่อวัตถุประสงค์ในการตรวจสอบ / ข้อบังคับ สิ่งนี้จะช่วยให้คุณมีประวัติของโค้ดที่สร้างขึ้นที่เหมาะสม + ไฟล์ปฏิบัติการ + อะไรก็ตามที่เพิ่มขึ้นตามเวลาที่เกี่ยวข้องกับการเผยแพร่ / การทดสอบสแนปชอต ฯลฯ และแยกออกจากการพัฒนาแบบวันต่อวัน

อาจมีวิธีที่ดีในการ Subversion / Mercurial / Git / etc เพื่อผูกประวัติของไฟล์ต้นฉบับจริงในทั้งสองที่เข้าด้วยกัน

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

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