การเขียนโปรแกรม“ เหมาะสม” เมื่อไรจะไม่สำคัญอีกต่อไป?

ฉันกำลังสร้างเกม Android ในเวลาว่าง มันใช้ไลบรารีlibgdxดังนั้นการยกของหนักก็ทำได้สำหรับฉัน

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

เมื่อฉันเจอปัญหาแปลก ๆ และค้นหา Stack Overflow เพื่อขอความช่วยเหลือฉันเห็นผู้คนจำนวนมากเพิ่งตั้งคำถามใหม่ที่ใช้ประเภทข้อมูลบางประเภทเมื่ออีกคนหนึ่งมีเทคนิค "เหมาะสม" เช่นเดียวกับการใช้ ArrayList เพราะมันไม่ต้องการขอบเขตที่กำหนดเมื่อเทียบกับการกำหนด int [] ใหม่ด้วยขอบเขตที่รู้จักกันใหม่ หรือแม้แต่เรื่องเล็กน้อยเช่นนี้

for(int i = 0; i < items.length; i ++)
{
    // do something
}

ฉันรู้ว่ามันประเมินรายการความยาวของการวนซ้ำทุกครั้ง อย่างไรก็ตามฉันก็รู้ว่าสิ่งของจะไม่เกิน 15 ถึง 20 รายการ ดังนั้นฉันควรสนใจถ้าฉันประเมินรายการความยาวของการวนซ้ำทุกครั้งหรือไม่

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

ดังนั้นฉันคิดว่าคำถามของคุณคือ: มีเกณฑ์เมื่อมันไม่สำคัญอีกต่อไปหรือไม่? มันจะโอเคถ้าจะพูดว่า - "ตราบใดที่มันทำงานเสร็จฉันไม่สนหรอก"

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

แค่นั้นแหละ.

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

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

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

ดังนั้นเช่นเดียวกับหลายสิ่งหลายอย่างในการพัฒนาซอฟต์แวร์ขึ้นอยู่กับ

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

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

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

การเขียนโปรแกรมที่เหมาะสมอย่างแท้จริงนั้นเกี่ยวกับการปฏิบัติตามกฎเกณฑ์ที่ดีซึ่งมีเหตุผลอย่างชาญฉลาด

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

การลดลงของผลตอบแทนจะเกิดขึ้นเมื่อผลประโยชน์ส่วนรวมน้อยกว่าเวลา / ความพยายามเล็กน้อย

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

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

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

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

เมื่อใดที่คุณไม่ควรสนใจรหัสของคุณว่า "เหมาะสม"

• หากคุณจัดการเพื่อตอบสนองเป้าหมายทางธุรกิจและเก็บไว้ในช่วงเวลาที่มีค่าใช้จ่ายต่ำ (ผู้ใช้ไม่ได้ดูแหล่งข้อมูลก่อนที่จะจ่ายเงินให้คุณ)
• MVP / POC - หากการเขียนโค้ดที่ถูกต้องหมายถึงการเสียเวลากับแนวคิดก่อนที่คุณจะรู้วิธีการทำเงินจากมัน (ถ้าคุณใช้เวลาหลายปี 45 ล้านดอลลาร์ในการเขียนแอปและท้ายร้านปิดเพราะไม่มีตลาด เหมาะสมคือรหัส)
• เมื่อมีสถานการณ์ที่คุกคามชีวิต (เช่น Iron Man Prototype 1 เป็นแฮ็คสกปรก แต่มันทำให้เขาออกจากถ้ำใช่มั้ย)
• หรือถ้าคุณไม่รู้วิธีการเขียนรหัสที่ถูกต้อง (ถ้า somene จัดการเพื่อให้การใช้ชีวิตการเขียนรหัสไม่ถูกต้องในการว่างงานวันนี้ฉันพูดว่าเขียนรหัสที่ไม่ดีได้ดีกว่าไม่มีที่อยู่อาศัย)
• หากคุณเพียงแค่รู้ว่าสิ่งที่คุณทำหรือคิดว่าคุณสามารถออกไปกับมันทำท่าที่คุณทำ

ควรเขียนรหัสที่ถูกต้องเมื่อใด

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

ความกังวลหลักของคุณคือประสิทธิภาพหรือไม่? นั่นคือสิ่งที่คุณพยายามที่จะเพิ่มหรือไม่

ถ้าเป็นเช่นนั้นมีบทเรียนพื้นฐานในการเรียนรู้และถ้าคุณทำคุณจะเป็นหนึ่งในไม่กี่คน

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

นั่นเป็นการคาดเดา ทุกคนทำ แต่ไม่ได้ผล

ให้โปรแกรมบอกตัวเองว่าปัญหาคืออะไร นี่คือตัวอย่างโดยละเอียด

คุณเห็นความแตกต่างหรือไม่

คำถามของคุณคือ "ตราบใดที่มันทำงานเสร็จฉันไม่สนใจเหรอ?"

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

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

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

คำตอบก็คือมันไม่สำคัญและมันก็สำคัญ ...

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

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

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

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

แค่ระวัง: บางครั้งแอพที่รวดเร็วและสกปรกเหล่านั้นก็มีความเป็นตัวของตัวเองซึ่งหมายความว่าช็อตคัทสั้น ๆ จะกัดคุณใน ...

หรือแม้แต่เรื่องเล็กน้อยเช่นนี้

for(int i = 0; i < items.length;i ++) {
     // do something 
}

ฉันรู้ว่ามันประเมินรายการความยาวของการวนซ้ำทุกครั้ง อย่างไรก็ตามฉันก็รู้ว่าสิ่งของจะไม่เกิน 15 ถึง 20 รายการ ดังนั้นฉันควรสนใจถ้าฉันประเมินรายการความยาวของการวนซ้ำทุกครั้งหรือไม่

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

ดังนั้นฉันคิดว่าคำถามของคุณคือ: มีเกณฑ์เมื่อมันไม่สำคัญอีกต่อไปหรือไม่? มันจะโอเคถ้าจะพูดว่า - "ตราบใดที่มันทำงานเสร็จฉัน> ไม่แคร์?"

มันขึ้นอยู่กับสิ่งที่คุณคาดหวังจากผลิตภัณฑ์ขั้นสุดท้ายของคุณ ความแตกต่างระหว่างผลิตภัณฑ์ทั่วไปกับผลิตภัณฑ์ที่ยอดเยี่ยมต้องอาศัยรายละเอียด รถอย่างทาทานาโนและรถอย่างเมอร์เซเดสเอส "ทำงานให้สำเร็จ" - มันจะพาคุณจากที่หนึ่งไปอีกที่หนึ่ง ความแตกต่างนั้นขึ้นอยู่กับรายละเอียด: กำลังเครื่องยนต์ความสะดวกสบายความปลอดภัยและอื่น ๆ เหมือนกันกับผลิตภัณฑ์ใด ๆ ที่มีอยู่รวมถึงผลิตภัณฑ์ซอฟต์แวร์ เช่นทำไมทุกคนจะจ่ายเงินให้ Oracle, IBM หรือ Microsoft สำหรับฐานข้อมูล Oracle, DB2 หรือ MS SQL Server ตั้งแต่ MySQL และ Postgre ฟรี

หากคุณต้องการใส่ใจกับรายละเอียดและรับผลิตภัณฑ์คุณภาพสูงคุณควรใส่ใจกับสิ่งนี้ (และสิ่งอื่น ๆ อย่างชัดเจน)

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

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

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

ดูด้านดีแม้ว่า คุณเคยถามเกี่ยวกับเรื่องนี้ดังนั้นบางทีคุณอาจจะทราบจุดที่ฉันทำอยู่แล้ว

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

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

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