คำถามติดแท็ก changes

ฉันทำงานให้กับ บริษัท ใหญ่ (พนักงานมากกว่า 8,000 คน) เป็นเวลาเกือบ 2 ปีแล้วและได้รับการจ้างงานหลังจากเรียนจบหลักสูตร ทุกคนที่นี่ต้องจัดการรหัสประจำวันซึ่งมักจะออกแบบมาไม่ดีและเต็มไปด้วยแฮ็ก ในตอนแรกฉันเก็บข้อมูลไม่ดีพยายามอย่าวิพากษ์วิจารณ์สิ่งต่างๆ แต่สถานการณ์ตามที่ได้กลายเป็นเรื่องยากมากที่จะอยู่กับและดูเหมือนว่าไม่มีใครเต็มใจที่จะปรับปรุง / แทนที่เครื่องมือที่เราใช้ เพื่อให้ชัดเจนยิ่งขึ้นเรามี: เครื่องมือควบคุมแหล่งที่ล้าสมัย (Visual SourceSafe) makefiles เก่าธรรมดาที่รองรับเฉพาะการสร้างใหม่อย่างเต็มรูปแบบ .def ไฟล์ที่ต้องดูแลรักษาด้วยตนเองและแยกกันสำหรับสถาปัตยกรรมที่มีอยู่ทั้งหมด ส่วนหัวของเสาหินไฟล์และโครงการที่มีไฟล์ต่างกันน้อยมาก (แต่แต่ละไฟล์มีโค้ดประมาณ 3000 บรรทัดซึ่งบางครั้งก็ดูแลงานที่แตกต่างกันมาก) ไม่มีการใช้สิ่งอำนวยความสะดวกด้านภาษา "ใหม่" ( std::stringก็ไม่ใช่เรื่องใหม่ แต่ไม่มีใครยกเว้นฉันใช้) ฉันตัดสินใจไม่กี่เดือนที่ผ่านมาเพื่อทำอะไรกับมันโดยการออกแบบสภาพแวดล้อมการรวบรวมใหม่ ฉันสามารถสร้างบิวด์เพิ่มเติมเพื่อทำงานได้อย่างน่าเชื่อถือใช้เวลาในการคอมไพล์เร็วขึ้นสร้างโครงงานที่ดีกว่า.defสร้างไฟล์อัตโนมัติ ฉันยังสร้างบริดจ์จาก / ถึง Git ถึง / จาก Visual SourceSafe ฉันแสดงความสำเร็จของฉันต่อเพื่อนร่วมงานหลายคนและเจ้านายของเรา แต่ก็เหมือนไม่มีใครสนใจ พวกเขาทุกคนต่างก็พูดว่า "อืม ... ผู้คนเคยทำแบบนั้นแล้วทำไมเราจะเปลี่ยนสิ่งต่าง ๆ ? …

40 architecture  productivity  changes 

เพื่อนของฉันกำลังทำงานให้กับ บริษัท เล็ก ๆ ในโครงการที่ผู้พัฒนาทุกคนจะเกลียด: เขาถูกกดดันให้ปล่อยตัวโดยเร็วที่สุดเขาเป็นคนเดียวที่ดูเหมือนจะสนใจหนี้ทางเทคนิคลูกค้าไม่มีพื้นฐานด้านเทคนิค ฯลฯ เขาเล่าเรื่องซึ่งทำให้ฉันคิดถึงความเหมาะสมของรูปแบบการออกแบบในโครงการเช่นนี้ นี่คือเรื่องราวของ เราต้องแสดงผลิตภัณฑ์ในที่ต่างๆบนเว็บไซต์ ตัวอย่างเช่นผู้จัดการเนื้อหาสามารถดูผลิตภัณฑ์ แต่ยังรวมถึงผู้ใช้หรือคู่ค้าผ่าน API บางครั้งข้อมูลหายไปจากผลิตภัณฑ์ตัวอย่างเช่นกลุ่มหนึ่งไม่มีราคาเมื่อสร้างผลิตภัณฑ์ แต่ยังไม่ได้ระบุราคา บางคนไม่มีคำอธิบาย (คำอธิบายเป็นวัตถุที่ซับซ้อนที่มีประวัติดัดแปลงเนื้อหาที่แปลเป็นภาษาท้องถิ่น ฯลฯ ) บางคนขาดข้อมูลการจัดส่ง แรงบันดาลใจจากการอ่านล่าสุดของฉันเกี่ยวกับรูปแบบการออกแบบผมคิดว่านี่คือโอกาสที่ดีที่จะใช้ที่มีมนต์ขลังรูปแบบวัตถุ Null ดังนั้นฉันจึงทำและทุกอย่างราบรื่นและสะอาด มีเพียงแค่โทรproduct.Price.ToString("c")เพื่อแสดงราคาหรือproduct.Description.Currentแสดงคำอธิบาย; ไม่จำเป็นต้องมีเงื่อนไข จนกระทั่งวันหนึ่งผู้มีส่วนได้เสียขอให้แสดงต่างกันใน API โดยมี a nullใน JSON และยังแตกต่างกันสำหรับผู้จัดการเนื้อหาด้วยการแสดง "ราคาไม่ระบุ [เปลี่ยน]" และฉันต้องฆ่ารูปแบบวัตถุ Null ที่รักของฉันเพราะมันไม่จำเป็นอีกต่อไป ในทำนองเดียวกันฉันต้องลบโรงงานนามธรรมไม่กี่แห่งและผู้สร้างไม่กี่คนฉันลงเอยด้วยการเปลี่ยนรูปแบบ Facade ที่สวยงามของฉันโดยการโทรโดยตรงและน่าเกลียดเพราะอินเทอร์เฟซพื้นฐานเปลี่ยนไปสองครั้งต่อวันเป็นเวลาสามเดือน เมื่อข้อกำหนดบอกว่าวัตถุที่เกี่ยวข้องจะต้องแตกต่างกันขึ้นอยู่กับบริบท มากกว่าสามสัปดาห์ของการทำงานประกอบด้วยการเพิ่มรูปแบบการออกแบบจากนั้นฉีกออกเป็นชิ้น ๆ ในอีกหนึ่งเดือนต่อมาและในที่สุดโค้ดของฉันก็กลายเป็นสปาเก็ตตี้มากพอที่จะเป็นไปไม่ได้ที่จะรักษาโดยใครก็ตาม จะเป็นการดีกว่าหรือที่จะไม่ใช้รูปแบบเหล่านั้นตั้งแต่แรก? อันที่จริงฉันต้องทำงานด้วยตัวเองในโครงการประเภทต่างๆที่ความต้องการมีการเปลี่ยนแปลงอยู่ตลอดเวลาและถูกกำหนดโดยบุคคลที่ไม่ได้อยู่ในใจของการทำงานร่วมกันหรือการเชื่อมโยงของผลิตภัณฑ์ ในบริบทนี้มันไม่สำคัญว่าคุณจะคล่องตัวแค่ไหนคุณจะมาพร้อมกับวิธีการแก้ปัญหาที่สง่างามและเมื่อคุณใช้มันในที่สุดคุณจะได้เรียนรู้ว่าความต้องการเปลี่ยนแปลงไปอย่างมากและโซลูชันที่สง่างามของคุณไม่เหมาะสม ได้อีกต่อไป. อะไรจะเป็นทางออกในกรณีนี้? ไม่ได้ใช้รูปแบบการออกแบบหยุดคิดและเขียนรหัสโดยตรงหรือไม่ …

32 design-patterns  agile  changes 

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

13 agile  business  financial  changes 

นี่เป็นคำถามที่ค่อนข้างคลุมเครือ แต่เป็นสิ่งที่ฉันไม่เคยรู้สึกว่าได้รับคำตอบอย่างน่าพอใจเมื่ออ่านเกี่ยวกับการออกแบบที่เหมาะสม โดยทั่วไปเมื่อเรียนรู้เกี่ยวกับการเขียนโปรแกรมเชิงวัตถุ, นามธรรม, แยกตัวประกอบ ฯลฯ จอกศักดิ์สิทธิ์ของการออกแบบ - และเหตุผลที่พวกเขาอ้างเสมอว่าคุณใช้เทคนิคการพัฒนาที่เป็นปัญหา - คือมันจะทำให้โปรแกรมของคุณ "ง่ายต่อการเปลี่ยนแปลง" , "maintainable", "ยืดหยุ่น" หรือคำพ้องความหมายใด ๆ ที่ใช้เพื่อแสดงแนวคิดเกี่ยวกับการผลิตที่ทำให้เกิดเสียงดังกล่าว ด้วยการทำเครื่องหมายส่วนตัวของ ivars ให้แยกรหัสออกเป็นวิธีเล็ก ๆ ที่มีอยู่ในตัวเองทำให้อินเตอร์เฟสทั่วไปทำให้คุณสามารถปรับเปลี่ยนโปรแกรมของคุณได้อย่างง่ายดาย สำหรับการเปลี่ยนแปลงที่ค่อนข้างเล็กสิ่งนี้ใช้ได้ดีสำหรับฉัน การเปลี่ยนแปลงโครงสร้างข้อมูลภายในที่ใช้โดยคลาสเพื่อเพิ่มประสิทธิภาพไม่เคยมีความยุ่งยากที่สำคัญและไม่มีการเปลี่ยนแปลงส่วนท้ายของส่วนต่อประสานผู้ใช้ที่เป็นอิสระจาก API เช่นการออกแบบระบบป้อนข้อความใหม่หรือปรับปรุงกราฟิกสำหรับองค์ประกอบการเล่นเกม . การเปลี่ยนแปลงทั้งหมดเหล่านี้ดูเหมือนมีอยู่ในตัวเองโดยเนื้อแท้ ไม่มีสิ่งใดที่เกี่ยวข้องกับการเปลี่ยนแปลงพฤติกรรมหรือการออกแบบองค์ประกอบของโปรแกรมของคุณที่ได้รับการแก้ไขตราบใดที่รหัสภายนอกเกี่ยวข้อง ไม่ว่าคุณจะเขียนขั้นตอนหรือในสไตล์ OO ที่มีฟังก์ชั่นขนาดใหญ่หรือขนาดเล็กการเปลี่ยนแปลงเหล่านี้ง่ายต่อการเปลี่ยนแปลงแม้ว่าคุณจะมีการออกแบบที่ดีพอสมควรก็ตาม อย่างไรก็ตามเมื่อใดก็ตามที่การเปลี่ยนแปลงมีขนาดใหญ่และมีขนฟูนั่นคือการเปลี่ยนแปลง API - ไม่มีรูปแบบ "อันมีค่า" ของฉันเลยที่จะช่วยเหลือ การเปลี่ยนแปลงครั้งใหญ่ยังคงใหญ่รหัสที่ได้รับผลกระทบยังคงได้รับผลกระทบและงานการวางไข่หลายชั่วโมงอยู่ข้างหน้าฉัน ดังนั้นคำถามของฉันคือสิ่งนี้ การออกแบบที่เหมาะสมนั้นมีการเปลี่ยนแปลงขนาดใหญ่เพียงใดเพื่อให้สามารถอำนวยความสะดวกได้? มีเทคนิคการออกแบบเพิ่มเติมบางอย่างไม่เป็นที่รู้จักสำหรับฉันหรือฉันล้มเหลวในการใช้งานที่ทำให้การปรับเปลี่ยนที่ทำให้เกิดเสียงง่าย ๆ หรือเป็นสัญญานั้น (ซึ่งฉันได้ยินจากกระบวนทัศน์ที่แตกต่างกันมากมาย) เป็นแนวคิดที่ดี ตัดการเชื่อมต่ออย่างสมบูรณ์จากความจริงที่ไม่เปลี่ยนรูปแบบของการพัฒนาซอฟต์แวร์? มี "เครื่องมือเปลี่ยน" …

11 design  object-oriented  maintenance  abstraction  changes 

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

9 project  changes