วิธีอธิบายขนาดตัวอย่างไม่ส่งผลกระทบต่อความยาวของโครงการ

เรามีโครงการองค์กรขนาดใหญ่โดยปกติแล้วพวกเขาเกี่ยวข้องกับการคัดลอกข้อมูลจากฐานข้อมูลต้นทางไปยังฐานข้อมูลปลายทางแล้วตั้งค่าแอปพลิเคชันเพิ่มเติมจำนวนมากที่ซิงค์ข้อมูลนี้เป็นต้น

โครงการสุดท้ายมี 250,000 รายการ (แถวของข้อมูล) โครงการถัดไปจะมีเพียง 4,000 รายการ ผู้จัดการโครงการ / นักธุรกิจเชื่อว่าโครงการควรจะเสร็จสมบูรณ์ในเวลา 1/10 เนื่องจากมีเพียงส่วนน้อยของขนาดโครงการสุดท้าย

อะไรคือการเปรียบเทียบที่ดีฉันสามารถใช้เพื่ออธิบายว่าการเขียนโค้ดเพื่อถ่ายโอนข้อมูลจากระบบหนึ่งไปยังอีกระบบหนึ่งใช้จำนวนเท่ากันโดยไม่คำนึงถึงรายการหมายเลข - การเขียนสำหรับ 1 รายการหรือ 100,000,000 จะใช้เวลาประมาณเดียวกัน มุมมอง.

บอกพวกเขาว่ามันเหมือนกับการสร้างทางหลวงสี่เลนใหม่ไปยังส่วนที่ห่างไกลของประเทศ ไม่ว่าถนนสายนั้นจะใช้ 100 คันต่อวันหรือ 1,000 คันต่อวันความพยายามในการสร้างถนนจะเป็นแบบเดียวกัน

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

ให้เครื่องคิดเลขและขอให้พวกเขาเพิ่ม 1238783423 ถึง 9858238483 ซึ่งใช้เวลานานแค่ไหน จากนั้นขอให้พวกเขาเพิ่ม 3423 ถึง 8483 และบอกพวกเขาว่าคุณคาดหวังคำตอบได้เร็วขึ้นประมาณ 100,000 ครั้ง

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

พูดให้เป็นผู้จัดการ

หากคุณสร้างเครื่องเพื่อสร้างวิดเจ็ตที่ 1 วิดเจ็ตต่อวินาทีมันไม่สำคัญว่าคุณจะใช้เพื่อสร้าง 100 วิดเจ็ตหรือ 10,000 วิดเจ็ตตัวเครื่องเองใช้เวลาในการสร้าง

ความแตกต่างคือ ณ รันไทม์ไม่ใช่การสร้างเวลา

คลาสการจัดการทั้งหมดทำงานกับปัญหาเช่นนี้กับโรงงานวิดเจ็ตสมมุติ

อย่าใช้การเปรียบเทียบ เพียงแค่อธิบาย

• สำหรับรายการจำนวนน้อยมาก (10 รายการ) การแปลงด้วยตนเองนั้นถูกที่สุด อย่าเขียนโปรแกรมเลย
• สำหรับรายการเล็ก ๆ น้อย ๆ (100?) มันจะคุ้มค่าที่จะเขียนโปรแกรม คุณอาจประหยัดได้โดยเพิกเฉยวิธีเรียงสับเปลี่ยนของข้อมูลที่เป็นไปได้ในทางทฤษฎี แต่ไม่ปรากฏในทางปฏิบัติในชุดข้อมูลขนาดเล็ก หรือปรากฏเป็นตัวเลขขนาดเล็กที่โปรแกรมสามารถปฏิเสธได้และสามารถแปลงได้ด้วยตนเอง มีความเป็นไปได้ที่จะเรียกใช้การวิเคราะห์ข้อมูลอย่างรวดเร็วเพื่อตรวจสอบว่ามุมตัวพิมพ์เล็กหรือใหญ่ปรากฏในข้อมูล หากพวกเขาไม่ปรากฏพวกเขาสามารถถูกละเว้น
• เมื่อคุณผ่านจุดนี้ขนาดที่แท้จริงของข้อมูลจะไม่มีผลกระทบ คุณต้องเขียนโปรแกรมที่ร้ายแรงที่สามารถจัดการกับอินพุตที่เป็นไปได้ โปรแกรมสามารถจัดการ 1,000 รายการหรือ 100,000 ใช้เวลาในการรันนานกว่า

การศึกษาดีกว่าคุยกัน :)

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

โครงการก่อนหน้าของคุณรวมอยู่ (จากสิ่งที่ฉันได้รับ) คัดลอกข้อมูลพร้อมการดัดแปลงบางอย่าง

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

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

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

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

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

มันเป็นวิธีที่แย่มากในการจัดการทีมโปรแกรมเมอร์ (จริงๆแล้วทีมงานประเภทใดก็ได้) และมันก็ไม่ได้ช่วยใครเลย

ฉันรู้ว่าคุณขอการเปรียบเทียบ แต่ฉันคิดว่านั่นเป็นเทคนิคที่ผิด

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

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

อาจจะเป็นโทรศัพท์? ลูกค้าของคุณต้องการโทรศัพท์ทำเอง หากเขาโทรออก 0 ครั้งต่อวันหรือ 100 ครั้งต่อวันมันจะใช้เวลาในการสร้างโทรศัพท์เท่ากัน

ข้อมูลที่โทรศัพท์ส่งนั้นคล้ายคลึงกับข้อมูลที่โปรแกรมของคุณคัดลอก

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

ตามที่ฉันต้องการอธิบายว่าข้อมูลมีความยาวและความกว้าง 2 มิติ ความยาวคือจำนวนของบันทึกความกว้างคือจำนวนคอลัมน์ทั้งหมดในตารางทั้งหมด

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

ขณะนี้มี 10 ล้านและ 10,000 ขนาดที่เล็กที่สุดยังคงเป็นความกว้าง ดังนั้นมันคือความกว้างที่กำหนดระยะเวลาในการสร้างหลุม

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

ฉันนำเข้าไฟล์ไคลเอนต์หลายร้อยไฟล์ทุกสัปดาห์

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

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

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

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

ผู้จัดการหลายคนคุ้นเคยกับค่าใช้จ่ายที่เกี่ยวข้องในการฝึกอบรมพนักงานใหม่ดังนั้นสิ่งนี้อาจเหมาะสมสำหรับพวกเขา

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