เป็นไปได้ไหมที่โปรแกรมเมอร์ที่ดีจะไม่เคยใช้การควบคุมเวอร์ชัน? [ปิด]

ฉันกำลังมองหาโปรแกรมเมอร์ผู้เชี่ยวชาญเพื่อช่วยแก้ไขสถานการณ์ที่ยากลำบาก

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

ปัญหาในตัวมันเองอาจไม่จริงจังเกินไปเพราะเป็นสิ่งที่สามารถเรียนรู้ได้ในเวลาอันสั้น

แต่มีแง่มุมที่ลึกกว่าซึ่งทำให้ฉันเป็นกังวล:

เป็นไปได้อย่างไรที่จะพัฒนาซอฟต์แวร์อย่างต่อเนื่องเป็นเวลา 10-15 ปีโดยไม่จำเป็นต้องมีการควบคุมเวอร์ชัน?

ความจริงแล้วตัวเองไม่ได้มองหาวิธีแก้ไขปัญหาในการติดตามการเปลี่ยนแปลงสัญญาณของทัศนคติที่ไม่ถูกต้องในการเขียนโปรแกรมหรือไม่?

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

ใช่มีการเขียนโปรแกรมก่อนอินเทอร์เน็ต

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

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

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

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

• ดี

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

• ไม่ดี

  การควบคุมเวอร์ชันเป็นเพียงคำศัพท์ที่กำลังจะตายอย่างช้า ๆ ในอุตสาหกรรม ฉันเหนือการควบคุมเวอร์ชัน

ฉันจะให้มุมมองจากการพัฒนาซอฟต์แวร์ใน DOS และ Windows มานานกว่า 20 ปี

ซอฟต์แวร์ควบคุมเวอร์ชันในโลก Windows / PC นั้นมักไม่น่าเชื่อถือในช่วงต้นยุค 90 Visual Sourcesafe (VSS) เป็นเรื่องเกี่ยวกับ Windows ที่ดีที่สุดที่มีอยู่ทั่ว แต่มันอาจแปลกและโปรแกรมเมอร์หลายคนเกลียดมัน บางทีมก็ไม่สนุกกับการใช้งานหลังจากจัดการกับสถานการณ์นี้

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

ในหลายกรณีในช่วงปลายยุค 90 ต้นปี 00 ถ้าทีม Windows ไม่ได้ใช้ VSS พวกเขาไม่ได้ใช้สิ่งใดสำหรับการควบคุมแหล่งที่มานอกเหนือจากการประชุมภายในองค์กร หลายคนยังไม่ได้ใช้ VCS แม้จะมีความซับซ้อนของ Team Foundation Server (TFS) และตัวเลือกฟรีที่ยอดเยี่ยมเช่น git และ SVN

เป็นไปได้ว่าบางคนที่ทำงานเป็นเวลาหลายปีในทีมพัฒนา Windows ขนาดเล็กเป็นเวลาหลายปีไม่ได้ใช้ VCS ฉันเคยสัมภาษณ์และทำงานรับจ้างในบางแห่งที่ไม่ได้ใช้งาน

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

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

ต้องการทำสิ่งต่าง ๆ ด้วยตนเองการสร้างวงล้อใหม่และทนทานต่อการเปลี่ยนแปลงนั้นไม่มีอะไรใหม่สำหรับการเขียนโปรแกรม คุณกำลังจะพูดจาหยาบคายกับผู้สมัครที่ใช้ Visual Source Safe และ VSS "only" หรือไม่?

เมื่อพยายามหาคนที่มีความสามารถคุณจะต้องสามารถบอกความแตกต่างระหว่าง: ไม่ได้ไม่ได้และจะไม่

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

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

• SCCS เปิดตัวในปี 1972 ( 40 ปีที่แล้ว )
• RCS เปิดตัวในปี 1982 ( 30 ปีที่ผ่านมา ) และเป็นโอเพ่นซอร์สอย่างสมบูรณ์และฟรี
• CVS เปิดตัวในปี 1990 ( 21 ปีที่แล้ว ) ซึ่งเป็นโอเพนซอร์สและสมบูรณ์ฟรี

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

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

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

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

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

คุณทิ้งข้อมูลไว้มากมายเกี่ยวกับประสบการณ์ของเขา

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

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

โชคดี.

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

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

ฉันเห็นคำตอบที่ค่อนข้างจะตัดสินที่นี่ซึ่งไม่ได้คำนึงถึงคนที่ถูกตัดสิน

ฉันพบว่าซอฟต์แวร์ควบคุมเวอร์ชันเป็นเครื่องมือที่ทรงคุณค่า แต่เราไม่มีทางเลือกและควบคุมเกี่ยวกับเครื่องมือและกระบวนการที่ใช้ในสภาพแวดล้อมการทำงานของเรา ฉันได้ทำงานในการพัฒนา Windows มาตั้งแต่ปี 1990 ตามที่โพสต์โดยคนอื่นในเวลานั้น VCS ใน Windows ยังไม่พร้อมใช้งานมากนัก เราจะไม่นำเซิร์ฟเวอร์ UNIX มาเพื่อรับ VCS นั่นทำให้ฉันเป็นโปรแกรมเมอร์ที่ไม่ดีเหรอ? ต่อมาในอาชีพการงานของฉันฉันทำงานให้กับ บริษัท ที่มีผลิตภัณฑ์เชิงพาณิชย์ในตลาดแนวดิ่งซึ่งการควบคุมเวอร์ชันไม่ใช่กระบวนการ นั่นทำให้ฉันเป็นโปรแกรมเมอร์ที่ไม่ดีเหรอ? งานสามครั้งสุดท้ายของฉันนั้นพึ่งพาเครื่องมือ VCS อย่างมาก นั่นทำให้ฉันเป็นโปรแกรมเมอร์ที่ดีหรือไม่?

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

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

ฉันไม่เคยคิดว่าตัวเองเป็น "โปรแกรมเมอร์" จนกว่าฉันจะเริ่มทำเงินได้อย่างมืออาชีพ

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

ฉันสามารถ GSD (ทำให้บางสิ่งเสร็จสิ้น) ได้อย่างรวดเร็วซึ่งสำหรับการพัฒนาเว็บไซต์มักจะทำให้ลูกค้าของฉันพอใจ พวกเขาอาจไม่เห็นโค้ดที่น่าเกลียดอยู่เบื้องหลังการขาดความคิดเห็น ฯลฯ

ฉันไม่ได้ใช้ Git และไม่มีโปรไฟล์ Github มาจนถึงปีนี้ซึ่งฉันรู้สึกว่า "ล้าสมัย" ในแง่ของมาตรฐานโปรแกรมเมอร์ที่ทันสมัย ฉันเพิ่งเริ่มทำโครงการ Rails และ Django หลังจากทำ PHP, Flash และ iOS ในอดีตเท่านั้น ฉันได้รับสัญญาจากเจ้าของที่ดินที่พัฒนาเว็บไซต์ทั้งสำหรับลูกค้าและสำหรับฉันมันไม่เจ็บปวดเกินกว่าที่จะเรียนรู้สิ่งใหม่ ๆ ในวัย 30 ปีและอีกไม่กี่ปีจากการเขียนโปรแกรม

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

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

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

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

เขามีประสบการณ์อะไรบ้าง ฉันจะสงสัยในสิ่งที่เขาไม่ทราบว่าคุณยังไม่พบ

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

ถ้าเขาออกมาแข็งแรงอยู่กับชนิดของสิ่งที่แล้วบางทีผมอาจจะมองข้ามการขาดความรู้การควบคุมแหล่งที่มา

เป็นไปได้ไหมที่โปรแกรมเมอร์ที่ดีจะไม่เคยใช้การควบคุมเวอร์ชัน?

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

เป็นไปได้อย่างไรที่จะพัฒนาซอฟต์แวร์อย่างต่อเนื่องเป็นเวลา 10-15 ปีโดยไม่จำเป็นต้องมีการควบคุมเวอร์ชัน?

ฉันได้แนะนำการควบคุมเวอร์ชันเป็น บริษัท เล็ก ๆ 2 ตัวได้อัพเกรด บริษัท ขนาดกลาง 1 แห่งจากสิ่งที่น่ากลัวเป็น SVN (ตัวเลือกที่ดีที่สุดในเวลานั้น) และทำงานใน บริษัท เล็ก ๆ อีกแห่งที่มี VC เพียงตัวเดียวเขียนโซลูชัน VC ของตนเองสำหรับรหัสบางตัว มีรหัสจำนวนมากไม่ได้อยู่ใน VC ใด ๆ

ความจริงแล้วตัวเองไม่ได้มองหาวิธีแก้ไขปัญหาในการติดตามการเปลี่ยนแปลงสัญญาณของทัศนคติที่ไม่ถูกต้องในการเขียนโปรแกรมหรือไม่?

มันไม่ได้ล้มเหลวทันที แต่ฉันจะถามคำถามติดตามมาก สิ่งที่ชอบ:

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

ฉันต้องการเห็นด้วยกับ Explosion Pills (แต่ตัวแทนของฉันต่ำเกินไป, atm ... ) ... ทัศนคติมีความสำคัญมากกว่า

มีบางสิ่งที่ต้องมองหาซึ่งฉันเชื่อว่าเป็นประโยชน์ต่อความเป็นเลิศในการเขียนโปรแกรม:

1. การสื่อสาร
2. ความคิดสร้างสรรค์
3. ความเมตตา (พูดอะไร)

และบ่อยครั้งมากกว่า OCD เล็กน้อย

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

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

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

เป็นไปได้อย่างไรที่จะพัฒนาซอฟต์แวร์อย่างต่อเนื่องเป็นเวลา 10-15 ปีโดยไม่จำเป็นต้องมีการควบคุมเวอร์ชัน?

ถ้าเขามาจากทีมโรงเรียนเก่าที่จัดการโครงการเล็ก ๆ โดยคนเดียวก็เป็นไปได้มาก เขาอาจมีประสบการณ์ 10 ปีในเทคโนโลยีเดียวกันโดยไม่ต้องเรียนรู้และพัฒนาตนเอง

ความจริงแล้วตัวเองไม่ได้มองหาวิธีแก้ไขปัญหาในการติดตามการเปลี่ยนแปลงสัญญาณของทัศนคติที่ไม่ถูกต้องในการเขียนโปรแกรมหรือไม่?

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

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

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

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

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

อย่างไรก็ตามเขาไปถึงที่นั่นถ้าเขาเป็นหมาป่าโดดเดี่ยวมานานกว่าทศวรรษหรือมากกว่านั้นมันอาจทำให้การใช้ชีวิตกับผู้คนยากที่จะทำ

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

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

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

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

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

สถานการณ์พิเศษต้องมีคำอธิบายพิเศษ

นี่เป็นเหมือนช่างซ่อมรถยนต์ที่อ้างว่าเขาซ่อมรถยนต์มา 15 ปีแล้ว แต่ไม่เคยมีคราบไขมันในตัวเขาเลย

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

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

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

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

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

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

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

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

2c ของฉันเองก็คือมันขึ้นอยู่กับว่าเขาตอบสนองต่อการถูกถามเกี่ยวกับ VC ปฏิกิริยาที่เป็นไปได้อาจเป็น:

1. ฮะ? นั่นอะไร
2. ไม่เราทำแทน
3. ไม่มีการสับเปลี่ยนที่ลำบากใจฝ่ายจัดการไม่อนุญาตให้เราทำ
4. ไม่มีการสับเปลี่ยนที่น่าอายแต่ฉันตรวจสอบตัวเองเล็กน้อยและคิดว่ามันดูเหมือนสิ่งที่เราควรจะทำ

ในกรณีที่ 4 คนที่แต่งตัวประหลาดจะได้รับผ่านจากฉันเขามีทัศนคติที่ถูกต้องและอาจจะรับมันได้ดี ในกรณีที่ 3 เขาได้รับเครดิตสำหรับการทำความเข้าใจว่ามันเป็นสิ่งที่ควรทำ แต่ไม่น่าเชื่อถือเท่าที่ 4 ถ้าเขาสามารถตั้งชื่อของข้อเท็จจริงสองสามข้อเกี่ยวกับ VC (รายการแพ็คเกจ VC บางรายการ) ฉัน ' ใช้เป็นหลักฐานของความอยากรู้อยากเห็นและอาจผ่านเขาไป

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

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

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

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

ทุกอย่างเกี่ยวกับสิ่งที่คุณกำลังเขียนโปรแกรม

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ทำงานใน บริษัท ที่ไม่ได้พัฒนาซอฟต์แวร์เป็นสายธุรกิจหลัก
2. หรือหากผู้พัฒนาตัดสินใจที่จะใช้ระบบอื่น - ใช้ได้สำหรับระบบที่มีประสบการณ์เท่านั้น
3. หรือหากนักพัฒนายังไม่ได้เรียนรู้วิธีการทำงานของแต่ละระบบ
4. หรือเป็นปัญหาทัศนคติต่อเครื่องมือที่พวกเขาไม่คุ้นเคย

แต่คุณควรระวังเมื่อพบคนที่คิดว่า:

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

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

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

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

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