จับคู่ตรรกะการเขียนโปรแกรมทางธุรกิจกับบุคคลที่ไม่ใช่ด้านไอที [ปิด]

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

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

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

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

• การปฏิบัตินี้เป็นเรื่องปกติหรือไม่
• มันมีชื่อหรือไม่?
• คุณเคยมีประสบการณ์คล้าย ๆ กันบ้างไหม?

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

นั่นคือคุณกำลังตรวจสอบความถูกต้องของกฎเกณฑ์ทางธุรกิจ (การคำนวณและกระบวนการที่ถูกต้อง) กับผู้ใช้ทางธุรกิจ

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

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

ใช่. ฉันทำงานที่ไหนฉันทำสิ่งที่ประเภท hardcore programming ขณะที่นักวางกลยุทธ์ใช้กลยุทธ์ uhm กล่าวคือฉันเขียนโปรแกรมที่ใช้โมเดลการซื้อขายของพวกเขา

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

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

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