ทำไมฉันควรหลีกเลี่ยงการเขียนสคริปต์แบบอินไลน์

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

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

ตกลงคำถามนั้นกลายเป็นคำถามหลายข้อในการเขียน แต่โดยพื้นฐานแล้วสคริปต์แบบอินไลน์ - อะไรคือข้อตกลง?

ปัญหาที่แท้จริงของการสคริปต์แบบอินไลน์คืออะไร มีปัญหาเรื่องประสิทธิภาพหรือไม่หรือเป็นแค่เรื่องของสไตล์ที่ดี?

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

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

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

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

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

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

• ของ Google
• วิกิพีเดีย
• ไมโครซอฟท์
• อะโดบี
• Dell,
• ไอบีเอ็ม

โฮมเพจทั้งหมดของพวกเขาใช้ JavaScript แบบอินไลน์ มันหมายความว่าทุก บริษัท เหล่านั้นจ้างคนที่ชำนาญในการสร้างหน้าแรกของพวกเขา?

ฉันเป็นหนึ่งในนักพัฒนาที่ไม่สามารถใส่รหัส JavaScript ลงใน HTML ได้ ฉันไม่เคยทำมันในโครงการที่ฉันทำงาน (ยกเว้นบางคนอาจชอบการโทร<a href="javascript:...">สำหรับโครงการที่ JavaScript ไม่สร้างความรำคาญไม่ได้เป็นข้อกำหนดจากจุดเริ่มต้นและฉันจะลบ JavaScript แบบอินไลน์เสมอเมื่อฉัน refactor รหัสของคนอื่น ๆ ไม่แน่ใจ

ประสิทธิภาพที่ชาญฉลาดคุณไม่ได้มีประสิทธิภาพที่ดีขึ้นเสมอไปเมื่อวาง JavaScript ในไฟล์แยกต่างหาก โดยทั่วไปเราถูกล่อลวงให้พิจารณาแบนด์วิดท์ที่เสียของ inline JavaScript เนื่องจากไม่สามารถแคชได้ (ยกเว้นเมื่อคุณจัดการกับ HTML ที่แคชแบบคงที่) ในทางตรงกันข้ามไฟล์ exjs. exs จะถูกโหลดเพียงครั้งเดียว

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

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

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

จากนั้นอาร์กิวเมนต์สุดท้ายคือคุณผสม JavaScript และ HTML ในแหล่งที่มาของคุณดังนั้นคุณจึงดูด แต่ใครบอกว่าคุณผสมทั้งคู่ ซอร์สโค้ดที่เบราว์เซอร์ใช้ไม่ได้เป็นซอร์สโค้ดที่คุณเขียนเสมอไป ตัวอย่างเช่นรหัสแหล่งที่มาอาจจะถูกบีบอัดลดขนาดลงหรือหลาย CSS หรือ JS ไฟล์อาจจะเข้าร่วมเป็นหนึ่งไฟล์ แต่นี้ไม่ได้หมายความว่าคุณชื่อจริงๆของคุณตัวแปรa, b, c... a1ฯลฯ หรือว่าคุณเขียน ไฟล์ CSS ขนาดใหญ่ที่ไม่มีช่องว่างหรือบรรทัดใหม่ ในทำนองเดียวกันคุณสามารถแทรกซอร์สโค้ด JavaScript ภายนอกลงใน HTML ได้อย่างง่ายดายในเวลารวบรวมหรือหลังจากผ่านเทมเพลต

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

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

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

เป็นการดีที่จะพยายามแยก HTML และ JS โดยทั่วไป HTML ใช้สำหรับมุมมอง JS เป็นตรรกะของแอปพลิเคชัน แต่จากประสบการณ์ของฉัน decoupling สุดขีดของ html และ javascript (เพื่อความบริสุทธิ์) ไม่ได้ทำให้การบำรุงรักษามากขึ้น มันสามารถรักษาได้น้อยลง

ตัวอย่างเช่นบางครั้งฉันใช้รูปแบบนี้ (ยืมจาก ASP.net) ในการตั้งค่าตัวจัดการเหตุการณ์:

<input type="button" id="yourId" onclick="clickYourId()" />

หรือ

<input type="button" id="yourId" onclick="clickYourId(this)" />

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

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

<input id="yourId"  />

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

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

ดังนั้นโดยสรุปวิธีปฏิบัติที่ดีที่สุดคือแยก HTML และ Javascript ออก แต่ยังเข้าใจกฎของหัวแม่มือบางครั้งต่อต้านเมื่อสุดขีด ฉันขอเถียงหากลางถนน หลีกเลี่ยง inline js จำนวนมาก หากคุณใช้อินไลน์ลายเซ็นของฟังก์ชั่นควรจะง่ายมากเช่น:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

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

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

นี่คือเหตุผลไม่กี่

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

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

3. สคริปต์แบบอินไลน์ยากต่อการดีบักเนื่องจากหมายเลขบรรทัดที่สัมพันธ์กับข้อผิดพลาดใด ๆ นั้นไม่มีความหมาย

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

5. สคริปต์แบบอินไลน์ไม่สามารถทดสอบแยกต่างหากจากหน้าได้ ไฟล์ Javascript ภายนอกสามารถเรียกใช้ผ่านการทดสอบอิสระรวมถึงการทดสอบอัตโนมัติ

6. สคริปต์แบบอินไลน์สามารถนำไปสู่การแยกข้อกังวลได้ไม่ดี (ดังอธิบายโดยคำตอบอื่น ๆ อีกมากมายที่นี่)

มีสาเหตุหลายประการที่จะไม่รวมถึงสคริปต์แบบอินไลน์:

• ก่อนอื่นคำตอบที่ชัดเจนคือมันสร้างรหัสที่ชัดเจนขึ้นกระชับเข้าใจและอ่านง่ายขึ้น

• จากมุมมองเชิงปฏิบัติที่มากขึ้นคุณมักต้องการนำสคริปต์ / CSS / etc มาใช้ซ้ำ ทั่วทั้งเว็บไซต์ของคุณการรวมส่วนต่างๆเหล่านี้อาจหมายถึงต้องแก้ไขทุก ๆ หน้าเดียวทุกครั้งที่คุณทำการเปลี่ยนแปลงเล็กน้อย

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

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

ฉันไม่ได้ตระหนักถึงการทดสอบที่เป็นทางการใด ๆ ในพื้นที่นี้ถึงแม้ว่ามีโอกาสมากที่บางคนได้ทำการทดสอบ

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

คำตอบนั้นขึ้นอยู่กับวิธีใช้รหัสในบรรทัด (สมมติว่ามีจาวาสคริปต์)

เราใช้การรวมโค้ดแบบอินไลน์, ของ SSI (ฝั่งเซิร์ฟเวอร์รวมถึง), ไฟล์ js และไฟล์ css เพื่อสร้างเอฟเฟกต์ที่เราต้องการและยังลดทริปกลับเซิร์ฟเวอร์สำหรับกิจกรรม onClick

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

ต้องบอกว่าถ้าแต่ละหน้ามีรหัสและจาวาสคริปต์วางเหมือนกันแทนที่จะใช้ไฟล์ js ผมบอกว่ามันแย่

หากแต่ละหน้ามีสำเนาของตัวเองและวางส่วน CCS แทนการใช้ไฟล์ css ฉันบอกว่ามันไม่ดี

นอกจากนี้ยังมีค่าใช้จ่ายมากมายในการรวมไลบรารี js ทั้งหมดของคุณในทุกหน้าโดยเฉพาะอย่างยิ่งหากไม่มีการใช้งานฟังก์ชั่นใด ๆ ในหน้านั้น

ฉันจะสมมติ javascript แบบอินไลน์ที่นี่

ไม่เห็นรหัสมันยากที่จะแน่ใจ ฉันสงสัยว่าเขากำลังอ้างถึงสองสิ่ง:

1. คุณ<script>กระจัดกระจายไปทั่วหน้า
2. สิ่งที่คุณ JS อยู่ในส่วนหัวของหน้าไม่ใช่ในไฟล์ภายนอก

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

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

เหตุผลหนึ่งที่ไม่ควรใช้ InLine Javascript (ไม่แม้แต่ onclick = "DoThis (นี่)" บนปุ่ม) คือถ้าคุณตั้งใจจะทำให้เว็บแอปพลิเคชันของคุณเป็น Chrome App ดังนั้นหากคุณวางแผนที่จะย้ายแอปพลิเคชันเว็บของคุณไปยัง Native Chrome App ให้เริ่มต้นด้วยการไม่รวมจาวาสคริปต์แบบอินไลน์ใด ๆ สิ่งนี้ถูกอธิบายในตอนต้นของสิ่งที่คุณจะต้องเปลี่ยน (บังคับ) จากแอปพลิเคชันเว็บของคุณหากคุณต้องการ "Chrome-etize"

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

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

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

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

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

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

มีปัญหาเรื่องประสิทธิภาพหรือไม่หรือเป็นแค่เรื่องของสไตล์ที่ดี?

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

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

ไม่ถ้ามันโง่และใช้งานได้ก็ไม่ใช่โง่

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

อะไรคือปัจจัยที่ทำให้คุณพูดว่า "อืมทำงานมืออาชีพที่นี่" และอะไรที่ทำให้คุณหดตัวจากงานที่ไม่ชำนาญ

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

จากทั้งหมดที่กล่าวมาเป็นเรื่องง่ายที่จะเลือกการเขียนโปรแกรมคุณภาพขององค์กร