ควรเขียนโค้ดวิธีปฏิบัติที่ดีที่สุดเสมอ [ปิด]

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

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

ควรเขียนโค้ดวิธีปฏิบัติที่ดีที่สุดเสมอ

เสมอ? ไม่นั่นโง่

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

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

ใช่. นั่นคือความชัดเจนในตัวเอง ทำไมคุณไม่ทำในสิ่งที่ดีที่สุด?

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

กฎง่ายๆข้อหนึ่งที่ดี: มันไม่ได้เป็นแนวปฏิบัติที่ดีที่สุดในการใช้ชื่อของรูปแบบการออกแบบมากมาย

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

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

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

พูดอีกอย่างก็คือมันไม่ได้ทันสมัยเลย

แต่จะรวมกรอบ HTML5 ที่ล้ำสมัยซึ่งมีฐานข้อมูลแบบ Angular เหมือนการปรับขนาดอัตโนมัติไปยังอุปกรณ์ประเภทต่าง ๆ เช่นมือถือและเดสก์ท็อปการทำงานร่วมกับ Kendo UI ของ Telerik เพื่อยกระดับหนักทั้งหมดและเข้ารหัสอย่างปลอดภัย ช่องทางข้อมูล

สิ่งที่ดีที่สุดก็คือมันจะเสร็จสิ้นภายใน 30 วันนับเป็นความสำเร็จที่จะนำกองทัพของนักพัฒนา Java ในสถาปัตยกรรม Enterprise ออกมาปีละครั้ง รหัสคือ ES6 / Typescript; เป็นโค้ดที่สะอาดที่สุดที่ฉันเคยเห็น

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

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

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

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

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

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

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

แต่ตรงประเด็น: คำตอบสั้น ๆ : ปกติ แต่ไม่เสมอไป

ทุกสาขามี "แนวทางปฏิบัติที่ดีที่สุด" และ "วิธีแก้ไขปัญหาตำราเรียน" สิ่งเหล่านี้แสดงถึงประสบการณ์ที่สะสมและภูมิปัญญาของหลาย ๆ คนหลายคนในหลายปีและไม่ควรละเลย แต่! มีสถานการณ์พิเศษกรณีผู้ได้รับรางวัล ฯลฯ ผู้ที่มีความสามารถอย่างแท้จริงในสาขาใด ๆ จะรู้ว่าเมื่อใดที่ต้องปฏิบัติตามกฎและเมื่อใดที่จะทำลายพวกเขา

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

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

แต่ถ้าคุณทำตามกฎรายการจากหนังสือบางเล่ม 100% อย่างช้าๆคุณจะพบว่าตัวเองกำลังตอกหมุดสี่เหลี่ยมจัตุรัสลงในรูกลม คนที่เขียนกฏอาจไม่เจอกับกรณีของคุณเลย และแม้ว่าพวกเขาจะมีถ้ามันหายากพอพวกเขาอาจจะไม่สนใจมัน กฎที่ใช้งานได้ 80% ของเวลานั้นเป็นกฎที่ยอดเยี่ยม - ตราบใดที่คุณเข้าใจว่ามันใช้งานได้ 80% ของเวลาและไม่ใช่ 100% ของเวลา

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

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

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

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

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

บางสิ่งมีความสำคัญบางอย่างไม่

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

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

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

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

ฉันจะพยายามดูจากมุมมองที่แตกต่าง

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

ไม่ยากที่จะใช้บางอย่างเช่น Spring Boot สำหรับแอปพลิเคชันเว็บ 2 หน้าแล้วเลื่อน servlets ของคุณเองแบบสอบถาม jdbc และสิ่งอื่น ๆ

จากประสบการณ์ของฉันมีวิธีปฏิบัติที่ดีที่สุดเพียงข้อเดียวที่ฉันพิจารณาว่าเป็นข้อบังคับ:

ทำให้มันง่ายโง่ (KISS)

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

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

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

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

ในทฤษฎีใช่

ในโลกแห่งความเป็นจริง [ยัง] ใช่ตราบใดที่คุณสามารถทำได้

ซึ่งแน่นอนหมายความว่า "ไม่"

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

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

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