ฉันประสบวิกฤตความเชื่อมั่นในความสามารถของฉันในฐานะโปรแกรมเมอร์คอมพิวเตอร์

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

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

โอ้อย่างน้อยฉันก็สามารถสร้างการเรียงลำดับฟองได้: D

โปรแกรมเมอร์ที่ดีควรตระหนักว่าอัลกอริทึมที่ยอดเยี่ยมนั้นถูกเขียนขึ้นเพื่อแก้ไขปัญหาและไม่ต้องเสียเวลาในการสร้างล้อใหม่

ฉันสงสัยว่า Dijkstra เกิดอัลกอริธึมพา ธ ที่สั้นที่สุดในเวลาไม่กี่ชั่วโมงดังนั้นนี่จึงเป็นมาตรฐานที่สูงมากในการพิจารณาว่ามีใครบางคนเป็น 'โปรแกรมเมอร์ที่ดี' หรือไม่

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

ก่อนอื่นคุณอาจสับสนในการเขียนโปรแกรมด้วยวิทยาศาสตร์คอมพิวเตอร์เชิงทฤษฎี โปรแกรมเมอร์ที่ยอดเยี่ยมต้องการพื้นฐานที่ดีในด้านวิทยาศาสตร์คอมพิวเตอร์ แต่เขาไม่จำเป็นต้องยอดเยี่ยม Dijkstra นั้นยอดเยี่ยมทางวิทยาศาสตร์คอมพิวเตอร์

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

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

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

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

ไม่สมจริงอย่างแน่นอน ผู้คนไม่เพียงแค่ "คิด" ด้วยอัลกอริทึมในเวลาไม่กี่ชั่วโมง ต้องใช้ความพยายามและทำงานอย่างมาก หากต้องการอ้างอิงบล็อกนี้ :

ในการเขียนโปรแกรม Pearls เบนท์ลีย์อ้างถึง Donald Knuth กล่าวว่า "ในขณะที่การค้นหาไบนารีครั้งแรกได้รับการเผยแพร่ในปี 1946 การค้นหาไบนารีครั้งแรกที่ทำงานอย่างถูกต้องสำหรับค่าทั้งหมดของ n ไม่ปรากฏขึ้นจนกระทั่งปี 1962"

และเวอร์ชั่นของเบนท์ลีย์ก็มีปัญหาเช่นกันเมื่อนำไปใช้กับชุดใหญ่

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

เป็นไปได้ยากมากที่คุณจะสามารถหาทางออกที่ดีกว่าโซลูชันที่คุณเลือกได้

ออกมาพร้อมอัลกอริทึมที่ดีกว่าที่คิดว่า "ดีที่สุด" (ในกรณีของคุณสั้นที่สุด) ไม่ใช่สิ่งที่ทุกคนสามารถทำได้ อาจเป็นไปไม่ได้

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

(s) เขาควรจะรู้ด้วยเช่นกันว่าเป็นวิธีที่ดีที่สุดในการแก้ไขปัญหานั้นหรือไม่

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

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

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

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

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

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

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

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

โอกาสที่ดีที่คุณได้คิดค้นสิ่งใหม่โดยไม่รู้ตัวหลายๆ อย่างที่คนอื่น ๆ ไม่เคยคิดมาก่อนถ้าไม่ได้รับการสอนอย่างชัดเจน

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

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

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

ฉันคิดว่าฉันฟังดูรุนแรงขึ้นกว่าที่ฉันต้องการจริงๆ แต่ประเด็นของฉันคือ: ฉันคาดหวังว่าโปรแกรมเมอร์จะมีความคิดสร้างสรรค์มากพอที่จะคิดหาวิธีแก้ปัญหาแม้ว่าวิธีแก้ปัญหาจะยุ่งเหยิงหรือยุ่งเหยิงก็ตาม

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

(BTW การอนุมัติของฉันนับตามลำดับความสำคัญเช่นเดียวกับคูปองล้างรถฟรี)

ใช่เขา / เธอควรจะ

มันอาจจะเทียบเท่ากับการจัดเรียงฟองสบู่ แต่ฉันคิดว่าโปรแกรมเมอร์ที่ดีควรสามารถสร้างสิ่งที่ได้ผลอย่างน้อยที่สุดอย่างไรก็ตามมันอาจจะไม่มีประสิทธิภาพ

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

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

ไม่ต้องกังวล

ในฐานะที่เป็นโปรแกรมเมอร์ Perl ฉันทุกคนเกี่ยวกับไม่เคย reinventing ล้อ นั่นคืองานของ CPAN หากมีอัลกอริทึมหรือโมดูลที่ได้รับการสนับสนุนอย่างง่ายเราจะใช้มัน ถ้าไม่มีโมดูลดีแล้วเราคิดค้นล้อ นั่นเป็นหนึ่งในสิ่งที่ยิ่งใหญ่ที่สุดเกี่ยวกับ Perl

ดังนั้นสิ่งที่ฉันพูดคือ:

1. ฉันไม่แนะนำให้ปรับแต่งล้อ แต่เมื่อคุณทำ ...
2. พยายามอย่าบูรณาการใหม่และ ...
3. ไม่ต้องกังวลหากคุณไม่สามารถทำได้ นั่นเป็นเหตุผลที่เรามีชุมชนการเขียนโปรแกรม :-)

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

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

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

มันหมายความว่าคุณไม่สนใจประวัติเกี่ยวกับปัญหาเส้นทางที่สั้นที่สุดไปจาก algoritm O (| V | ^ 4) ที่ตีพิมพ์ในปี 1955 ถึงอัลกอริทึม O (E + V log V) ที่ตีพิมพ์ในปี 1984 (ซึ่งเป็น Dijkstra's อัลกอริทึมกับต้นไม้ฟีโบนักชี) คุณเกือบรับประกันว่าจะทำสิ่งที่แย่กว่าอัลกอริทึมที่ได้วางแผนไว้แล้ว ยังมีโอกาสที่อัลกอริทึมของคุณมีช่องว่างหรือข้อผิดพลาดทำให้ไม่ถูกต้อง นอกจากนี้คุณจะต้องใช้เวลามากขึ้นในการคิดอัลกอริทึมของคุณใช้งานและทดสอบมากกว่าเวลาที่ใช้ในการใช้อัลกอริทึมที่มีอยู่อีกครั้ง

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

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