วิธีที่มีประสิทธิภาพ / มีประสิทธิภาพมากที่สุดในการพัฒนาแอปพลิเคชั่นที่มีหลายคนโดยไม่มีการควบคุมแหล่งที่มาคืออะไร?

รู้เบื้องต้นเกี่ยวกับสถานการณ์ของฉัน

ฉันทำงานให้กับ บริษัท พัฒนาเว็บไซต์ขนาดเล็ก เรามีทีมนักพัฒนา ASP.NET สี่คนซึ่งรวมถึงฉันด้วย โครงการของเราเกือบทั้งหมด (> 98%) เป็นโครงการแบบคนเดียวที่ใช้เวลาดำเนินการประมาณ 1-4 สัปดาห์ เราไม่ได้ใช้การควบคุมแหล่งที่มาหรือรุ่น สิ่งเดียวที่เรามีคือโฟลเดอร์แชร์บนเซิร์ฟเวอร์ภายในที่มีแหล่งข้อมูลล่าสุด (== แหล่งที่มาของแอปพลิเคชั่นที่ใช้งานจริง) ของโครงการทั้งหมด

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

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

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

คำอธิบายปัญหา / ข้อกังวลของฉัน

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

เนื่องจากฉันสงสัยว่าเราจะสามารถ

• ตั้งค่าเซิร์ฟเวอร์ Git ของเราเอง
• สอนให้ทุกคนทำงานกับ Git และ
• จ้าง Git สำเร็จในโครงการใหญ่นี้

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

ปรับปรุง

ฉันขอขอบคุณทุกคนสำหรับคำตอบและความคิดเห็นของพวกเขา นี่คือแผน:

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

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

นี้จะไม่เสียเวลา

เวลาที่คุณจะสูญเสียเมื่อมีคนเขียนทับหรือลบรหัสบางอย่างจะทำให้คุณเสียค่าใช้จ่ายมากขึ้น

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

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

จากนั้นเปรียบเทียบกับค่าใช้จ่ายในการรับการควบคุมเวอร์ชัน - ไม่มี (ถ้าคุณไปเปิดแหล่งที่มา) และตั้งค่า - 3 วันคน

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

หากคุณแบ่งปันแหล่งข้อมูลในโฟลเดอร์คุณสามารถแบ่งปัน repo ของที่นั่นได้เช่นกัน เจ้านายจะไม่รู้เกี่ยวกับมันยกเว้นว่ามีโฟลเดอร์. git อยู่ในนั้น

คุณไม่ควรต้องขออนุญาตทำงานของคุณอย่างถูกต้อง - เซ ธ โกลิน

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

อย่ารอจนกว่าคุณจะอยู่ตรงกลางและมีปัญหาอย่างหนักก่อนที่คุณจะทำอะไรสักอย่าง เพียงแค่ทำมันและทำงานให้เสร็จ

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

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

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

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

ฉันไม่ได้ทำงานกับฐานข้อมูลมากนัก แต่จากความรู้ของฉันที่ผสานการเปลี่ยนแปลงสกีมาของฐานข้อมูลไม่ได้รับการจัดการอย่างดีจากแหล่งควบคุม หากการรวมเหล่านั้นยากคุณอาจต้องการพิจารณาการเปลี่ยนแปลงกระบวนการที่การเปลี่ยนแปลงฐานข้อมูลทั้งหมดผ่านผู้รักษาประตูคนเดียว

นี่มันบ้า คุณควรใช้ VCS แม้ว่าคุณจะทำงานด้วยตัวเอง ห้ามใช้ VCS ใน บริษัท ควรถูกห้าม แค่ทำมัน. ตอนนี้! จริง ๆ ... คุณไม่ต้องการสิ่งขั้นสูงตั้งแต่ต้น GitHub และ GitLab นั้นใช้งานง่าย แต่ฉันแน่ใจว่าคุณสามารถหาบริการโฮสติ้งที่เข้ากันได้กับ Windows เพิ่มเติมถ้าเจ้านายของคุณยืนยัน (แม้ว่าการติดตั้งและใช้งาน Git บน Windows นั้นไม่ยาก

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

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

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

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

• ติดตั้งการควบคุมเวอร์ชันที่ใช้งานง่าย ผมใช้ในการติดตั้ง CollabNetSubversion เป็นเซิร์ฟเวอร์ SVN ก็ค่อนข้างง่ายและรวดเร็วในการติดตั้งถ้าคุณไม่สนใจที่เกี่ยวกับการรักษาความปลอดภัย ถ้าคุณใช้ Visual Studio, AnkhSvn อาจถูกติดตั้งเพื่อให้นักพัฒนาสามารถอัปเดต / คอมไพล์ซอร์สโค้ดได้ง่ายจากภายใน Visual Studio

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

• ออกจาก บริษัท นี้เนื่องจากฉันมีข้อสงสัยว่าทุกอย่างยกเว้นการควบคุมเวอร์ชันสมบูรณ์แบบและเป็นมืออาชีพที่นั่น

การไม่ใช้ VCS ในโครงการขนาดใหญ่ใด ๆ เพราะคุณไม่ต้องการลงทุนเวลาในการตั้งค่าก็เหมือนกับการเดินทางเท้าเปล่าเพราะคุณไม่ต้องการลงทุนเวลาใส่รองเท้า

VCS ใด ๆ นั้นมีลำดับความสำคัญดีกว่าไม่มีเลย

วิธีง่ายๆในการตั้งค่า VCS คือการรับTortoiseSVN (เนื่องจากคุณดูเหมือนจะใช้ C # ฉันถือว่าคุณใช้ Windows) คุณสร้างพื้นที่เก็บข้อมูลในโฟลเดอร์ท้องถิ่นที่คุณเลือก (นำทางไปยังคลิกขวา> TortoiseSVN> สร้างพื้นที่เก็บข้อมูลที่นี่) แชร์โฟลเดอร์นี้ในเครือข่ายของคุณ (มันควรจะอยู่ในเครื่องที่ใช้ได้เสมอ) และจ่ายเงินให้กับที่ file://computername/path/to/that/repositoryurl ไม่รวมการดาวน์โหลดการดำเนินการนี้ใช้เวลาไม่เกินหนึ่งนาทีในการตั้งค่า

คำตอบของคุณคือลิงค์ที่ง่ายต่อเจ้านายของคุณ ... ส่งหน้านี้ให้เขา / เธอและเน้นจำนวนครั้งที่คำว่า "ออกจาก" ปรากฏขึ้นจากมืออาชีพ

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

การควบคุมแหล่งที่มามีความจำเป็นเฉพาะเมื่อจำนวนนักพัฒนาในโครงการคือ> 0 ฉันเริ่มคิดว่าใครบางคนอาจพูดแบบเดียวกันเกี่ยวกับการรวมต่อเนื่อง ...

(-:

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

TFS จะทำให้คุณมีการรวมกลุ่มที่น่าทึ่ง DVCS (mercurial หรือ git) อาจให้ความยืดหยุ่นและความสามารถสูงสุดแก่คุณ ไม่มีเหตุผลที่ดีที่จะไม่ทำเช่นนี้

ถ้าฉันเริ่มต้นจากศูนย์มันคงจะเป็น Mercurial แน่นอน

เมื่อคุณมีการควบคุมเวอร์ชันแล้วคุณสามารถไปยังเซิร์ฟเวอร์บิลด์ (TFS, TeamCity) และจากที่นั่นไปยังการรวมระบบอย่างต่อเนื่องและ ณ จุดนั้นคุณจะเริ่มเอาชนะการกำปั้น

ในการกลับมาที่จุดเริ่มต้นของคุณ:

ฉันจะเป็นหัวหน้าโครงการ (ผู้จัดการโครงการและหัวหน้านักพัฒนา) และฉันจะรับผิดชอบทุกอย่าง

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

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

ฉันขอแนะนำให้คุณใช้ Git อย่างใดอย่างหนึ่งเนื่องจากคุณมีประสบการณ์มาแล้วหรือ Mercurial ซึ่งมีการรวมเข้ากับ Visual Studio เป็นอย่างดี

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

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

ดังนั้นสิ่งที่เราทำค่อนข้างง่าย "เฮ้ทอมฉันจะทำงานกับ xyz.pbl ดังนั้นอย่าเปลี่ยนแปลงอะไรเลย" ในโครงการที่ยิ่งใหญ่ของสิ่งที่เราไม่ค่อยมีปัญหาใด ๆ

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

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

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

มันไม่ใช่ทางออกในอุดมคติ แต่ก็ดีกว่าไม่มีอะไรเลย

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

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

อันตราย

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

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

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

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

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

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

แต่ละโคลนเป็นการสำรองข้อมูล

หากเซิร์ฟเวอร์ฮาร์ดไดรฟ์ขัดข้องทุกคนมีสำเนาพร้อมที่จะนำไปใช้กับไดรฟ์หรือเซิร์ฟเวอร์ใหม่ เนื่องจาก บริษัท ของคุณไม่จริงจังกับการควบคุมเวอร์ชันฉันคิดว่ามันอาจเหมือนกับการสำรองข้อมูล

ข้อมูลอ้างอิงทั่วไป

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

ส่งมอบอย่างสะดวกสบายมากขึ้น

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

ย้อนเวลากลับไปและแก้ไขข้อผิดพลาดของคุณ

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

ค้นหาข้อบกพร่องได้ง่ายขึ้น

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

ผู้พัฒนาแต่ละคนรับผิดชอบงานของตนเอง

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

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

ความแตกต่างคือการผสานนั้นกระทำโดยผู้ที่ทำการเปลี่ยนแปลงซึ่งรู้รหัสนั้นดีที่สุดเพราะเขา / เธอเขียนมัน

ใครเป็นคนเขียนรหัสนั้น

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

โครงการกำลังใหญ่ขึ้นเรื่อย ๆ

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

การเปลี่ยนแปลงที่เร่งด่วน

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

มันทำงานได้ 10 นาทีที่แล้ว

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

ด้วย VCS คุณเพียงแค่ทำสิ่งต่าง ๆgit diffในทันทีและมีการเปลี่ยนแปลงเมื่อเทียบกับรหัสที่ถูกต้องที่คุณใช้

ฉันต้องเก็บบันทึกการดีบักของฉัน

ดังนั้นคุณเป็นคนเลวและไม่ใช้การบันทึกหรือไม่ คุณต้องโรยprintfโค้ดโค๊ดทั้งหมดของคุณจนกว่าคุณจะพบชิ้นส่วนทั้งหมดของข้อผิดพลาดที่น่ารังเกียจ? ตอนนี้คุณพบแล้วแก้ไขได้ แต่ต้องการเก็บรหัสการดีบักที่ออกแบบมาอย่างดีเพื่อแก้ไขปัญหาที่เหลือ

หากไม่มี VCS คุณจะต้องคัดลอกไฟล์ expurge code debug (ซึ่งอาจเพิ่มข้อผิดพลาดในการแก้ไขบางส่วน) ดันมันและนำไฟล์สำรองที่สำรองไว้กลับมา โอ้ดูเหมือนว่าจะมีรหัสการดีบักบางส่วนอยู่ในนั้น

ด้วยคอมไพล์คุณเพียงgit add --patchและเลือกกี่บรรทัดของรหัสที่คุณต้องการที่จะใส่ในกระทำของคุณและสามารถกระทำเพียงว่า จากนั้นคุณทำงานต่อและยังคงมีรหัสการดีบัก คุณไม่จำเป็นต้องแตะรหัสดังนั้นจึงไม่มีข้อผิดพลาดในการคัดลอก / วาง

ลูกบอลโคลนขนาดใหญ่

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

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

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

รอยหยัก

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

คุณเป็นหัวหน้าโครงการ

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

ใช้ dropbox มันมีประวัติรุ่นอัตโนมัติ คุณสามารถแบ่งปันโฟลเดอร์ดรอปบ็อกซ์ระหว่างผู้ใช้หลายคน

แก้ไข

คุณยังสามารถดาวน์โหลด TortoiseSVN-client และสร้าง "local repository" บนไดรฟ์เครือข่าย จากนั้นผู้คนสามารถเช็คเอาต์ซอร์สโค้ดตามตำแหน่งโฟลเดอร์เครือข่าย