“ Soft Coding” คืออะไรจริงๆ?

ในบทความนี้โดย Alex Papadimoulis คุณสามารถดูตัวอย่างนี้:

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {

    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

ฉันไม่เข้าใจบทความนี้จริงๆ

ฉันพูด:

ถ้าทุกคนคงกฎทางธุรกิจที่ถูกเก็บไว้ในแฟ้มการกำหนดค่าบางอย่างในชีวิตจะมาก [มากขึ้น ( sic )] เป็นเรื่องยากสำหรับทุกคนที่ยังคงรักษาซอฟต์แวร์: มันน่าจะมีไฟล์จำนวนมากรหัสที่ใช้ร่วมกันหนึ่งไฟล์ขนาดใหญ่ (หรือ, การสนทนา, มีไฟล์กำหนดค่าเล็ก ๆ จำนวนมาก); การปรับใช้การเปลี่ยนแปลงกับกฎเกณฑ์ทางธุรกิจไม่จำเป็นต้องใช้รหัสใหม่ แต่การเปลี่ยนไฟล์กำหนดค่าด้วยตนเอง และการดีบั๊กนั้นยากกว่ามาก

นี่คืออาร์กิวเมนต์ที่มีจำนวนเต็มคงที่ "500000" ในไฟล์กำหนดค่าหรือ "AUTHCNS-1A" และค่าคงที่สตริงอื่น ๆ

นี่เป็นวิธีที่ไม่ดีได้อย่างไร

ในตัวอย่างนี้ "500000" ไม่ใช่ตัวเลข ตัวอย่างเช่นไม่ใช่:

int doubleMe(int a) { return a * 2;}

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

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

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

นอกจากนี้หากวันพรุ่งนี้รัฐบาลเรียกร้องให้ "ตั้งแต่วันที่ 5/3/2550 คุณต้องเพิ่ม AUTHLDG-122B แทน AUTHLDG-1A" ค่าคงที่สตริงนี้ไม่ใช่ค่าคงที่สตริงที่เรียบง่าย มันเป็นสิ่งที่แสดงถึงความคิด เป็นเพียงมูลค่าปัจจุบันของแนวคิดนั้น (ซึ่งก็คือ "สิ่งที่คุณเพิ่มถ้าบัญชีแยกประเภทสูงกว่า 500k")

ให้ฉันอธิบาย ฉันไม่ได้บอกว่าบทความผิด ฉันแค่ไม่เข้าใจ อาจจะอธิบายไม่ดีเกินไป (อย่างน้อยก็สำหรับความคิดของฉัน)

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

ผู้เขียนได้เตือนถึงสิ่งที่เป็นนามธรรมก่อนวัยอันควร

บรรทัดif (ledgerAmt > 500000)ดูเหมือนกฎเกณฑ์ทางธุรกิจที่คุณคาดว่าจะเห็นสำหรับระบบธุรกิจขนาดใหญ่ที่มีความต้องการซับซ้อนอย่างเหลือเชื่อ แต่แม่นยำและได้รับการบันทึกไว้อย่างดี

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

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

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

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

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

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

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

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

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

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

นอกจากนี้ในวันพรุ่งนี้รัฐบาลจะไป "ตั้งแต่วันที่ 5/3/2550 คุณต้องเพิ่ม AUTHLDG-122B แทน AUTHLDG-1A"

ใช่แล้วคุณเปลี่ยนรหัส จุดของบทความคือมันไม่ซับซ้อนในการเปลี่ยนรหัสมากกว่าการเปลี่ยนไฟล์การกำหนดค่า

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

คุณจะรู้ได้อย่างไรว่าคุณจะไม่ต้องการมันในภายหลัง หรือคนอื่นสำหรับเรื่องนั้น?

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

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

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

บทความจะกล่าวถึง 'Enterprise Rule Engine ซึ่งอาจเป็นตัวอย่างที่ดีกว่าของสิ่งที่เขาโต้เถียง

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

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

<statecode id="AZ">
    <document id="SR008-04X"/>
    <document id="SR008-04XI"/>
</statecode>

บางทีคุณอาจจะใส่จำนวนบัญชีแยกประเภทด้วย?

<statecode id="ALL">
    <document id="AUTHLDG-1A" rule="ledgerAmt >= 50000"/>
</statecode>

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

ควรสังเกตว่าบทความนี้มาจาก 2007 เมื่อสิ่งประเภทนี้เป็นวิธีการทั่วไป

ทุกวันนี้เราอาจจะแก้ปัญหาด้วยการพึ่งพาการฉีด (DI) เช่นคุณจะมี 'รหัสยาก'

InvoiceRules_America2007 : InvoiceRules

ซึ่งคุณจะแทนที่ด้วยฮาร์ดโค้ดหรือกำหนดค่าได้มากกว่า

InvoiceRules_America2008 : InvoiceRules

เมื่อกฎหมายหรือข้อกำหนดทางธุรกิจเปลี่ยนไป

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

และนั่นแสดงโดยมี (และฉันสามารถโต้แย้งได้ว่าแม้แต่ความคิดเห็นซ้ำซ้อน):

 if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

นี่เป็นเพียงการทำซ้ำสิ่งที่รหัสกำลังทำอยู่:

LEDGER_AMOUNT_REQUIRING_AUTHLDG1A=500000
if (ledgerAmnt >= LEDGER_AMOUNT_REQUIRING_AUTHLDG1A) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
}

โปรดทราบว่าผู้เขียนสันนิษฐานว่าความหมายของ 500,000 คือผูกกับกฎนี้ มันไม่ใช่ค่าที่เป็นหรือน่าจะนำกลับมาใช้ที่อื่น:

กฎทางธุรกิจเพียงข้อเดียวที่เปลี่ยนแปลงก่อนหน้านี้การเข้ารหัสแบบซอฟต์ก่อนหน้านี้อาจจะมีผลต่อการเปลี่ยนแปลงในจำนวนบัญชีแยกประเภทที่ต้องใช้ฟอร์ม AUTHLDG-1A การเปลี่ยนแปลงกฎธุรกิจอื่น ๆ จะต้องมีการทำงานมากขึ้น - การกำหนดค่าเอกสารรหัส ฯลฯ

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

คำตอบอื่น ๆ นั้นถูกต้องและรอบคอบ แต่นี่คือคำตอบสั้น ๆ และหวานของฉัน

  Rule/value          |      At Runtime, rule/value…
  appears in code:    |   …Is fixed          …Changes
----------------------|------------------------------------
                      |                 |
  Once                |   Hard-code     |   Externalize
                      |                 |   (soft-code)
                      |                 |
                      |------------------------------------
                      |                 |
  More than once      |   Soft-code     |   Externalize
                      |   (internal)    |   (soft-code)
                      |                 |
                      |------------------------------------

หากกฎและค่าพิเศษปรากฏในที่เดียวในรหัสและไม่เปลี่ยนแปลงระหว่างรันไทม์ให้ใช้รหัสยากตามที่แสดงในคำถาม

หากกฎหรือค่าพิเศษปรากฏในที่มากกว่าหนึ่งแห่งในรหัสและไม่เปลี่ยนแปลงระหว่างรันไทม์ให้ใช้รหัสอ่อน ซอฟท์โค้ดสำหรับกฎฉันอาจกำหนดเฉพาะระดับ / วิธีการหรือใช้รูปแบบการสร้าง สำหรับค่าการเข้ารหัสแบบนุ่มนวลอาจหมายถึงการกำหนดค่าคงที่เดียวหรือค่า enum สำหรับค่าที่จะใช้กับรหัสของคุณ

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

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

ในตัวอย่างที่กำหนดมันไม่ได้ทำให้เกิดความแตกต่างเล็กน้อยว่าค่าที่ให้นั้นเป็นฮาร์ดโค้ดเป็นค่าอินไลน์หรือกำหนดเป็น const

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

ดูว่าหากมีรหัสอยู่รอบ ๆ สิ่งที่ไม่ดีจะเกิดขึ้นอย่างชัดเจน

สิ่งที่เลวร้ายอันดับแรกคือมูลค่า 50000 จะถูกนำไปใช้กับค่าอื่นที่บางแห่งกล่าวว่าจำนวนเงินในบัญชีแยกประเภทที่เปลี่ยนแปลงอัตราภาษีในบางรัฐ ... จากนั้นเมื่อมีการเปลี่ยนแปลงเกิดขึ้นผู้ดูแลไม่มีทางรู้เมื่อเขาพบว่า สองอินสแตนซ์ของ 50,000 ในโค้ดไม่ว่าจะหมายถึง 50k เดียวกันหรือ 50ks ที่ไม่เกี่ยวข้องทั้งหมด และคุณควรค้นหา 49999 และ 5,0001 ในกรณีที่มีคนใช้ค่าคงที่ด้วยหรือไม่ นี่ไม่ใช่การเรียกร้องให้ plonk ตัวแปรเหล่านั้นในไฟล์ปรับแต่งของบริการที่แยกต่างหาก: แต่ควรเป็นค่าคงที่กำหนดและกำหนดขอบเขตภายในคลาสหรือไฟล์ที่ใช้ หากสองอินสแตนซ์ของ 50k ใช้ค่าคงที่เดียวกันพวกเขาก็น่าจะเป็นตัวแทนของข้อ จำกัด ทางกฎหมายเดียวกัน ถ้าไม่พวกเขาอาจไม่; และทั้งสองวิธีพวกเขาจะมีชื่อ

ชื่อไฟล์จะถูกส่งผ่านไปยังฟังก์ชั่น - attachDocument () - ซึ่งยอมรับชื่อไฟล์ฐานเป็นสตริงโดยไม่มีเส้นทางหรือส่วนขยาย ชื่อไฟล์โดยพื้นฐานแล้วคือคีย์ต่างประเทศในบางระบบไฟล์หรือฐานข้อมูลหรือที่ใดก็ตามที่ AttachDocument () รับไฟล์จาก แต่สายไม่ได้บอกอะไรคุณเกี่ยวกับเรื่องนี้ - มีกี่ไฟล์? ไฟล์ประเภทใด คุณจะรู้ได้อย่างไรว่าเมื่อคุณเปิดตลาดใหม่ไม่ว่าคุณจะต้องอัพเดตฟังก์ชั่นนี้หรือไม่? พวกเขาสามารถแนบกับสิ่งประเภทใดได้บ้าง ผู้ดูแลถูกทิ้งให้อยู่ในความมืดมิดและสิ่งที่เขามีคือสตริงซึ่งอาจปรากฏหลายครั้งในรหัสและหมายถึงสิ่งต่าง ๆ ทุกครั้งที่ปรากฏ ในที่เดียว "SR008-04X" เป็นรหัสโกง อีกอย่างหนึ่งก็คือคำสั่งให้สั่งจรวดเสริม SR008 สี่ตัว ที่นี่มัน ' ชื่อไฟล์ สิ่งเหล่านี้เกี่ยวข้องกันหรือไม่? มีคนเพิ่งเปลี่ยนฟังก์ชั่นนั้นเพื่อพูดถึงไฟล์อื่น "ลูกค้า" จากนั้นคุณผู้ดูแลที่ไม่ดีได้รับแจ้งว่าไฟล์ "ลูกค้า" ต้องเปลี่ยนชื่อเป็น "ลูกค้า" แต่สตริง "ลูกค้า" ปรากฏขึ้น 937 ครั้งในรหัส ... คุณจะเริ่มมองหาที่ไหน?

ปัญหาของเล่นคือค่าที่มีความผิดปกติและสามารถรับประกันสมควรจะไม่ซ้ำกันในรหัส ไม่ใช่ "1" หรือ "10" แต่ "50,000" ไม่ใช่ "ลูกค้า" หรือ "รายงาน" แต่ "SR008-04X"

ตัวแทนเชิดคือเพียงวิธีการอื่น ๆ ในการแก้ไขปัญหาของค่าคงที่ทึบแสง impenetrably คือการรังพวกเขาออกลงในไฟล์ config ของการบริการที่ไม่เกี่ยวข้องบางส่วน

คุณสามารถใช้ข้อผิดพลาดสองข้อนี้เพื่อพิสูจน์ว่าเป็นจริงได้

มีหลายประเด็นในเรื่องนี้

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

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

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

เช่นเดียวกับค่าคงที่เป็นส่วนตัวจึงไม่สามารถนำไปใช้ในที่อื่นในรหัสได้

จากนั้นมีรายการกฎทั้งหมดและใช้รายการ

ปัญหาเพิ่มเติมคือวิธีจัดการค่าคงที่ 500,000 อาจดูไม่เด่น แต่ต้องใช้ความระมัดระวังเป็นอย่างมากเพื่อให้แน่ใจว่าแปลงได้อย่างถูกต้อง หากใช้การคำนวณเลขทศนิยมใด ๆ มันอาจถูกแปลงเป็น 500,000.00001 ดังนั้นการเปรียบเทียบกับ 500,000.00000 อาจล้มเหลว หรือแย่ลง 500,000000 ทำงานได้ตามปกติ แต่อย่างใด 565000 ล้มเหลวเมื่อแปลง ตรวจสอบให้แน่ใจว่าการแปลงนั้นชัดเจนและคุณไม่ต้องเดาโดยคอมไพเลอร์ บ่อยครั้งสิ่งนี้ทำได้โดยการแปลงเป็น BigInteger หรือ BigDecimal ก่อนที่จะถูกใช้

แม้ว่าจะไม่ได้กล่าวถึงในคำถามโดยตรง แต่ฉันต้องการทราบว่าสิ่งที่สำคัญไม่ควรทำ ฝังตรรกะทางธุรกิจไว้ในโค้ด

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

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

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

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