วิธีหลีกเลี่ยงคำสาปของการเพิ่มประสิทธิภาพก่อนวัยอันควร

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

อะไร? ผม? ทีม ของฉัน ?

นั่นเป็นข้อกล่าวหาที่ค่อนข้างหนักหนาพอสมควร ให้ฉันอธิบาย

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

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

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

1. เมื่อเข้ารหัสอัลกอริทึมครั้งแรก
2. ก่อนที่เกณฑ์มาตรฐานจะยืนยันว่าคุณต้อง
3. ก่อนทำโปรไฟล์จะระบุจุดที่เหมาะสมที่จะรบกวนการเพิ่มประสิทธิภาพ
4. ในระดับที่ต่ำกว่าโครงการของคุณในปัจจุบันกำหนด

ตอนนี้ ฉันเป็นคนมองโลกในแง่ดี ออพติมัส

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

ในฐานะที่เป็นคนในวงการเทคโนโลยี บางครั้งคุณอาจสงสัยว่าเป็นไปได้อย่างไรที่จะเป็น $year และถึงแม้เราจะก้าวหน้าไปทั้งหมด แต่ก็เป็นมาตรฐานที่ยอมรับได้สำหรับ $task ที่จะใช้เวลานานจนน่ารำคาญ คุณต้องการที่จะผอม มีประสิทธิภาพ. สุดยอด. บางคนเช่นโปรแกรมเมอร์ Rockstar ที่ประกาศรับสมัครงานเหล่านั้นส่งเสียงดัง แต่มีหัวหน้าสับ ดังนั้นเมื่อทีมของคุณเขียนโค้ด คุณต้องสนับสนุนให้พวกเขาทำถูกต้องในครั้งแรก (แม้ว่าคำว่า "ถูกต้อง" จะเป็นคำที่สัมพันธ์กันอย่างสูงก็ตาม) พวกเขารู้ว่านั่นคือวิถีของ Clever Coder และยังเป็นวิถีของบรรดาผู้ที่ไม่ต้องเสียเวลาสร้างโครงสร้างใหม่ในภายหลัง

ฉันรู้สึกว่า. พลังแห่งความสมบูรณ์แบบบางครั้งก็แข็งแกร่งในตัวฉันเช่นกัน คุณต้องการให้ทีมของคุณใช้เวลา เล็กน้อย ในตอนนี้เพื่อประหยัดเวลาได้ มาก ในภายหลัง เพราะทุกคนต่างพาดพิงถึงการแบ่งปันของพวกเขาเรื่อง “Shitty Code Other People Wrote (What the hell Were They Thinking?)” นั่นคือ SCOPWWHWTT สั้น ๆ เพราะฉันรู้ว่าคุณชอบตัวย่อที่ไม่สามารถออกเสียงได้

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

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

สิ่งที่ ต้องปรับให้เหมาะสม: ยินดีต้อนรับสู่ This Being an Art

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

มาทำให้มันคลุมเครือ ยิ่งขึ้นกัน เถอะ! แค่ตอนแรก.

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

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

สำหรับโปรแกรมเมอร์หลายๆ คน… ยิ่งพวกเขารู้มากเท่าไหร่ พวกเขาก็จะยิ่งถูกล่อลวงให้ปรับให้เหมาะสมก่อนเวลาอันควรมากขึ้นเท่านั้น

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

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

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

1. ง่ายที่สุดที่จะอธิบายให้พนักงานใหม่ของคุณเข้าใจ
2. มีแนวโน้มมากที่สุดที่จะผ่านการตรวจสอบโค้ดโดยนักพัฒนาที่มีประสบการณ์มากที่สุดของคุณ
3. บำรุงรักษาได้ดีที่สุด
4. เร็วที่สุดในการเขียน
5. ง่ายที่สุดในการทดสอบ
6. พกพาสะดวกที่สุด
7. ฯลฯ

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

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

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

รักษา UX ไว้ในใจ

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

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

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

ฉันไม่ได้บอกว่าความคิดเห็นเป็นปัญหาในตัวเอง มากเกินไปของมันกลายเป็นปัญหาในกรณีของเรา จากตัวอย่างที่ขัดแย้ง การดึง Ruby on Rails ครั้งใหญ่อย่างหนึ่งก็ คือ การแสดงความคิดเห็นในระบบ front-end ที่ใครๆ ก็มีอาการเวียนศีรษะบ้านหมุนจากการมีตัวเลือกมากเกินไป (ขอความคิดเห็นหน่อยเถอะ จนกว่าฉันจะคิดออกเอง!)

ในทางตรงกันข้าม คุณอาจถูกล่อลวงให้สวมมงกุฎ UX ราชาแห่งทุกสิ่งในโครงการของคุณ เป้าหมายที่คู่ควร แต่ให้ฉันเล่าเรื่องที่สองของฉัน

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

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

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

หลีกเลี่ยงการเพิ่มประสิทธิภาพก่อนวัยอันควร: เวลาและวิธีการเพิ่มประสิทธิภาพ

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

ในแง่ของประสิทธิภาพ มีวิธีการเพิ่มประสิทธิภาพใดบ้างที่ต้องปฏิบัติตามจริง มาขุดกันเถอะ

นี่ไม่ใช่ความคิดริเริ่มระดับรากหญ้า แต่เป็น Triple-Eh

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

1. สถาปัตยกรรม
2. อัลกอริทึม
3. การประกอบ

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

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

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

สถาปัตยกรรม

ในโปรเจ็กต์ สถาปัตยกรรมเป็นส่วนที่แพงที่สุดในการเปลี่ยนแปลงหลังจากข้อเท็จจริง ดังนั้น ที่นี่จึงเป็นสถานที่ที่สมเหตุสมผลที่จะเพิ่มประสิทธิภาพตั้งแต่เริ่มต้น ตัวอย่างเช่น หากแอปของคุณต้องส่งข้อมูลผ่านนกกระจอกเทศ คุณจะต้องจัดโครงสร้างข้อมูลให้เป็นแพ็กเก็ตความถี่ต่ำที่มีน้ำหนักโหลดสูง เพื่อหลีกเลี่ยงไม่ให้คอขวดแย่ลงไปอีก ในกรณีนี้ คุณควรใช้งาน Tetris อย่างเต็มรูปแบบเพื่อสร้างความบันเทิงให้กับผู้ใช้ของคุณ เนื่องจากสปินเนอร์โหลดจะไม่ตัดมัน (ล้อเล่น: หลายปีก่อน ฉันกำลังติดตั้ง Corel Linux 2.0 ดิสทริบิวชัน Linux ตัวแรกของฉัน และดีใจที่กระบวนการติดตั้งที่ใช้เวลานานนั้นรวมเอาแค่นั้น เมื่อได้เห็นหน้าจอ infomercial ของผู้ติดตั้ง Windows 95 หลายครั้งจนฉันจำได้ ได้สูดอากาศบริสุทธิ์ในตอนนั้น)

ตัวอย่างของการเปลี่ยนแปลงทางสถาปัตยกรรมที่มีราคาแพง เหตุผลที่ทำให้รายงาน SQL ดังกล่าวไม่สามารถปรับขนาดได้อย่างมากตั้งแต่แรกก็ชัดเจนจากประวัติของมัน แอปมีวิวัฒนาการเมื่อเวลาผ่านไป จากรากฐานใน MS-DOS และฐานข้อมูลที่กำหนดเองซึ่งไม่ใช่ผู้ใช้หลายคนในตอนแรก เมื่อผู้ขายเปลี่ยนมาใช้ SQL ในที่สุด สคีมาและรหัสการรายงานดูเหมือนจะถูกย้ายทีละรายการ สิ่งนี้ทำให้พวกเขาได้รับการปรับปรุงประสิทธิภาพที่น่าประทับใจกว่า 1,000%+ เป็นเวลาหลายปีในการโรยตลอดการอัปเดต เมื่อใดก็ตามที่พวกเขาต้องเปลี่ยนสถาปัตยกรรมให้เสร็จโดยใช้ประโยชน์จากข้อดีของ SQL สำหรับรายงานที่กำหนด ดีสำหรับธุรกิจที่มีลูกค้าที่ล็อคอินเช่นนายจ้างของฉัน และพยายามจัดลำดับความสำคัญของประสิทธิภาพการเข้ารหัสอย่างชัดเจนในระหว่างการเปลี่ยนครั้งแรก แต่ในบางกรณีก็สามารถตอบสนองความต้องการของลูกค้าได้พอๆ กับที่ค้อนหมุนสกรู

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

ฉันจะไม่เรียกมันว่า แต่คนอื่นทำ

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

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

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

อัลกอริทึมและการประกอบ

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

แต่เมื่อคุณและทีมของคุณได้นำสิ่งที่ไม่มีประสิทธิภาพมาปรับใช้แล้ว คุณปล่อยให้มันเป็น หน้าที่ Don't do it จริง หรือ? คุณ ไม่เคย เพิ่มประสิทธิภาพ?

คุณถูก. กฎถัดไปคือ สำหรับผู้เชี่ยวชาญเท่านั้น อย่า เพิ่ง ทำ

ถึงเวลาเกณฑ์มาตรฐาน!

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

ทำไม? ไม่ชัดเจนหรือว่าอัลกอริธึม O(n³) ของฉันไม่สามารถแย่ไปกว่าอย่างอื่นได้ ด้วยเหตุผลสองประการ:

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

ไม่เชื่อฉันในประเด็นที่สองนั้นเหรอ?

วิธีรับผลลัพธ์ที่ดีขึ้นจากฮาร์ดแวร์ 1,400 ดอลลาร์ มากกว่าฮาร์ดแวร์มูลค่า 7,000 ดอลลาร์

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

คุณควรซื้ออะไร เห็นได้ชัดว่าเงินเยนเป็นเงินเยนฮาร์ดแวร์ที่มีราคาแพงกว่ามักจะทำงานได้ดีกว่าฮาร์ดแวร์ที่ถูกกว่า เห็นได้ชัดว่า Mac Pro ราคา $ 7,000 ควรรวบรวมซอฟต์แวร์ของคุณเร็วกว่า Mac Mini ระดับกลางใช่ไหม

ผิด!

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

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

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

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

คิดก่อนจะพัง

“ฉันไม่รู้เกี่ยวกับพวกคุณ แต่…”

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

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

นอกจากนี้ ถ้าเราไม่ทำ คนอื่นจะทำ

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

Postscript

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