การพัฒนาเว็บ 10 Antipattern การเข้ารหัสที่คุณต้องหลีกเลี่ยง

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

รูปแบบการออกแบบโดยทั่วไป โซลูชั่นที่นำมาใช้ซ้ำได้ สำหรับบางสถานการณ์ที่สามารถทำได้ มีประโยชน์ในการแก้ปัญหาทั่วไปที่เกิดขึ้น, และสามารถช่วยเราปรับปรุงโค้ดของเราได้อย่างมหาศาล.

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

Antipatterns คืออะไร?

ระยะเวลา “antipattern” ถูกประกาศเกียรติคุณในหนังสือที่ชื่อว่า AntiPatterns ในปี 1998 มันหมายถึง โซลูชันที่นำกลับมาใช้ใหม่ซึ่งดูเหมือนว่ามีประโยชน์ในตอนแรก, แต่ต่อมาปรากฎออกมา ทำอันตรายมากกว่าดี.

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

Antipatterns นั้นมักถูกเรียกเช่นกัน รูปแบบของความล้มเหลว. ข่าวดีก็คือว่ามันเป็น เป็นไปได้ที่จะรับรู้และหลีกเลี่ยงพวกเขา.

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

1. การเพิ่มประสิทธิภาพก่อนวัยอันควร

ช่วงเวลาที่ดีเป็นปัจจัยสำคัญในการเพิ่มประสิทธิภาพรหัส เราสามารถทำเลียนแบบ Antipattern ของ “การเพิ่มประสิทธิภาพก่อนวัยอันควร”, ถ้าเราใส่ใจกับประสิทธิภาพที่มีขนาดเล็กและปรับให้เหมาะสมสำหรับพวกเขาเร็วเกินไปในกระบวนการพัฒนาก่อนที่เราจะรู้ว่าสิ่งที่เราต้องการจะทำ.

ตามคำกล่าวที่โด่งดังของ Donald Knuth “การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด“, ซึ่งอาจเป็นการพูดเกินจริง แต่ก็ยังแสดงให้เห็นว่าปัญหาร้ายแรงที่เกิดขึ้นก่อนวัยอันควรทำให้เกิดประโยชน์สูงสุด.

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

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

2. ประกอบล้อใหม่

“บูรณาการล้อ” antipattern บางครั้งก็เรียกว่า “การออกแบบในสุญญากาศ”. มันเกิดขึ้นเมื่อเราต้องการ ทำทุกอย่างด้วยตัวเอง และ เขียนทุกอย่างตั้งแต่เริ่มต้น, โดยไม่ต้องค้นหาวิธีการ API หรือไลบรารีที่มีอยู่แล้ว.

การสร้างวงล้อใหม่ไม่ใช่แค่การเสียเวลาทำ แต่ โซลูชันที่กำหนดเองโดยเฉพาะอย่างยิ่งสำหรับฟังก์ชั่นพื้นฐานไม่ค่อยดีเท่าตัวมาตรฐาน ที่ได้รับการทดสอบโดยนักพัฒนาและผู้ใช้หลายคน.

3. นรกพึ่งพา

ตรงข้ามกับ “บูรณาการล้อ” antipattern เป็นอีกอันที่เรียกว่า antipattern “นรกพึ่งพา”.

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

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

4. รหัสสปาเก็ตตี้

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

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

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

5. การเขียนโปรแกรมโดย Permutation

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

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

6. คัดลอกและวางการเขียนโปรแกรม

“คัดลอกและวางโปรแกรมมิง” เกิดขึ้นเมื่อเราไม่ปฏิบัติตามหลักการการเข้ารหัส Don't Repeat Yourself (DRY) และแทนที่จะสร้างวิธีแก้ไขปัญหาทั่วไปเราจะแทรกข้อมูลโค้ดที่มีอยู่แล้วในสถานที่ต่าง ๆ และแก้ไขในภายหลังเพื่อให้เข้ากับบริบทที่กำหนด.

การปฏิบัตินี้ ผลลัพธ์ในรหัสที่ซ้ำซ้อนสูง, เนื่องจากส่วนของรหัสที่แทรกมักจะแตกต่างกันในความคลาดเคลื่อนเล็กน้อย.

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

7. การเขียนโปรแกรม Cargo-Cult

ชื่อของ “การเขียนโปรแกรมการขนส่งสินค้าทางศาสนา” มาจากปรากฏการณ์ชาติพันธุ์เฉพาะที่เรียกว่า “ลัทธิขนส่งสินค้า”. ลัทธิขนถ่ายสินค้าปรากฏขึ้นในแปซิฟิกใต้หลังจากสงครามโลกครั้งที่สองเมื่อการบังคับให้ติดต่อกับอารยธรรมขั้นสูงทำให้ชาวพื้นเมืองคิดว่าผลิตภัณฑ์ที่ผลิตเช่น Coca-Cola, ทีวีและตู้เย็นที่นำโดยเรือบรรทุกสินค้าไปยังเกาะถูกสร้างขึ้นโดยธรรมชาติ วิธีการ; และหากพวกเขาแสดงพิธีกรรมเวทย์มนตร์คล้ายกับประเพณีของชาวตะวันตกสินค้าที่เต็มไปด้วยสินค้าจะมาอีกครั้ง.

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

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

8. ลาวาไหล

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

มันมักจะเกิดขึ้นกับ รหัสดั้งเดิม, หรือเมื่อ รหัสถูกเขียนโดยคนอื่น (โดยปกติจะไม่มีเอกสารที่เหมาะสม) หรือเมื่อโครงการย้ายเร็วเกินไปจากการพัฒนาไปยังขั้นตอนการผลิต.

antipattern ชื่อของมันมาจาก ressemblance กับลาวาที่มาจากภูเขาไฟในตอนแรกมันเคลื่อนที่อย่างรวดเร็วและลื่นไหลโดยไม่ต้องใช้ความระมัดระวังมากเกินไป แต่ต่อมามันแข็งตัวและยากที่จะลบออก.

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

9. การเข้ารหัสฮาร์ด

“การเข้ารหัสยาก” เป็น antipattern ที่รู้จักกันดีซึ่งหนังสือการพัฒนาเว็บส่วนใหญ่เตือนเราในคำนำ การเขียนโค้ดที่ยากคือการปฏิบัติที่โชคร้าย เราจัดเก็บการกำหนดค่าหรือข้อมูลอินพุต, เช่นเส้นทางของไฟล์หรือชื่อโฮสต์ระยะไกล, ในซอร์สโค้ด แทนที่จะได้มาจากไฟล์กำหนดค่าฐานข้อมูลอินพุตผู้ใช้หรือแหล่งภายนอกอื่น.

ปัญหาหลักของรหัสยากคือ มันทำงานได้อย่างถูกต้องในสภาพแวดล้อมที่แน่นอน, และที่ เมื่อใดก็ตามที่เงื่อนไขมีการเปลี่ยนแปลง, เราจำเป็นต้องแก้ไข ซอร์สโค้ดมักอยู่ในหลาย ๆ แห่ง.

10. การเข้ารหัสนุ่ม

หากเราพยายามอย่างหนักเพื่อหลีกเลี่ยงหลุมพรางของการเข้ารหัสอย่างหนักเราสามารถวิ่งเข้าไปในกลุ่มต่อต้านอื่นที่เรียกว่า “การเข้ารหัสอ่อน”, ซึ่งเป็นสิ่งที่ตรงกันข้าม.

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

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