คำถามติดแท็ก programming-practices

Programming Practices เป็นวิธีที่ใช้กันทั่วไปหรือไม่ใช้กันทั่วไปในการพัฒนาซอฟต์แวร์ สิ่งเหล่านี้อาจรวมถึงสิ่งต่าง ๆ เช่นการพัฒนาแบบ Agile, Kanban, ทางลัดการเข้ารหัส ฯลฯ

16
การสร้างซอฟต์แวร์ใหม่เป็นส่วนสำคัญของงานเขียนโปรแกรมส่วนใหญ่หรือไม่? [ปิด]
ฉันได้ทำงานในการพัฒนาซอฟต์แวร์มานานกว่า 10 ปีแล้วและฉันก็เริ่มที่จะสร้างอะไรใหม่ "ใหม่" ฉันรู้ว่า "ใหม่" เป็นคำที่คลุมเครือ แต่ฉันจะนิยามมันเป็นอะไรก็ได้ตั้งแต่โครงการขนาดใหญ่ใหม่ไปจนถึงคุณสมบัติขนาดใหญ่ใหม่ในโครงการที่มีอยู่ (พูดบางสิ่งที่ต้องใช้ความคิดในการออกแบบและอาจ ใช้เวลา 2 สัปดาห์หรือมากกว่าในการดำเนินการ) บางทีแนวทางคร่าวๆอาจเป็นสิ่งใหม่หากต้องการข้อมูลจำเพาะที่เป็นลายลักษณ์อักษร ฉันคิดว่าโปรแกรมเมอร์ส่วนใหญ่รู้ว่าฉันกำลังพูดถึงอะไรคุณอยู่ในโซนเขียนโค้ดจำนวนมากในเวลาอันรวดเร็ว อย่างไรก็ตามเมื่อคิดย้อนกลับไปยังสิ่งที่ฉันทำฉันคาดว่าจะใช้เวลาน้อยกว่า 10% ของเวลาที่ใช้ในการทำงาน "ใหม่" มีสิ่งต่าง ๆ เช่น "ปรับระบบที่มีอยู่นี้ให้ทำงานในสภาพแวดล้อมใหม่นี้" ซึ่งแน่นอนว่าต้องมีการวางแผนมากมาย แต่การเข้ารหัสที่เกิดขึ้นจริงและ "สิ่งใหม่" นั้นเกิดขึ้นจากการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ในหลาย ๆ รหัส เช่นเดียวกันกับการร้องขอฟีเจอร์เล็ก ๆ - ถ้าฉันรู้ว่าจะต้องทำสิ่งเหล่านี้มักจะเสร็จสิ้นภายในไม่ถึงหนึ่งชั่วโมงและถ้าฉันทำไม่ได้มันเป็นเพียงการอ่านโค้ดจำนวนมากและการหาสิ่งที่ต้องทำ (ซึ่งทำให้ฉันหงุดหงิด ทำได้ดีกว่ามากโดยไม่ต้องอ่าน) โดยทั่วไปแล้วฉันรู้สึกว่าฉันไม่ได้สร้างอะไรเป็นส่วนใหญ่ ฉันคิดว่านี่เป็นกรณีในสถานที่ส่วนใหญ่ - ผลิตภัณฑ์ใหม่จะออกมาค่อนข้างเร็วและ ณ จุดนั้นทุกคนจะตื่นเต้นและต่อสู้กับรหัสอย่างรวดเร็ว แต่จากนั้นเมื่อมันเข้าสู่โหมดการบำรุงรักษา การเปลี่ยนแปลงที่ตามมาเล็กน้อยจะถือเป็น "ใหม่และสร้างสรรค์" ฉันผิดหรือเปล่า? ฉันอธิบายงานการเขียนโปรแกรมส่วนใหญ่อย่างถูกต้องหรือไม่หรือโปรแกรมเมอร์ส่วนใหญ่รู้สึกว่าพวกเขามักจะสร้างสิ่งใหม่ ๆ …

22
ทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎีและการปฏิบัติ? [ปิด]
เมื่อเปรียบเทียบกับวิศวกรรมซอฟต์แวร์กับวิศวกรรมโยธาฉันรู้สึกประหลาดใจที่สังเกตวิธีการคิดที่แตกต่าง: วิศวกรโยธาคนใดรู้ว่าถ้าคุณต้องการสร้างกระท่อมเล็ก ๆ ในสวนคุณก็จะได้วัสดุและสร้างมันในขณะที่ถ้าคุณต้องการสร้าง บ้าน 10 ชั้น (หรือบางอย่างเช่นนี้ ) คุณต้องทำคณิตศาสตร์เพื่อให้แน่ใจว่ามันจะไม่พัง ในทางตรงกันข้ามการพูดกับการเขียนโปรแกรมบางส่วนหรืออ่านบล็อกหรือฟอรั่ฉันมักจะพบความเห็นในวงกว้างที่สามารถนำสูตรมากหรือน้อยดังต่อไปนี้: ทฤษฎีและวิธีการอย่างเป็นทางการสำหรับนักคณิตศาสตร์ / นักวิทยาศาสตร์ในขณะที่การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการทำสิ่งต่างๆ สิ่งที่บอกเป็นนัยก็คือการเขียนโปรแกรมเป็นสิ่งที่ใช้งานได้จริงและแม้ว่าวิธีการอย่างเป็นทางการคณิตศาสตร์ทฤษฎีอัลกอริทึมภาษาโปรแกรมสะอาด / เชื่อมโยงกัน ฯลฯ อาจเป็นหัวข้อที่น่าสนใจพวกเขามักไม่จำเป็นถ้าทุกคนต้องการได้สิ่ง เสร็จแล้ว จากประสบการณ์ของฉันฉันจะบอกว่าในขณะที่คุณไม่จำเป็นต้องใช้ทฤษฎีมากในการรวบรวมสคริปต์ 100 บรรทัด (กระท่อม) เพื่อพัฒนาแอปพลิเคชันที่ซับซ้อน (อาคาร 10 ชั้น) คุณต้องมีการออกแบบที่มีโครงสร้าง - วิธีการกำหนดภาษาการเขียนโปรแกรมที่ดีหนังสือข้อความที่ดีที่คุณสามารถค้นหาอัลกอริทึม ฯลฯ ดังนั้น IMO (ปริมาณที่เหมาะสมของ) ทฤษฎีเป็นหนึ่งในเครื่องมือสำหรับการทำสิ่งต่างๆ คำถามของฉันคือทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎี (วิธีการที่เป็นทางการ) และการฝึกฝน ซอฟต์แวร์วิศวกรรม (ซอฟท์แวร์อาคาร) ถูกมองว่าเป็นเรื่อง ง่ายเมื่อเทียบกับวิศวกรรมโยธา (บ้านอาคาร)? หรือทั้งสองสาขาแตกต่างกันจริงๆ (นอกเหนือจากซอฟต์แวร์ที่มีความสำคัญต่อภารกิจแล้วความล้มเหลวของซอฟต์แวร์นั้นเป็นที่ยอมรับได้มากกว่าการสร้างความล้มเหลว) ฉันพยายามสรุปสิ่งที่ฉันเข้าใจจากคำตอบแล้ว ตรงกันข้ามกับวิศวกรรมซอฟต์แวร์ในสาขาวิศวกรรมโยธามันมีความชัดเจนมากขึ้นว่าจำนวนของทฤษฎี (การสร้างแบบจำลองการออกแบบ) เป็นสิ่งจำเป็นสำหรับงานบางอย่าง …

10
มีสิ่งใดที่มีฟังก์ชั่น / เมธอดส่วนตัวมากเกินไปหรือไม่?
ฉันเข้าใจถึงความสำคัญของรหัสที่มีเอกสารดี แต่ฉันก็เข้าใจถึงความสำคัญของรหัสการจัดทำเอกสารด้วยตนเอง ยิ่งง่ายต่อการอ่านฟังก์ชั่นโดยเฉพาะยิ่งเราสามารถเดินหน้าได้เร็วขึ้นในระหว่างการบำรุงรักษาซอฟต์แวร์ ด้วยที่กล่าวว่าฉันชอบที่จะแยกฟังก์ชั่นใหญ่เป็นคนเล็ก ๆ แต่ฉันทำจนถึงจุดที่ชั้นเรียนสามารถมีมากกว่าห้าคนเพื่อรับใช้วิธีการเดียวเท่านั้น ทีนี้คูณวิธีการส่วนตัวห้าวิธีด้วยวิธีสาธารณะห้าวิธีและคุณจะได้วิธีซ่อนเร้นประมาณยี่สิบห้าวิธีซึ่งอาจเรียกได้โดยสาธารณะเหล่านั้นเพียงครั้งเดียว แน่นอนว่าตอนนี้การอ่านวิธีสาธารณะนั้นง่ายขึ้น แต่ฉันอดไม่ได้ที่จะคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี [แก้ไข] มีคนถามฉันว่าทำไมฉันคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี คำตอบง่าย ๆ : มันเป็นความรู้สึกทางเดินอาหาร ความเชื่อของฉันไม่ใช่เพียงหนึ่งบิตที่ได้รับการสนับสนุนจากประสบการณ์ด้านวิศวกรรมซอฟต์แวร์นานนับชั่วโมง มันเป็นความไม่แน่นอนที่ทำให้ฉัน "บล็อกนักเขียน" แต่สำหรับโปรแกรมเมอร์ ในอดีตที่ผ่านมาฉันเพิ่งจะเขียนโปรแกรมโครงการส่วนบุคคล เมื่อไม่นานมานี้ฉันได้ย้ายไปยังโครงการที่ทำงานเป็นทีม ตอนนี้ฉันต้องการให้แน่ใจว่าคนอื่นสามารถอ่านและเข้าใจรหัสของฉันได้ ฉันไม่แน่ใจว่าจะปรับปรุงความชัดเจนได้อย่างไร ในมือข้างหนึ่งฉันกำลังคิดที่จะแยกฟังก์ชั่นใหญ่หนึ่งอันออกเป็นฟังก์ชันย่อยที่มีชื่อที่เข้าใจได้ แต่มีอีกด้านหนึ่งของฉันบอกว่ามันซ้ำซ้อน ดังนั้นฉันขอให้สิ่งนี้สอนตัวเองเพื่อเลือกเส้นทางที่ถูกต้อง [แก้ไข] ด้านล่างฉันรวมสองรุ่นว่าฉันสามารถแก้ปัญหาของฉันได้อย่างไร คนแรกแก้มันโดยไม่แยกชิ้นใหญ่ของรหัส คนที่สองไม่สิ่งที่แยกจากกัน รุ่นแรก: public static int Main() { // Displays the menu. Console.WriteLine("Pick your option"); Console.Writeline("[1] Input and display a polynomial"); Console.WriteLine("[2] …

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

16
แนวทางปฏิบัติที่ดีที่สุดสำหรับ if / return
ฉันต้องการที่จะรู้ว่าสิ่งที่ถือว่าเป็นวิธีที่ดีกว่าของการกลับมาเมื่อฉันมีifคำสั่ง ตัวอย่างที่ 1: public bool MyFunction() { // Get some string for this example string myString = GetString(); if (myString == null) { return false; } else { myString = "Name " + myString; // Do something more here... return true; } } ตัวอย่างที่ 2: public bool MyFunction() { // …

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

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

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

17
ทางเลือกในการควบคุมเวอร์ชันมืออาชีพ [ปิด]
เรากำลังร่วมมือกับโปรแกรมเมอร์ (นักเขียน) ที่ไม่ใช่คนที่ต้องการมีส่วนร่วมในโครงการของเรา ตอนนี้พวกเขาไม่ชอบแนวคิดของการใช้ Git (หรืออะไรก็ตามสำหรับเรื่องนั้น) สำหรับเวอร์ชันที่ควบคุมการทำงานของพวกเขา ฉันคิดว่าเป็นเช่นนี้เพราะพวกเขาไม่คิดว่ามันจะคุ้มค่าที่จะห่อหุ้มแนวคิดที่บิดเบี้ยวของการควบคุมเวอร์ชัน (เมื่อฉันแนะนำพวกเขาให้รู้จักกับการแตกแขนงและรวมเข้าด้วยกัน - พวกเขาดูเหมือนว่าฉันจะทำให้พวกเขาขุ่นเคือง) ตอนนี้เราไม่อยู่ในฐานะที่จะให้การศึกษาแก่พวกเขาหรือโน้มน้าวให้พวกเขาใช้มัน เราแค่พยายามหาทางเลือกอื่นเพื่อให้เราได้งานทั้งหมด (ซึ่งเป็นสิ่งที่เราต้องการ) - และพวกเขาได้รับขั้นตอนการทำงานที่ง่ายและมีสมาธิกับสิ่งที่พวกเขาทำ ฉันได้ไอเดียมา ... บอกให้พวกเขาบันทึกงานของพวกเขาเป็นไฟล์แยกต่างหากทุกครั้งที่พวกเขาทำการเปลี่ยนแปลงที่ไม่สำคัญและจากนั้นใช้ diff ด้านข้างของเราเพื่อติดตามการเปลี่ยนแปลง เขียนโปรแกรม (ใน Python) ที่ใช้ "เหตุการณ์สำคัญ" ใน CSSEdit อย่างใด เกี่ยวกับโครงการ: เป็นระบบประมวลผลภาษาธรรมชาติ (เขียนด้วย C + Python) เราได้จ้างนักเขียนเพื่อเตรียมอินพุตสำหรับระบบในภาษาต่างๆ และเมื่อเราพัฒนาซอฟต์แวร์เราต้องการนักเขียนเหล่านั้นเพื่อทำการเปลี่ยนแปลงอินพุต (บทความ) บางครั้งการเปลี่ยนแปลงมีขนาดเล็กมาก (คำหนึ่งหรือสองคำ) และบางครั้งใหญ่ เหตุผลที่เราจำเป็นต้องควบคุมเวอร์ชันการเปลี่ยนแปลงเหล่านั้นก็เพราะว่าการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ / ใหญ่ในอินพุทนั้นมีศักยภาพที่จะเปลี่ยนเอาต์พุตของระบบได้อย่างมาก

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

8
สถาปัตยกรรม MVC - ฉันต้องการคอนโทรลเลอร์จำนวนเท่าใด
ฉันได้รับการเข้ารหัสในขณะที่ แต่ส่วนใหญ่สคริปต์และโปรแกรมที่เรียบง่าย ฉันได้ย้ายไปสู่บทบาทใหม่ที่เกี่ยวข้องกับการพัฒนาเว็บแอปและใช้สถาปัตยกรรม MVC ที่เหมาะสมดังนั้นฉันจึงพยายามเรียนรู้เกี่ยวกับสิ่งเหล่านั้นอย่างรวดเร็ว ฉันหวังว่าคำถามนี้จะไม่คล้ายกับ " แนวทางปฏิบัติที่ดีที่สุดสำหรับสถาปัตยกรรม MVC " แต่เมื่อฉันทำแบบฝึกหัดที่แตกต่างกันสองสามครั้งฉันสังเกตเห็นว่าบางคนมีตัวควบคุมหลายตัวสำหรับสิ่งที่แตกต่างกัน แอปพลิเคชันเว็บเดียวต้องมีคอนโทรลเลอร์จำนวนเท่าใด ฉันรู้ว่ามันคงยากที่จะตอบโดยไม่มีตัวอย่างดังนั้นฉันจะให้: การประยุกต์ใช้: ผู้ใช้เข้าสู่ระบบ ผู้ใช้สามารถทำหนึ่งในสามสิ่งต่อไปนี้: ก) อัปโหลดไฟล์ (เก็บไว้ในฐานข้อมูล mongodb พร้อมข้อมูลเมตา) b) ค้นหาไฟล์ c) ออกจากระบบ คำถามของฉันเป็นคำถามทั่วไป แต่ฉันยกตัวอย่างเพื่อช่วยใครก็ตามที่พยายามจะตอบ

8
เป็นการดีหรือไม่ที่ผู้ทดสอบกำลังแข่งขันกันเพื่อดูว่าใครเป็นผู้เปิดบั๊กมากกว่านี้
ฉันเป็นนักพัฒนาซอฟต์แวร์ มีทีมทดสอบที่ติดตามและดำเนินการกรณีทดสอบที่เขียนโดยนักวิเคราะห์ แต่ยังดำเนินการทดสอบเชิงสำรวจ ดูเหมือนว่าผู้ทดสอบได้ทำการแข่งขันกันเพื่อดูว่าใครเปิดบั๊กมากกว่านี้และฉันสังเกตว่าคุณภาพของรายงานบั๊กลดลง แทนที่จะทดสอบการทำงานและการรายงานข้อผิดพลาดที่เกี่ยวข้องกับการทำงานของซอฟต์แวร์ผู้ทดสอบได้ส่งข้อบกพร่องเกี่ยวกับการปรับปรุงหน้าจอการใช้งานหรือข้อบกพร่องที่โง่ เป็นสิ่งที่ดีสำหรับโครงการหรือไม่ ถ้าไม่ฉันจะ (ในฐานะนักพัฒนาซอฟต์แวร์) ได้อย่างไรลองเปลี่ยนความคิดและทัศนคติของทีมทดสอบ ปัญหาอีกประการหนึ่งคือเนื่องจากกำหนดเวลาสิ้นสุดและไม่สามารถเปลี่ยนแปลงได้ดังนั้นเมื่อใกล้ถึงกำหนดผู้ทดสอบจะต้องตรวจสอบเพื่อให้เสร็จสิ้นกรณีทดสอบและจะทำให้คุณภาพของการทดสอบลดลง สิ่งนี้จะทำให้เกิดบั๊กที่ถูกกฎหมายในผลิตภัณฑ์ขั้นสุดท้ายที่ลูกค้าได้รับ OBS: การแข่งขันครั้งนี้ไม่ใช่การฝึกฝนของ บริษัท ! เป็นการแข่งขันระหว่างผู้ทดสอบเท่านั้นที่จัดโดยพวกเขาและไม่มีรางวัลใด ๆ

17
วิธีการจัดการกับความคิดเห็นซ้ำซากในความคิดเห็น? [ปิด]
บางครั้งฉันพบว่าตัวเองอยู่ในสถานการณ์ที่ส่วนหนึ่งของรหัสที่ฉันเขียนคือ (หรือดูเหมือนว่าจะเป็น ) ดังนั้นตัวเองชัดเจนว่าชื่อของมันจะถูกทำซ้ำโดยทั่วไปเป็นความคิดเห็น: class Example { /// <summary> /// The location of the update. /// </summary> public Uri UpdateLocation { get; set; }; } (ตัวอย่าง C # แต่โปรดอ้างอิงคำถามว่าเป็นผู้ไม่เชื่อเรื่องภาษา) ความคิดเห็นเช่นนั้นไร้ประโยชน์ ผมทำอะไรผิดหรือเปล่า? มันเป็นทางเลือกของชื่อที่ผิดหรือเปล่า? ฉันจะแสดงความคิดเห็นชิ้นส่วนเช่นนี้ดีกว่าได้อย่างไร ฉันควรจะข้ามความคิดเห็นสำหรับสิ่งเช่นนี้หรือไม่?

9
วิธีการของชั้นเรียนควรเรียกผู้ได้รับและผู้ตั้งตน?
ฉันทำงานที่ไหนฉันเห็นชั้นเรียนจำนวนมากที่ทำสิ่งนี้: public class ClassThatCallsItsOwnGettersAndSetters { private String field; public String getField() { return field; } public void setField(String field) { this.field = field; } public void methodWithLogic() { setField("value"); //do stuff String localField = getField(); //do stuff with "localField" } } หากฉันเขียนสิ่งนี้ตั้งแต่เริ่มต้นฉันจะเขียนสิ่งmethodWithLogic()นี้แทน: public class ClassThatUsesItsOwnFields { private String field; public …

11
ฉันจะหลีกเลี่ยงการทำรีดักชั่นแบบเรียงซ้อนได้อย่างไร?
ฉันมีโครงการแล้ว ในโครงการนี้ฉันต้องการ refactor เพื่อเพิ่มคุณสมบัติและฉัน refactored โครงการเพื่อเพิ่มคุณสมบัติ ปัญหาคือเมื่อฉันเสร็จแล้วมันกลับกลายเป็นว่าฉันต้องการที่จะทำการเปลี่ยนแปลงอินเตอร์เฟซเล็กน้อยเพื่อรองรับมัน ดังนั้นฉันจึงทำการเปลี่ยนแปลง จากนั้นคลาสการบริโภคไม่สามารถนำไปใช้กับอินเทอร์เฟซปัจจุบันในแง่ของอินเทอร์เฟซใหม่ดังนั้นมันจึงต้องการอินเทอร์เฟซใหม่เช่นกัน ตอนนี้สามเดือนต่อมาและฉันต้องแก้ไขปัญหาที่ไม่เกี่ยวข้องอย่างมากมายนับไม่ถ้วนและฉันกำลังมองหาการแก้ปัญหาที่ถูกทำแผนที่สำหรับหนึ่งปีต่อจากนี้ อีกครั้ง ฉันจะหลีกเลี่ยงการปรับลดประเภทของการเรียงซ้อนในอนาคตได้อย่างไร มันเป็นแค่อาการของชั้นเรียนก่อนหน้าของฉันซึ่งขึ้นอยู่กับแต่ละคนแน่นเกินไปหรือไม่? การแก้ไขสั้น ๆ : ในกรณีนี้ refactor เป็นคุณลักษณะเนื่องจาก refactor เพิ่มความสามารถในการขยายของโค้ดบางส่วนและลดการเชื่อมต่อบางส่วน นั่นหมายความว่าผู้พัฒนาภายนอกสามารถทำอะไรได้มากกว่าซึ่งเป็นคุณลักษณะที่ฉันต้องการนำเสนอ ดังนั้นตัวปรับเปลี่ยนดั้งเดิมเองไม่ควรเปลี่ยนฟังก์ชัน แก้ไขที่ใหญ่กว่าที่ฉันสัญญาห้าวันที่ผ่านมา: ก่อนที่ฉันจะเริ่ม refactor นี้ฉันมีระบบที่ฉันมีอินเทอร์เฟซ แต่ในการนำไปใช้นั้นฉันเพิ่งdynamic_castผ่านการใช้งานที่เป็นไปได้ทั้งหมดที่ฉันจัดส่ง เห็นได้ชัดว่านั่นหมายความว่าคุณไม่สามารถสืบทอดจากอินเทอร์เฟซสำหรับสิ่งใดสิ่งหนึ่งและอย่างที่สองว่ามันจะเป็นไปไม่ได้สำหรับทุกคนที่ไม่มีการเข้าถึงเพื่อใช้งานอินเทอร์เฟซนี้ ดังนั้นฉันตัดสินใจว่าฉันต้องการแก้ไขปัญหานี้และเปิดอินเทอร์เฟซสำหรับการบริโภคสาธารณะเพื่อให้ทุกคนสามารถใช้งานได้และการใช้อินเทอร์เฟซนั้นเป็นสัญญาทั้งหมดที่จำเป็นต้องมี - การปรับปรุงอย่างชัดเจน เมื่อฉันค้นหาและฆ่าด้วยไฟในทุกสถานที่ที่ฉันได้ทำสิ่งนี้ฉันพบที่เดียวที่พิสูจน์แล้วว่าเป็นปัญหาเฉพาะ มันขึ้นอยู่กับรายละเอียดการใช้งานของคลาสที่ได้รับมาทั้งหมดและฟังก์ชั่นการทำซ้ำที่มีการใช้งานแล้ว แต่ดีกว่าที่อื่น มันอาจถูกนำมาใช้ในแง่ของอินเทอร์เฟซสาธารณะแทนและนำมาใช้ใหม่การใช้งานที่มีอยู่ของฟังก์ชั่นนั้น ฉันค้นพบว่ามันจำเป็นต้องใช้บริบทบางอย่างในการทำงานอย่างถูกต้อง พูดโดยประมาณการเรียกใช้งานก่อนหน้านี้ดูเหมือนจะเป็นไปได้ for(auto&& a : as) { f(a); } อย่างไรก็ตามเพื่อให้ได้บริบทนี้ฉันต้องเปลี่ยนมันเป็นอะไรที่มากกว่า std::vector<Context> contexts; for(auto&& a …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.