Tại sao một số lập trình viên ghét phần UI của sự phát triển? [đóng cửa]

Rất nhiều lập trình viên mà tôi đã gặp luôn nói rằng "Anh ấy không phải là một anh chàng UI". Thực tế là sự phát triển ngày nay, cho dù web, Windows, Linux, OSX hay bất kỳ loại phát triển nào khác hiện nay đều bao gồm phần mềm với giao diện người dùng đẹp. Tại sao nhiều nhà phát triển dường như không thích giao diện người dùng?

Tôi cũng không phải là người dùng UI. Vâng, tôi làm UI trên các dự án của riêng mình, nhưng trong công việc tôi không có gì để làm với nó - công việc của tôi nằm trong ruột của ứng dụng, không phải ở mặt trước.

Ngoài ra, tôi nghĩ rằng nó chán hơn là ghét. Thiết kế UI là phần khó và đầy thách thức. Thực hiện chủ yếu là công việc lẩm cẩm. Có rất ít thách thức hoặc đổi mới trong cách người ta có thể thực hiện giao diện người dùng và chỉ có rất nhiều lần người ta có thể đặt một hộp kiểm trên màn hình trước khi hơi mất tinh thần. Và điều đó thậm chí không chạm đến việc dành hàng giờ để căn chỉnh các pixel "chỉ như vậy".

Tạo một giao diện người dùng tốt bao gồm rất nhiều kỹ năng khác nhau so với việc viết một số mã phụ trợ.

Yêu cầu back-end thường có thể được chỉ định như hộp đen, x đi vào và dự kiến ​​y sẽ xuất hiện. Làm cho nó hoạt động liên quan đến việc thực hiện logic và bạn có thể kiểm tra theo chương trình xem nó có hoạt động hay không.

Để tạo một giao diện người dùng tốt, bạn cần xem xét khả năng sử dụng, thiết kế trực quan, bố cục và những thứ như bảng màu. Có một số sáng tạo nghệ thuật là một phần thưởng ở đây, và nhiều lập trình viên không cảm thấy rằng họ có điều này. Đối với một bộ não logic, giải pháp cho vấn đề UI có vẻ chủ quan vì không có câu trả lời đúng hoặc không có cách nào dễ dàng để xác nhận rằng nó được thực hiện "chính xác".

Tôi nghĩ rằng nhiều lập trình viên không có nhiều kinh nghiệm về UI hoặc chưa thực hiện nhiều nghiên cứu về nó không nhận ra rằng có những quy tắc và khoa học đằng sau cả thiết kế UI tốt từ cả góc độ khả dụng và thiết kế (ví dụ như màu sắc học thuyết).

Tất nhiên, một số lập trình viên không gặp vấn đề gì với khía cạnh này nhưng ghét nó vì nhiều UI chỉ nhàm chán khi viết mã. Chúng có thể bao gồm rất nhiều công việc lặp đi lặp lại như các trang biểu mẫu cho các trang quản trị nơi chúng chỉ cần có chức năng và không có thách thức thiết kế.

Mọi người chỉ có lợi ích khác nhau. Một số lập trình viên quan tâm nhiều hơn đến các quy tắc và thuật toán dữ liệu, một số về kiến ​​trúc, một số về khả năng sử dụng và thiết kế giao diện người dùng - hoặc bất kỳ sự kết hợp nào giữa chúng và các hốc khác. Mỗi người trong số họ đòi hỏi những kỹ năng khác nhau và cách suy nghĩ khác nhau về một vấn đề. Nếu bạn thích các loại hạt và bu lông lập trình cấp thấp, có thể bạn không quan tâm nhiều đến cách người dùng nghĩ, hoặc ngược lại.

Cá nhân, tôi rơi vào trại sau - Tôi muốn thiết kế một giao diện người dùng hơn là một thuật toán phức tạp. Nó chỉ là thứ mà tôi thấy thú vị.

Cho dù một thiết kế UI nhất định là tốt hay xấu là khá chủ quan , điều mà tôi nghĩ rằng các lập trình viên nói chung thấy không hấp dẫn. Một vài thập kỷ nỗ lực để định lượng và đủ điều kiện các kỹ thuật UI tốt đã giúp tạo ra một số quy tắc rộng lớn mà người ta có thể áp dụng, nhưng thường thì không xác định liệu UI có tốt hay không đòi hỏi nhiều thử nghiệm A / B và quan sát người dùng khác kỹ thuật.

Mặc dù chắc chắn có sự chủ quan trong lập trình, nhưng thông thường bạn có thể chỉ ra một số lý do khách quan về lý do tại sao một lựa chọn tốt hơn lựa chọn khác: tốc độ thực hiện, yêu cầu bộ nhớ, linh hoạt để đáp ứng các nhu cầu trong tương lai, các thực tiễn đã được chứng minh hiệu quả hơn trong quá khứ, v.v. Bảo vệ một lựa chọn UI nhất định - và thậm chí là đưa ra lựa chọn đó - thường biến thành "Tôi thích nó", đó là một loại lập luận hoàn toàn khác để hỗ trợ.

Cá nhân tôi không thích phát triển giao diện người dùng vì tôi không giỏi về nó. Có yếu tố tâm lý người dùng LỚN mà tôi không hiểu rõ lắm. Tôi nghĩ vấn đề lớn nhất của tôi là tôi không thể đặt mình vào vị trí của người dùng. Tôi không biết cách tạo bố cục trực quan phần lớn vì tôi không biết điều gì là trực quan với người dùng, tôi cũng không biết làm thế nào để mọi thứ trở nên đẹp mắt.

Tôi không nhất thiết nghĩ rằng một số lập trình viên ghét thiết kế UI nhiều như họ ghét làm những việc mà họ không giỏi. Nó chỉ xảy ra rằng có rất nhiều nhà phát triển không giỏi phát triển giao diện người dùng.

Vấn đề với thiết kế UI là mọi người đều có ý kiến ​​... Và không có câu trả lời đúng hay sai. Các nhà phát triển mặt khác yêu thích màu đen và trắng và logic. Trong bất kỳ công ty quy mô nào, mọi người đều đồng ý điều đó 1+1=2, nhưng hãy hỏi phông chữ nào giúp dễ đọc nhất (Comic Sans Obviously)... sẵn sàng cho trận lụt. Mười ngàn câu trả lời khác nhau và mọi người đều đúng, bởi vì mọi người đều khác nhau.

Là một nhà phát triển thực sự thích làm việc trên UI (cụ thể, tôi đã thực hiện phần chia sẻ công bằng về thiết kế web của mình), tôi đánh giá cao khi ai đó không có bộ kỹ năng tránh xa nó.

Phát triển đòi hỏi khả năng lưu giữ nhiều dữ liệu trong tâm trí của bạn và xử lý nhiều vấn đề cùng một lúc. Thiết kế giao diện người dùng yêu cầu khả năng đun sôi nó tối thiểu nhất có thể, mà không làm mất tính toàn vẹn của nó. Tôi thích những thách thức của điều đó; và tôi co rúm người lại khi thấy ai đó tạo ra một giao diện người dùng không thể quản lý được trên màn hình. (Tôi cũng là một người đam mê tổng thể khi nói về bố cục, lý thuyết màu sắc, v.v.)

Mặt khác, tôi ghét những thứ cấp thấp. Tôi sẽ không bao giờ chạm vào mã cho trình điều khiển, hạt nhân hoặc bất cứ thứ gì tương tự: shudder: Tôi sẽ để lại cho "những người không phải UI", và tôi rất vui khi có người khác thích làm điều đó, hoặc nó sẽ không bao giờ được thực hiện.

Tôi nghĩ rằng nó phụ thuộc vào hầu hết các lập trình viên sử dụng phần não trái của họ.

Một nguồn tốt để đọc thêm về chủ đề này.

Phát triển giao diện người dùng trở nên phức tạp vì bạn nhận được quá nhiều đầu vào từ những người sai. Họ đều là những chuyên gia thiết kế đồ họa. Chúng không có ở đâu khi bạn muốn biết công thức cho một cái gì đó.

Họ không biết họ muốn gì nhưng biết điều đó khi họ thấy nó, không có sở thích và những người có quyền quyết định sẽ không sử dụng ứng dụng này nhưng chắc chắn nó sẽ có màu xanh. Bạn làm theo hướng dẫn cho giao diện người dùng tốt như giới hạn số lượng trường trên một biểu mẫu và bạn nhận được yêu cầu thêm 50 trường nữa vì họ 'cần' tất cả chúng và có chúng trên các tab riêng biệt là quá nhiều nỗ lực. Bạn biết đấy, giống như Excel. Nông dân!

Bạn không thể làm điều này lên. Tôi ngồi trong một cuộc họp nơi hai người đứng đầu trong bộ phận kế toán (khoảng 500 nghìn / năm lương) cho một công ty luật lớn đã dành nửa giờ để tranh luận về một nhãn trên trang web thanh toán được sử dụng bởi các luật sư. Điều này được cho là để làm cho các luật sư dễ hiểu. Tại sao không hỏi luật sư? Quá dễ dàng. Vì vậy, bộ phận CNTT nhận được 50 cuộc gọi điện thoại từ các luật sư muốn biết WTF "Số tiền thanh toán ròng còn lại" và tại sao lại có trong mẫu đơn nhập cảnh thời gian của họ.

Một số người thích bông cải xanh, một số thì không. Chúng tôi có thể phải ăn nó, nhưng chúng tôi không phải thích nó và chúng tôi sẽ không thưởng thức nó khi chúng tôi ăn nó. Không chỉ vậy, chúng ta sẽ tránh phải ăn nó nhiều nhất có thể.

Có rất nhiều thứ khác để mã hóa ngoài giao diện người dùng. Dịch vụ web, Dịch vụ Windows, được nhúng (không có nhiều giao diện người dùng trên lò vi sóng), chỉ để nêu tên một vài ví dụ.

Điều đó có thể là do - trong một số trường hợp - các công cụ được hình thành rõ ràng để giúp bạn vẽ UI hút khỉ con chết qua ống hút thay thế.

Có một số điều nhất định trong phát triển UI rất khó để có được đúng.

Bố cục là một trong số đó. Tôi đã xây dựng giao diện người dùng trong hơn 15 năm và vẫn chưa phải là một giải pháp tốt để quản lý bố cục.

Một cách khác là định tuyến sự kiện - ngay cả với các kiến ​​trúc MVP và các công cụ được ủy quyền bởi các khung, tôi sẽ lập luận rằng hầu hết các UI phức tạp đều có vấn đề định tuyến sự kiện - có thể được phát hiện nếu bất kỳ khung kiểm tra nào có thể giải quyết tốt chúng.

Tôi biết rằng đối với tôi, tôi đã từng ghét UI dev vì tôi thấy nó rất tẻ nhạt và chậm chạp, đặc biệt là viết mã bố cục để định vị mọi thứ trong một biểu mẫu hoặc winow. Bây giờ với các công cụ thiết kế giao diện người dùng như Trình thiết kế biểu mẫu trong Visual Studio, tôi gần như thích nó. Những lý do khác để ghét nó tôi đã nghe từ những người khác bao gồm "thật ngu ngốc", "nó luôn thay đổi quá nhiều", "nó không đủ thách thức", "nó tẻ nhạt / nhàm chán".

Tại sao tất cả những người chơi cờ không thích thiết kế bàn cờ và quân cờ họ chơi?

Không có gì lạ khi một số người không thích điều đó ... thật kỳ lạ mà bạn mong đợi.

Tôi thích làm việc trên UI. Điều đó không phải lúc nào cũng đúng với tôi, nhưng sự thích thú với công việc UI của tôi đã tăng lên khi tôi trở nên tốt hơn trong vài năm qua. Tôi biết một số nhà phát triển không được phép ở gần biểu định kiểu hoặc bảng màu. Đó chắc chắn là một kỹ năng khác nhau, và không phải ai cũng có nó.

Tôi không ghét UI làm việc nhiều như tôi ghét một số khung UI. Ví dụ: tôi đã lập trình .NET cho> 10 năm. Các khung để tạo các ứng dụng web là rất tốt (ASP.NET WebForms và ASP.NET MVC). Nhưng các khung để viết các ứng dụng máy tính để bàn, tốt, tôi không thích chúng (WinForms và WPF).

Vì vậy, về mặt này, viết các ứng dụng GUI là một khía cạnh của việc sử dụng các khung mà tôi không thích.

Có một khía cạnh khác. Tôi thường làm việc với các ứng dụng kiểu "doanh nghiệp", tức là các ứng dụng mà ứng dụng máy tính để bàn cần nhận dữ liệu từ máy chủ. Trong trường hợp này, có rất nhiều lớp chuyển đổi dữ liệu từ định dạng này sang định dạng khác đến nỗi nó thực sự nhàm chán.

Ví dụ, ứng dụng nhận thông tin thông qua một loạt các đối tượng DTO. Sau đó, ứng dụng tạo biểu diễn mô hình dữ liệu của riêng nó (không sử dụng lại các lớp miền tương tự đã được tạo trên máy chủ). Các lớp mô hình được sử dụng bởi một mô hình khung nhìn (trong mẫu MVVM của WPF), để lộ các thuộc tính trên mô hình.

Đó là rất nhiều lần mà cùng một dữ liệu được đại diện bởi các lớp khác nhau. Và điều đó trở nên nhàm chán. Nhưng đây là một vấn đề cụ thể đối với loại ứng dụng máy tính để bàn này.

Ngoài ra còn có những thách thức thú vị trong loại ứng dụng này, chẳng hạn như làm thế nào để chúng tôi nhận được các thay đổi từ một khách hàng này để cập nhật ngay lập tức trên một khách hàng khác.

Tôi không phải là một fan hâm mộ lớn của phát triển UI vì những lý do sau:

1. Là một nhà phát triển, bạn có ít tự do hơn để tạo: Khách hàng có thể thấy và có ý kiến ​​về mọi khía cạnh nhỏ của giao diện người dùng mà bạn phải phản ứng. Bạn sẽ nhận được các yêu cầu như: thay đổi màu sắc của điều này; di chuyển nút đó đến đó; Đừng bận tâm, di chuyển nó trở lại. Mã back-end hiếm khi được nhìn thấy.

2. Giao diện người dùng thì lộn xộn hơn, trong khi phần cuối lại có phần "phẳng" hơn. Mặc dù tôi đã nhìn thấy những mớ hỗn độn xấu xí của mã back-end, tôi nghĩ rằng nó phổ biến hơn đối với mã này (từ góc độ mã) so với mã UI. Một giao diện người dùng có thể thực sự trông rất sạch sẽ và được thiết kế tốt cho người dùng, nhưng vì tôi là nhà phát triển và dành nhiều thời gian cho mã hơn là sử dụng nó, tôi thích mã sạch hơn.

3. Tôi cảm thấy rằng UI giống như một "hệ thống ống nước" hơn là back-end, tức là có ít cơ hội hơn cho các thuật toán thông minh và thực sự đẩy bộ não của bạn đến giới hạn.

Tôi làm cả UI (máy tính để bàn, không phải web) và nội bộ.

Số tiền tôi thích hoặc không thích một trong hai tùy thuộc vào số tiền tôi có thể hoàn thành bằng cách sử dụng thứ gì đó như ngôn ngữ dành riêng cho tên miền (DSL).

Trong miền UI, những gì tôi đang trình bày cho người dùng và sự phức tạp của thông tin tôi nhận được từ họ, đến nỗi tôi sẽ phát điên nếu phải sử dụng các công cụ điển hình, như người thiết kế biểu mẫu, rất nhiều trình xử lý sự kiện, MVC , tất cả những thứ "nhà nước của nghệ thuật". Rất may, nhiều thập kỷ trước tôi đã khám phá ra điều mà tôi nghĩ là một cách tốt hơn, đó là tạo ra DSL cho nó và hoạt động theo cách đó. Hiện tại tôi gọi nó là Hộp thoại động và nó dựa trên cấu trúc điều khiển mà tôi gọi là Thực thi vi sai . Tin tốt là, đối với một chức năng nhất định, mã nguồn gần như là một thứ tự cường độ nhỏ hơn, cho phép tôi đưa nhiều chức năng hơn vào giao diện người dùng. Tin xấu là, nhiều như tôi đã cố gắng dạy nó, tôi đã không gặp nhiều may mắn khi chuyển giao công nghệ.

Trong miền không có UI, tôi đã học một bài học từ một số sản phẩm bắt đầu dưới dạng DSL có thể sử dụng được từ dòng lệnh, trên đó UI được ghép sau đó. Điều đó mang lại cho người dùng chuyên gia một cái gì đó nơi họ có thể bỏ qua giao diện người dùng, trong khi cung cấp cho người dùng thông thường một cái gì đó họ có thể sử dụng một cách tình cờ. (Ví dụ: R, SPlus, Matlab, SAS, WinBugs.) Vì vậy, sản phẩm của chúng tôi có ngôn ngữ dòng lệnh cho các chuyên gia. Tôi thích phát triển những thứ như vậy, với trình phân tích cú pháp, trình tạo mã, trình biên dịch trước và công cụ mô hình hóa thời gian chạy. Nỗ lực dành cho điều đó ít nhất là ít hơn 10 lần so với nỗ lực dành cho UI.

Một lý do khiến nỗ lực của UI rất nhiều là vẫn còn rất nhiều "chất keo" không thể thực hiện được với DSL - quản lý lưới dữ liệu, tất cả các cách sắp xếp dữ liệu, tất cả những thứ rơi vào "bẻ khóa" ngáp giữa UI thuần túy và ngôn ngữ cơ bản.

Vì vậy, câu hỏi của bạn là "Tại sao một số lập trình viên ghét phần phát triển UI?". Tôi chỉ ghét nó vì "chất keo" mà tôi không có DSL.

Thành thật mà nói, tôi thấy rằng việc tìm kiếm bộ công cụ GUI tốt nhất sau đó thực sự học được những thứ đó là một Pita ... chưa kể bạn không học được nhiều công cụ UI ở trường đại học và tôi là một người mới. ..

Ngoài những gì đã nêu (công việc tẻ nhạt, nhàm chán, bực bội để mã hóa nó và thiết kế thường được thực hiện trước một người không biết gì về những vấn đề mà ý tưởng của anh ta gây ra cho những người cố gắng thực hiện chúng), một yếu tố quan trọng là bạn Tôi phải làm việc với những người có ý tưởng về những gì bạn nên thay đổi liên tục, nhiều hơn so với những gì họ làm cho phần phụ trợ. Kết quả là, bạn đang chống lại một thông số kỹ thuật di chuyển thậm chí nhiều hơn, và những người này cũng có xu hướng trở thành những kẻ lừa đảo. Tôi thực sự có các giao diện người dùng thất bại trong các bài kiểm tra vì một thành phần nằm ngoài vị trí mà người kiểm tra nghĩ rằng nó nên có. Nó có hoạt động không? Đúng. Trông nó có tốt không? Đúng. Nhưng anh ta bắt đầu đếm pixel và một cái gì đó là một pixel không khớp với phần còn lại, vì vậy anh ta đã gửi nó trở lại để làm lại.

Một vài điểm nữa:

1) Thiết kế giao diện người dùng có thể khó kiểm tra hơn, chắc chắn bạn có thể kiểm tra xem nút đó có làm những gì cần không, nhưng kiểm tra xem nó có dễ sử dụng hay không thì khó hơn. Làm thế nào về việc kiểm tra nếu nó sẽ có thể sử dụng được với người khuyết tật?

2) Nhiều lập trình viên không được đào tạo về nó và không biết nhiều về nó.

Thực tế là có rất nhiều công cụ / khung / API UI rất tệ, phức tạp, rất xa để có thể trực quan. Tôi đã phát triển với API Win32 trong C / C ++, với javax.swing, CSS, v.v. Từ đó, tôi ghét phải giao dịch với phát triển UI ... Cho đến khi Qt framework!

Là sinh viên CS, bạn sẽ được dạy cấu trúc dữ liệu, cơ sở dữ liệu, C ++ ... ngoại trừ UI. Vì vậy, bạn sẽ không giỏi từ đầu . Nếu bạn không giỏi về nó, bạn sẽ ghét nó.

Đã làm việc trên cả hai mặt của đồng xu, tức là thiết kế giao diện người dùng và mã phụ trợ, tôi thấy rằng cả hai mặt của đồng tiền về cơ bản là giống nhau.

Các yêu cầu khác với những gì bạn làm hàng ngày không xuất hiện mọi lúc và bây giờ trong thời đại mà tất cả các dịch vụ xoay quanh CRUD thì nó trở nên nhàm chán.

Dù sao, mã hóa frontend cho phép tương tác tốt hơn và các động lực điên rồ về cơ bản vặn vẹo một bàn tay thiếu kinh nghiệm trong thiết kế frontend. Cá nhân tôi đã học được cách khó khăn trong frontend và có thể thoải mái nói rằng thiết kế frontend thú vị và thách thức hơn nhiều.