ทำไมโปรแกรมเมอร์บางคนถึงเกลียดการเป็นส่วนหนึ่งของการพัฒนา UI? [ปิด]

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

ฉันไม่ใช่คน UI เช่นกัน ฉันทำ UI ในโครงการของตัวเอง แต่ที่ทำงานฉันไม่มีอะไรเกี่ยวข้องกับมัน - งานของฉันอยู่ในความกล้าหาญของแอพไม่ใช่ในส่วนหน้า

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

การสร้าง UI ที่ดีนั้นเกี่ยวข้องกับทักษะที่แตกต่างกว่าการเขียนโค้ดแบ็กเอนด์

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

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

ฉันคิดว่าโปรแกรมเมอร์จำนวนมากที่ไม่มีประสบการณ์ UI มากหรือยังไม่ได้ทำการวิจัยมากนักไม่รู้ว่ามีกฎและวิทยาศาสตร์อยู่เบื้องหลังทั้งการออกแบบ UI ที่ดีจากทั้งมุมมองการใช้งานและการออกแบบ (เช่นสี ทฤษฎี).

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

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

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

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

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

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

ฉันไม่คิดว่าโปรแกรมเมอร์บางคนเกลียดการออกแบบ UI เท่าที่พวกเขาเกลียดการทำสิ่งที่พวกเขาไม่เก่ง มันเพิ่งเกิดขึ้นที่มีนักพัฒนาจำนวนมากที่ไม่เก่งในการพัฒนา UI

ปัญหาของการออกแบบ UI คือทุกคนมีความคิดเห็น ... และไม่มีคำตอบที่ถูกหรือผิด นักพัฒนาในทางกลับกันรักขาวดำและตรรกะ ทุกคนใน บริษัท ทุกขนาดจะเห็นด้วย1+1=2แต่ขอให้ตัวอักษรตัวไหนที่อ่านง่ายที่สุด(Comic Sans Obviously)... เตรียมพร้อมสำหรับเหตุการณ์น้ำท่วม คำตอบที่แตกต่างกันหมื่นคำและทุกคนพูดถูกเพราะทุกคนแตกต่างกัน

ในฐานะนักพัฒนาที่สนุกกับการทำงานกับ UI (โดยเฉพาะฉันทำส่วนแบ่งการออกแบบเว็บอย่างยุติธรรม) ฉันขอขอบคุณเมื่อมีคนที่ไม่มีทักษะความชำนาญใช้งานอยู่

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

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

ฉันคิดว่ามันขึ้นอยู่กับโปรแกรมเมอร์ส่วนใหญ่ใช้สมองซีกซ้าย

แหล่งข้อมูลที่ดีสำหรับการอ่านหัวข้อนี้เพิ่มเติม

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

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

คุณไม่สามารถทำมันได้ ฉันนั่งในที่ประชุมที่คนสองคนแรกในแผนกบัญชี (ประมาณเงินเดือน 500K / ปี) สำหรับ บริษัท กฎหมายขนาดใหญ่ใช้เวลาครึ่งชั่วโมงในการโต้แย้งเรื่องฉลากบนหน้าเว็บไซต์การเรียกเก็บเงินที่ใช้โดยทนายความ นี่เป็นเรื่องง่ายที่ทนายจะเข้าใจ ทำไมไม่ถามแค่ทนาย ง่ายเกินไป ดังนั้นฝ่ายไอทีจึงได้รับโทรศัพท์ 50 สายจากทนายความที่ต้องการทราบ WTF "จำนวนเงินที่เรียกเก็บสุทธิ" คืออะไรและทำไมมันถึงอยู่ในแบบฟอร์มการกรอกเวลา

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

มีสิ่งอื่น ๆ อีกมากมายในการเขียนโค้ดมากกว่าแค่ UI บริการเว็บ, บริการ Windows, ฝังตัว (ไม่มาก UI บนไมโครเวฟ) เพียงเพื่อชื่อตัวอย่าง

นั่นอาจเป็นเพราะ - ในบางกรณี - เครื่องมือที่คิดขึ้นมาอย่างชัดเจนเพื่อช่วยให้คุณวาด UI ที่ดูดลิงทารกที่ตายแล้วด้วยฟางแทน

มีบางสิ่งในการพัฒนา UI ที่หาได้ยาก

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

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

ฉันรู้ว่าสำหรับฉันฉันเคยเกลียด UI dev เพราะฉันพบว่ามันน่าเบื่อและช้าโดยเฉพาะการเขียนรหัสเลย์เอาต์เพื่อจัดวางสิ่งต่าง ๆ ในรูปแบบหรือ winow ตอนนี้ด้วยเครื่องมือออกแบบ UI เช่น Forms Designer ใน Visual Studio ฉันเกือบจะสนุกกับมันแล้ว เหตุผลอื่นที่เกลียดชังฉันเคยได้ยินจากคนอื่น ๆ รวมถึง "มันโง่", "มันเปลี่ยนไปมากเกินไป", "มันไม่ท้าทายพอ", "มันน่าเบื่อ / น่าเบื่อ"

ทำไมผู้เล่นหมากรุกทุกคนไม่ชอบออกแบบกระดานหมากรุกและชิ้นส่วนที่เล่นด้วย

ไม่ใช่เรื่องแปลกที่บางคนไม่ชอบ ... มันแปลกที่คุณคาดหวังว่าเราควร

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

ฉันไม่ชอบ UI ที่เกลียดชังเท่าที่ฉันเกลียดบางเฟรมเวิร์กของ UI เช่นฉันเคยเขียนโปรแกรม. NET เป็นเวลา> 10 ปี กรอบการสร้างเว็บแอปพลิเคชั่นนั้นยอดเยี่ยม (ASP.NET WebForms และ ASP.NET MVC) แต่เฟรมเวิร์กสำหรับการเขียนแอปพลิเคชันเดสก์ท็อปดีฉันไม่ชอบ (WinForms และ WPF)

ดังนั้นในแง่นี้การเขียนแอปพลิเคชัน GUI จึงเป็นเรื่องของการใช้เฟรมเวิร์กที่ฉันไม่ชอบ

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

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

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

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

ฉันไม่ใช่แฟนตัวยงของการพัฒนา UI ด้วยเหตุผลเหล่านี้:

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

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

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

ฉันทำทั้ง UI (เดสก์ท็อปไม่ใช่เว็บ) และความกล้าภายใน

จำนวนที่ฉันชอบหรือไม่ชอบขึ้นอยู่กับว่าฉันสามารถทำได้โดยใช้บางอย่างเช่นโดเมนเฉพาะภาษา (DSL)

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

ในโดเมนที่ไม่ใช่ UI ฉันได้รับบทเรียนจากผลิตภัณฑ์จำนวนหนึ่งที่เริ่มต้นจาก DSL ที่ใช้งานได้จากบรรทัดคำสั่งซึ่ง UI ได้รับการต่อกิ่ง สิ่งนี้ทำให้ผู้ใช้ที่เชี่ยวชาญสามารถผ่านทาง UI ในขณะที่ให้สิ่งที่ผู้ใช้ทั่วไปสามารถใช้งานแบบไม่เป็นทางการ (ตัวอย่าง: R, SPlus, Matlab, SAS, WinBugs) ดังนั้นผลิตภัณฑ์ของเราจึงมีภาษาบรรทัดคำสั่งสำหรับผู้เชี่ยวชาญ ฉันชอบที่จะพัฒนาสิ่งต่าง ๆ ด้วยตัวแยกวิเคราะห์ตัวสร้างโค้ดพรีคอมไพเลอร์และเอ็นจิ้นโมเดลเวลาทำงาน ความพยายามที่ใช้ไปอย่างน้อย 10 อย่างน้อยกว่าความพยายามที่ใช้ใน UI

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

ดังนั้นคำถามของคุณคือ "ทำไมโปรแกรมเมอร์บางคนถึงเกลียดการเป็นส่วนหนึ่งของการพัฒนา UI" ฉันเกลียดเพียงเพราะ "กาว" ซึ่งฉันไม่มี DSL

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

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

อีกไม่กี่คะแนน:

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

2) โปรแกรมเมอร์จำนวนมากไม่ได้รับการฝึกฝนและไม่รู้จักมากนัก

ความจริงก็คือเครื่องมือ UI / framework / API จำนวนมากนั้นไม่ดีซับซ้อนซับซ้อนและอยู่ห่างไกลจากการใช้งานง่าย ฉันพัฒนาด้วย Win32 API ใน C / C ++, กับ javax.swing, CSS, เป็นต้นตั้งแต่นั้นฉันเกลียดต้องจัดการกับการพัฒนา UI ... จนกระทั่งกรอบ Qt!

ในฐานะนักเรียน CS คุณจะได้รับการสอนโครงสร้างข้อมูลฐานข้อมูล C ++ ... ยกเว้น UI ดังนั้นคุณจะไม่ดีที่มันจากจุดเริ่มต้น หากคุณไม่เก่งคุณจะเกลียดมัน

เมื่อทำงานกับทั้งสองด้านของเหรียญเช่นการออกแบบ UI และรหัสแบ็กเอนด์ฉันพบว่าเหรียญทั้งสองข้างนั้นเหมือนกัน

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

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