Các lập trình viên GUI có một lợi thế không đáng có so với những người khác?


23

Thật dễ dàng cho các nhà quản lý và khách hàng đánh giá cao những gì họ có thể nhìn thấy.

Tôi đã thấy nhiều nhà phát triển GUI là những lập trình viên trung bình có kiến ​​thức tối thiểu về các nguyên tắc thiết kế hoặc các thành ngữ lập trình khác. Tuy nhiên, những thiếu sót này thường không được chú ý, đặc biệt là bởi quản lý và khách hàng, nếu lập trình viên có thể tạo ra một giao diện người dùng trông ấn tượng. Nhiều đến mức nhiều nhà phát triển GUI mà tôi biết đã dành hàng giờ để làm đẹp GUI với chi phí viết mã xấu, không thể nhầm lẫn.

Mặt khác, các lập trình viên trung cấp phát triển API hoặc chức năng kinh doanh hoặc mã cơ sở dữ liệu (SQL, v.v.) gặp bất lợi vì không có gì hữu hình để hiển thị. Có lẽ một nhà phê bình mã hoặc một kiến ​​trúc sư có thể đánh giá cao sự thanh lịch, thiết kế tốt, khả năng mở rộng vv của mã nhưng nó không có ý nghĩa gì với thế giới bên ngoài. Mã của bạn có thể chạy trong nhiều năm mà không bị phá vỡ, có thể rất dễ bảo trì và có hiệu suất tốt, nhưng nó không bao giờ gợi ra 'wow' mà GUI trông bóng bẩy.

Theo ý kiến ​​của tôi, một hệ quả của điều này là (và tôi sẽ bị hạ thấp nặng nề vì điều này, tôi biết) rằng có ít động lực hơn để một lập trình viên GUI viết mã sạch tốt.

EDIT : Tôi phải giải thích ở đây rằng bởi lập trình viên GUI, tôi không có nghĩa là một nhà thiết kế web / GUI chính thức mà là một lập trình viên đầu cuối, ví dụ, một lập trình viên java-swing.

Phần còn lại của cộng đồng có đồng ý không?


6
Ai phải chịu đựng những yêu cầu của người dùng 'ngớ ngẩn' về phông chữ, nhãn, màu sắc và di chuyển mọi thứ xung quanh? Bạn lấy cái tốt với cái xấu.
JeffO

@Jeff O: Rất đúng. Không có người dùng nào từng chỉ trích sự lựa chọn của tôi về việc phân bổ bao nhiêu bộ nhớ cho cấu trúc dữ liệu hoặc cột nào của bảng cơ sở dữ liệu để lập chỉ mục.
dan04

2
Phải làm việc với các bố cục (cho dù Swing, GWT, HTML, CSS.) Là một cực hình mà không phải đối phó với nó là một lợi thế ...
Uri

@ dan04: Hãy thử làm việc với những người dùng khoa học cao cấp. Họ rất vui khi sử dụng các UI xấu xí và sẽ mất nhiều thời gian để chiến đấu với các cấu trúc cơ sở dữ liệu (thường là trong nỗ lực giữ một số hành trình cũ không thể giải thích được vì các tập lệnh cũ của chúng sử dụng nó). Grrẻ
Donal Fellows

Bit giống như sự khác biệt giữa một tay bass và phần còn lại của một ban nhạc. Họ làm rất nhiều công việc nhập khẩu trong nền nhưng không ai chú ý ngoại trừ những người chơi bass khác.
Gordon

Câu trả lời:


21

Tôi nghĩ rằng tôi thấy quan điểm của bạn, nhưng tôi nghi ngờ rằng cũng có một vấn đề ngược lại để xem xét.

Về cơ bản, tôi tin rằng bạn đang đề xuất rằng, vì UI là yếu tố của ứng dụng 'đối mặt' với người dùng cuối, nên các nhà phát triển UI tận hưởng khả năng hiển thị cao hơn các thành viên trong nhóm làm việc trong các lớp sâu hơn của ứng dụng.

Chắc chắn tôi đồng ý rằng có thể có một tầm nhìn cao hơn. Chẳng hạn, các nhà phát triển làm việc trên các thành phần UI có thể thường xuyên tương tác với người dùng cuối (vì lý do chính đáng, vì họ tập trung vào khía cạnh Tương tác giữa Người / Máy tính).

Tuy nhiên, tôi nghĩ rằng khả năng hiển thị cao hơn xuất hiện ngay cả trong trường hợp khi có vấn đề. Chẳng hạn, người dùng cuối rất có khả năng báo cáo các sự cố dưới dạng 'Vấn đề GUI' ngay cả khi không.

Tất cả có thể tập trung vào nhận thức và một tổ chức trưởng thành sẽ có thể nhận ra các giá trị, đức tính và điểm yếu của các thành viên nhóm khác nhau một cách độc lập với lớp ứng dụng mà họ làm việc. Một tổ chức trưởng thành cũng có thể đã vượt ra ngoài sự khác biệt như 'Nhà phát triển giao diện người dùng' và 'nhà phát triển lớp doanh nghiệp', nhận ra dù sao họ cũng là thành viên trong nhóm, có chuyên môn khác nhau, nhưng luôn cố gắng giáo dục lẫn nhau về các lĩnh vực chuyên môn đó.


1
Và nó không giống như hầu hết các công ty tham gia một cuộc khảo sát người dùng để xem ai là lập trình viên giỏi nhất.
JeffO

1
+1. Tôi làm việc trên GUI và bất cứ khi nào có "sự cố", nó sẽ nằm trong hộp thư đến của tôi. Sau đó, trách nhiệm của tôi là 'chứng minh' rằng nguồn gốc của vấn đề đến từ phía dưới. Các lập trình viên GUI cũng phải thay đổi 'độ tinh khiết' của các API đẹp mắt đó với sự hỗn loạn của các yêu cầu người dùng.
Stewol

10

Đối với một người không giao dịch với các lập trình viên, tôi có thể tự tin nói rằng họ sẽ tin vào loại công cụ này. Họ không biết khối lượng công việc ở chế độ nền, tất cả những gì họ thấy là một loạt các nút / hộp văn bản / menu / [chèn phần tử GUI] và tốc độ cần thiết để hoàn thành những gì nút bắt đầu. Vì vậy, ban đầu, mọi người GUI thích hơn.

Nếu người đó làm việc với các lập trình viên, thì nó hơi khác một chút. Như bạn đã nói họ sẽ chú ý nếu bạn làm cho nó có thể mở rộng, dễ bảo trì hơn, viết lại một thuật toán để nó có ý nghĩa hơn hoặc bất kỳ tác vụ loại bảo trì nào khác. Loại người này sẽ nhìn vào tất cả các lập trình viên như nhau.

Ở giữa nó phụ thuộc vào những gì bạn làm. Tốc độ sau đó trở thành yếu tố quan trọng ở đây. Nếu bạn có thể hiển thị trước và sau khi ghi lại thời gian cần thiết để xử lý và lưu trữ một biểu mẫu và có sự cải thiện, bạn sẽ bình đẳng. Nếu bạn có thể hiển thị ứng dụng đang tải từ 100 khách hàng và cho họ thấy máy chủ đang tan chảy, sau đó hiển thị cho họ phiên bản của bạn, nơi mọi thứ đều ổn, bằng nhau. V.v.


Tóm lại, nó phụ thuộc vào người và những gì bạn làm.


8
Là một người vừa mới trải qua 5 năm hoạt động trên các công cụ cơ sở hạ tầng (ngăn xếp SIP), +1 - hầu hết mọi người không biết bạn đang làm gì và không có gì đặc biệt rõ ràng, ngoài những thứ không hoạt động. Bạn nghĩ bao nhiêu về hệ thống ống nước của bạn ... cho đến khi nó bị vỡ?
Frank Shearar

6

Là "chuyên gia UI" tại công ty của tôi (người phụ trách tất cả sự phát triển UI, không chỉ là thiết kế), tôi nghĩ bạn có thể đang thiếu một phần của câu chuyện. Trong khi tôi là người chịu trách nhiệm về UI, tôi cũng làm việc ở phần back-end, trên cơ sở dữ liệu, v.v. Tôi làm tất cả (chúng tôi là một nhóm nhỏ). [Phát triển WebForms C # và ASP.Net]

Trước hết, vâng, những người không có kỹ thuật sẽ dễ dàng hơn nhiều khi đánh giá cao công việc của một nhà phát triển GUI vì đó là những gì phải đối mặt với mọi người. Đối với những người không có kỹ thuật, GUI là ứng dụng . Hạn chế là GUI cũng là cái đầu tiên bị đổ lỗi khi có sự cố.

Thứ hai, việc phát triển front-end đối với tôi khó khăn hơn nhiều so với back-end từng là (thuật toán tối nghĩa / phức tạp sang một bên). Có quá nhiều thứ để bảo vệ, đó là trạng thái không trạng thái (các ứng dụng của chúng tôi trên Web), các trình duyệt không hoạt động ổn định (thư viện JavaScript là một ơn trời), v.v. Tôi hy vọng phần lớn sự phức tạp này là do khuôn khổ mà tôi có để làm việc với (ASP.Net WebForms) và tất cả những thứ khó khăn sẽ không còn là vấn đề trong tương lai.

Nhìn chung, tôi gặp nhiều khó khăn hơn khi giải quyết các vấn đề về UI so với các vấn đề về mặt sau.


5

Tôi ghét phát triển GUI vì hai lý do,

  1. Tôi logic hơn đồ họa nghệ thuật và kết quả là UI của tôi luôn bị ảnh hưởng.
  2. Vì UI không dựa trên logic, các bài kiểm tra đơn vị gần như không thể viết với bất kỳ ý nghĩa nào

Tuy nhiên, vào cuối ngày, tôi nghĩ rằng mã của tôi sẽ được người dùng cuối đánh giá cao hơn (trái ngược với nhà tài trợ dự án), so với nhà phát triển tầm thường là một người thích sử dụng UI, vì nó thường hoạt động .


4

Để (có thể) mở rộng một chút về câu trả lời của @ TheLQ, tôi nghĩ nó cũng phụ thuộc vào "người xem".

Tôi đã có một số kinh nghiệm với một vài người quản lý / giám sát cấp trên không có nền tảng lập trình. Một số người đánh giá cao rằng họ không lập trình, nhưng hiểu rằng chrome và hubcaps cũng quan trọng như động cơ và khung gầm.

Và tôi đã có kinh nghiệm với một số người quản lý / giám sát cấp trên không quan tâm đến bất kỳ số liệu nào khác ngoài cơn sốt UI. Thậm chí nói rằng các nhà phát triển định hướng UI nhiều hơn quan trọng.

IMHO, tất cả chúng ta đều biết rằng bạn không thể đánh bóng một con gà tây và một ứng dụng nhanh, đáng tin cậy nhưng xấu xí sẽ tồi tệ hơn nhiều so với một ứng dụng vừa tốt vừa hoạt động tốt. Đó là tất cả trong mắt của kẻ si tình và ở một mức độ nào đó, bạn có sức mạnh (bất kể bạn làm gì) để được nhìn thấy trong ánh sáng bạn muốn, bằng cách làm việc cho những người đánh giá cao những phẩm chất như bạn.

EDIT: Tôi có thể nói thêm, là một người cảm thấy thoải mái hơn khi làm việc với các vật phẩm cấp thấp hơn, tôi đã cảm thấy khó chịu khi bạn làm việc chăm chỉ như nhóm UI và đó là sự đánh bóng được ca ngợi trong bản demo chứ không phải hệ thống " chỉ làm việc ". Nhưng như tôi đã nói, tôi biết rằng người giám sát của tôi biết rằng công việc là cần thiết trên tất cả các lĩnh vực.


3

Tôi nghĩ rằng có một giả định chung ngoài kia rằng các nhà phát triển UI là các nhà phát triển "đàn em". Tôi chỉ có thể nghĩ về một trường hợp tôi gặp phải khi một anh chàng UI được coi là cấp cao.

Điều đó nói rằng, tôi nghĩ UI khó hơn rất nhiều so với bất kỳ phần nào khác trong ứng dụng của chúng tôi. Và tôi không nói về thiết kế UX, tôi đang nói về mã hóa. Có bao nhiêu lĩnh vực khác để chúng tôi mã hóa trong đó chúng tôi phải tính đến hàng chục, nếu không phải là hàng trăm, hoặc các tình huống có thể xảy ra? Chỉ thay đổi kích thước màn hình đôi khi có thể trở thành nỗi đau của hoàng gia khi bạn cần tìm hiểu điều gì cần xảy ra với một vài yếu tố. Điều này chủ yếu xuất hiện khi bạn có các hướng dẫn có nội dung "chúng tôi cần hỗ trợ 800x600" và sau đó các nhà thiết kế UX không bao giờ sử dụng bất kỳ thứ gì ngoài độ phân giải HD.

Vì vậy, nếu họ nhận được nhiều lòng tốt hơn vì tiếp xúc nhiều hơn, họ có thể xứng đáng với điều đó. Thông thường, họ ở đầu nhận sai thường xuyên hơn đầu nhận tốt.


3

Dường như thường có ý tưởng rằng một lập trình viên GUI nằm ở cuối chuỗi lập trình viên. Làm thế nào khó có thể kéo và thả một nút trong VS vào một hình thức? Cái gì, bạn sẽ mất một tuần để lập trình điều đó? Đó là vẽ một số thanh. Vì vậy, tôi không ngạc nhiên khi thấy ý tưởng rằng các lập trình viên GUI, là người kéo nút như họ, cũng phải viết mã khủng khiếp.

Lập trình GUI có một số thách thức độc đáo. Đa luồng để giữ GUI hoạt động trong khi tải dữ liệu. Điều này dẫn đến chủ đề mã an toàn và đúng. Hiệu suất là rất quan trọng. Không ai thích đợi hai phút cho đến khi họ kiểm soát lại ứng dụng. Tái sử dụng cũng trở thành một vấn đề lớn. Nếu bạn phải viết mười màn hình tương tự, bạn sẽ cấu trúc mã tốt hơn. Điều này dẫn đến mã tốt hơn. Và tất nhiên việc tạo ra một GUI tốt là một thách thức trong chính nó.

Nhưng với một số người, nó sẽ chỉ kéo một nút vào ứng dụng của bạn. Cũng như đối với một số người, logic nghiệp vụ không gì khác hơn là "phân tích một thông điệp và đưa nó vào DB".


2

Tôi nghĩ rằng rõ ràng là họ làm. Có lẽ các nhà phát triển hàng đầu được miễn, nhưng hầu hết những người khác thì không.

Khi người quản lý của bạn hỏi bạn những gì bạn đã làm trong tháng qua, thật dễ dàng để hiển thị một GUI tuyệt vời. Thật khó để hiển thị một API tuyệt vời. Rất vất vả. Độ mát của API chỉ rõ ràng thông qua việc sử dụng thực tế - nó không thể được đánh giá cao trong nháy mắt.


1

Bạn có thể thoát khỏi tất cả các loại tin tặc và lối tắt trong các hệ thống nội bộ. Khi làm việc với GUI bạn không có quyền tự do đó. Api nội bộ của bạn có thể có sự không nhất quán và bạn chỉ mong các lập trình viên giải quyết nó vì quá khó để khắc phục. Bạn không thể cố gắng và làm cho khách hàng của bạn làm điều tương tự. Vì vậy, trong một số ý nghĩa, những người phải đối phó với các thành phần hữu hình của người dùng phải thực sự tuân theo một tiêu chuẩn cao hơn.


1

Tôi sẽ nói có, vì một lý do đơn giản: iPhone. Mọi người tôi từng nói đều nghĩ nó tuyệt vời vì giao diện bóng bẩy, nhưng tôi chỉ có thể tưởng tượng công việc bên dưới để biến tất cả thành có thể.


1

Nó phụ thuộc vào khán giả. Tôi làm việc với nhiều nhà phân tích tài chính và ý tưởng của họ về một thiết kế gui tốt là một lĩnh vực có nhiều lĩnh vực mà bạn có thể có thể tham gia vào một hình thức. Nghiêm túc mà nói, tôi đang nói 75 - 100. Họ là những người nghiện dữ liệu luôn muốn nhiều hơn nữa. Gần đây tôi đã cải thiện hiệu suất trên một vài thủ tục được lưu trữ có thể mất 45 giây để tải (tính trung bình có trọng số kể từ khi bắt đầu công cụ thời gian). Giảm xuống còn 30 giây; Tôi đang suy nghĩ wow, cắt giảm một phần ba thời gian; nó phải là một mục hàng trong sơ yếu lý lịch của tôi. Thậm chí không ai để ý. Giữ làm việc trên nó và có nó đến 15-20. Thay đổi đáng chú ý. Mọi người đều rất vui. Tôi vẫn nghĩ rằng GUI là một sự ghê tởm và nếu chúng ta loại bỏ thứ vô dụng này, nó sẽ tải trong 2 giây,

Vì vậy, nếu bạn muốn người dùng thực sự yêu bạn, hãy nhớ rằng giao diện người dùng tốt nhất hoàn toàn không có giao diện (ước gì tôi nhớ ai đã nói vậy). Sau khi muốn xem tất cả các dữ liệu này, các nhà phân tích của tôi đã nhận ra họ là những người thực hiện tất cả các mục nhập dữ liệu - điều kinh dị.


1

Kiểm tra các phần UI của ứng dụng là một cơn ác mộng.

Mọi người xung quanh đều cảm thấy có thẩm quyền để đưa ra một lời khuyên hoặc đặt ra yêu cầu về cách bạn nên làm điều đó.

Sau khi hệ thống hoạt động tốt, sau này ngay cả khi ai đó có thể vô tình nhớ lại những người ngần ngại đức tính trong đó, không ai sẽ nhớ ai đã làm gì.

Nhưng nếu có bất kỳ lỗi nào được nhìn thấy ( một số luôn xảy ra), người đàn ông đầu tiên bị kết án sẽ là lập trình viên GUI, Người dùng đơn giản là chưa bao giờ nhìn thấy những người khác!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.