ติดอยู่เนื่องจาก“ รู้มากเกินไป” [ปิด]

บันทึกการสนทนาเพิ่มเติมได้ที่http://news.ycombinator.com/item?id=4037794

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

ฉันจำตัวเองได้ไม่นานก่อนหน้านี้อายุน้อยกว่าและอาจจะกระตือรือร้นมากกว่าเดิม "ฉัน" แล้วฉันก็ไม่ได้คิดอะไรเกี่ยวกับสิ่งนั้น - เขาจะได้ไปข้างหน้าและเขียนอะไรแล้วเขียนใหม่แล้วเขียนมันอีกครั้ง (และอีกครั้ง ... ) วันนี้ "ฉัน" ลังเลมากขึ้นระวังตัวมากขึ้น

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

มันผิดหรือเปล่า? นี่เป็นวิวัฒนาการตามธรรมชาติหรือไม่หรือว่าฉันขับรถเข้าไปในรูต?

การเปิดเผยที่เป็นธรรม - ในอดีตฉันเป็นนักพัฒนาวันนี้ตำแหน่งงานของฉันคือ "สถาปนิกระบบ" ขอให้โชคดีในการค้นหาความหมาย - แต่นั่นคือชื่อ

ว้าว. ฉันไม่ได้คาดหวังว่าคำถามนี้จะสร้างคำตอบมากมาย ฉันจะพยายามสรุปมัน

เหตุผล:

1. การวิเคราะห์อัมพาต / เหนือวิศวกรรม / การชุบทอง / (อื่น ๆ "การคิดมากเกินไปล่วงหน้าอาจทำให้คุณเจ็บ")
2. มีประสบการณ์มากเกินไปสำหรับงานที่กำหนด
3. ไม่เน้นสิ่งที่สำคัญ
4. ประสบการณ์ไม่เพียงพอ (และตระหนักว่า)

วิธีแก้ปัญหา (ไม่ตรงกับเหตุผล):

1. ทดสอบก่อน
2. เริ่มการเข้ารหัส (+ เพื่อความสนุกสนาน)
3. One to throw away (+ หนึ่ง API เพื่อทิ้ง)
4. ตั้งข้อ จำกัด เวลา
5. ถอดปุยให้อยู่กับสิ่ง
6. สร้างรหัสที่ยืดหยุ่นได้ (ตรงข้ามกับ "one to throw away", no?)

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

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

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

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

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

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

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

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

40 ปีที่ผ่านมา Fred Brooks เขียนเกี่ยวกับเรื่องนี้ "เขียนหนึ่งทิ้งคุณจะอย่างไรก็ตาม" ไม่มีอะไรเปลี่ยนแปลง........

มันผิดหรือเปล่า? นี่เป็นวิวัฒนาการตามธรรมชาติหรือไม่หรือว่าฉันขับรถเข้าไปในรูต?

มันขึ้นอยู่กับ. นี่เป็นขั้นตอนทั่วไปบนถนนของนักพัฒนา

1. เริ่มโยนอึด้วยกันโดนกัดตูด
2. เริ่มต้นปรับเปลี่ยนนรกที่มีชีวิตออกไปจากทุกสิ่งตระหนักว่า YAGNI
3. ตั้งอยู่บนพื้นที่ตรงกลางทางปฏิบัติบางอย่างที่มีสิ่งที่ง่ายต่อการถูกตบด้วยกันและสิ่งที่ยาก / การเปลี่ยนแปลงมีโอกาสได้รับวิศวกรรมพอที่จะทำให้มันง่ายพอที่จะทำงานกับ / เปลี่ยน

มันเป็นแค่ร่องถ้าคุณอยู่ที่หมายเลข 2

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

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

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

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

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

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

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

1. ระบุศูนย์กลางของแผ่นดินไหว : นึกถึงโปรเจ็กต์ของคุณในฐานะที่เป็นฮอทด็อกฮอตสปอร์กลางจะเป็นฮอทดอก คุณสามารถนำเครื่องเทศ / น้ำสลัด / ผักออกจากขาตั้งของคุณและยังสามารถขายฮอทดอกได้ วัตถุประสงค์หลักของซอฟต์แวร์ของคุณคืออะไร? แยกการเติมและ / หรือการเพิ่มมูลค่าอื่น ๆ ออกจากกันแล้วโฟกัสที่จุดศูนย์กลางหลักก่อน
2. "ทำในภายหลังหมายความว่าทำมันให้ดีขึ้น" : ดูว่ามันสมเหตุสมผลหรือไม่ หากคุณทำได้ดีและคิดเกี่ยวกับการใช้งานจริงคุณจะได้รับการออกแบบที่เหมือนกัน แต่จัดลำดับความสำคัญในแผนงาน
3. Diminish-Decouple-Discard : อะไรก็ตามที่การออกแบบโมดูลของคุณทำให้มันง่าย / จำเป็น / บริสุทธิ์ / สากลเท่าที่คุณสามารถทำได้ (บางครั้งสิ่งนี้สามารถทำได้โดยไม่ต้องถอดคุณสมบัติออก) เมื่อคุณไม่สามารถทำให้มันง่ายขึ้นให้เริ่มการแยกองค์ประกอบที่สามารถอยู่ได้ด้วยตนเองและมีจุดประสงค์ ในท้ายที่สุดถ้าคุณยังมีไขมันอยู่ในนั้นคุณจะสามารถตัดมันออกได้
4. แยก "รหัสห้องสมุด" ออกจาก "รหัสผลิต" : จะมีรหัสที่ไม่สามารถนำกลับมาใช้ใหม่ได้เสมอ แต่จะเพิ่มเสียงรบกวนในการออกแบบเสมอ รหัสนี้เป็นรหัสที่มีกฎเกณฑ์ทางธุรกิจ คุณจะพบว่าบางครั้งกฎทางธุรกิจบางอย่างก็ง่ายและรวดเร็วในการเปลี่ยนแปลง ( สำคัญมาก ) กว่าด้วยการออกแบบที่แข็งแกร่ง คุณจะพบรหัสที่คุณวางใจได้และกำหนดรหัสลูกค้าจำเป็นต้องเปลี่ยนหรือนำกลับมาใช้ใหม่ในอนาคต คุณจะต้องการให้ถูกเก็บแยกกันมากที่สุด

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

ผมเอาที่ 1 และ 2 จากการทำใหม่

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

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

มีเพียงสองสิ่งที่คุณต้องทราบเมื่อเขียนและออกแบบซอฟต์แวร์: การบำรุงรักษาและความถูกต้อง

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

การบำรุงรักษาจะช่วยในภายหลังในการพัฒนา แต่ยากที่จะปักหลัก

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

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

ฉันคิดว่ามันเป็นอาการที่ว่างานที่คุณทำนั้นง่ายเกินไปสำหรับคุณ

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

ฉันคิดว่าคุณควรพิจารณาเปลี่ยนงานของคุณ บางทีคุณควรเรียนรู้ภาษาการเขียนโปรแกรมใหม่

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

• ถ้าคุณมีความคิดว่าอาจจะปรับปรุงการทำงานที่ทำให้มัน Univeral เพิ่มเติม ... เขียนความคิดนี้ลงไปแยก textfile "ideas.txt" แต่ไม่ได้ดำเนินการในขณะนี้
• ดำเนินการอย่างเร่งด่วนต่อไป
• หลังจากหกเดือนให้ตรวจสอบ "ideas.txt" ของคุณและวิเคราะห์ว่าการเปลี่ยนแปลงใดที่จะเป็นประโยชน์ต่อโครงการ

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

คำตอบคือ - เพียงแค่ได้รับกับ ;-)

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

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

จำไว้ว่าในอนาคตการปรับเปลี่ยนรหัสเพื่อให้สอดคล้องกับลำดับความสำคัญใหม่นั้นเป็นสิ่งที่ดี คุณไม่สามารถคาดการณ์ทั้งหมดได้ล่วงหน้าดังนั้นอย่าพยายาม

รหัสสำหรับงานต่อไป - เท่านั้น รหัสนั้นเรียบง่ายและดีดังนั้นจึงง่ายต่อการปรับโครงสร้างหากคุณต้องการ ตรวจสอบให้แน่ใจว่าโปรแกรมทำงานได้ ทำซ้ำ

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

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

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

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

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

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

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

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

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

คุณไม่รู้จักมากเกินไป คุณไม่รู้จักพอ! และคุณเพิ่งตระหนักว่า

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

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

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

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

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

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

ไม่คุณยังไม่รู้จักพอ

เต็มอิ่มกับความรู้ของคุณเช่นโดยกฎง่ายๆเหล่านี้:

• KISS: ทำให้มันเล็กและเรียบง่าย
• YAGNI: คุณไม่ต้องการมัน
• เลวร้ายยิ่งดี: โซลูชันที่แย่กว่านั้นจริง ๆ แล้วดีกว่าในแง่ของการบำรุงรักษา

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

โดยสรุป: ทำให้รหัสของคุณยืดหยุ่นเพียงพอ แต่ไม่มาก แต่จงทำให้ตัวเองมีความยืดหยุ่นซื้อหนังสือเกี่ยวกับการปรับโครงสร้าง

สองสิ่ง:

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

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

แต่ทุกครั้งที่ฉันพยายามจู่โจม

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

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

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

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

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

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

คุณไม่โหดเหี้ยมพอ

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

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