ภาษาไดนามิกมีผลเสียต่อการพัฒนาที่คล่องตัวหรือไม่?

12

จากสิ่งที่ฉันได้อ่านการพัฒนาที่คล่องตัวมักจะเกี่ยวข้องกับการเปลี่ยนโครงสร้างหรือเปลี่ยนรหัสวิศวกรรมเป็นไดอะแกรม แน่นอนมีมากกว่านั้น แต่ถ้าเราพิจารณาการปฏิบัติที่อาศัยสองวิธีนี้เป็นภาษาที่พิมพ์แบบไดนามิกที่เสียเปรียบ?

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

การรีแฟคเตอร์หรือวิศวกรรมย้อนกลับเป็นเรื่องยากหากไม่สามารถทำได้ในภาษาที่พิมพ์แบบไดนามิกหรือไม่? โครงการโลกแห่งความจริงบอกอะไรเกี่ยวกับการใช้ภาษาที่พิมพ์แบบไดนามิกสำหรับวิธีการแบบเปรียว

agile dynamic-typing static-typing

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

5

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

— CaffGeek

7

Agile ไม่ได้แปลว่า "code first, document later"

— Gort the Robot

@CaffGeek: หนังสือที่แนะนำมักจะแนะนำให้วาดไดอะแกรมบนไวท์บอร์ดจากนั้นให้โค้ดและในที่สุดก็ย้อนรหัสวิศวกรลงในไดอะแกรมสำหรับการประชุมครั้งต่อไป

— Gerenuk

1

ฉันคิดว่าควรพิมพ์ตัวอักษรที่รุนแรงออกจากแท็กและข้อความของคำถามนี้ คำถามดูเหมือนว่าจะเกี่ยวกับคงที่และแบบไดนามิกไม่แข็งแรงเทียบกับที่อ่อนแอ

— Winston Ewert

@WinstonEwert - โทรดีฉันเปลี่ยนแท็กเป็นdynamic-typingและstatic-typing

— Carson63000

11

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

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

ในทางตรงกันข้ามมีภาษาที่พิมพ์แบบคงที่โดยมีข้อได้เปรียบเช่นเดียวกับภาษาไดนามิก (เช่นขนาดกะทัดรัดและเข้าใจได้ - มีประเภทส่วนใหญ่อนุมาน แต่มีมาก): Haskell อาจเป็นตัวอย่างชั้นนำ แต่ OCaML / F #, Scala, และอื่น ๆ ที่อยู่ในหมวดหมู่นี้ด้วย น่าเสียดายเนื่องจากมีการใช้งานน้อยกว่าภาษาที่พิมพ์แบบคงที่ที่ได้รับความนิยมมากที่สุดจึงไม่มีชุดเครื่องมือมากมายสำหรับพวกเขา (เช่นสำหรับการปรับโครงสร้างใหม่)

ดังนั้นในฐานะที่เป็นกำไรฉันคิดว่าคุณจะมีวิธีการที่คล่องตัวในภาษาส่วนใหญ่อย่างเพียงพอ ฉันจะไม่พูดว่ามีผู้ชนะที่ชัดเจนในขณะนี้เนื่องจากการฝึกฝนยังไม่ทันกับทฤษฎี

— เร็กซ์เคอร์
แหล่งที่มา

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

— Gerenuk

1

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

— Rex Kerr

14

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

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

— Winston Ewert
แหล่งที่มา

1

แล้ววิศวกรรมย้อนกลับล่ะ? Smalltalk ต่างจาก Python เกี่ยวกับการพิมพ์หรือไม่? ดูเหมือนว่าเป็นปัญหาที่ยากที่จะอนุมานทุกประเภทใน Python และกำหนดว่าวิธีใดที่เหมือนกันจริงๆและไม่ใช่แค่ชื่อเดียวกัน

— Gerenuk

2

สมอลล์ทอล์คไม่ว่ามากแตกต่างจากงูใหญ่เกี่ยวกับการพิมพ์ มันเป็นอย่างไรอย่างมีนัยสำคัญที่แตกต่างกันเกี่ยวกับการขับรถ เครื่องมือและ IDEs ที่มีอยู่สำหรับสมอลล์ทอล์คมีวิธีที่ดีกว่าที่มีอยู่สำหรับงูใหญ่หรือแม้กระทั่ง C #, C ++ และ Java เหตุผลที่ IDEs สำหรับ Python ไม่ดีนั้นไม่ได้เป็นเพราะ Python นั้นถูกพิมพ์แบบไดนามิกมันก็เป็นเพราะดีว่า IDEs สำหรับ Python นั้นไม่ดี อย่าลืมว่า IDE ที่เรารู้จักในชื่อ Eclipse นั้นเคยถูกเรียกว่า VisualAge สำหรับ Smalltalk หนึ่งครั้ง ชุมชน Smalltalk มีประสบการณ์ 40 ปีในการสร้าง IDE และพวกเขาใช้มันกับ Java

— Jörg W Mittag

@ Gerenuk การพิมพ์ของ Smalltalk ไม่แตกต่างจากงูใหญ่ ในวิธีอื่นเช่นการวิปัสสนาสมอลทอล์คได้จัดเตรียมคุณลักษณะที่เป็นมิตรกับการปรับโครงสร้างอีกครั้ง การอนุมานประเภทในหลามจะต้องใช้งาน แต่ได้ทำไปแล้วดูโครงการ PyPy

— Winston Ewert

1

@WinstonEwert "แต่คุณสามารถ refactor ด้วยตนเองและภาษาแบบไดนามิกทำให้มันค่อนข้างง่าย" - ไม่การปรับโครงสร้างด้วยตนเองไม่ได้ปรับขนาด การสนับสนุนเครื่องมือสำหรับการเปลี่ยนการเปลี่ยนแปลงใหม่ทุกอย่างแม้ในขณะที่การเปลี่ยนสถานะไม่ได้เป็นแบบอัตโนมัติ 100% (ดูตัวอย่างกรณีศึกษาด้านล่าง - programmers.stackexchange.com/a/166594/4334 )

— igouy

1

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

— Rex Kerr

8

การรีแฟคเตอร์ถูกคิดค้นในภาษาแบบไดนามิก เครื่องมือ Refactoring อัตโนมัติถูกคิดค้นในภาษาแบบไดนามิก IDE ถูกประดิษฐ์ในภาษาแบบไดนามิก ระเบียบวิธี Agile จำนวนมากถูกคิดค้นในภาษาแบบไดนามิก

ฉันไม่เห็นปัญหาใด ๆ

— Jörg W Mittag
แหล่งที่มา

"Smalltalk นั้นไม่ได้มีความแตกต่างจากงูใหญ่มากนักเกี่ยวกับการพิมพ์อย่างไรก็ตามมันแตกต่างอย่างมากจากการใช้เครื่องมือ" - บางทีนั่นอาจจะเริ่มเปลี่ยนไปดูjetbrains.com/pycharm/features/index.html

— igouy

3

เพื่อไม่ให้ลืมวิธีการทำงานแบบ "เปรียว" ซึ่งต่อมาได้กลายเป็นที่รู้จักในชื่อExtreme Programming (XP) นั้นถูกสร้างขึ้นในโครงการ Smalltalk (และ Smalltalk นับเป็นภาษา "ไดนามิก")

ต่อไปนี้เป็นกรณีศึกษาการใช้เครื่องมือการปรับโครงสร้างให้ใหม่ที่มาพร้อมกับภาษาที่พิมพ์แบบไดนามิก:

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

การวิเคราะห์พบว่าแม้ว่าการค้นหาแบบไดนามิกจะใช้เวลาดำเนินการไคลเอนต์ 40% แต่ก็ไม่จำเป็น

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

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

พบน้อยกว่า 35 ข้อบกพร่องในการเปลี่ยนแปลง 17,100 ข้อบกพร่องทั้งหมดได้รับการแก้ไขอย่างรวดเร็วในระยะเวลาสามสัปดาห์

หากการเปลี่ยนแปลงทำด้วยตนเองเราคาดว่าจะใช้เวลา 8,500 ชั่วโมงเทียบกับ 235 ชั่วโมงเพื่อพัฒนากฎการเปลี่ยนแปลง

งานเสร็จสมบูรณ์ใน 3% ของเวลาที่คาดหวังโดยใช้กฎการเขียนซ้ำ นี่คือการปรับปรุงโดย 36 ปัจจัย

จาก“ การแปลงชั้นข้อมูลแอปพลิเคชัน” Will Loew-Blosser OOPSLA 2002

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

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

1

หลักการของคุณคิดว่าฟังดูถูกต้องแล้ว

ภาษาที่พิมพ์อย่างรุนแรงเช่น C # เป็นตัวเลือกที่ดีสำหรับฐานรหัสที่ต้องการการแฟคตอริ่งใหม่อย่างต่อเนื่อง เครื่องมือการแฟคตอริ่งส่วนใหญ่โดยทั่วไป (เช่น Resharper, JustCode และอื่น ๆ ) ในตลาดมีประสิทธิภาพมากในภาษาการเขียนโปรแกรมแบบคงที่

โครงการโลกแห่งความจริงบอกอะไรเกี่ยวกับการใช้ภาษาที่พิมพ์แบบไดนามิกสำหรับวิธีการแบบเปรียว

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

ดังนั้นวิธีการแบบเปรียวจึงไม่ให้ประโยชน์กับภาษาที่พิมพ์แบบคงที่หรือแบบไดนามิกครั้งเดียว สิ่งที่ให้คือวิธีการวนซ้ำเพื่อสร้างแอปพลิเคชันที่มั่นคง

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

4

ภาษาแบบไดนามิกมีเครื่องมือการเปลี่ยนโครงสร้างอัตโนมัติแบบอัตโนมัติมานานก่อนที่ C # จะปรากฏขึ้นและเมื่อ Notepad ยังคงเป็น Java IDE ที่ทรงพลังที่สุด

— Jörg W Mittag

4

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

— David Thornley

1

ทำไมคุณถึงคิดเช่น javascript เป็นภาษาแบบไดนามิก แต่ Re-sharper ไม่ทำงานที่ลื่นเหมือนที่ทำกับ C # ประการที่สองฉันไม่ได้พูดว่า "ภาษาแบบไดนามิกช้าลงในการทำสิ่งต่าง ๆ "

— Yusubov

จากคนที่ทำให้คุณ IntelliJ IDEA - PyCharm - "การเปลี่ยนชื่อการเปลี่ยนสถานะใหม่ช่วยให้สามารถทำการเปลี่ยนแปลงรหัสสากลได้อย่างปลอดภัยและทันทีการเปลี่ยนแปลงภายในไฟล์จะดำเนินการในสถานที่การทำ Refactorings ทำงานในโครงการ Python และ Django แบบธรรมดา ฟิลด์ / ค่าคงที่และอินไลน์โลคัลสำหรับการปรับปรุงโครงสร้างโค้ดภายในเมธอด, วิธีแยกเพื่อแยกวิธีที่ยาวกว่า, แยกซูเปอร์คลาส, ดันขึ้น, ดึงลงและย้ายเพื่อย้ายเมธอดและคลาส " jetbrains.com/pycharm/features/index.html

— igouy

@igouy ฉันหมายถึง Resharper และ JustCode ในคำตอบของฉัน ดังนั้นจึงเป็นเรื่องจริงสำหรับบริบทที่มีการอ้างอิง

— Yusubov