การปฏิบัติที่ไม่ดี - สลับกรณีเพื่อตั้งค่าสภาพแวดล้อม

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

ตัวอย่างด้านหลัง (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

ตัวอย่างหน้า (JavaScript):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

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

ใครสามารถอธิบายข้อดีข้อเสียของการฝึกซ้อมข้างต้นได้บ้าง?

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

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

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

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

คุณคิดถูกว่านี่เป็นการฝึกฝนที่ไม่ดี ฉันเคยเห็นสิ่งนี้ในรหัสการผลิตและมันกลับมากัดคุณอยู่เสมอ

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

การกำหนดค่าควรถูกบังคับจากรหัสและในสภาพแวดล้อมเอง มันเป็นหลักการของแอพ Twelve-Factor ( http://12factor.net/config ) แต่เป็นวิธีปฏิบัติที่ดีสำหรับแอปพลิเคชันใด ๆ คุณอาจพบว่าตัวแปรสภาพแวดล้อมไม่เหมาะกับสถานการณ์ของคุณซึ่งในกรณีนี้ฉันขอแนะนำให้ดูที่การจัดเก็บการกำหนดค่านั้นในฐานข้อมูลของไฟล์การตั้งค่าพร้อมกับโค้ด (แต่ไม่ได้เช็คอินด้วย) รหัส

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

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

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

ข่าวร้ายหมี

ที่ดีที่สุดสิ่งที่จะต้องทำคือการตั้งค่าของคุณจากสภาพแวดล้อม (เช่นในคำตอบที่เชื่อมโยงก่อนหน้านี้สิบสองปัจจัย App มีคำแนะนำที่ดีในหัวข้อ) มีหลายวิธีในการทำเช่นนี้ขึ้นอยู่กับภาษาของคุณ หนึ่งในวิธีที่ง่ายที่สุด (ปกติ) คือการตั้งค่าตัวแปรสภาพแวดล้อม จากนั้นคุณเพียงแค่เปลี่ยนตัวแปรตามตำแหน่งที่คุณใช้งานไม่ว่าจะเป็นกล่อง dev ท้องถิ่น qa หรือการผลิต ตัวเลือกอื่นคือการจัดเก็บค่าใน.iniไฟล์หรือ JSON อีกทางเลือกหนึ่งจะเก็บค่าการกำหนดค่าของคุณเป็นรหัสจริง ขึ้นอยู่กับภาษาหรือสภาพแวดล้อมที่คุณใช้สิ่งนี้อาจจะใช่หรือไม่ใช่ความคิดที่ดี

แต่เป้าหมายสูงสุดคือการให้คุณใช้ฐานรหัสหนึ่งวางลงบนใด ๆเครื่องที่มีการสนับสนุนสถาปัตยกรรม / การเชื่อมต่อและสามารถทำงานได้โดยไม่ต้องปรับเปลี่ยนรหัสในทางใดทางหนึ่ง

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

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

มันเป็นการปฏิบัติที่ไม่ดี

หลักการพื้นฐานของการออกแบบซอฟต์แวร์: อย่ากำหนดค่าฮาร์ดโค้ดในโปรแกรมของคุณ นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งสำหรับทุกสิ่งที่มีโอกาสพอสมควรในการเปลี่ยนแปลงในอนาคต

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

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

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

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

รหัสสิ่งที่ถูกต้องที่สุดเท่าที่จะทำได้ มีโอกาสน้อยที่จะกลายเป็นปัญหาในภายหลัง