เป็นเรื่องปกติหรือไม่ที่จะคิดถึงปัญหาการออกแบบเป็นเวลาหลายวันโดยที่ไม่มีการเขียนโค้ด? [ปิด]

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

เป็นเรื่องปกติหรือเปล่าที่ต้องคิดมากเป็นเวลาหลายวันโดยไม่ต้องเขียนโค้ด? นี่เป็นสัญญาณที่บ่งบอกว่าฉันกำลังเข้าใกล้ปัญหาผิดทั้งหมดหรือไม่? มันทำให้ฉันกังวลที่จะไม่ได้รับรหัสที่เป็นรูปธรรมใด ๆ ที่เขียนใน IDE ของฉัน

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

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

สิ่งนี้เรียกโดยทั่วไปว่า "การวิเคราะห์อัมพาต"

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

แนะนำให้อ่านโปรแกรมเมอร์ในทางปฏิบัติบทที่ 2 ในหัวข้อ "Tracer Bullets" โดยเฉพาะ

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

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

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

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

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

ฉันไม่รู้ว่าฉันมีวินัยที่จะยึดติดกับวิธีใดวิธีหนึ่งหรือแม้กระทั่งเมื่อฉันค้นพบวิธีหนึ่งทำงานได้ดีกว่าวิธีอื่น บางครั้งฉันรู้สึกว่าต้องไปที่กระดานไวท์บอร์ด คนอื่น ๆ แป้นพิมพ์

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

มันเป็นปรากฏการณ์ทางธรรมชาติและดีสำหรับนักพัฒนาที่จะขัดขวางเวลาและความคิดของเขา

เมื่อฉันเรียนหลักสูตรการจัดการโครงการสิ่งหนึ่งที่ผู้สอนเกี่ยวข้องกับเราเกี่ยวกับการวางแผนที่ติดอยู่ในหัวของฉันคือกฎของหัวแม่มือที่พวกเขาสอนในกองทัพคือการคิด 1 ใน 3 ของการวางแผน . ดังนั้นหากคุณมีการผ่าตัดที่ต้องใช้เวลา 3 เดือนนับจากนี้ให้วางแผนการใช้เวลาหนึ่งเดือนในการวางแผนก่อนที่จะเริ่มดำเนินการ

ในมุมมองของฉันมีสามวิธีซึ่งแต่ละวิธีเหมาะสำหรับสถานการณ์การเข้ารหัสที่เฉพาะเจาะจง

1. ฉันเคยเห็นปัญหาที่คล้ายกันมาก่อนดังนั้นฉันจึงมีความคิดที่ดีเกี่ยวกับรูปแบบที่จะใช้และชัดเจนว่าวิธีแก้ปัญหาควรปฏิบัติและตอบสนองอย่างไร

   => ใช้ BDD / TDD เริ่มต้นจากโซลูชันที่ต้องการและทำงานกับโค้ด (ตกลงบางครั้งฉันก็โกงและเขียนรหัสเล็กน้อยจากนั้นทำการทดสอบ - ชนิดที่ซ้อนกัน 2 -> 1. วิธีการ)

2. ฉันมีความคิดที่ดีเกี่ยวกับรูปแบบที่จะนำไปใช้ แต่ฉันไม่แน่ใจว่าโซลูชันนั้นควรมีลักษณะอย่างไร

   => ต้นแบบเพื่อดูว่ามีสิ่งน่าสนใจประเภทใดโผล่ออกมา ย้ายไปที่ 1 เมื่อฉันรู้ว่าต้องการสิ่งใดที่น่าสนใจ

3. ฉันไม่แน่ใจว่าจะใช้รูปแบบใด

   => คิดเกี่ยวกับปัญหาและวิธีการที่หลากหลายในการเข้าถึงปัญหาที่มีผลต่อรหัส ย้ายไปที่ 2) หรือ 1) ขึ้นอยู่กับผลลัพธ์ของการฝึก

กล่าวอีกนัยหนึ่งคำตอบคือความชื่นชอบของวิศวกร: ขึ้นอยู่กับ

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

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

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

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

Satchel Paige กล่าวว่า "บางครั้งฉันนั่งและคิดและบางครั้งฉันก็นั่ง"

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

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

โปรแกรม = อัลกอริทึม + โครงสร้างข้อมูล

IMHO กระบวนการออกแบบ (การแก้ปัญหา) กฎทั้งหมด รายละเอียดการใช้งาน (ปัญหาทางเทคนิค) ติดตามและแก้ไขอย่างเป็นธรรมชาติ

นี่คือกรณีความคิดของฉัน

1. เริ่มต้นจากศูนย์ขั้นแรกคุณต้องมีแนวคิดคร่าวๆเกี่ยวกับสิ่งที่คุณต้องการ ลองรับรายการข้อกำหนดบางอย่างหรือสร้างขึ้นมา ควรใช้เวลาสักครู่เพื่อคิดสิ่งต่าง ๆ ที่นี่ เมื่อคุณมีชิ้นส่วนอย่างน้อยที่คุณมั่นใจว่าคุณต้องการแล้วให้รู้จักอินเทอร์เฟซส่วนใหญ่ของชิ้นส่วนนั้นแล้วเริ่มการเข้ารหัส

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

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

4. การเพิ่มคุณสมบัติที่เรียบง่ายหากไม่จำเป็นต้องเปลี่ยนแปลงการออกแบบที่สำคัญเพียงแค่เขียนโค้ดในฟีเจอร์ของคุณโดยใช้การทดลอง / ข้อผิดพลาด โดยทั่วไปไม่ควรใช้เวลามากมาย

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

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

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

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