อะไรทำให้โครงการใหญ่ [ปิด]

31

แค่อยากรู้อยากเห็นอะไรคือความแตกต่างระหว่างโครงการขนาดเล็กกลางและใหญ่ มันวัดจากบรรทัดของรหัสหรือความซับซ้อนหรืออะไร

ฉันกำลังสร้างระบบแลกเปลี่ยนสินค้าและมีรหัสประมาณ 1,000 บรรทัดสำหรับการเข้าสู่ระบบ / การลงทะเบียน แม้ว่าจะมี LOC จำนวนมากฉันก็ไม่คิดว่ามันจะเป็นโครงการใหญ่เพราะมันไม่ซับซ้อน แต่นี่เป็นโครงการแรกของฉันดังนั้นฉันไม่แน่ใจ มันวัดได้อย่างไร?

project

— โจนาธาน
แหล่งที่มา

2

ใช่ ............ ความซับซ้อนที่มากขึ้นหมายถึงบรรทัดของโค้ดที่มากขึ้น

— Robert Harvey

3

KLOC แรกนั้นยากที่สุด ...

ถัดไปคุณต้องถามว่า "อะไรทำให้โครงการซับซ้อนได้เส้นของโค้ด?

— Steven Evers

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

— TMarshall

ฉันจะบอกว่า "bigness" ของโครงการขึ้นอยู่กับมากกว่า 1 ปัจจัย ...

— kiwixz

20

ความซับซ้อน

ยิ่งซับซ้อนยิ่งยากที่จะเรียนรู้ทุกสิ่งในโครงงาน

5

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

— Henrik

... หรือโดยธรรมชาติการวัดความซับซ้อนอื่น ๆ

— Henrik

@Henrik "ระบบที่ซับซ้อน" ไม่เท่ากับ "ระบบขนาดใหญ่"

1

ไม่มันเป็นคำพ้องความหมาย

— Henrik

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

33

คร่าวๆว่าฉันจะทำสิ่งต่าง ๆ อย่างไร - โปรดจำไว้ว่านี่เป็นเรื่องที่มากหรือน้อยก็ได้ "ขนาด" ของโครงการประกอบด้วยองค์ประกอบอื่น ๆ เช่นความซับซ้อน, ซอร์สโค้ด, จำนวนคุณสมบัติ / มูลค่าทางธุรกิจเป็นต้นผลิตภัณฑ์ขนาดเล็กมากสามารถส่งมอบมูลค่าจำนวนมากและอื่น ๆ ที่กล่าวไว้:

2m + slocเป็นโครงการขนาดใหญ่ถึงใหญ่ โดยทั่วไปแล้วสิ่งเหล่านี้มีความซับซ้อนน้อยมากหากมีคน 'คล่องแคล่ว' ในระบบทั้งหมด ความรับผิดชอบค่อนข้างมีแนวโน้มที่จะถูกทำให้เป็นโมดูลตามโครงสร้างของรหัส โครงการเหล่านี้มักจะให้คุณค่าทางธุรกิจมหาศาลและอาจเป็นภารกิจสำคัญ บางครั้งพวกเขาก็ตกอยู่ภายใต้ความกดดันของหนี้ทางเทคนิคและความกังวลเรื่องมรดกอื่น ๆ
100k - 2m slocเป็นโครงการขนาดกลาง นี่คือพื้นฐานของฉัน: โครงการมีความซับซ้อนเพียงพอที่จะต้องมีความรู้จากผู้เชี่ยวชาญและมีแนวโน้มที่จะเกิดหนี้ทางเทคนิคในระดับหนึ่ง เป็นไปได้ว่าจะส่งมอบมูลค่าทางธุรกิจในระดับหนึ่ง
10k - 100kเป็นโครงการขนาดเล็ก แต่ไม่เล็กเกินไปที่จะมีความซับซ้อนเพียงพอที่คุณจะต้องการการพิจารณาจากผู้เชี่ยวชาญ หากคุณเป็นโอเพนซอร์ซลองพิจารณาให้คนที่คุณไว้ใจตรวจสอบคำมั่นสัญญาของคุณ
อะไรก็ตามที่น้อยกว่า 10k sloc นั้นเล็กมากจริง ๆ นั่นไม่ได้หมายความว่ามันไม่สามารถให้คุณค่าใด ๆ เลยและโครงการที่น่าสนใจหลายแห่งก็มีสำนักพิมพ์ขนาดเล็กมาก (เช่นค่ายพักแรมซึ่งมีแหล่งกำเนิดอยู่ที่ ~ 2 kb (!)) โดยทั่วไปผู้ที่ไม่ใช่ผู้เชี่ยวชาญสามารถผลักดันความกังวลเกี่ยวกับคุณค่าแก้ไขข้อบกพร่องและเพิ่มคุณสมบัติได้โดยไม่จำเป็นต้องรู้เกี่ยวกับโดเมนมากเกินไป

— โจเซฟไวส์แมน
แหล่งที่มา

4

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

— Eric Anderson

1

@EricAnderson แน่นอนว่าจะคิดได้ง่ายกว่านี้ในแง่ของคำอธิบายมากกว่าการวัด sloc 100k SLOC โปรแกรม Erlang เป็นได้อย่างง่ายดายลำดับความสำคัญ "ขนาดใหญ่" กว่าโปรแกรม 100k SLOC C ++ ขึ้นอยู่เพียงแค่ในสิ่งที่ไม่คำนึงถึงวิธีการที่ง่ายรหัสคือการอ่านในระดับที่สูงขึ้น ในบางจุดการอ่านโค้ดนั้นไม่ได้ยากอย่างที่ควรจำไว้ว่าสิ่งที่เกิดขึ้นภายในระบบในระดับสูงเพราะมีคุณสมบัติและศูนย์ตรรกะมากมาย

— zxq9

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

— Yongwei Wu

14

ขนาดของโครงการวัดจากระดับความไม่แน่นอน

— mojuba
แหล่งที่มา

2

นั่นเป็นแง่ร้าย: D

— Henrik

.... และการวัดนั้นคืออะไร?

— Casey Patton

1

@Casey Patton การวัดนั้นคุ้มค่ากับการบำรุงรักษา

— mojuba

12

ความซับซ้อนซึ่งอาจประเมินได้ในไม่กี่วิธี:

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

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

— JB King
แหล่งที่มา

11

ขนาดของโครงการน่าจะวัดได้ดีที่สุดตามจำนวนข้อกำหนดที่ระบบมีซึ่งไม่สามารถลดความต้องการลงได้อีก

แน่นอนความต้องการมากขึ้นหมายถึงความซับซ้อนมากขึ้น แต่ก็ไม่ได้เป็นเช่นนั้นเสมอไป

— David_001
แหล่งที่มา

1

นั่นอาจไม่ใช่มาตรการที่ดี: ข้อกำหนดสำหรับคอมไพเลอร์และเมล็ด OS อาจมีขนาดใหญ่กว่าเมื่อเทียบกับผลิตภัณฑ์ประเภทอื่น

— mojuba

2

@mojuba: "บิ๊ก" เป็นคำที่กว้างมากฉันคิดว่าการเขียนคอมไพเลอร์หรือระบบปฏิบัติการจะเป็นโปรเจ็กต์ "ใหญ่"

— David_001

@ David_001: ใช้ Turbo Pascal compiler, f.ex. ซึ่งมีขนาดไบนารีที่หนึ่งจุดคือ 70 กิโลไบต์และ TP เป็นภาษาการเขียนโปรแกรมเชิงวัตถุเต็มรูปแบบ เราไม่เคยเห็นแหล่งที่มา แต่การปฏิบัติการขนาด 70kb ไม่สามารถเป็นโครงการขนาดใหญ่ได้

— mojuba

@ David_001: ไม่ใช่ว่าฉันไม่เห็นด้วยกับคุณโดยทั่วไป คำจำกัดความของโครงการ "ใหญ่" จะคลุมเครือเหมือนกับคำว่า "ใหญ่"

— mojuba

@mojuba: เมื่อฉันใช้ Turbo Pascal มันไม่ได้เป็นเชิงวัตถุเลย

— David Thornley

4

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

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

— dsimcha
แหล่งที่มา

3

คำตอบโดยพลการ: โครงการมีขนาดใหญ่เพียงใดที่คุณต้องการให้คุณทำด้วยการจัดหากิจกรรมและ SOA ตั้งแต่เริ่มต้น หรือว่าผู้เขียนระบบได้อ่านหนังสือของ Evan "DDD: Tackling Complexity in Heart of Software";)

— เฮนริก
แหล่งที่มา

2

ขอบเขตและความ Compexity

ความซับซ้อนและขอบเขตฉันเชื่อว่าสิ่งที่กำหนดว่าโครงการใหญ่จริง ๆ อย่างไรก็ตามมีหลาย intangibles ที่สามารถมีผลต่อขนาดของโครงการเช่นกัน

ความต้องการ

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

ขาด CCMU

CCMU คือสิ่งที่ฉันเรียกว่า " คูหมู่หมู่ " (Clear Complete Mutual เข้าใจ) คุณต้องมี CCMU กับลูกค้าของคุณ

หากคุณมีโครงการขนาดเล็กที่มี CCMU ไม่ดีคุณสามารถยุติการทำโครงการ 2,3,4 ครั้งหรือมากกว่า งานง่าย ๆ 20 ชั่วโมงกลายเป็นโครงการ 60 ชั่วโมงโดยมีพนักงานที่เครียดและลูกค้าไม่พอใจมาก

ขอบเขตคืบ

สิ่งนี้เกิดขึ้นบ่อยกว่าที่คุณคิด ลูกค้าตัดสินใจว่าเนื่องจากคุณกำลังทำ A, B & C อยู่แล้วไม่ควรเพิ่ม D หรือ F ที่ยากหากไม่ได้ตรวจสอบพฤติกรรมนี้มันสามารถเปลี่ยนโครงการขนาดเล็กให้เป็นโครงการขนาดกลางได้ และขึ้นอยู่กับว่าผู้จัดการฝ่ายขายขายงานขอบเขตเหล่านี้ความคาดหวังที่คืบคลานอาจดูเหมือน"ฟรี"ให้กับลูกค้า

— Michael Riley - AKA Gunny
แหล่งที่มา

1

มันแปลกที่อ่านคำตอบเหล่านี้มากมายฉันพบว่าฉันดูขนาดของโครงการแตกต่างกันมาก บางทีมันอาจเป็นงานของฉันใน บริษัท ขนาดใหญ่ แต่ฉันมักจะดูขนาดของโครงการเป็นมากกว่าระดับของการมองเห็น / ความปรารถนาของลูกค้า (ขึ้นอยู่กับพื้นที่การทำงานของคุณเหล่านี้อาจเป็นเพื่อนร่วมงานหรือลูกค้าที่จ่ายจริง)

— Kavet Kerek
แหล่งที่มา

1

ความซับซ้อนเป็นคำตอบที่ถูกต้อง แต่จะประเมินได้อย่างไร

ปัจจัยคือ:

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

ยิ่งคุณมีสิ่งเหล่านั้นมากเท่าไหร่ก็ยิ่งมีความซับซ้อนมากขึ้นเท่านั้น

— Klaim
แหล่งที่มา

0

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

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

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

— Jason Baker
แหล่งที่มา