การออกแบบที่น่าเศร้าหรือการตัดสินใจเขียนโปรแกรมที่คุณทำ [ปิด]

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

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

ขอบคุณที่แบ่งปันประสบการณ์ของคุณ

ไม่สนใจYAGNIซ้ำแล้วซ้ำอีก ...

"จะทำในภายหลัง"
"ภายหลัง" ไม่เคยมา

C ++, เพชรรูปมรดกหลายเสมือน คุณได้รับความคิด

การกำหนดค่าในแอปพลิเคชันนั้นดี การกำหนดค่ามากเกินไปเป็นฝันร้ายที่จะใช้และดูแลรักษา

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

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

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

ฉันเดาว่านี่เป็นรูปแบบหนึ่งของการเพิ่มประสิทธิภาพที่ไม่จำเป็นก่อนวัยอันควรและการเพิ่มประสิทธิภาพตาบอด ราวกับว่าใช้ถ่านตัวเดียวจะช่วยโลกวันนี้ นอกเหนือจาก Y / N booleans ในฐานข้อมูลที่ไม่รองรับ booleans / bits

ไม่พัฒนาData Access Layerที่เหมาะสมและมี sql ทุกที่ในรหัสของฉันเพียงเพื่อให้ได้สิ่ง "รวดเร็ว" และทำงาน ต่อมาเมื่อโครงการเริ่มขยายและความต้องการเปลี่ยนไปมันก็กลายเป็นฝันร้าย ฉันไม่รู้ว่า DAL คืออะไรในเวลานั้น

... ดีใจที่ฉันผ่านมาแม้ว่าฉันจะยังเห็นโปรแกรมเมอร์ที่มีประสบการณ์มากกว่า 20 ปีในการทำสิ่งนี้

คิดว่าฉันสามารถเป็นสถาปนิกนักพัฒนาและ PM ทั้งหมดในโครงการเดียวกัน

นอน 2 เดือน 3 ชั่วโมงต่อคืนสอนฉันว่าคุณทำไม่ได้

การเลือก Microsoft Foundation Classes (MFC) สำหรับการเขียน Java IDE

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

ผล:

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

อุ่ย

การสร้างวงล้อขึ้นใหม่

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

การเชื่อว่าลูกค้ารู้ว่าสิ่งที่พวกเขาต้องการแล้วทำมากเกินไปก่อนที่จะตรวจสอบกับพวกเขา

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

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

หากคุณได้เข้ารหัสทุกอย่างตรงตามข้อกำหนดปัจจุบันในขณะที่เอาชนะใครก็ตามที่บอกว่า ด้วย YAGNI ตะลุมพุกของคุณ - จากนั้นความต้องการเปลี่ยนไปอย่างมาก (แต่เป็นไปตามที่คาดการณ์ไว้อย่างสมเหตุสมผล) นั่นอาจเป็นความแตกต่างระหว่างการปรับตัว 2 สัปดาห์กับการปรับตัว 20 นาที

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

YAGNI เป็นหลักการที่มีค่า แต่ไม่ควรใช้ (ab) เพื่อแก้ตัวการออกแบบที่ไม่ดีและการเข้ารหัสแบบไม่เหมาะสม มีความสมดุลและด้วยประสบการณ์ฉันเชื่อว่าฉันกำลังใกล้เข้ามา

ทรัพยากรมนุษย์ที่ไร้ความสามารถ

พยายามทำสิ่งที่ถูกและดีกับคนผิด!
แม้ว่าพวกเขาจะอยู่ในบทบาทของอีโก้ PM ที่ฟุ่มเฟือย (ซึ่งค่อนข้างบ่อยเกินไปโดยเฉพาะใน บริษัท ใหญ่ ๆ

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

ใช้บริการการรวมเซิร์ฟเวอร์ SQL (SSIS)

ฉันไม่ต้องการมันกับศัตรูที่เลวร้ายที่สุดของฉัน

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

เป็นสถานการณ์ที่เลวร้ายมากหากคุณมีเวลาน้อยกว่า 48 ชั่วโมงในการเขียนแพ็กเกจ SSIS ของคุณใหม่ในรหัส. NET POCO ของแท้หรือพลาดกำหนดเวลาเป้าหมายของคุณ

มันทำให้ฉันประหลาดใจที่ฉันสามารถเขียนแพคเกจ SSIS สามชุด (ซึ่งใช้เวลาสองเดือนในการทดสอบและพัฒนา) ภายใน 12 ชั่วโมงในรหัส. NET บริสุทธิ์ด้วย OLEDB Adapters และตัวปรับเปลี่ยน SQL

SSIS ไม่สามารถแจกจ่ายได้และจะไม่ดำเนินการแพคเกจจากเครื่องไคลเอนต์หากไม่มีใบอนุญาต SQL Server ติดตั้งอยู่ (เฉพาะ DTSPipeline.dll) นี่จะเป็นการดีที่ได้ทราบล่วงหน้า ฉันเห็นข้อจำกัดความรับผิดชอบในขณะนี้ (ในการพิมพ์ดี) บน MSDN ไม่ดีเมื่อคุณมีรหัสตัวอย่างทั่วอินเทอร์เน็ตโดยใช้รหัสเครื่อง SQL-LICENSED เท่านั้น โดยทั่วไปคุณต้องสร้างบริการเว็บที่จะพูดคุยกับเซิร์ฟเวอร์ SQL ของคุณเพื่อเรียกใช้แพคเกจ SSIS ของคุณโดยทางโปรแกรม คุณไม่สามารถเรียกใช้งานได้จากรหัส pure .NET ยกเว้นว่าคุณมีใบอนุญาต SQL ติดตั้งอยู่ในเครื่องที่ใช้งาน มันไม่สมจริงแค่ไหน? Microsoft คาดหวังให้ใช้ SSIS จากเครื่องที่ต้องติดตั้งเซิร์ฟเวอร์ SQL หรือไม่ ช่างเป็นเรื่องสมบูรณ์สิ้นสองเดือนแล้ว

บริษัท ของฉันจะไม่ใช้ SSIS อีกครั้งเพราะงานพิมพ์ขนาดเล็ก "gotcha"

ไม่ได้กำหนดกลไก / โมเดลการปรับใช้ให้เร็วที่สุดเท่าที่จะทำได้

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

เจ้านายของฉันไม่ประทับใจเมื่อเขาตรวจดูขณะที่ฉันไม่อยู่และเขาก็รู้สึกประทับใจน้อยลงเมื่อหนึ่งใน 'ไข่อีสเตอร์' หนึ่งที่เกี่ยวข้องกับใบหน้าของเขาการ์ตูนตลกใน ASCII

mmmmmm ...

การใช้ชุดรูปแบบ ASP.Net เมื่อโฟลเดอร์ CSS 'ol ปกติ' จะทำได้ดี

การใช้ถนนอย่างรวดเร็วเพื่อให้โค้ดทำงานได้ดีกว่าถนนที่ถูกต้อง (เป็นบิตทั่วไป แต่เราจะเรียกมันว่า abstraction ดังนั้นจึงเป็นคำตอบที่ 'ถูกต้อง')

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

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

ดังนั้นฉันจึงให้สิ่งที่พวกเขาขอ อย่างน้อยที่สุดมันทำงานได้ดี แต่ฐานข้อมูลได้รับการออกแบบแปลก ๆ :

• การปรับสภาพที่ไม่จำเป็นจำนวนมาก ระเบียนเดียวที่มี 5 หรือ 10 เขตข้อมูลจะถูกแบ่งข้าม 3 หรือ 4 ตาราง ฉันสามารถจัดการกับมันได้ แต่โดยส่วนตัวแล้วฉันอยากดึงฟิลด์ 1: 1 ทั้งหมดมาไว้ในตารางเดียว

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

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

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

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

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

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

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

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

ไม่ใช่ตัวเลือกวิธีการของฉัน แต่สร้าง XSLT เพื่อแปลงไฟล์ XML ตามแถวเป็นรายงาน HTML ตามคอลัมน์

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

ในที่สุดฉันก็ถูกแทนที่ด้วยสคริปต์ C # ขนาดเล็กซึ่งทำสิ่งเดียวกัน

พยายามที่จะใช้เทคโนโลยีใหม่ทั้งหมด (เพื่อเรียนรู้เทคโนโลยีใหม่) แม้ว่ามันจะต้องใช้ doent ..

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

การออกแบบโดยไม่มีข้อกำหนด

ฉันนำส่วนย่อยของแอปพลิเคชันไปใช้ตามข้อกำหนด

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