การฝึกเขียนโปรแกรมแบบใดที่คุณเคยชอบทำให้คุณเปลี่ยนใจ? [ปิด]

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

ตัวอย่างของการปฏิบัติผมเคยใช้ค่อนข้างบ่อย แต่มีในปีที่ผ่านมามีการเปลี่ยนแปลงคือการใช้ของรูปแบบวัตถุซิงเกิล

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

คำถามของฉันต่อชุมชนด้วยจิตวิญญาณของการพัฒนาตนเองคือ:

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

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

จุดคืนเดียว

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

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

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

ในคำเดียวการกลั่นมากเกินไป

สัญกรณ์ฮังการี (ทั้งแบบฟอร์มและระบบ) ฉันใช้คำนำหน้าทุกอย่าง strSomeString หรือ txtFoo ตอนนี้ฉันใช้ someString และ textBoxFoo มันอ่านง่ายกว่าและง่ายกว่าสำหรับคนใหม่ที่จะมารับ ในฐานะที่เป็นโบนัสเพิ่มเติมมันเป็นเรื่องเล็กน้อยที่จะทำให้มันมีความสม่ำเสมอ - อูฐกำหนดขอบเขตการควบคุมและต่อท้ายชื่อที่มีประโยชน์ / เป็นคำอธิบาย Forms Hungarian มีข้อเสียตรงที่ความไม่สอดคล้องกันเสมอไปและ Systems Hungarian ก็ไม่ได้ให้ประโยชน์อะไรกับคุณมากนัก การรวมตัวแปรทั้งหมดของคุณเข้าด้วยกันไม่ได้มีประโยชน์จริงๆโดยเฉพาะอย่างยิ่งกับ IDE ที่ทันสมัย

สถาปัตยกรรมที่ "สมบูรณ์แบบ"

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

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

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

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

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

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

การใช้คำสั่ง #region มากเกินไป / ไม่เหมาะสม มันเป็นแค่เรื่องเล็กน้อย แต่ใน C # ก่อนหน้านี้ฉันจะใช้ #region directives ทั่วทุกที่เพื่อจัดระเบียบชั้นเรียน ตัวอย่างเช่นฉันจะจัดกลุ่มคุณสมบัติคลาสทั้งหมดเข้าด้วยกันในภูมิภาค

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

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

ไม่เคยขัดข้อง

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

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

รูปแบบ "ไม่พัง" ที่ฉันชอบคือ:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

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

ฉันคิดว่ามันสมเหตุสมผลแล้วที่จะใช้รูปแบบการออกแบบทุกครั้งที่ฉันจำได้

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

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

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

จริง ๆ แล้วการยึดติดกับสิ่งใด ๆ อย่างไม่เป็นระเบียบอาจเป็นอันตรายได้

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

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

(โปรดทราบว่าสิ่งนี้ไม่เหมือนกับการไม่มีสไตล์ที่สอดคล้องกันฉันคิดว่าสไตล์ที่สอดคล้องกันในโค้ดเบสมีความสำคัญมากสำหรับความสามารถในการอ่าน)

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

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

ในความเป็นจริงฉันเพิ่งสร้างเนมสเปซขนาดใหญ่ที่มีฟังก์ชันการทำงานที่จัดระเบียบไม่ดีจำนวนมาก

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

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

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

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

การย่อตัวแปร / วิธีการ / ตาราง / ... ชื่อ

ฉันเคยทำสิ่งนี้มาตลอดแม้ว่าจะทำงานในภาษาที่ไม่มีการบังคับใช้กับความยาวของชื่อ (อาจเป็น 255 หรือบางอย่าง) ผลข้างเคียงอย่างหนึ่งคือความคิดเห็นจำนวนมากที่ทิ้งเกลื่อนกลาดตลอดรหัสที่อธิบายตัวย่อ (ไม่เป็นมาตรฐาน) และแน่นอนว่าหากเปลี่ยนชื่อไม่ว่าจะด้วยเหตุผลใดก็ตาม ...

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

การห่อคอมโพเนนต์การเข้าถึงข้อมูลที่มีอยู่เช่นไลบรารีขององค์กรด้วยชั้นวิธีการตัวช่วยที่กำหนดเอง

• มันไม่ได้ทำให้ชีวิตของใครง่ายขึ้น
• รหัสเพิ่มเติมที่สามารถมีข้อบกพร่องได้
• หลายคนรู้วิธีใช้คอมโพเนนต์การเข้าถึงข้อมูล EntLib ไม่มีใครนอกจากทีมงานในพื้นที่รู้วิธีใช้โซลูชันการเข้าถึงข้อมูลภายในองค์กร

ฉันเคยได้ยินเกี่ยวกับการเขียนโปรแกรมเชิงวัตถุเป็นครั้งแรกในขณะที่อ่านเกี่ยวกับ Smalltalk ในปี 1984 แต่ฉันไม่สามารถเข้าถึงภาษา oo ได้จนกว่าฉันจะใช้คอมไพเลอร์ cfront C ++ ในปี 1992 ในที่สุดฉันก็ใช้ Smalltalk ในปี 1995 ฉันคาดหวังไว้อย่างใจจดใจจ่อ oo เทคโนโลยีและซื้อแนวคิดที่ว่าจะช่วยประหยัดการพัฒนาซอฟต์แวร์

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

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

ใน C # โดยใช้ _notationสำหรับสมาชิกส่วนตัว ตอนนี้คิดว่าน่าเกลียด

จากนั้นฉันก็เปลี่ยนเป็นthis.notationสำหรับสมาชิกส่วนตัว แต่พบว่าฉันไม่สอดคล้องกันในการใช้งานดังนั้นฉันจึงทิ้งสิ่งนั้นไปด้วย

ฉันหยุดใช้วิธีการออกแบบที่มหาวิทยาลัยแนะนำก่อนนำไปใช้ การทำงานในระบบที่วุ่นวายและซับซ้อนทำให้ฉันต้องเปลี่ยนทัศนคติ

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

โค้ดจะไม่ดูทั้งหมดที่คุณคิดว่าตอนแรกจะมีหน้าตาเป็นอย่างไร เกิดขึ้นทุกครั้ง :)

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

ฉันจะใช้สแตติกส์ในหลายวิธี / คลาสเพราะมันกระชับกว่า เมื่อฉันเริ่มเขียนแบบทดสอบการฝึกฝนนั้นเปลี่ยนไปเร็วมาก

ตรวจสอบข้อยกเว้น

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

แน่นอนว่ามันกลายเป็นเรื่องยุ่งเหยิงในทางปฏิบัติ จนถึงจุดที่มีไลบรารีในปัจจุบันเช่น Spring JDBC ซึ่งซ่อนข้อยกเว้นการตรวจสอบแบบดั้งเดิมไว้เป็นหนึ่งในคุณสมบัติหลัก

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

ตั้งแต่นั้นมาฉันได้ชื่นชมภาษาต่างๆมากมายและประโยชน์ / ฟังก์ชันที่พวกเขานำเสนอ ถ้าฉันต้องการโค้ดอะไรเล็ก ๆ - เร็ว ๆ - ฉันจะใช้ Python ถ้าฉันต้องการทำงานในโปรเจ็กต์ขนาดใหญ่ฉันจะเขียนโค้ดใน C ++ หรือ C # ถ้าผมต้องการที่จะพัฒนาเนื้องอกในสมองฉันจะรหัสในPerl

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

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

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

กำลังเริ่มต้นสมาชิกชั้นเรียนทั้งหมด

ฉันเคยเริ่มต้นสมาชิกชั้นเรียนทุกคนอย่างชัดเจนด้วยบางสิ่งโดยปกติจะเป็น NULL ฉันได้ตระหนักว่าสิ่งนี้:

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

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

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