ควรใช้รหัสเทียมก่อนการเข้ารหัสจริงหรือไม่

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

• ระบุและแยกงานการเข้ารหัส
• เขียน pseudocode
• รับการอนุมัติ [โดย PL หรือ TL]
• เริ่มการเข้ารหัสตาม Pseudocode

นี่เป็นแนวทางที่แนะนำหรือไม่ มีการฝึกฝนในอุตสาหกรรมหรือไม่?

การเขียน pseudocode ก่อนการเข้ารหัสนั้นดีกว่าการเข้ารหัสโดยไม่ต้องวางแผน แต่มันก็ยังห่างไกลจากการฝึกฝนที่ดีที่สุด การพัฒนาที่ขับเคลื่อนด้วยการทดสอบเป็นการปรับปรุง

ยิ่งไปกว่านั้นคือการวิเคราะห์ปัญหาโดเมนและวิธีการแก้ปัญหาการออกแบบโดยใช้เทคนิคเช่นเรื่องราวของผู้ใช้กรณีการใช้งานบัตร CRC การทำไดอะแกรมตามที่ได้รับการดำเนินการโดยวิธีการเช่น Cleanroom, RUP, Lean, Kanban, Agile เป็นต้น

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

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

ไม่อย่าหลอกรหัสก่อน

นี่คือค่าใช้จ่ายมากเกินไป คุณกำลังทำงานเขียนตรรกะโดยไม่มีประโยชน์ ฉันขอแนะนำสิ่งต่อไปนี้แทน:

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

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

ในความคิดของฉันรหัสหลอกมีเพียงสองวัตถุประสงค์ที่ถูกต้อง:

(1) สำหรับนักเรียนที่ต้องการเรียนรู้เกี่ยวกับแนวคิดของโมดูลและอัลกอริธึม แต่ยังไม่คล่องในภาษาการเขียนโปรแกรม

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

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

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

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

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

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

1. การกำหนดสัญญา (เงื่อนไขก่อน / หลัง / ค่าคงที่) ของวิธีการก่อนที่จะเริ่ม
2. TDD
3. 1 และ 2 รวมกัน (เขียนแบบทดสอบเพื่อทำสัญญา)

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

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

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

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

ครั้งเดียวที่ฉันใช้รหัสเทียมในช่วง 10 ปีที่ผ่านมาคือการสัมภาษณ์เมื่อเราทำงานบนไวท์บอร์ดและภาษานั้นไม่สำคัญ

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

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

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

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

pseudocode ถูกเขียนด้วยกราฟิกด้วยเครื่องมืออย่าง UML ยกตัวอย่างเช่นลองyUML

เครื่องมือออนไลน์สำหรับการสร้างและเผยแพร่ไดอะแกรม UML อย่างง่าย มันทำให้ง่ายสำหรับคุณที่จะ:

• ฝังไดอะแกรม UML ไว้ในบล็อกอีเมลและวิกิ
• โพสต์แผนภาพ UML ในฟอรัมและความคิดเห็นในบล็อก
• ใช้โดยตรงภายในเครื่องมือติดตามบั๊กบนเว็บของคุณ
• คัดลอกและวางไดอะแกรม UML ลงในเอกสาร MS Word และงานนำเสนอ PowerPoint

... yUML ช่วยคุณประหยัดเวลา มันถูกออกแบบมาสำหรับผู้ที่ต้องการสร้างไดอะแกรมและร่าง UML ขนาดเล็ก

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

การทำงานที่ดี. คุณเริ่มการสนทนาที่ดี ในฐานะของฉันฉันเคยเขียนโค้ดหลอกเมื่อฉันเรียนรู้การเขียนโปรแกรมเพื่อทำความเข้าใจลูปและอัลกอริทึมต่างๆ นี่เป็นอีกหนึ่งทศวรรษครึ่งแล้ว วันนั้นแม้ภาษาการเขียนโปรแกรมไม่ได้ทรงพลังมาก ... และการเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์ก็เป็นอนาคต ตอนนี้ด้วย 4GLs และ 5GL เราคิดว่าในภาษานั้นค่อนข้างจะเป็นภาษาอังกฤษธรรมดา เมื่อเราคิดถึงปัญหาเราคิดในแง่ของวัตถุและการปฏิบัติงาน และจนกว่ามันจะเป็นรูปแบบที่ซับซ้อนการเขียนโค้ดหลอก (หรือ PSEU-DO-Codes, ล้อเล่น) ไม่สมเหตุสมผล ดีกว่าแสดงโซลูชันด้วยวิธีกราฟิก

ขึ้นอยู่กับภาษาที่ใช้และความคุ้นเคยของคุณกับมัน

ภาษาสมัยใหม่หลายภาษาเช่น Python หรือ Java นั้นใกล้เคียงกับ pseudocode แล้วการเขียน pseudocode ad hoc บางอันก่อนนั้นสิ้นเปลือง IMHO ดีกว่าทำได้ทันทีโดยใช้แนวทางกระสุนติดตาม

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

มีหลายกรณีที่ pseudocode มีแนวโน้มที่จะแตกหักในงานของฉันซึ่งอยู่ในวงการวิชาการที่การเขียนโปรแกรมมีแนวโน้มที่จะใช้เป็นเครื่องมือหรือ "และตอนนี้เราแก้ปัญหาได้" กรอกกลางโครงการ:

1. เมื่อรหัสจะต่อต้านความคิดสร้างสรรค์ของสิ่งที่จะเกิดขึ้นมากกว่าหลอกรหัสจะเป็น ยกตัวอย่างเช่น SAS จะใช้ไวท์บอร์ดครึ่งหนึ่งในการเขียนโปรแกรมพื้นฐานขั้นพื้นฐาน ดูเพิ่มเติมที่ C ซึ่งมีผู้โพสต์อื่นพูดถึง
2. ด้วยการวิเคราะห์ข้อมูลและการเข้ารหัสสถิติจำนวนมากมีแนวโน้มที่จะมีการแก้ไขด้วยโค้ดเนื่องจากผลลัพธ์ถูกสร้างขึ้น Pseudocode ค่อนข้างใช้งานได้ง่ายกว่าสำหรับ "ในที่นี้เป็นกระบวนการแบบไปกลับมาหากแผนการวินิจฉัยไม่ถูกต้องลองใช้ X"
3. นักเรียนเรียนรู้ภาษาการเขียนโปรแกรมที่แตกต่างกันมากมาย ตัวอย่างเช่นในหมู่คนที่ฉันรู้จักอาจมีการวิเคราะห์ปัญหาสถิติใน SAS, R หรือ Stata บางสิ่งที่ต้องการบางสิ่งบางอย่างที่ใกล้เคียงกับการเขียนโปรแกรมแบบดั้งเดิมอาจทำได้ใน R, Matlab, C, C ++, Java, Python ... ขึ้นอยู่กับสิ่งที่นักเรียนบางคนกำลังนำโปรแกรมไปใช้และเพื่อวัตถุประสงค์อะไร แต่ก็ยังมีประโยชน์สำหรับคน Java และคน Python และคน Matlab ที่จะมีความคิดร่วมกันในสิ่งที่คนอื่นกำลังทำและวิธีการวิธีการมากกว่ารหัสตัวเองทำงาน

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

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

หลอกรหัสที่จริงรหัสที่เหมาะสมในภาษาระดับสูงนอกจากนี้ยังใช้มักจะเรียกว่าการสร้างต้นแบบ

นอกเหนือจากการทำความเข้าใจโค้ดหลอกก็ดีสำหรับการสื่อสาร

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