มูลค่าที่แท้จริงของรูปแบบรหัสที่สอดคล้องกันคืออะไร


47

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

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

ตัวอย่างที่ 1 (ฟังก์ชั่นอินไลน์แบบครั้งเดียว)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

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

ตัวอย่างที่ 2 (ฟังก์ชันที่ไม่ถูกผูก)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

นี่คือวิธีที่เรามักจะทำ (หลีกเลี่ยงการผ่านรัฐและอุปกรณ์ประกอบฉาก):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

แม้ว่ารูปแบบการเข้ารหัสเหล่านี้จะถูกต้องในทางเทคนิค แต่ก็ไม่สอดคล้องกับส่วนที่เหลือของ codebase หรือสไตล์และรูปแบบที่ Facebook (ผู้เขียน React) แนะนำในบทช่วยสอนและตัวอย่าง

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

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

คำถาม:

คุณค่าที่ลูกค้ารับรู้และผู้พัฒนาการบำรุงรักษาของฐานรหัสที่สอดคล้องกันคืออะไรและช่วยให้ความไม่สอดคล้องกันเช่นนี้จะยังคงอยู่และอาจแพร่กระจาย?


50
ค่าของการันต์ที่สอดคล้องกันคืออะไร? ถาวรความเร็วคงที่ในการอ่านและการเขียนข้อความ มูลค่าของรูปแบบรหัสที่สอดคล้องคืออะไร? รหัสการอ่านและการเขียนที่รวดเร็วและสม่ำเสมอ คุณต้องการอะไรอีก
Kilian Foth

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

1
โจเอลมีความคิดที่ดีในหัวข้อนั้น ในระยะสั้นมาตรฐานการเข้ารหัสที่ดีทำให้ข้อบกพร่องดูง่าย joelonsoftware.com/articles/Wrong.html

13
ฉันต้องการเพิ่มฟังก์ชั่นที่ตั้งชื่อไว้มักจะชอบฟังก์ชั่นที่ไม่ระบุชื่อใน JavaScript เมื่อแก้จุดบกพร่องนี้จะช่วยให้ตันเพื่อตรวจสอบว่าคุณอยู่ที่ไหนในกอง
Mike McMahon

1
@yoniLavi คุณควรถามใน meta
RubberDuck

คำตอบ:


48

ข้อได้เปรียบในการโอนรหัส

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

ปัญหาความเข้ากันได้ย้อนหลังที่อาจเกิดขึ้น

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

สมาชิกใหม่ในทีมเริ่มต้นทำงานได้เร็วขึ้น

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

ปัญหาที่ยังไม่ถูกค้นพบ

อาจมีปัญหาในอนาคตที่คุณยังไม่ได้ค้นพบด้วยวิธีการของคุณที่ได้รับการแก้ไขโดยวิธีการของผู้เขียน

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


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

2
+1 "rather than teaching new patterns"- การฝึกอบรมตามขั้นตอนเป็นช่วงเวลาที่มีขนาดใหญ่มากพร้อมพนักงานใหม่ พยายามลดค่าใช้จ่ายให้น้อยที่สุดโดยการ
แบก

1
@Alexus: เกี่ยวกับความเข้ากันได้ย้อนหลัง React ยังไม่อยู่ในรุ่น 1.0 เวอร์ชันปัจจุบัน 0.13 ทำลายความเข้ากันได้ในรูปแบบที่รุนแรงแม้ว่าความล้มเหลวเหล่านี้จะเกิดขึ้นหรือไม่นั้นขึ้นอยู่กับกลไกที่ใช้เรียกส่วนประกอบของ React การมีกฎที่สอดคล้องกันมากสำหรับวิธีเรียกใช้ React อาจไม่ป้องกันการอัพเกรด React จากการแตกรหัส แต่การแก้ไขรหัสที่สอดคล้องนั้นง่ายกว่าเร็วขึ้นและเชื่อถือได้มากกว่า ความกังวลของคุณเกี่ยวกับปัญหาความเข้ากันได้แบบย้อนหลังนั้นเป็นสิ่งที่สมเหตุสมผลในกรณีของ React เช่นดูความคิดเห็นของฉันในstackoverflow.com/a/20913637/18192
Brian

53

ไม่สอดคล้องกันทำให้คุณหยุดและคิดว่าทำไม , ซึ่งและที่ :

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

    ทวีคูณโดยนักพัฒนาคนอื่น ๆ ทุกคนในทีมที่ต้องการสัมผัส / อ่านรหัสนั้น

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

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


6
ยอดเยี่ยมข้อมูลเชิงลึกของแฟน ทำไมผู้พัฒนาบางคนถึงดูเหมือนจะ 'ได้รับสิ่งนี้' และคนอื่น ๆ ก็ต่อสู้กับมัน?
Dogweather

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

4

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

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

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

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


2

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

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

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

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

สิ่งที่คุณกำลังมองหาคือสื่อความสุขของทีมคุณ


2

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

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

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

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

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

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


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

2

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

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

ฉันจะไม่อ้างถึงตัวอย่างแรกของคุณในฐานะ style, style คือตัวเลือกที่ไม่ถูกหรือผิดอย่างชัดเจนในกรณีนี้ฟังก์ชั่นพิเศษคือ code bloat ที่ไม่มีส่วนกลับหัว มันเป็นเพียง 2 บรรทัดพิเศษยังคงอ่านง่ายและง่ายต่อการแก้ไขดังนั้นตัวอย่างนี้ไม่มีปัญหาใหญ่

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

เกี่ยวกับลูกค้า

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


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

0

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

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