Bogarting Data Access Layer

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

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

Martin Fowler และ Pramod Sadalage ได้เขียนบทความที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้

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

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

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

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

หากเขาจะเป็นผู้รักษาประตูเพียงคนเดียวเขาต้องมีสเป็คคงที่หรือสามารถ "ขาย" วิสัยทัศน์ของเขาให้กับผู้พัฒนาที่เหลือ

มีปัญหาสำคัญที่ทำให้เกิดปัญหาอื่น ๆ :

1. ทำไมผู้รับเหมาถึงมีรหัสตรวจสอบอยู่เสมอ ?

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

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

แทนที่จะชอบแนวนอนฉันชอบทำงานในไซโลข้ามชั้น

ด้วยวิธีนี้ไม่มี 1 คน / ทีมสามารถบล็อกในแบบนี้

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

แน่นอนว่ามีส่วนต่างๆ (การออกแบบ UI และการออกแบบฐานข้อมูล) ที่อาจต้องการงานพิเศษเพิ่มเติม แต่คุณจะได้รับแนวคิด

ง่ายถ้าคุณยังไม่ได้สร้างคุณควรมี 3 สภาพแวดล้อม:

• การพัฒนาสภาพแวดล้อม
• สภาพแวดล้อม QA
• สภาพแวดล้อมการผลิต

สภาพแวดล้อมที่พัฒนาขึ้นควรได้รับการดูแลโดยนักพัฒนาของคุณ

คุณอาจต้องการเพิ่มสภาพแวดล้อม RC

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

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

นี่คือปัญหาการจัดการมากพอ ๆ กับด้านเทคนิค

มีเหตุผลที่ถูกต้องอย่างแน่นอนสำหรับ DBA (ไม่ว่าสถานที่หรือนอกสถานที่, ผู้รับเหมาหรือพนักงาน) เพื่อป้องกันไม่ให้นักพัฒนาทำการเปลี่ยนแปลงฐานข้อมูลทุกประเภท

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