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

อัลกอริทึมที่เหมาะสมช่วยปรับปรุงคุณภาพและประสิทธิภาพของโปรแกรมหรือไม่?

เราสามารถผลิตโปรแกรมที่มีคุณภาพดีได้หรือไม่

อัลกอริทึมที่เหมาะสมเป็นสิ่งจำเป็นสำหรับการเขียนโปรแกรมสมัยใหม่หรือไม่?

ฉันคิดว่าคำถามนี้ทำให้เกิดมุมมองทางประวัติศาสตร์

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

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

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

เพียงเพื่อชี้ให้เห็นสิ่งที่:

อัลกอริทึมนั้นเป็นวิธีการแก้ปัญหาทั่วไปของคุณ ดังนั้นหากคุณแก้ไขปัญหาได้จริง ๆ แล้วคุณใช้อัลกอริทึม

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

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

แก้ไข:

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

• รายการโปรดส่วนตัวของฉันที่นี่คือรหัสเทียมและครอบคลุมเฉพาะเค้าโครงนามธรรมทั่วไปของอัลกอริธึมที่น่าสงสัย - มันไร้สาระที่จะได้รับรายละเอียดด้วยรหัสเทียมนั่นคือสิ่งที่เป็นรหัสจริง

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

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

• นอกจากนี้หากคุณอ้างอิงอัลกอริทึมของคุณในการสลับระหว่างสถานะต่างๆแผนภาพสถานะนั้นค่อนข้างมีประโยชน์

• โดยทั่วไปค่าเฉลี่ยใด ๆ ที่คุณต้องทำ คือการวาดภาพความคิดเบื้องหลังอัลกอริทึมบางอย่างเป็นวิธีที่ดี

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

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

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

อัลกอริทึมจะต้องกลายเป็นโดเมนการเขียนโปรแกรมที่ทันสมัยหรือไม่
มันเป็น 'ต้อง' อยู่แล้วเว้นแต่คุณจะมี 'php ninja' กำลังเขียน 'cool codez' อยู่ บริษัท ที่ดีที่สุดทั้งหมด (Google, Amazon, ฯลฯ ) ทดสอบประสบการณ์อัลกอริทึมของคุณในการสัมภาษณ์และฉันคิดว่าพวกเขาจะไม่ทำมันโดยไม่มีเหตุผล

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

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

หลังจากนั้นคุณอาจแก้ไขรหัสอีกครั้งหากการทำโปรไฟล์แนะนำว่ามีปัญหาเรื่องประสิทธิภาพในพื้นที่นั้น

เหตุผลก็คือมันเร็วกว่าที่จะแก้ไขข้อผิดพลาดก่อนที่คุณจะเขียนรหัสผิด

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

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

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

ออกแบบอัลกอริทึมในส่วนจากนั้นแบ่งส่วนเหล่านั้นและรหัสแต่ละส่วนแยก ด้วยวิธีนี้คุณสามารถผสมผสานมุมมองทั้งสอง:

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

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

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

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

เมื่อคุณนั่งลงและเริ่มเขียนโปรแกรมคุณมีอัลกอริทึมในใจไม่ว่า "ออกแบบ" หรือไม่

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

1) ปุ่ม mashing แบบสุ่ม นี่อาจจะทำให้เกิดข้อผิดพลาดของคอมไพเลอร์

2) การเขียนโค้ดที่คอมไพล์ได้ซึ่งอาจทำอะไรก็ได้ยกเว้นสิ่งที่คุณต้องการให้ทำ

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

ดังนั้นคนมักจะเขียนโปรแกรมด้วยอัลกอริทึมในหัวของพวกเขา อาจมีการโป่งพองหรือมีเหตุผลเกี่ยวกับกระดาษหรือสื่ออื่น ๆ

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

คุณต้องหยุดมองการสร้างซอฟต์แวร์เป็นสิ่งพื้นฐานจากการสร้างสิ่งอื่นที่มีคุณค่า มันไม่ใช่. ดังนั้นไม่ว่าจะเป็นแผนการหรือการออกแบบที่มีความคิดดี แต่ก็จำเป็นต้องมีเสมอ

อัลกอริทึมที่เหมาะสมช่วยปรับปรุงคุณภาพและประสิทธิภาพของโปรแกรมหรือไม่?

แผนการสร้าง / แผนงานที่เหมาะสมช่วยสร้างบ้านที่มีคุณภาพได้อย่างมีประสิทธิภาพหรือไม่?

เราสามารถผลิตโปรแกรมที่มีคุณภาพดีได้หรือไม่

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

อัลกอริทึมที่เหมาะสมเป็นสิ่งจำเป็นสำหรับการเขียนโปรแกรมสมัยใหม่หรือไม่?

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

ในความเป็นจริงการเขียนโปรแกรมที่ทันสมัยได้รับการย้ายออกไปจากวิศวกรซอฟต์แวร์การเขียนโปรแกรมคาวบอยที่วางแผนการเรียงลำดับบางอย่างถ้าต้อง

แม้ว่าคุณจะมีไลบรารี่ของอัลกอริทึมและโครงสร้างข้อมูลตามที่คุณต้องการ (.ie. เพิ่มใน C ++ หรือไลบรารีคอลเลกชัน Java) คุณต้องรู้ว่าสิ่งนั้นทำงานอย่างไรเพื่อใช้งานได้อย่างเหมาะสม อัลกอริทึมระดับ

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

ใส่การทดสอบและเกณฑ์มาตรฐานบางอย่างก่อนอื่น

จากนั้นเขียนอะไรก็ได้ ทำการ refactor-rewrite -loop จนกว่าคุณจะหมดเวลาหรือไม่สามารถปรับปรุงได้อีกต่อไป

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

นอกจากนี้คุณไม่สามารถเพิ่มประสิทธิภาพสัญลักษณ์ของคุณก่อนที่จะเขียน

IOW "อยู่ใกล้กับโลหะ"