ผู้พัฒนา C # สามารถผลิตโค้ดได้กี่บรรทัดต่อเดือน [ปิด]

ผู้บริหารในที่ทำงานของฉันถามคำถามกับกลุ่มนักพัฒนาของฉัน:

ผู้พัฒนา C # สามารถผลิตโค้ดได้กี่บรรทัดต่อเดือน

ระบบเก่าจะถูกส่งไปยัง C # และเขาต้องการให้มาตรการนี้เป็นส่วนหนึ่งของการวางแผนโครงการ

จากแหล่งที่มา (น่าเชื่อถือ) บางแห่งเขาได้คำตอบของ "10 SLOC / เดือน " แต่เขาไม่พอใจกับสิ่งนั้น

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

ตอบคำถามนี้ได้ไหม? (เฉพาะหน้าหรือแม้กระทั่งกับการวิเคราะห์บางส่วน)

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

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

ผู้พัฒนา C # สามารถผลิตโค้ดได้กี่บรรทัดต่อเดือน

หากพวกเขาดีน้อยกว่าศูนย์

วิ่งไปทางอื่น ... ตอนนี้

LoC เป็นหนึ่งในตัวชี้วัดที่แย่ที่สุดที่คุณสามารถใช้ได้

นักพัฒนาที่ไม่ดีสามารถเขียน LoC ได้มากกว่านักพัฒนาที่ดี แต่ปั่นป่วนรหัสขยะ

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

ส่งให้เขาอ่านหน้าวิกิพีเดีย SLOC ถ้าให้ตัวอย่างที่ดีและเรียบง่ายว่าทำไมมันถึงแย่มาก

คำตอบที่ถูกต้อง: ไม่ ...

ผู้บริหารนี้ควรได้รับการศึกษาว่า SLOC ไม่ใช่ตัวชี้วัดที่ถูกต้องสำหรับความคืบหน้าการวิเคราะห์

The Sloppy Answer: จำนวนใด ๆ ที่คุณสามารถสร้างขึ้นจาก

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

ไม่ดี แต่ทำได้

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

ฉันมีเพียงสิ่งเดียวที่จะพูดว่า:

“ การวัดความคืบหน้าการเขียนโปรแกรมด้วยบรรทัดของรหัสเป็นเหมือนการวัดความก้าวหน้าของการสร้างเครื่องบินด้วยน้ำหนัก”

-- บิลเกตส์

หลังจากนั้นคุณอาจโต้แย้งว่า Bill Gates ไม่ทราบวิธีการสร้างซอฟต์แวร์ที่ประสบความสำเร็จ)

หมายเหตุ: SLOC เป็นการวัดความซับซ้อนของรหัสฐานที่ดีมาก!

I 
can
write
large
numbers
of
lines
of
code
per
month.

ตามสัดส่วนของจำนวนคำที่จริงแล้ว

คุณเห็นจุดของฉัน

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

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

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

บางคนที่ไม่ถือว่าโง่จริงใช้ตัวชี้วัดที่อยู่บนบรรทัดของรหัส Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan และ Steve McConnell ต่างก็ใช้มัน คุณอาจใช้มันแม้ว่าจะพูดกับเพื่อนร่วมงานโมดูลของพระเจ้านี้คือ 4000 บรรทัด แต่ก็ต้องแบ่งออกเป็นคลาสย่อย ๆ

มีข้อมูลเฉพาะที่เกี่ยวข้องกับคำถามนี้จากแหล่งข้อมูลที่เราหลายคนเคารพ

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

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

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

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

ให้ตัวชี้วัดที่ดีกว่าแก่เขาเพื่อทำงานกับ

แทน LOCอธิบายนี้เป็นที่เลวร้ายที่สุดกับการใช้ตัวชี้วัด จากนั้นให้ทางเลือกแก่เขา:

จำนวนฟังก์ชั่น / คุณสมบัติต่อร้องขอคุณสมบัติ / ฟังก์ชั่น -> NOFF / RFF

คุณอาจจำเป็นต้องเพิ่มน้ำหนัก / การทำให้เป็นมาตรฐานเหนือ NOFF / RFF เพื่อรองรับจำนวนคำขอต่อสัปดาห์

:) เห็นได้ชัดว่าถูกสร้างขึ้น แต่ไม่มีอะไรดีไปกว่า SLOC ...

ฉันสามารถบอกคุณได้ว่าจำนวนผู้รับเหมาสำหรับโครงการขนาดใหญ่เขียน 15,000 LOC (ต่อคน) ในหนึ่งปี นั่นเป็นคำตอบคร่าวๆอย่างไม่น่าเชื่อ แต่มันมีประโยชน์สำหรับเราเนื่องจากเรามี 400,000 C ++ LoC ที่มีอยู่และเราสามารถหาได้ว่าการแปลงทั้งหมดเป็น C # จะทำให้เราใช้เวลาประมาณ 26 ปี ให้หรือรับ.

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

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

ฟังดูถูกต้องแล้ว

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

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

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

ฉันเดาว่านักพัฒนาที่ทำงานด้วยภาษาอย่าง C # ควรสามารถเขียน / สร้าง LoC ได้ประมาณ 10K ต่อวัน ฉันคิดว่าฉันสามารถทำได้ ฉันไม่เคยจะ

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

เรียกได้ว่าการเขียนโค้ดเปรียบเสมือนบทกวี คำถามไม่ได้กี่บทกวีสามารถเขียน แต่เท่าไหร่เขาสามารถถ่ายทอดใน 14 บรรทัดของโคลง

ให้ผู้จัดการของคุณจัดการหรือเริ่มหางาน

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

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

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

มันคือโค้ด C # ประมาณ 3000 บรรทัดโดยไม่มี XML-doc ฉันใช้งานฟังก์ชั่นใหม่และจบลงด้วยจำนวนเงินนี้ในหนึ่งเดือนหรือหนึ่งเดือนและหนึ่งสัปดาห์ ทุกอย่างจบลงด้วยการควบคุมซอร์สโค้ดจำนวนมากถูกเขียนขึ้นจากนั้นปรับโครงสร้างใหม่หรือลบออก

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

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

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

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

แนวทางที่เหมาะสมกว่านี้คือ: -

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

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