อะไรเป็นสาเหตุของประสิทธิภาพที่ไม่ดีในแอพสำหรับผู้บริโภค [ปิด]


32

Comcast DVRของฉันใช้เวลาอย่างน้อยสามวินาทีในการตอบสนองต่อทุกปุ่มกดควบคุมระยะไกลทำให้งานง่าย ๆ ในการรับชมทีวีกลายเป็นประสบการณ์การกดปุ่มที่น่าผิดหวัง iPhone ของฉันใช้เวลาอย่างน้อยสิบห้าวินาทีในการแสดงข้อความและล่ม¼ครั้งที่ฉันพยายามเปิดแอพ iPod เพียงแค่การรับและอ่านอีเมลมักใช้เวลานานกว่าหนึ่งนาที แม้แต่ navcom ในรถของฉันก็มีการควบคุมที่นุ่มนวลและไม่ตอบสนองและมักจะกลืนอินพุตที่ต่อเนื่องหากฉันแยกพวกมันออกจากกันไม่กี่วินาที

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

อะไรอยู่เบื้องหลังสิ่งนี้ มันเป็นปัญหาทางเทคนิคหรือปัญหาสังคมหรือไม่? ใครหรืออะไรรับผิดชอบ

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

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

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


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

3
@Michael: นั่นดูเหมือนว่าจะสอดคล้องกับ "ความผิดของฉันที่ต้องซื้ออุปกรณ์เหล่านี้" หรือโดยทั่วไปแล้ว "ความผิดของเราในฐานะผู้บริโภคในการยอมรับความน่าเบื่อระดับนี้"
Crashworks

3
@ Crashworks: ใช่สวยมาก ผู้คนจะไม่ขาย crapware ต่อไปถ้าเราจะไม่ซื้อมัน
Mason Wheeler

4
พวกเขาได้รับการพัฒนาใน บริษัท ที่ทันสมัยและไม่เก็บขยะ

2
แทนที่จะ "เป็นเพราะสิ่งเหล่านี้เขียนด้วยภาษาที่มีการจัดการและเก็บขยะ?" ฉันอ่าน "เป็นเพราะสิ่งเหล่านี้เขียนด้วยภาษาขยะที่ผู้จัดการเลือกหรือไม่"
Carlos Campderrós

คำตอบ:


27

คำถามที่ดี. สิ่งที่ฉันเห็นทุกวันคือสิ่งนี้

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

ความจริงก็คือหากนักพัฒนาซอฟต์แวร์ค้นหาปัญหาด้านประสิทธิภาพเป็นระยะ ๆ (ซึ่งจริง ๆ แล้วง่ายมาก ) พวกเขาก็สามารถกำจัดพวกมันได้

แต่ "สถานะของศิลปะ" คือ:

  1. พึ่งพาคำพังเพยเช่น "การเพิ่มประสิทธิภาพก่อนวัยอันควรหลีกเลี่ยง" และ 90/10 hoo-haw
  2. พูดอย่างกล้าหาญเกี่ยวกับการทำโปรไฟล์และบางครั้งก็ลองจริง ๆ แล้วมักจะมีผลลัพธ์ที่น่าผิดหวังอย่างที่คุณเห็นในคำถาม SO ทั้งหมดเกี่ยวกับเรื่องนี้
  3. ถอยกลับไปคาดเดาเก่าดีปลอมตัวเป็นประสบการณ์และความรู้

แต่จริงๆแล้วมันเป็นลบ จะเป็นบวก, วิธีการนี้ทำงานเกือบตลอดเวลาและมันไม่สามารถจะง่าย นี่คือตัวอย่างรายละเอียด


3
วันหนึ่งคุณกับฉันจะต้องเขียนหนังสือเกี่ยวกับการทำโปรไฟล์ตัวอย่างด้วยกัน มันจะเป็น "Cathedral and the Bazaar" ของการเขียนโปรแกรมประสิทธิภาพ
Crashworks

@ Crashworks: มันคงจะสนุก หากคุณจริงจังเอาฉันลง
Mike Dunlavey

@ ไมค์แน่นอน แต่ต่อมาในช่วงฤดูร้อนฉันคิดว่า - ฉันมีงานในมือและบทความจำนวนมากที่ฉันติดหนี้ให้กับ GDC #AltDevBlogADay และนายจ้างของฉันเอง!
Crashworks

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

@delnan: ครั้งแรกที่ฉันจำได้ว่าการใช้การหยุดแบบสุ่มอยู่ที่ประมาณ '78 บน Raytheon mini ด้วยปุ่ม "หยุด" และ "ขั้นตอน" ฉันจำไม่ได้ว่าเคยคิดว่าจะมีวิธีอื่นที่จะทำ ดังนั้นในขณะที่เรื่องใหญ่ -O มันลึกลับฉันว่าผู้คนสามารถพูดคุยเกี่ยวกับการเพิ่มประสิทธิภาพในซอฟต์แวร์จริงโดยไม่ต้องมีโปรแกรมตัวแรกบอกพวกเขาว่าจะมีสมาธิ
Mike Dunlavey

16

นี่ไม่ใช่ปัญหาด้านเทคนิค แต่เป็นปัญหาด้านการตลาดและการจัดการ

คุณอาจจะกลิ้งตาไปที่จุดนี้ แต่โปรดทนกับฉัน

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

ดังนั้นลอง Comcast DVR ของคุณ โดยหลักการแล้วสิ่งต่างๆจะได้ผลเช่นนี้:

  1. ผู้จัดการผลิตภัณฑ์เขียนในข้อมูลจำเพาะ "เมื่อผู้ใช้กดปุ่มบนรีโมทคอนโทรลและอยู่ในระยะ 25 ฟุตของ DVR DVR จะต้องตอบสนองต่อการกดภายใน 250 มิลลิวินาที"
  2. ผู้คนด้านเทคนิคสร้างฮาร์ดแวร์เขียนซอฟต์แวร์ฝังตัว ฯลฯ
  3. ผู้ทดสอบ QA อาจอนุมัติว่าระบบตรงตามข้อกำหนดหรือตีกลับไปที่ทีมเทคนิคเพื่อแก้ไข

แน่นอนมีหลายสิ่งที่ผิดปกติ:

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

คุณเห็นโปรแกรมเมอร์ไร้สาระทุกคนในนั้นไหม? ไม่มีเลย

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

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


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


+1 - ปัญหา (ข้อบกพร่องหรือประสิทธิภาพ) กับผลิตภัณฑ์ขั้นสุดท้ายไม่สามารถถูกตำหนิได้บนโปรแกรมเมอร์ หากผลิตภัณฑ์ผ่านการทดสอบหลายระดับตามที่ต้องการโปรแกรมเมอร์จะทำงานของเขาอย่างถูกต้อง หากผลิตภัณฑ์ผ่านการทดสอบและมีปัญหากับมันการทดสอบ / ข้อมูลจำเพาะคือการตำหนิ
Qwerky

5
+1 เขียนอย่างดีโดยเฉพาะเกี่ยวกับการจัดการผลิตภัณฑ์เป็นต้นอย่างไรก็ตามฉันไม่เห็นด้วยกับความรับผิดชอบ ฉันใส่มันกับคนที่ให้ความรู้แก่โปรแกรมเมอร์ทำให้โปรแกรมเมอร์ไม่รู้จริง ๆ ว่าจะหาข้อบกพร่องด้านประสิทธิภาพได้อย่างไร (และเป็นเรื่องง่ายแค่ไหน
Mike Dunlavey

1
@ ไมค์: จริงมาก ในบทบาทนำครั้งแรกของฉันหนึ่งในรายงานของฉันคือผู้ชายที่เพิ่งได้รับ MSCS จาก Stanford ซึ่งเพิ่งได้รับการสอนให้เขียนรหัส "ถูกต้อง" และคิดว่าฉันแปลกมากเพราะคาดว่าจะมีวงซ้อนสองระดับที่เรียบง่าย ไม่ปล่อยให้ CPU วางไว้บนหัวเข่าเพื่อปล่อยออกซิเจนในผลิตภัณฑ์เชิงพาณิชย์ที่ใช้งานได้หลากหลาย มีการให้คำปรึกษาเล็กน้อยที่จะทำที่นั่น :-)
Bob Murphy

11

เพราะโปรแกรมเมอร์ไม่สมบูรณ์

ฉันเป็นโปรแกรมเมอร์ของสิ่งที่ฝังอยู่ บางรหัสของฉันไม่สมบูรณ์ รหัสฝังตัวของฉันส่วนใหญ่ทำงานได้อย่างรวดเร็ว

เพื่อแก้ไขปัญหาประสิทธิภาพการทำงานในตอนท้ายของโครงการเป็นเรื่องยากมาก

บางครั้งเพื่อให้สิ่งต่าง ๆ เรียบง่าย (และทดสอบได้พัฒนาได้ในเวลาจริงไม่ใช่บั๊กร้ายแรง) เราทำการเลเยอร์สิ่งต่าง ๆ เช่นอินพุตระยะไกลไปยัง "บริการ" ที่ไม่ได้เป็นส่วนหนึ่งของแอปพลิเคชันหลัก ผลลัพธ์สุดท้าย, เวลาในการตอบสนอง ทางเลือกคือการใส่ทุกอย่างไว้ในแอพพลิเคชั่นแบบเสาหินเป็นหายนะแบบบั๊กกี้ใน C หรือ C ++ (ภาษาที่ฝังสองภาษาที่พบบ่อยที่สุด)

บางครั้งอุปกรณ์ฝังตัวของคุณมีตัวกำหนดตารางกระบวนการที่ไม่ทำสิ่งที่คุณต้องการ ประณามยากที่จะแก้ไขในฐานะนักพัฒนาที่ฝังตัว

ความซับซ้อนทำให้เกิดความล่าช้าเนื่องจากความล่าช้าในการฝังรากลึก คุณถามถึงคุณสมบัติ ลองใช้ Nokia รุ่นเก่าจริงๆเช่น 3210 รุ่นเก่า Zippy fast UI คุณสมบัติไม่มาก

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

ประสิทธิภาพของ UI ต้องเป็นข้อกำหนดที่คุณทดสอบเมื่อการออกแบบดำเนินไป

หากไม่ได้ระบุไว้ผู้พัฒนาจะคุ้นเคยกับมัน เราทุกคนทำสิ่งนี้ "ลูกของฉันไม่น่าเกลียด"

และไม่ใช่ภาษา GC; Embedded Realtime Java นั้นรวดเร็วน่ากลัวมาก (Python แบบฝังตัวในทางกลับกันคือสุนัขทั้งหมด)

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

ผู้เล่นดีวีดีบางคนเพียงเรียกใช้สคริปต์ "นำออก" เพื่อทำการดีดออก คุณ DVR อาจใช้วิธีนี้เพื่อรักษาต้นทุนการพัฒนาอย่างมีสติ จากนั้นคุณข้าม CPU หรือ RAM และมันดูด


1
+1 โดยเฉพาะอย่างยิ่งสำหรับ "ลูกของฉันไม่ได้น่าเกลียด" และสิ่งที่ debouncing ฉันทำงานฝังตัวบางอย่างกลับมาเมื่อ (ในปาสกาลเชื่อว่า) เมื่อมันถูกวาดตัวเลขจุดลอยบนวิดีโอและช้าเกี่ยวกับเรื่องนี้อย่างเจ็บปวด หนึ่งวันหยุดสุดสัปดาห์ฉันเสียบ ICE เอาสแต็คช็อต (เป็น hex) แล้วทำให้งง มันอยู่ในจุดลอยจำลองถูกเรียกว่าจากงานประจำที่เปลือกออกแต่ละหลักโดยการหารตัดทอน, คูณ, การลบ, ฯลฯ และแน่นอนว่าเป็นรหัสของฉัน (ฉันพบวิธีที่ดีกว่าที่จะทำ)
Mike Dunlavey

3

เป็นเพราะสิ่งเหล่านี้ทั้งหมดถูกเขียนในภาษาที่มีการจัดการและเก็บรวบรวมขยะมากกว่ารหัสท้องถิ่นหรือไม่?

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

โปรแกรมเมอร์แต่ละคนเป็นผู้เขียนซอฟต์แวร์สำหรับอุปกรณ์เหล่านี้หรือไม่?

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

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

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

ส่วนหนึ่งของปัญหาคือซอฟต์แวร์อาจไม่ได้พัฒนาบนฮาร์ดแวร์มันทำในอีมูเลเตอร์ สิ่งนี้ทำให้ยากที่จะอธิบายถึงประสิทธิภาพของอุปกรณ์ที่แท้จริงแม้ว่าอีมูเลเตอร์นั้นจะมีความแม่นยำ 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 เร็วขึ้น) จากนั้นก็โม้เกี่ยวกับมัน ! ยิ่งผู้บริโภคเริ่มเรียกร้องประสิทธิภาพมากเท่าไหร่ตัวนับถั่วยิ่งเริ่มให้งบประมาณมากขึ้น

นี่เป็นคำตอบที่ละเอียดรอบคอบ ฉันอ่านเรื่องนี้โดยบังเอิญหลังจากกลับมาจากการประชุมทีมโดยที่หัวข้อคือ "# 1 A-priority bug รอบนี้: เวลาแฝงคือ> 60ms, ต้องเป็น 33ms, ZOMG !!! 1!"
Crashworks

1

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

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

คุณกำลังตำหนิโปรแกรมเมอร์ พวกเขาเขียนรหัสแน่นอน แต่พวกเขาไม่ได้กำหนดและไม่ควรกำหนดความต้องการของลูกค้าฮาร์ดแวร์ค่า BOM ค่า R & D งบประมาณการตลาด ..... ทุกสิ่งที่จะทำให้ผลิตภัณฑ์ นั่นไม่ใช่ซอฟต์แวร์

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


2
หมายเลข iPhone ของฉันไม่ได้พูดเกินจริง ฉันได้รับพวกเขาโดยการนับวินาทีออกมาดัง ๆ ในขณะที่ใช้โทรศัพท์ของฉันเอง มีอารมณ์ขัน (ถ้ามีน้อยมาก) ภาพของปัญหานี้ที่เป็นyoutube.com/watch?v=Pdk2cJpSXLg นอกจากนี้โทรศัพท์ของฉันยังใช้งานได้ดีเมื่อฉันซื้อมัน! ฉันประเมินประสิทธิภาพอย่างรอบคอบเมื่อเลือกโทรศัพท์ แต่มันก็ช้าลงเรื่อย ๆ เมื่อมีการอัพเดทเฟิร์มแวร์ต่อเนื่องจาก Apple จนถึงจุดที่ไม่สามารถใช้งานได้ ฉันคิดว่าอาจเป็นความผิดของฉันในการติดตั้งการอัปเดตของ Apple
Crashworks

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

1

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

หากคุณมี iPhone 3G, Apple เปิดตัวอัปเดตระบบปฏิบัติการสองตัวที่ได้รับการปรับให้เหมาะสำหรับอุปกรณ์รุ่นใหม่เท่านั้น อัปเดตระบบปฏิบัติการในภายหลังสำหรับ 3G อาจให้ประสิทธิภาพที่ดีขึ้นเล็กน้อยบน 3G


1
"การเพิ่มประสิทธิภาพก่อนวัยอันควรบางครั้งก็ไม่ดี แต่ไม่จำเป็นเมื่อต้องมีประสบการณ์การใช้งานที่ดี" ไม่ใช่การเพิ่มประสิทธิภาพก่อนเวลา
Carlos Campderrós

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

0

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


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

ฉันไม่เห็นด้วยกับคำสั่งนี้ หลังจากเปลี่ยนจาก AT&T Uverse เป็น Comcast ฉันพบว่า DVR สำหรับ Comcast ช้ามากเมื่อเทียบกับกล่อง Uverse นั่นอาจเป็นสาเหตุของความล่าช้า แต่นั่นไม่ได้หมายความว่ามันจะเป็นเหตุผลเดียวที่ทำให้กล่องช้า
Jetti

-2

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


2
คำตอบนี้อาจไร้ประโยชน์ในกรณีที่คนอื่นโพสต์ความคิดเห็นตรงข้ามโดยไม่มีคำอธิบาย ตัวอย่างเช่นหากมีคนโพสต์การอ้างสิทธิ์เช่น"แอปควบคุมและทำการตลาดโดยคนเก่ง ๆ ที่จ้างนักพัฒนาที่ยอดเยี่ยม"คำตอบนี้จะช่วยให้ผู้อ่านเลือกความคิดเห็นที่คัดค้านสองเรื่องได้อย่างไร ลองพิจารณาแก้ไขในรูปแบบที่ดีขึ้น
gnat
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.