“ แนวทางปฏิบัติที่ดีที่สุด” ยอดนิยมแบบใดที่ไม่ได้ดีที่สุดเสมอไปและเพราะอะไร [ปิด]

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

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

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

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

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

ฉันต้องการรับฟังตัวอย่างและประสบการณ์ที่เฉพาะเจาะจง

ฉันคิดว่าคุณตีเล็บที่หัวด้วยข้อความนี้

ฉันเกลียดที่จะทำสิ่งที่มีมูลค่าและไม่คิดถึงพวกเขาอย่างยิ่ง

ฉันเพิกเฉยแนวทางปฏิบัติที่ดีที่สุดเกือบทั้งหมดเมื่อไม่มีคำอธิบายว่าทำไมจึงมีอยู่

เรย์มอนด์เฉินทำให้บทความนี้ดีที่สุดเมื่อเขาพูด

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

อาจโยนสิ่งนี้ลงในวงแหวน:

Premature optimization is the root of all evil.

ไม่มันไม่ใช่.

คำพูดที่สมบูรณ์:

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

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

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

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

หนึ่งผลตอบแทนต่อฟังก์ชั่น / วิธี

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

ปัญหาคือว่าแก้ปัญหาที่เหมาะสม 100% ไม่ค่อยมีอยู่ อาจมีวิธีแก้ปัญหาที่เหมาะสม 80% และอาจใช้งานได้ดี แต่ประมาณ 60% เหมาะสมล่ะ 40%? คุณวาดเส้นที่ไหน หากคุณไม่วาดเส้นคุณสามารถจบการรวมไลบรารี่ของโครงการเข้ากับโปรเจ็กต์ของคุณเพราะคุณใช้ฟีเจอร์ของมัน 10% เพียงเพราะคุณต้องการหลีกเลี่ยง

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

"หน่วยทดสอบทุกอย่าง"

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

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

เสมอโปรแกรมอินเตอร์เฟซ

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

อย่าใช้อะไรก็ตามโอเพนซอร์ซ (หรือไม่ใช่ของ Microsoft สำหรับนักพัฒนา. NET ของคุณ)

ถ้า Microsoft ไม่พัฒนา - เราจะไม่ใช้ที่นี่ ต้องการใช้ ORM - EF, ต้องการใช้ IOC - Unity, ต้องการบล็อกแอปพลิเคชันบันทึกองค์กร มีห้องสมุดที่ดีกว่าอยู่มากมาย แต่ฉันยังคงสั่งซื้อจากเมนูดอลล่าร์ของโลกแห่งการพัฒนาอยู่เสมอ ฉันสาบานทุกครั้งที่ฉันได้ยินแนวทางปฏิบัติที่ดีที่สุดของ Microsoft ฉันคิดว่า "แนวทางโภชนาการของแมคโดนัลด์" แน่นอนว่าคุณจะมีชีวิตอยู่หากคุณติดตามพวกเขา แต่คุณจะขาดสารอาหารและมีน้ำหนักเกิน

• โปรดทราบว่านี่อาจไม่ใช่วิธีปฏิบัติที่ดีที่สุดของคุณแต่เป็นสิ่งที่ปฏิบัติกันทั่วไปตามเกือบทุกที่ที่ฉันทำงาน

การวางแนววัตถุ

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

รหัสทั้งหมดควรได้รับการแสดงความคิดเห็น

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

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

วิธีการโดยเฉพาะอย่างยิ่งการต่อสู้ ฉันไม่สามารถรักษาหน้าตรงได้เมื่อฉันได้ยินผู้ใหญ่ใช้วลี "Scrum Master" ฉันรู้สึกเบื่อหน่ายกับการได้ยินนักพัฒนาประท้วงว่าบางแง่มุมของระเบียบวิธี X ไม่ได้ทำงานให้กับ บริษัท ของพวกเขาเท่านั้นที่จะได้รับการบอกเล่าจาก Guru So-and-ดังนั้นเหตุผลที่มันไม่ทำงานก็เพราะพวกเขาไม่ใช่ผู้ปฏิบัติจริง of Methodology X. "การต่อสู้ที่ยากขึ้นคุณต้องเป็นผู้เรียน Padawan ของฉัน!"

มีนักเก็ตแห่งปัญญาในวิธีการแบบว่องไว --- พวกมันจำนวนมาก --- แต่พวกมันมักจะหมอบอยู่ในมูลสัตว์มากจนฉันไม่สามารถต่อสู้กับกฏกติกาได้ รับบิตนี้จากหน้าการต่อสู้ของ Wikipedia :

จำนวนบทบาทถูกกำหนดในการต่อสู้ บทบาททั้งหมดแบ่งออกเป็นสองกลุ่มที่แตกต่างกัน - หมูและไก่ - ตามลักษณะของการมีส่วนร่วมในกระบวนการพัฒนา

จริงๆ? หมูและไก่คุณพูดว่า? ที่น่าสนใจ! อดใจรอไม่ไหวที่จะส่งเจ้านายคนนี้ ...

การทำแผนที่วัตถุสัมพันธ์ ... http://en.wikipedia.org/wiki/Object-relational_mapping

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

การเขียนชื่อฟังก์ชั่นราวกับเป็นประโยคภาษาอังกฤษ:

Draw_Foo()
Write_Foo()
Create_Foo()

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

Foo_Draw()
Foo_Write()
Foo_Create()

เป็นต้น

MVC - ฉันมักจะพบว่าการขัดจังหวะปัญหาการออกแบบเว็บจำนวนมากในแนวทาง MVC นั้นเป็นเรื่องเกี่ยวกับการทำเฟรมเวิร์ก (rails และอื่น ๆ ) ให้มีความสุขมากกว่าความเรียบง่ายหรือโครงสร้าง MVC เป็นที่ชื่นชอบของ "นักบินอวกาศสถาปัตยกรรม" ที่ดูเหมือนจะให้ความสำคัญกับการนั่งร้านมากกว่าความเรียบง่าย YMMV

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

YAGNI

( คุณไม่ต้องการมัน )

วิธีนี้มีค่าใช้จ่ายฉันชั่วโมงและชั่วโมงเมื่อฉันต้องใช้คุณสมบัติใน codebase ที่มีอยู่ที่วางแผนอย่างรอบคอบจะได้รวมคุณสมบัติเหล่านี้ไว้ล่วงหน้า

ความคิดของฉันมักจะถูกปฏิเสธเพราะ YAGNI และส่วนใหญ่มีคนต้องจ่ายสำหรับการตัดสินใจในภายหลัง

(แน่นอนว่าคนหนึ่งอาจโต้แย้งว่า codebase ที่ออกแบบมาอย่างดีจะอนุญาตให้เพิ่มคุณสมบัติในภายหลังได้ แต่ความเป็นจริงนั้นแตกต่างกัน)

สำหรับ SQL

1. อย่าใช้ทริกเกอร์
2. ซ่อนตารางไว้หลังมุมมองเสมอ

ในการสั่งซื้อ:

1. มันเป็นคุณสมบัติที่มีอยู่ คุณมีเส้นทางการอัปเดตหลายเส้นทางไปยังตารางหรือต้องการการตรวจสอบ 100% หรือไม่

2. ทำไมล่ะ ฉันจะถ้าฉัน refactoring เพื่อรักษาสัญญา แต่ไม่เมื่อฉันอ่านว่าชาวบ้านเปลี่ยนมุมมองเพื่อให้ตรงกับการเปลี่ยนแปลงตารางใด ๆ

แก้ไข:

ข้อ 3: หลีกเลี่ยง * ด้วย EXISTS ลอง 1/0 มันได้ผล. รายการคอลัมน์ไม่ได้รับการประเมินตามมาตรฐาน SQL หน้า 191

รูปแบบการออกแบบส่วนใหญ่ มีการใช้เกินและต่ำกว่าที่ใช้

หลักการความรับผิดชอบเดี่ยว

^{("ทุกชั้นควรมีความรับผิดชอบเพียงอย่างเดียว; ในคำอื่น ๆ ทุกชั้นควรมีหนึ่งและเหตุผลเดียวเท่านั้นที่จะเปลี่ยน")}

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

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

ลองนึกภาพถ้าผู้สร้าง. Net API มีความคิดเช่นนี้: แทนที่จะเป็น List.Sort (), List.Reverse (), List.Find () เป็นต้นเรามีคลาส ListSorter, ListReverser และ ListSearcher!

แทนที่จะเถียงกับ SRP อีกต่อไป(ซึ่งตัวมันเองก็ไม่ได้เลวร้ายในทางทฤษฎี)ฉันจะแบ่งปันประสบการณ์เล็ก ๆ น้อย ๆ ของฉันเกี่ยวกับประสบการณ์อันยาวนาน:

ในที่แห่งหนึ่งที่ฉันทำงานฉันเขียนตัวแก้ปัญหาการไหลอย่างง่าย ๆซึ่งประกอบด้วยห้าคลาส: โหนด, กราฟ, ผู้สร้างกราฟ, ผู้แก้กราฟและชั้นเรียนเพื่อใช้ผู้สร้างกราฟ / นักแก้ปัญหาเพื่อแก้ ปัญหาโลกแห่งความจริง ไม่มีความซับซ้อนหรือความยาวเป็นพิเศษ (ตัวแก้ปัญหานั้นยาวที่สุดที่ ~ 150 บรรทัด) อย่างไรก็ตามมีการตัดสินใจว่าชั้นเรียนมี "ความรับผิดชอบ" มากเกินไปดังนั้นเพื่อนร่วมงานของฉันจึงกำหนดให้มีการสร้างรหัสใหม่ เมื่อพวกเขาทำเสร็จแล้ว 5 ชั้นเรียนของฉันได้รับการขยายเป็น 25 ชั้นซึ่งบรรทัดของรหัสทั้งหมดมากกว่าสามเท่าที่พวกเขาเดิม การไหลของรหัสไม่ชัดเจนอีกต่อไปและไม่มีจุดประสงค์ของการทดสอบหน่วยใหม่ ตอนนี้ฉันมีเวลายากที่จะหาสิ่งที่รหัสของตัวเองทำ

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

ที่อื่น (ซึ่งมีคลาสความคิดที่ควรมีเพียงวิธีเดียวเท่านั้น ) เรากำลังพยายามปรับวิธีที่เหมาะสมซึ่งใช้เวลา 95% ของเวลาในระหว่างการดำเนินการบางอย่าง หลังจาก (ค่อนข้างโง่) ปรับให้เหมาะสมเล็กน้อยฉันหันความสนใจของฉันไปทำไมมันถูกเรียกว่าเป็นพันล้านครั้ง มันถูกเรียกในลูปในคลาส ... ซึ่งวิธีการถูกเรียกในลูปในคลาสอื่น .. ซึ่งก็ถูกเรียกในลูป ..

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

คำขอของฉันในการปรับโครงสร้าง 13 คลาสเหล่านั้นเป็นคลาสเดียวถูกปฏิเสธ

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

นอกจากนี้การเปลี่ยนสิ่งประถมง่าย ๆ เช่น

0 == memberArray.length

ภายในคลาสที่มีการเรียกไปยังวิธีการของคลาสเช่น

isEmpty()

เป็น "การปรับปรุง" IMHO ที่น่าสงสัย เพิ่มเติม:ความแตกต่างคือการตรวจสอบครั้งแรกทำสิ่งที่มันบอกว่า: ตรวจสอบว่าความยาวของอาร์เรย์เป็น 0 ตกลงisEmpty()อาจตรวจสอบความยาวของอาร์เรย์ด้วย แต่มันสามารถนำไปใช้เช่นนี้:

return null != memberArray ? 0 == memberArray.length : true;

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

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

ฉันจะไปไกลถึงจะบอกว่าในบางกรณีวิธี 1 บรรทัดสั้นเกินไปที่จะสมควรได้รับวิธีการ

"เป็นคนใจกว้างกับความคิดเห็น"

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

GoTo ถือว่าเป็นอันตราย

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

"แนวปฏิบัติที่ดีที่สุด" ใด ๆ ที่ไม่อนุญาตให้มีข้อยกเว้นที่สมเหตุสมผลและมีเอกสารประกอบของกฎนั้นเป็นเพียงเรื่องธรรมดาที่น่ากลัว

การเสียสละที่เราทำเพื่อให้สามารถทดสอบโค้ดได้

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

• การสร้างส่วนต่อประสานสำหรับทุกชั้นเรียน วิธีนี้จะเพิ่มจำนวนคลาส (ไฟล์) ที่จะจัดการและเพิ่มรหัสซ้ำ ใช่การเขียนโปรแกรมอินเทอร์เฟซดี แต่นั่นคือสิ่งที่ตัวระบุสาธารณะ / ส่วนตัวมีความหมายสำหรับ
• ทุกคลาสที่ไม่ได้สร้างอินสแตนซ์เมื่อเริ่มต้นจำเป็นต้องมีโรงงาน เห็นได้ชัดว่าnew MyClass()ง่ายกว่าการเขียนโรงงาน แต่ตอนนี้วิธีการที่สร้างมันไม่สามารถทดสอบแยกได้ ถ้าไม่ใช่เพราะเรื่องนี้ฉันจะทำเพียง 1 ใน 20 ของจำนวนคลาสโรงงานที่ฉันทำตอนนี้
• ทำให้ทุกคลาสเป็นแบบสาธารณะซึ่งเอาชนะจุดประสงค์ของการมีตัวระบุการเข้าถึงบนคลาสเลย อย่างไรก็ตามคลาสที่ไม่ใช่แบบสาธารณะไม่สามารถเข้าถึงได้ (และผ่านการทดสอบ) จากโครงการอื่น ๆ ดังนั้นตัวเลือกอื่นเท่านั้นที่จะย้ายรหัสการทดสอบทั้งหมดไปยังโครงการเดียวกัน (และปล่อยด้วยผลิตภัณฑ์สุดท้าย)
• ฉีดพึ่งพา เห็นได้ชัดว่าการให้คลาสอื่น ๆทุกครั้งที่ฉันใช้ฟิลด์และคอนสตรัคเตอร์พารามิเตอร์นั้นทำงานได้ดีกว่าการสร้างเมื่อฉันต้องการ แต่จากนั้นฉันไม่สามารถทดสอบชั้นนี้ได้อีกต่อไป
• หลักการความรับผิดชอบเดี่ยวซึ่งได้ทำให้ผมปวดหัวมากดังนั้นฉันได้ย้ายไปของคำตอบของตัวเอง

แล้วเราจะทำอย่างไรเพื่อแก้ไขปัญหานี้? เราต้องการการเปลี่ยนแปลงอย่างมากในสถาปัตยกรรมภาษา:

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

ในระยะสั้นเราต้องใช้ภาษาที่ออกแบบมาจากพื้นดินขึ้นกับการตรวจสอบในใจ

การแยกแอปพลิเคชันออกเป็น Tiers; ชั้นข้อมูล, ชั้นธุรกิจ, ชั้น UI

เหตุผลหลักที่ฉันไม่ชอบสิ่งนี้คือสถานที่ส่วนใหญ่ที่ใช้วิธีการนี้ใช้กรอบที่เปราะบางมากในการทำให้เสร็จ IE UI Layer นั้นเขียนด้วยมือเพื่อจัดการกับวัตถุเลเยอร์ธุรกิจวัตถุเลเยอร์ธุรกิจนั้นเขียนด้วยมือเพื่อจัดการกับกฎเกณฑ์ทางธุรกิจและฐานข้อมูลฐานข้อมูลคือ SQL และค่อนข้างเปราะบางและจัดการโดยกลุ่ม "DBA" ที่ไม่ชอบการเปลี่ยนแปลง

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

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

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

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

ฉันอาจจะได้รับการกระแทกสำหรับเรื่องนี้ แต่มี :)

JavaBeans

การใช้ JavaBeans ใน Java ดูคำถามของฉันทำไมฉันไม่ควรใช้ POJO ที่ไม่เปลี่ยนรูปแบบแทน JavaBeans บน StackOverflow

เรื่องราวของผู้ใช้ / กรณีใช้งาน / บุคคล

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

80 ขีด จำกัด ถ่าน / บรรทัดโง่

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

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

แน่นอนว่ามีบรรณาธิการของ CLI ที่ใช้ * nix ไดโนเสาร์อย่างเคร่งครัดซึ่งปฏิบัติตามข้อ จำกัด เก่า ๆ ที่เหนื่อยล้าของเทอร์มินัล VT220 ของพวกเขา แต่ทำไมพวกเราที่เหลืออยู่ถึงมาตรฐานเดียวกัน?

ฉันพูดว่าขันขีด จำกัด ถ่าน 80 ตัว หากไดโนเสาร์มีความกล้าพอที่จะแฮ็ก emacs / vim ได้ตลอดทั้งวันทำไมไม่สามารถสร้างส่วนขยายที่ล้อมเส้นโดยอัตโนมัติหรือให้ความสามารถในการเลื่อนแนวนอนกับ CLI IDE ของพวกเขา

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

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

แก้ไข:

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

เมื่อจอภาพคอมพิวเตอร์ 800x600 กลายเป็นบรรทัดฐานสำหรับผู้ใช้ส่วนใหญ่นักพัฒนาเว็บได้เพิ่มความกว้างของเว็บไซต์เพื่อรองรับส่วนใหญ่ ... ทำไมนักพัฒนาไม่สามารถทำเช่นเดียวกัน

วัด, วัด, วัด

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

ฉันพยายามติดตามแหล่งที่มาของ "ปัญญา" ของการวัด ใครบางคนที่มีกล่องสบู่สูงพอที่จะพูดได้และตอนนี้มันเดินทาง

ครูของฉันความต้องการที่จะเริ่มต้นตัวบ่งชี้ของฉันทั้งหมด (ไม่รวมค่าคงที่) myVariableที่มีตัวอักษรตัวพิมพ์เล็กเช่น

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

ใช้ Singletons

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

ใช้ int เป็น iterator ที่ไม่ได้ลงชื่อ

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

วิธีการไม่ควรยาวเกินหน้าจอเดียว

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

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

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

นี่คือกฎของฉัน ...

เขียนฟังก์ชั่น / วิธีการเพื่อให้บรรลุบางสิ่งบางอย่าง

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

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

ฉันดูจากมุมมอง API dev ... หากผู้ใช้รายใหม่ดูที่คลาสไดอะแกรมของรหัสของคุณว่าส่วนใดของแผนผังนั้นจะสมเหตุสมผลในโครงการทั้งหมดที่มีขนาดใหญ่ขึ้น ผู้ช่วยเหลือไปยังส่วนอื่น ๆ ภายในโครงการ

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

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