ทีมพัฒนาสามารถป้องกันประสิทธิภาพที่ช้าในแอพสำหรับผู้บริโภคได้อย่างไร

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

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

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

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

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

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

มีอีกปัจจัยหนึ่งที่มีอิทธิพลต่อประสิทธิภาพที่ดีคือความจริงที่ว่านักพัฒนาทำงานบนเครื่องพีซีที่มีราคาแพงซึ่งทำงานได้ดี เมื่อคุณทำงานเป็นเวลาหลายปีบนพีซีแบบ quad-core ที่มี RAM 8 GB, SSD ระดับไฮเอนด์, ระบบปฏิบัติการล่าสุด ฯลฯ มันยากที่จะจินตนาการว่าแอปพลิเคชันของคุณจะทำงานบน Windows XP บนพีซีแบบดูอัลคอร์ได้อย่างไร ด้วย RAM ขนาด 512 Mo และฮาร์ดดิสก์เก่าที่ 90% และไม่ได้จัดเรียงข้อมูลเป็นเวลาหลายปี น่าเสียดายที่ในบางประเทศกรณีสุดท้ายคือกรณีที่เราเห็นสำหรับผู้บริโภคส่วนใหญ่ของแอป ช่องว่างที่ใหญ่ขึ้นระหว่างพีซีสำหรับนักพัฒนาและพีซีสำหรับผู้บริโภคนั้นซับซ้อนมากขึ้นสำหรับนักพัฒนาที่จะดูแลประสิทธิภาพของแอพของเขา

ปัญหา(?):

• ลูกค้า (หรือผู้ใช้ปลายทาง) ไม่ได้บ่นเกี่ยวกับมัน (พอ)
• ดังนั้นผู้จัดการโครงการ (/ ผลิตภัณฑ์) จึงไม่พิจารณาว่าเป็นข้อกำหนด
• ดังนั้นผู้พัฒนาจึงไม่ได้รับเวลาในการแก้ไข

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

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

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

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

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

ในความคิดของคุณช้าคุณสามารถแก้ไขได้ในภายหลัง แต่แอปอย่างน้อยทำงาน

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

แต่ PM เพิ่งให้รายการคุณลักษณะและไม่มีเวลาแก้ไขประสิทธิภาพ

และวงจรอุบาทว์ยังคงดำเนินต่อไป

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

ผู้คนจะต้องรู้วิธี - และพวกเขาทำไม่ได้

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

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

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

สวรรค์รู้ฉันได้ลองในฟอรัมเหล่านี้ดังที่ -

• วิธีการขั้นพื้นฐานที่ง่ายที่สุด
• ความเร็ว 43x - ทำเช่นนั้นกับ profiler ของคุณ
• เหตุผลทำไมในรายละเอียดที่น่าขยะแขยง

ทุกคนสามารถทำได้ พวกเขาแค่ต้องทำมันจริงๆ

ทำให้ความต้องการมีประสิทธิภาพ

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

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

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

หากประสิทธิภาพเป็นข้อกำหนดให้ทดสอบ

มิฉะนั้นเก่งสามารถเขียนวงไม่สิ้นสุดและออกจากต้น "มันใช้เวลาสักครู่" เขาสามารถเรียกร้อง

การทดสอบการยอมรับซอฟต์แวร์ของคุณควรมีการทดสอบการยอมรับอย่างละเอียดสำหรับลักษณะการทำงานที่หลากหลาย

ถ้าคุณไม่ทำเช่นนี้คุณไม่วิศวกรรมใด ๆประสิทธิภาพการทำงานลงในผลิตภัณฑ์

ประสิทธิภาพ (เช่นการใช้ทรัพยากร) ควรได้รับการจัดสรรงบประมาณไปยังระบบย่อย จากนั้นการทดสอบการยอมรับระบบย่อยสามารถตรวจสอบได้

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

ดังนั้นตอนนี้นักพัฒนาจึงมีเกณฑ์การยอมรับและสามารถจัดระเบียบวิธีการของพวกเขาเพื่อให้เหมาะกับมัน

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

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

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

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

เห็นด้วยไม่ควร มันควรจะใช้เวลามากกว่าว่าหลักฐานที่ได้รับความล่าช้าคือความเกี่ยวข้องสำหรับผู้ใช้

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

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

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

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

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

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

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

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

ไม่สนใจนักพัฒนาที่ดูเหมือนจะไม่สนใจ ...

ฉันคิดว่าบ่อยครั้งที่นักพัฒนาที่ทำงานกับโค้ดไม่มีเครื่องมือในการวัดประสิทธิภาพอย่างต่อเนื่อง

เช่นถ้าเป็นไปได้ที่จะวัดเวลาตอบสนองสำหรับแอปของคุณ (เช่นแอปพลิเคชันบนเว็บหรือสืบค้นฐานข้อมูลเป็นต้น) - คุณกำลังรับการแจ้งเตือน (อีเมล, SMS, อะไรก็ตาม) ที่ระบุว่า "10 อันดับแรก" แย่ที่สุด ดำเนินการตอบสนอง (หรือสูงกว่าเกณฑ์ที่กำหนด) หรือไม่

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

อย่างไรก็ตามหากทุกวันหรือไม่กี่ชั่วโมงคุณจะได้รับอีเมลที่ระบุว่าหน้าจอ "x" ใช้เวลาในการโหลด 13 วินาทีและมันกำลังเรียกใช้คิวรี SQL ต่อไปนี้SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...คุณควรเชื่อว่านักพัฒนาสามารถ (และหวังว่า) มัน.

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

หมายเหตุ: ฉันคิดว่านี่เป็นสิ่งที่ทั้งนักพัฒนาซอฟต์แวร์ควรร้องขอการเข้าถึง (หรือแม้แต่การพัฒนาคุณลักษณะดังกล่าว) และฝ่ายบริหารควรให้ / สนับสนุนเครื่องมือดังกล่าว

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

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

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

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

มันเป็นตลาดที่มีการตัดคอซึ่งมีการประนีประนอมจำนวนมาก หากเป็นอึจริงแล้วตลาดจะ (หรือควร) ผลิตภัณฑ์ล้มเหลว อาจมีลูกค้ามากพอที่จะอยู่กับสถานะเดิมได้หรือไม่

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

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

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

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

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

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

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

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

ฉันยอมรับว่าโปรแกรมเมอร์ควรได้รับการสอนที่ดีขึ้นเกี่ยวกับการเพิ่มประสิทธิภาพการทำงาน ฯลฯ

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

เนื่องจากมือถัดไปที่จะจัดการรหัสคือทีมงาน QA (ทดสอบ) คงจะดีกว่าที่จะสอนพวกเขาเกี่ยวกับความสำคัญของประสิทธิภาพการทำงานมีมาตรฐานของมาตรฐานการปฏิบัติงานที่ยอมรับได้ ฯลฯ เป็นมาตรฐานองค์กร (ดีในโลกที่สมบูรณ์แบบ) มาตรฐานประสิทธิภาพควรอยู่ในมาตรฐาน แต่ไม่ได้เกิดขึ้นบ่อยนัก)? (เช่นหน้า / แท็บที่เปลี่ยนไปตามปกติขององค์กรควรเกิดขึ้นทันที "บันทึกการอัปเดตควรเกิดขึ้นใน x วินาที" หากเป็นแอพที่สำคัญแล้ว ... ) คอมพิวเตอร์ที่ทีม QA ทำงานนั้นควรเป็นคอมพิวเตอร์ผู้ใช้ทั่วไป (เราไม่ต้องการฉี่พวกเขาออกโดยให้พวกเขา 386 แต่อย่าให้พวกเขาเป็นแกนรูปสี่เหลี่ยมที่มี RAM 8GB เช่น) พวกเขาจะไม่ระบายให้โปรแกรมเมอร์หากพวกเขาโกรธพอกับประสิทธิภาพหรือไม่

ฉันคิดว่าไคลเอนต์ / ผู้จัดการโครงการควรบังคับโปรแกรมเมอร์ / ทีม qa / นักพัฒนา / ตัวแทนของ บริษัท ให้ทำการนำเสนอของพวกเขาในฮาร์ดแวร์ทั่วไปที่ต่ำที่สุดที่พวกเขามี (คอมพิวเตอร์ที่อ่อนแอที่สุดใน บริษัท เป็นต้น) หากเขียนใหม่พวกเขาจะต้องรวบรวมข้อมูลเกี่ยวกับความรวดเร็วในการประมวลผล x ในซอฟต์แวร์เก่าและเปรียบเทียบกับความรวดเร็วของซอฟต์แวร์ใหม่ (อาจช้าลงเนื่องจากซอฟต์แวร์ใหม่อาจเกี่ยวข้องกับกระบวนการทางธุรกิจเพิ่มเติม แต่ ควรมีหน้าต่างที่ยอมรับได้)

ฉันเคยบอกไว้ก่อนหน้านี้ แต่ฉันจะบอกอีกครั้ง: ฉันคิดว่าวิธีที่ดีที่สุดวิธีหนึ่งในการจัดการเรื่องนี้ก็คือให้นักพัฒนาซอฟต์แวร์ของคุณทำงาน (ค่อนข้าง) ตามรอยขอบฮาร์ดแวร์

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

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

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