DBA จะเป็น 'โปรแกรมเมอร์ที่เป็นมิตร' มากขึ้นได้อย่างไร?

คำตอบและความคิดเห็นเกี่ยวกับรุ่น dba.seและprogrammers.se รุ่นของคำถาม"สิ่งที่ขัดแย้งกับหรือสำหรับการวางตรรกะของโปรแกรมประยุกต์ในชั้นฐานข้อมูลหรือไม่" มีการเปิดเผยเกี่ยวกับการแบ่งระหว่าง DBA และโปรแกรมเมอร์ในที่ทำงานบางแห่ง

DBA ทำอะไรได้บ้างเพื่อให้ทำงานได้ดีขึ้นกับโปรแกรมเมอร์ในประเด็นเช่นนี้

เราควร:

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

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

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

ฉันเป็น MySQL DBA มา 6.5 ปีแล้ว ฉันใช้เวลา 16 ปีในการเป็นนักพัฒนาซอฟต์แวร์และได้โต้ตอบกับ DBA จำนวนมาก หลายคนในทางปฏิบัติ บางคนน่ารังเกียจ บางคนไม่มีความคิดว่าการเป็น DBA หมายความว่าอย่างไร

ฉันมาถึงข้อสรุปนี้:

เทคนิคการพูด DBA ที่มีคุณสมบัติอย่างใดอย่างหนึ่งต่อไปนี้เป็นสิ่งที่ดีที่สุดในการทำงานกับ:

1. ใช้เวลาหลายปีในฐานะนักพัฒนาตัวเอง
2. มีความเข้าใจในทฤษฎีฐานข้อมูล
3. มีความเข้าใจที่ดีว่า RDBMS ทำงานอย่างไรภายใน
4. มีความรู้ที่ดีเกี่ยวกับระบบปฏิบัติการ

DBAs ที่มีระเบียบวินัยและมีความรู้มีจำนวนมากที่จะแบ่งปันและนำเสนอ พวกเขาอาจเห็นประสิทธิภาพของฐานข้อมูลจากมุมมองที่นักพัฒนาไม่ได้พิจารณาอย่างแท้จริง นักพัฒนารู้ว่าสิ่งที่พวกเขาต้องการจากฐานข้อมูล DBA รู้วิธีการ "สุภาพ" ต่อฐานข้อมูล

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

ไม่ว่าใครจะถูกมองว่าเป็นสามีและใครที่ถูกมองว่าเป็นภรรยาหลักการเหล่านี้ใช้:

1. เราต้องปรึกษาอีกฝ่าย
2. เราต้องให้ความสำคัญกับมุมมองของอีกฝ่าย
3. เราต้องตัดสินใจเพื่อประโยชน์ของทั้งสองฝ่าย
4. เราจะต้องสนับสนุนไม่ใช่การตัดสินใจของซาโบโทจี
5. หนึ่งจะต้องไม่ลดหย่อนอีกถ้าการตัดสินใจส่งผลให้เกิดผลกระทบที่ไม่ดี
6. เราต้องชื่นชมยินดีในการมีส่วนร่วมของทั้งสองฝ่ายต่อความสำเร็จของการตัดสินใจ
7. ต้องปรึกษาผู้มีอำนาจสูงกว่า (HA) หากการตัดสินใจไม่สามารถตกลงร่วมกันได้

หลักการเจ็ดข้อเหล่านี้มีผลบังคับใช้ในที่ทำงานโดยเฉพาะอย่างยิ่งในด้าน IT

โดยการสื่อสารทุกขั้นตอนทุกคนควร:

1. เค้าโครงความคาดหวังของพวกเขา
2. ทำให้เกิดความเคารพต่อความสามารถของอีกฝ่ายในการทำส่วนของพวกเขาตามผลงานที่ผ่านมา
3. มีความเชื่อมั่นและมั่นใจว่าอีกฝ่ายสามารถดำเนินการให้เสร็จ
4. ทำตามความคาดหวังของเราเอง
5. ยอมรับภายใต้การแนะนำของ HA (ดูหลักการ # 7)

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

ความคิดสุดท้าย

หลักการ # 7 ต้องการการมีส่วนร่วมและการควบคุมดูแลโดยหน่วยงานระดับสูง (HA) เช่นผู้จัดการโครงการหัวหน้าทีมผู้พัฒนานำ HA ของคุณรู้ดีว่าทั้งสองฝ่ายทำงานเป็นรายบุคคลอย่างไรและทั้งสองฝ่ายควรทำงานร่วมกันอย่างไร หาก HA ไม่ได้กำหนดกฎพื้นฐานสำหรับทั้งสองฝ่ายหรือหาก HA ไม่สามารถชี้แนะฝ่ายต่าง ๆ และร่วมกันโครงการจะหยุดชะงักในบางจุดและเป็นอันตรายต่อการดำรงอยู่ของนักพัฒนา DBA หรือแม้กระทั่ง HA

มีทีมนั่งในส่วน / ชั้นต่าง ๆ อย่างใดดูเหมือนว่าจะสนับสนุนความคิด "เราเทียบกับพวกเขา"

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

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

เรื่องแบบนี้แตกต่างกันไปในแต่ละสถานที่ ที่ไซต์ปัจจุบันของฉันเส้นแบ่งระหว่างนักพัฒนาและ DBA นั้นพร่ามัวอย่างแน่นอน - เรา (DBA) เขียน PL / SQL ด้วยและพวกเขา (นักพัฒนา) ตัดแผนคิวรีออก เราทุกคนมองว่าตัวเองเป็นแค่เพื่อนร่วมงานที่มีทักษะและความรับผิดชอบต่างกัน นี้เป็นที่น่าขบขันมาก: เมื่อเร็ว ๆ นี้ บริษัท ได้มีการเพิ่มขึ้นในกระดานDevOps bandwagon ชุมชนฐานข้อมูลไม่เข้าใจสิ่งนี้เลย เราได้เสมอทำงานเช่นเดียวกับที่ ไม่จำเป็นต้องพูดว่าเราทำงานได้อย่างมหาศาลเช่นนี้ฐานข้อมูลอยู่ไกลมากส่วนที่น่าเชื่อถือที่สุดของกองเทคโนโลยีของ บริษัท มันใช้งานง่าย (เนื่องจากเรามีทักษะในทีม DBA เพื่อทำความเข้าใจแอปพลิเคชันในระดับลึกและนักพัฒนามีการเปิดรับ DBA เพื่อทำความเข้าใจการดำเนินงาน 24/7/365 และวิธีการ เพื่อจัดโครงสร้างแอพของมัน)

แต่ฉันรู้ว่าคุณหมายถึงอะไรเมื่อคุณพูดถึงนักพัฒนาที่ "ผิด" เขาสอนตัวเองซึ่งในและของตัวเองเป็นสิ่งที่มีเกียรติ แต่ตลอดทางที่เขาหยิบความไม่ไว้วางใจจากคำแนะนำอย่างเป็นทางการใด ๆ เขาไม่รู้ว่าเขาไม่รู้อะไรและเขาไม่พอใจใครก็ตามที่พยายามสอนเขาเขาเห็นว่าเป็นการดูถูกทักษะการเรียนรู้ด้วยตนเองของเขา เขาได้เรียนรู้รูปแบบการเขียนโปรแกรมที่จำเป็นเพราะคุณสามารถเรียนรู้ได้โดยไม่ต้องมีทฤษฎีใด ๆ ที่ประเภท CS มักจะพูดพล่ามเกี่ยวกับ (ดีไม่ดีทุกคนต้องรู้ใหญ่ -Oและทฤษฎีที่คล้ายกัน) เขาได้เรียนรู้ OO เล็กน้อยเช่นกันเพียงเพราะเขาต้องใช้ Java แต่ผู้เชี่ยวชาญด้านฐานข้อมูลที่ดี - นักพัฒนาหรือ DBA - จะต้องมีความคิดที่สะดวกสบายในรูปแบบการประกาศความคิดเกี่ยวกับทฤษฎีเซตรูปแบบปกติแม้กระทั่งความสามารถในการเข้าใจพีชคณิตและแคลคูลัสเชิงสัมพันธ์ มันยากมากที่จะสื่อสารกับคนเหล่านี้เพราะพวกเขาเป็นศัตรูกับทุกสิ่งที่อาจทำให้พวกเขาหลุดพ้นจากเขตความสะดวกสบายของพวกเขาซึ่งเป็นเรื่องที่ จำกัด และมีขนาดใหญ่ในการจัดรูปแบบบางอย่างบนหน้าเว็บ หากพวกเขาคิดเกี่ยวกับฐานข้อมูลเลยพวกเขาคิดว่าตารางเป็นเหมือนคลาสและแถวนั้นเป็นเหมือนวัตถุ พวกเหล่านี้จะทำSELECT * FROM TABLEและกรองและเรียงลำดับผลลัพธ์ในรหัสของตัวเอง. พวกเขาจริงๆไม่เข้าใจว่าทำไมฐานข้อมูลดีกว่าไฟล์แฟล็ต (และพวกเขาไม่คิดอย่างลับๆว่าใครก็ตามที่ใช้ฐานข้อมูลเชิงสัมพันธ์เป็นคนงี่เง่า)

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

ค่าย MySQL เป็นแบบนี้มานาน พวกเขาจะบอกว่าคุณไม่ต้องการทำธุรกรรมกุญแจต่างประเทศ ฯลฯ ถ้าคุณคิดว่าคุณทำมันเป็นเพียงเพราะคุณไม่รู้ว่าคุณกำลังทำอะไร ฯลฯ (จากนั้นเมื่อพวกเขาโตขึ้น เหล่านี้คือประเภทของ ORM ของผู้คนเช่น ActiveRecord หรือ Hibernate ได้รับการพัฒนาเพื่อให้พวกเขาสามารถเขียนแอปพลิเคชันฐานข้อมูลโดยไม่จำเป็นต้องสัมผัสกับ SQL การใช้เทคโนโลยีเหล่านี้ฉันถือว่าเป็นธงสีแดง - นี่ไม่ใช่ บริษัท ที่ให้ความสำคัญกับทักษะ DBA สิ่งที่พวกเขาต้องการคือผู้เลี้ยง ...

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

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

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

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

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

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

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

ฐานข้อมูลยากต่อการปรับโครงสร้างอีกครั้งดังนั้น DBA จึงเกี่ยวข้องกับการทำให้ถูกต้องในครั้งแรก นักพัฒนาไม่เห็นปัญหาในการปรับสภาพถนน

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

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

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

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

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

ฉันจะแก้ไขได้ตามคำตอบอื่น ๆ (ฉันเห็นด้วย 100% กับ 2 จนถึงปัจจุบัน) แต่เพิ่มว่าการจัดการและวัฒนธรรมร้านค้าจะต้องสนับสนุนและบ่มเพาะความร่วมมือเช่นกัน

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

... ชุดรูปแบบทั่วไปใช่ไหม ... การสื่อสาร ... การสื่อสาร ... การสื่อสาร

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

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

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

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

ใครจะโทษที่นี่? นางสาวการสื่อสาร

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

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

ฉันโชคดีในสถานที่ส่วนใหญ่ที่ฉันเคยทำงานการเคารพซึ่งกันและกันและการสื่อสารเป็นส่วนหนึ่งของวัฒนธรรม

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

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

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

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

ความอ่อนน้อมถ่อมตนเล็กน้อยอาจช่วยคุณบางคน ;)

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