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

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

ความคิดเห็นในรหัส

ฉันแค่หวังว่าอาจารย์มหาวิทยาลัยจะเข้าใจว่าพวกเขาไม่จำเป็นต้องสอนให้นักเรียนเขียนความคิดเห็น 10 บรรทัดโดยบอกว่ารหัสต่อไปนี้เป็นวงวนซ้ำจาก 1 เป็นจำนวน x ฉันเห็นว่าในรหัส!

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

รูปแบบการออกแบบเดี่ยว

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

สิ่งที่ชั่วร้ายที่สุดในการปกป้องการเขียนโปรแกรมโง่ วางทุกอย่างในการลองจับและไม่ทำอะไรเลยกับการจับ

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

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

พึ่งพา StackOverflow เพื่อแก้ปัญหาของคุณแทนที่จะหาวิธีที่ยาก

โปรแกรมเมอร์ใหม่ที่ค้นหาความรู้มากมายเกี่ยวกับโพสต์ SO (บ่อยเกินไป) ก่อนที่จะคิดและทดลองใช้

ในวันของฉันเราต้องใช้รหัสจากหนังสือไม่มีอินเทอร์เน็ตไม่มี ตอนนี้ลงจากสนามหญ้าของฉัน

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

อีกสิ่งหนึ่งคือ (ใน Perl เช่นกัน) OOP มักจะเขียนสิ่งเดียวกันด้วยวิธีอื่น: result = $object ->function(pars)แทนที่จะเป็นแบบresult = function(object, pars)นี้บางครั้งก็สมเหตุสมผล แต่เมื่อผสมกับการเขียนโปรแกรมตามขั้นตอนก็สามารถทำให้การอ่านรหัสค่อนข้างสับสน และนอกเหนือจากนั้นคุณเพียงแค่แนะนำค่าใช้จ่ายเพิ่มเติมซึ่งไม่ได้ปรับปรุงการออกแบบ มันมาถึงสิ่งที่พูดเกี่ยวกับรูปแบบซิงเกิลเช่นกัน: ควรใช้ แต่ไม่ใช่ทุกอย่าง

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

ต้องใช้เวลาหลายปีใน ASP.NET Webforms ฉันต้องพูดอย่างแจ่มแจ้ง:

Smart UI

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

Steve Sanderson อธิบายรูปแบบการต่อต้านนี้ดีกว่าที่ฉันสามารถทำได้ในหนังสือ Pro ASP.NET MVC ของเขา:

ในการสร้างแอปพลิเคชัน Smart UI ผู้พัฒนาจะสร้าง UI เป็นอันดับแรกโดยการลากชุดของวิดเจ็ต UI ลงบนผืนผ้าใบจากนั้นเติมรหัสตัวจัดการเหตุการณ์สำหรับการคลิกแต่ละปุ่มที่เป็นไปได้หรือเหตุการณ์ UI อื่น ๆ แอปพลิเคชันตรรกะทั้งหมดอยู่ในตัวจัดการเหตุการณ์เหล่านี้: ตรรกะเพื่อยอมรับและตรวจสอบความถูกต้องของผู้ใช้เพื่อดำเนินการเข้าถึงข้อมูลและจัดเก็บข้อมูลและเพื่อให้ข้อเสนอแนะโดยการอัพเดต UI แอปพลิเคชันทั้งหมดประกอบด้วยตัวจัดการเหตุการณ์เหล่านี้ โดยพื้นฐานแล้วนี่คือสิ่งที่มีแนวโน้มที่จะเกิดขึ้นตามค่าเริ่มต้นเมื่อคุณวางสามเณรไว้ด้านหน้า Visual Studio ในการออกแบบนี้ไม่มีข้อกังวลใด ๆ เลย ทุกอย่างถูกหลอมรวมเข้าด้วยกันซึ่งจัดเรียงในแง่ของเหตุการณ์ UI ที่อาจเกิดขึ้นเท่านั้น เมื่อจำเป็นต้องใช้ตรรกะหรือกฎธุรกิจในตัวจัดการมากกว่าหนึ่งตัวรหัสมักจะถูกคัดลอกและวาง หรือบางส่วนที่เลือกแบบสุ่มถูกแยกออกเป็นคลาสยูทิลิตี้คงที่ ด้วยเหตุผลที่ชัดเจนมากมายรูปแบบการออกแบบชนิดนี้มักเรียกว่าการต่อต้านแบบ

ฉันเห็นสิ่งนี้เป็นครั้งคราวและมักเป็นผลมาจากการไม่เข้าใจนิพจน์บูลีน

if (someCondition == true)

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

มรดก

อย่าบังคับใช้ - เป็นสิ่งที่ไม่สมเหตุสมผล

การปรับแต่งซอฟต์แวร์ off-the-shelf

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

ใช้ complier เป็นดีบักเกอร์

ไม่สนใจคำเตือนผู้ใช้หรือปิดอย่างสมบูรณ์

ตัวแปรทั่วโลก

รูปแบบการออกแบบทั้งหมด

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

อย่าเข้าใจฉันผิด รูปแบบการออกแบบเป็นเทคนิคที่ยอดเยี่ยม ฉันใช้มันเยอะมาก แต่บางครั้งฉันพบโปรแกรมเมอร์ (บางคนเป็นเจ้านายเก่าของฉัน) ซึ่งมี "คุณต้องใช้รูปแบบการออกแบบ" แม้ว่าจะไม่ตรงกับปัญหา !!!

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

ฉันหวังว่ามันจะเพิ่มเป็นรูปแบบใหม่ให้กับหนังสือที่มีอยู่ในหนังสือ "Design Patterns" รุ่นใหม่

ใช้ข้อยกเว้นเป็นการควบคุมการไหล เรียงคล้ายกับคำตอบนี้แต่แตกต่างกัน

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

การจัดการข้อยกเว้นควรใช้เพื่อจัดการสถานการณ์พิเศษ (duh), สถานการณ์ที่ไม่คาดฝันอย่างแท้จริงเท่านั้นไม่ใช่สิ่งที่ผู้ใช้พิมพ์ด้วยตัวอักษรที่เป็นตัวอักษรซึ่งคาดว่าจะมีตัวเลข การใช้ข้อยกเว้นในทางที่ผิดนี้เป็นเรื่องธรรมดาอย่างมากในหมู่โปรแกรมเมอร์ที่ไม่ดีในโลกของ Java

ฉันจะไปด้วยความยืดหยุ่นผ่านการซ่อนข้อมูลมากเกินไป

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

ปัญหาคือเช่นเดียวกับปัญหาการค้นพบที่สมดุลสำหรับทุกบริบทมันต้องอาศัยประสบการณ์

เปิดเผยอาร์เรย์ภายใน

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

ตามhttp://www.oracle.com/technetwork/java/seccodeguide-139067.html

คัดลอกวัตถุที่ไม่แน่นอนก่อนที่จะกลับมาเว้นแต่ว่ามีเจตนาที่จะแบ่งปันรัฐ

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

ตัวอย่างเช่นสิ่งนี้นำมาโดยตรงจากเธรด StackOverflow:

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

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

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

ไม่มีลูปและไม่มีสถานะที่ไม่แน่นอน ก็โอเคไม่มีลูปอย่างชัดเจนและไม่มีตัวนับลูป

รหัสสั้นลงง่ายกว่ามากเหมือนคำอธิบายของรหัสที่ควรทำ (โดยเฉพาะอย่างยิ่งในกรณีทับทิมมันบอกว่า "จัดกลุ่มตามประเภท") โดยตรงและมีข้อผิดพลาดน้อยกว่ามาก ไม่มีอันตรายจากการวิ่งออกจากจุดสิ้นสุดของอาเรย์, ข้อผิดพลาดของโพสต์รั้วหรือข้อผิดพลาดแบบ off-one กับดัชนีลูปและเงื่อนไขการยกเลิกเนื่องจากไม่มีดัชนีลูปและเงื่อนไขการเลิกจ้าง

ซึ่งจำลอง. มันแนะนำข้อกำหนดทางประดิษฐ์ที่มากเกินไปสำหรับการแยก decoupling ในรหัสของคุณมากเกินไปนำไปสู่รหัสราวีโอลี่ที่ overengineered และบังคับให้ออกแบบสไตล์ OO ลงไปที่คอของคุณเมื่อการออกแบบขั้นตอนหรือการทำงานมากขึ้น

โปรแกรมเมอร์ Delphi ทั่วโลกได้รับการค้นพบในช่วงสองปีที่ผ่านมาว่ามันแย่แค่ไหนที่จะใช้อาร์เรย์อักขระเพื่อจัดเก็บไบต์เนื่องจากการแปลง Unicode แบบ wholescale

และ "เร็ว ๆ นี้" เราจะเรียนรู้ว่าการเก็บจำนวนเต็มในรายการไม่ดีเมื่อเราต้องการเปลี่ยนแปลงเป็น 64 บิตเป็นอย่างไร

คุณสมบัติ. ฉันรู้ว่านี่เป็นการโต้เถียง แต่ฉันรู้สึกว่ามีการใช้คุณสมบัติมากเกินไปใน. net

ความแตกต่างระหว่างสองบรรทัดนี้คืออะไร?

public string Property { get; set; }

public string Field;

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