เป็นเพราะสิ่งเหล่านี้ทั้งหมดถูกเขียนในภาษาที่มีการจัดการและเก็บรวบรวมขยะมากกว่ารหัสท้องถิ่นหรือไม่?
ไม่รหัสช้าจะทำงานได้ไม่ดี แน่นอนว่าภาษาหนึ่งอาจแนะนำปัญหาบางประเภทในขณะที่แก้ไขปัญหาอื่น ๆ แต่โปรแกรมเมอร์ที่ดีก็สามารถหาวิธีแก้ปัญหาได้ในเวลาที่เพียงพอ
โปรแกรมเมอร์แต่ละคนเป็นผู้เขียนซอฟต์แวร์สำหรับอุปกรณ์เหล่านี้หรือไม่?
เป็นบางส่วน ในหลายกรณีอย่างน้อยก็น่าจะเป็นปัจจัยสนับสนุน นี่เป็นผลข้างเคียงที่โชคร้ายของอุตสาหกรรมซึ่งโปรแกรมเมอร์ที่ดีมีความต้องการสูงและมีปริมาณไม่เพียงพอ ช่องว่างระหว่างความสามารถด้านเทคนิคในระดับต่าง ๆ อาจมีขนาดค่อนข้างใหญ่ ดังนั้นจึงเป็นเหตุผลที่บางครั้งผู้เขียนโปรแกรมที่ได้รับมอบหมายให้ใช้งานซอฟต์แวร์บางอย่างอาจแสดงความยินดีเพียงเพื่อให้มันใช้งานได้
ในทุกกรณีผู้พัฒนาแอปรู้ว่าแพลตฟอร์มฮาร์ดแวร์แบบใดที่พวกเขากำหนดเป้าหมายและความสามารถของมันคืออะไร พวกเขาไม่นำมาพิจารณาหรือไม่?
เป็นบางส่วน สำหรับการเริ่มต้นแพลตฟอร์มฮาร์ดแวร์ที่แน่นอนอาจไม่เป็นที่รู้จักเนื่องจากมักจะมีการเจรจากับผู้ผลิตหลายรายพร้อมกันในระหว่างการพัฒนาซอฟต์แวร์ ในความเป็นจริงอาจมีการเปลี่ยนแปลงเล็กน้อย (แต่ไม่จำเป็นเล็กน้อย) กับฮาร์ดแวร์ที่เกี่ยวข้องหลังจากมีการเปิดตัวครั้งแรก อย่างไรก็ตามฉันยอมรับว่าความสามารถทั่วไปนั้นเป็นที่รู้จัก
ส่วนหนึ่งของปัญหาคือซอฟต์แวร์อาจไม่ได้พัฒนาบนฮาร์ดแวร์มันทำในอีมูเลเตอร์ สิ่งนี้ทำให้ยากที่จะอธิบายถึงประสิทธิภาพของอุปกรณ์ที่แท้จริงแม้ว่าอีมูเลเตอร์นั้นจะมีความแม่นยำ 100% ซึ่งไม่ได้เป็นเช่นนั้น
แน่นอนว่านี่ไม่ได้เป็นการพิสูจน์ว่าการทดสอบฮาร์ดแวร์ต้นแบบที่เหมาะสมไม่เพียงพอก่อนที่จะเผยแพร่ ความผิดนั้นอาจอยู่นอกการควบคุม dev / qa
เขาเป็นคนที่พูดซ้ำ ๆ ว่า "การทำให้เกิดประโยชน์สูงสุดเป็นรากเหง้าของความชั่วทั้งหมด" เขาพาพวกเขาหลงทางหรือเปล่า?
ไม่ฉันค่อนข้างแน่ใจว่าพวกเขาไม่ฟังเขาอยู่ดี ไม่เช่นนั้นเขาจะไม่ถูกกล่าวอ้างผิดบ่อยนัก (นั่นควรจะเป็น " การเพิ่มประสิทธิภาพก่อนวัยอันควร ... ") :-D
มีความเป็นไปได้มากกว่าที่โปรแกรมเมอร์จำนวนมากเกินไปจะใช้หนึ่งในสองขั้วที่เกี่ยวข้องกับการปรับให้เหมาะสมที่สุด
- ไม่ว่าพวกเขาจะไม่สนใจมันอย่างสมบูรณ์
- หรือพวกเขาหมกมุ่นอยู่กับ minutiae ที่ไม่เกี่ยวข้องกับข้อกำหนดด้านประสิทธิภาพที่แท้จริง ผลกระทบสุทธิคืองบประมาณหมดและรหัสนั้นสับสนเกินกว่าที่จะแก้ปัญหาประสิทธิภาพที่แท้จริงได้อย่างปลอดภัย
มันเป็นความคิดของ "โอ้เป็นเพียง 100ms เพิ่มเติม" ทุกครั้งจนกว่ามิลลิวินาทีเหล่านั้นทั้งหมดเพิ่มขึ้นถึงนาที?
อาจ เห็นได้ชัดว่าหากSleep(100)
ใช้กระดาษทิชชู่เทียบเท่ากับกระดาษทิชชู่ที่ใช้เพื่อชะลอการไหลของแขนขาที่ถูกตัด - แล้วปัญหาจะเกิดขึ้น อย่างไรก็ตามฉันสงสัยว่าปัญหานั้นละเอียดกว่านั้นอีกมาก
สิ่งที่เป็นฮาร์ดแวร์คอมพิวเตอร์ที่ทันสมัย (รวมถึงอุปกรณ์ฝังตัว) เร็วกว่าที่ผู้คนให้เครดิตแก่พวกเขา คนส่วนใหญ่แม้แต่โปรแกรมเมอร์ที่ "มีประสบการณ์" ก็ไม่สามารถชื่นชมคอมพิวเตอร์ที่รวดเร็วแค่ไหน 100ms เป็นเวลานาน - เป็นเวลานานมาก และอย่างที่มันเกิดขึ้น "เวลานานมาก" นี้ได้ตัด 2 วิธี:
- ข้อแรกคือโปรแกรมเมอร์กังวลเกี่ยวกับสิ่งที่คอมพิวเตอร์ทำอย่างรวดเร็วโดยไม่จำเป็น (มันเกิดขึ้นว่ามันเป็นแค่ความกังวลเช่น "การเพิ่มมูลค่า 300 ครั้งต่อวินาที " ซึ่งทำให้ฉันมาที่นี่ตั้งแต่แรก)
- ประการที่สองคือบางครั้งพวกเขาล้มเหลวที่จะแสดงความกังวลเนื่องจากเมื่อสิ่งต่าง ๆ ใช้เวลานานมาก ดังนั้น:
- หากพวกเขาเพิกเฉยต่อผลกระทบของความล่าช้าในการสื่อสารผ่านเครือข่ายหรือกับอุปกรณ์เก็บข้อมูล
- หากพวกเขาละเว้นผลกระทบของเธรดที่ถูกบล็อกและรอเธรดอื่น
- ถ้าพวกเขาลืมว่าเพราะคอมพิวเตอร์ทำงานเร็วมากมันก็สามารถทำภารกิจซ้ำบ่อยกว่าที่ควรโดยไม่ต้องมีนักพัฒนาที่ตระหนักถึงปัญหา
- ... หากมีการรวมกันของการกำกับดูแลเกิดขึ้นกิจวัตรประจำวันจะทำงานช้ามากโดยไม่คาดคิด มีการทำซ้ำสองสามครั้งและมนุษย์จะสามารถสังเกตเห็นได้ - แต่อาจจะยุ่งยากในการตรึงเพราะสิ่งต่าง ๆ ที่เชื่อมต่อถึงกันหลายร้อยชิ้นกำลังทำงานอย่างรวดเร็วด้วยตัวเอง
เป็นความผิดของฉันหรือเปล่าที่ต้องซื้อผลิตภัณฑ์เหล่านี้ตั้งแต่แรก?
ใช่อย่างแน่นอน. ไม่ใช่คุณเป็นการส่วนตัว แต่เป็นผู้บริโภคทั่วไป ผลิตภัณฑ์ถูกขาย (และซื้อ ) ตามรายการตรวจสอบคุณสมบัติ ผู้บริโภคน้อยรายที่ต้องการประสิทธิภาพที่ดีขึ้น
เพื่อแสดงจุดของฉัน: ครั้งสุดท้ายที่ฉันต้องการซื้อโทรศัพท์มือถือร้านค้าไม่สามารถเสนอรูปแบบการสาธิตเพื่อเล่นกับในร้านได้ พวกเขามีเปลือกพลาสติกพร้อมสติ๊กเกอร์เพื่อแสดงว่าหน้าจอจะเป็นอย่างไร คุณไม่สามารถรู้สึกถึงน้ำหนักเช่นนั้นได้แม้แต่การแสดงหรือการใช้งานเพียงอย่างเดียว ประเด็นของฉันคือถ้ามีคนคัดค้านรูปแบบธุรกิจนั้นมากพอและโหวตด้วยกระเป๋าเงินของพวกเขาเพื่อคัดค้านพวกเขาเราจะเป็นก้าวเล็ก ๆ ไปในทิศทางที่ถูกต้อง
แต่พวกเขาทำไม่ได้ดังนั้นเราไม่ได้; และโทรศัพท์มือถือใหม่ทุกปีจะทำงานช้าลงบนฮาร์ดแวร์ที่เร็วขึ้น
(คำถามที่ไม่ได้ถาม)
- คนการตลาดจะตำหนิหรือไม่? เป็นบางส่วน พวกเขาต้องการวันที่ปล่อย และเมื่อวันที่ดังกล่าวปรากฏขึ้นตัวเลือกระหว่าง "ทำให้มันทำงาน" และ "ทำให้เร็วขึ้น" คือไม่มีเกมง่ายๆ
- มีคนขายที่จะตำหนิ? เป็นบางส่วน พวกเขาต้องการคุณสมบัติเพิ่มเติมในรายการตรวจสอบ พวกเขาขัดต่อรายการคุณสมบัติและไม่สนใจประสิทธิภาพ พวกเขา (บางครั้ง) ทำตามสัญญาที่ไม่สมจริง
- ผู้จัดการต้องตำหนิหรือไม่? เป็นบางส่วน ผู้จัดการที่ไม่มีประสบการณ์อาจทำผิดพลาดได้หลายครั้ง แต่แม้กระทั่งผู้จัดการที่มีประสบการณ์มากก็อาจเสียสละเวลาในการแก้ไขปัญหาด้านประสิทธิภาพเนื่องจากมีข้อกังวลอื่น ๆ
- ข้อกำหนดที่จะตำหนิหรือไม่ เป็นบางส่วน หากมีบางอย่างขาดคุณสมบัติมันจะง่ายกว่ามากที่จะ "ลืม" เกี่ยวกับเรื่องนี้ในภายหลัง และหากยังไม่ได้ระบุเจาะจงเป้าหมายคืออะไร (แม้ว่าฉันจะเชื่อเป็นการส่วนตัวว่าหากทีมมีความภาคภูมิใจในงานของพวกเขาพวกเขาจะกังวลเกี่ยวกับการทำงานโดยไม่คำนึงถึง)
- การศึกษาเป็นความผิดหรือไม่? อาจจะ. การศึกษาอาจอยู่ที่หลังเท้าเสมอ แน่นอนฉันไม่เห็นด้วยกับ "การศึกษา" ที่ปั่นป่วนผู้เริ่มต้นอย่างรวดเร็วด้วยการพัฒนาซอฟต์แวร์ความเข้าใจผิวเผิน อย่างไรก็ตามการศึกษาที่สำรองไว้กับทฤษฎีและปลูกฝังวัฒนธรรมแห่งการเรียนรู้ต้องไม่เลว
- การอัพเกรดเป็นความผิดหรือเปล่า? เป็นบางส่วน ซอฟต์แวร์ใหม่ฮาร์ดแวร์เก่าเป็นสิ่งดึงดูดชะตากรรม แม้กระทั่งก่อนที่เวอร์ชัน X จะวางจำหน่าย X + 1 ก็กำลังวางแผน ซอฟต์แวร์ใหม่เข้ากันได้ แต่ฮาร์ดแวร์เก่าเร็วพอหรือไม่ ผ่านการทดสอบแล้วหรือยัง? การแก้ไขประสิทธิภาพโดยเฉพาะอาจถูกนำไปใช้กับซอฟต์แวร์ใหม่ - ส่งเสริมการอัปเกรดซอฟต์แวร์ที่ไม่ได้รับคำแนะนำ
โดยพื้นฐานแล้วฉันเชื่อว่ามีปัจจัยสนับสนุนมากมาย ดังนั้นน่าเสียดายที่ไม่มี bullet เงินที่จะแก้ไข แต่นั่นไม่ได้หมายความว่ามันเป็นการลงโทษและความเศร้าโศก มีวิธีที่จะช่วยปรับปรุงสิ่งต่าง ๆ
ดังนั้นสิ่งที่จุดผิดพลาดสำหรับผลิตภัณฑ์เหล่านี้?
IMHO เราไม่สามารถระบุจุดเดียวได้ มีปัจจัยหลายอย่างที่เปลี่ยนแปลงไปตามกาลเวลา
- Bean counters: การลดต้นทุน, จังหวะตลาด แต่แล้วเราจะทำให้ความก้าวหน้าที่เราประสบความสำเร็จอีกครั้งโดยปราศจากแรงกดดันหรือไม่?
- ความต้องการสูงและการจัดหาบุคลากรที่มีทักษะต่ำในอุตสาหกรรม ไม่ใช่แค่โปรแกรมเมอร์ แต่ยังเป็นผู้จัดการทดสอบและแม้แต่พนักงานขาย การขาดทักษะและประสบการณ์จะนำไปสู่ข้อผิดพลาด แต่แล้วมันก็นำไปสู่การเรียนรู้อีกครั้ง
- เทคโนโลยีการตกเลือด จนกว่าเทคโนโลยีจะเติบโตเต็มที่มันจะกัดอย่างไม่คาดฝัน แต่บ่อยครั้งที่มันให้ประโยชน์หลายประการตั้งแต่แรก
- แทรกซ้อนแทรกซ้อน เมื่อเวลาผ่านไปอุตสาหกรรมได้มีการพัฒนา: เพิ่มเครื่องมือเทคโนโลยีเลเยอร์เทคนิค abstractions ฮาร์ดแวร์ภาษารูปแบบและตัวเลือกเพิ่มเติม สิ่งนี้ทำให้เป็นไปไม่ได้เลยที่จะมีความเข้าใจแบบ "เต็ม" ของระบบที่ทันสมัย อย่างไรก็ตามเราสามารถทำได้มากขึ้นในเวลาอันสั้น
เราในฐานะโปรแกรมเมอร์สามารถทำอะไรได้บ้างเพื่อหลีกเลี่ยงการสร้างความเจ็บปวดให้กับลูกค้าของเรา?
ฉันมีข้อเสนอแนะเล็กน้อย (ทั้งด้านเทคนิคและไม่ใช่ด้านเทคนิค) ซึ่งอาจช่วย:
- ใช้โซฟาของคุณเองเท่าที่จะทำได้ ไม่มีอะไรที่เหมือนกับประสบการณ์มือแรกที่จะเปิดเผยสิ่งที่น่าอึดอัดใจช้าหรือไม่สะดวก อย่างไรก็ตามคุณจะต้องหลีกเลี่ยงการหลีกเลี่ยงข้อบกพร่องเนื่องจาก "ความรู้ภายใน" อย่างมีสติ เช่นถ้าคุณไม่มีปัญหาในการซิงค์รายชื่อติดต่อเพราะคุณใช้สคริปต์ Python ลับๆ - คุณไม่ได้ใช้ "ผลิตภัณฑ์" ซึ่งนำไปสู่จุดต่อไป ...
- ฟังผู้ใช้ของคุณ (ควรมีมือแรก แต่อย่างน้อยก็มือสองผ่านการสนับสนุน) ฉันรู้ว่าโปรแกรมเมอร์ (โดยทั่วไป) ชอบซ่อนตัวอยู่ห่าง ๆ และหลีกเลี่ยงการมีปฏิสัมพันธ์ของมนุษย์ แต่นั่นไม่ได้ช่วยให้คุณค้นพบปัญหาที่คนอื่นพบเมื่อใช้ผลิตภัณฑ์ของคุณ เช่นคุณอาจไม่สังเกตเห็นว่าตัวเลือกเมนูช้าเพราะคุณรู้จักปุ่มลัดทั้งหมดและใช้ปุ่มเหล่านั้นโดยเฉพาะ แม้ว่าเอกสารจะจัดทำทางลัดทั้งหมดอย่างเต็มรูปแบบ แต่บางคนก็ยังคงต้องการเมนู - แม้ว่าจะช้าอย่างไม่น่าเชื่อ
- พยายามพัฒนาทักษะเทคนิคและความรู้ของคุณอย่างต่อเนื่อง พัฒนาทักษะเพื่อวิเคราะห์ทุกสิ่งที่คุณเรียนรู้อย่างยิ่ง ประเมินความรู้ของคุณเป็นประจำ ในบางกรณีเตรียมพร้อมที่จะลืมสิ่งที่คุณคิดว่าคุณรู้ ซึ่งนำมา ...
- เทคโนโลยี / เทคนิคบางอย่างอาจนำไปสู่ความเข้าใจผิดอย่างละเอียดและการใช้งานที่ไม่ถูกต้อง คนอื่น ๆ ผ่านการวิวัฒนาการของความรู้ทั่วไปหรือเครื่องมือที่มีอยู่อาจตกอยู่ในความโปรดปราน (เช่น Singletons) บางหัวข้อเป็นเรื่องยากมากที่พวกเขาจะสร้างกลุ่มของ "hocus-pocus pundits" ที่เผยแพร่ร่างข้อมูลที่ผิดขนาดใหญ่ Bugbear โดยเฉพาะอย่างยิ่งของฉันคือข้อมูลที่ผิดรอบมัลติเธรด การใช้หลายเธรดที่ดีสามารถปรับปรุงประสบการณ์การใช้งานของผู้ใช้ได้อย่างมาก น่าเสียดายที่วิธีการที่เข้าใจผิดหลายวิธีในการมัลติเธรดจะลดประสิทธิภาพลงอย่างมากเพิ่มข้อผิดพลาดที่ผิดปกติเพิ่มความเสี่ยงในการล็อคตายการแก้ไขข้อบกพร่องที่ซับซ้อนเป็นต้นโปรดจำไว้ว่าเพียงเพราะผู้เชี่ยวชาญกล่าวว่ามันไม่ได้ทำให้เป็นจริง
- เป็นเจ้าของ (ไม่จริงจังฉันไม่ได้เล่นบิงโกในห้องประชุม) เจรจาต่อรองกับผู้จัดการเจ้าของผลิตภัณฑ์พนักงานขายสำหรับคุณลักษณะด้านประสิทธิภาพที่มีความสำคัญกว่ารายการตรวจสอบบางรายการ ต้องการข้อมูลจำเพาะที่ดีกว่า ไม่ใช่เรื่องไร้สาระ แต่โดยการถามคำถามที่ทำให้ผู้คนคิดถึงการแสดง
- เป็นผู้บริโภคที่ฉลาด เลือกโทรศัพท์ที่มีคุณสมบัติน้อย แต่เร็วกว่า (ไม่ใช่ CPU ที่เร็วกว่า, UI เร็วขึ้น) จากนั้นก็โม้เกี่ยวกับมัน ! ยิ่งผู้บริโภคเริ่มเรียกร้องประสิทธิภาพมากเท่าไหร่ตัวนับถั่วยิ่งเริ่มให้งบประมาณมากขึ้น