วิธีจัดการกับความเข้าใจผิดเกี่ยวกับ“ การปรับให้เหมาะสมก่อนกำหนดเป็นรากของความชั่วทั้งหมด”?

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

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

ความพยายามครั้งก่อน

สองสามครั้งฉันได้ลองเสนอราคาที่สมบูรณ์จาก Donald Knuthเพื่ออธิบายว่า "การปรับให้เหมาะสมก่อนกำหนดไม่ดี" ↛ "การเพิ่มประสิทธิภาพทั้งหมดไม่ดี":

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

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

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

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

"การดำเนินการจะไร้เดียงสา O (n³) และ n มีขนาดใหญ่กว่า 100.000 นั่นจะทำงานบางวันในขณะที่การดำเนินการที่ไม่ให้ไร้เดียงสาจะทำงานใน O (n) ซึ่งจะใช้เวลาเพียงไม่กี่นาที"

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

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

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

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

ถามตัวคุณเองว่า:

• ซอฟต์แวร์ไม่ตรงตามข้อกำหนดประสิทธิภาพหรือไม่?
• ซอฟต์แวร์มีปัญหาเรื่องประสิทธิภาพหรือไม่

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

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

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

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

วิธีการทำงานกับคนที่ขัดขวางการอภิปรายในนาทีที่เกี่ยวข้องกับการแสดง?

เริ่มต้นด้วยหลักการที่ใช้ร่วมกันที่สร้างขึ้นในทิศทางกลยุทธ์ของกลุ่มของคุณ

หลักการของฉัน:

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

หากผู้บริโภคของคุณเป็นลูกค้าลูกค้าของคุณจะบอกคุณว่าคุณต้องการรหัสที่เร็วขึ้นหรือไม่

อย่างไรก็ตามมีทางเลือกที่รู้จักกันดีกว่าในรหัสที่สามารถทำได้ ฉันอยากทำให้ถูกต้องในร่างแรกของฉันด้วยเหตุผลหลายประการ:

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

สมมติว่าความต้องการการปรับให้เหมาะสมนั้นถูกต้อง

สมมติว่านี่เป็นส่วนสำคัญอย่างแท้จริงของรหัสของคุณที่ต้องการเพิ่มประสิทธิภาพคุณสามารถบอกคำอุปมาเรื่องSchlemiel the Painterหรือเน้นย้ำส่วนที่เหลือของใบเสนอราคา:

"โปรแกรมเมอร์เสียเวลาจำนวนมากที่คิดหรือกังวลเกี่ยวกับความเร็วของส่วนที่ไม่สำคัญของโปรแกรมและความพยายามเหล่านี้อย่างมีประสิทธิภาพมีผลกระทบเชิงลบอย่างมากเมื่อพิจารณาการดีบั๊กและการบำรุงรักษาเราควรลืมประสิทธิภาพเล็กน้อย 97% ของเวลา: การปรับให้เหมาะสมก่อนกำหนดเป็นรากฐานของความชั่วร้ายทั้งหมดแต่เราไม่ควรปล่อยให้โอกาสของเราผ่านไปในช่วงวิกฤตที่ 3% " - Donald Knuth

ชั่งน้ำหนักค่าใช้จ่ายของความซับซ้อนเพิ่มเติม

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

ความเป็นผู้นำ

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

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

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

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

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

โดยทั่วไปมีความเป็นไปได้สองอย่างเกี่ยวกับการปรับให้เหมาะสม:

1. รหัสที่ได้รับการปรับปรุงนั้นสั้นกว่าง่ายกว่าที่จะเข้าใจและง่ายต่อการบำรุงรักษา

2. รหัสที่ได้รับการปรับให้เหมาะสมนั้นซับซ้อนกว่าที่จะเข้าใจใช้เวลาในการเขียนและทดสอบนานกว่านี้หรือจะซับซ้อนกว่าในการเปลี่ยนแปลงในอนาคตหากความต้องการเปลี่ยนแปลงในวิธีที่ไม่คาดคิด

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

ฉันคิดว่าข้อความเต็มในบริบทนั้นเป็นประโยชน์ ฉันจะคัดลอกจากโพสต์ที่ฉันทำใน Reddit ในหัวข้อ:

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

แต่เราไม่ควรพลาดโอกาสที่สำคัญ 3% โปรแกรมเมอร์ที่ดีจะไม่ได้รับการกล่อมด้วยเหตุผลดังกล่าวเขาจะฉลาดที่จะดูรหัสวิกฤติอย่างรอบคอบ แต่หลังจากได้รับการระบุรหัสแล้ว

- Donald Knuth, การเขียนโปรแกรมแบบมีโครงสร้างพร้อมไปที่ Statement ,แบบสำรวจการคำนวณของคอมพิวเตอร์ ACM, Vol 6, No. 4, Dec. 1974, p.268

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

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

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

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

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

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

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

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

คุณสามารถทำสิ่งต่าง ๆ ในทางที่ผิดหรือทำสิ่งที่ถูกวิธี

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

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

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

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

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

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