Trước khi tôi bắt đầu, một tuyên bố từ chối trách nhiệm cần thiết:
Bài viết này là về phát triển web frontend. Tôi không phải là một nhà phát triển front-end có kinh nghiệm. Trong suốt sự nghiệp của mình, tôi đã thử phát triển máy tính để bàn, thiết bị di động và phụ trợ.
Vậy mà mỗi khi có nhu cầu thử tay vào front end, tôi lại rùng mình.
Tôi cảm thấy hào hứng ngay từ đầu - vì front end cho bạn cơ hội xem phép thuật trên màn hình theo cách nhanh nhất có thể - nhưng điều kỳ diệu đó không kéo dài qua một vài bài tập thực hành ở cấp độ hướng dẫn.
Dựa trên ý tưởng của tôi sau kinh nghiệm của tôi. Đây là lý do của tôi tại sao giao diện người dùng là khá khó khăn cho một lập trình viên trung bình.
Tôi có thể sai, trong trường hợp đó, vui lòng gửi phản hồi của bạn trong phần bình luận.
1. Thiết kế giao diện người dùng không phải sở trường của mọi người
Đúng là nhiều công ty có nhà thiết kế UI / UX làm việc riêng biệt với nhà phát triển giao diện người dùng, nhưng điều này không đúng trong hầu hết các trường hợp.
Ngược lại, hầu hết các nhà phát triển frontend được tìm thấy trong các cơ quan thực hiện các dự án cho khách hàng. Người dùng UI / UX là thứ xa xỉ mà nhà phát triển giao diện người dùng sẽ có nếu khách hàng trả tiền cho chúng. Trong các công ty khởi nghiệp, wireframe chủ yếu được tạo ra bởi những người đồng sáng lập, những người không thường xuyên làm việc trong lĩnh vực công nghệ.
Tệ hơn nữa, người dùng UI / UX thuộc về công ty của khách hàng. Người đứng đầu của đại lý được giao cho wireframe và hầu hết các truy vấn của họ không được trả lời. Chuyển đổi wireframe đó sang giao diện người dùng mà người quản lý khách hàng sẽ yêu thích là một nhiệm vụ phụ thuộc nhiều vào vận may của người giao diện người dùng.
Điều này đưa chúng ta đến điểm tiếp theo của chúng ta.
2. Giao tiếp là một vấn đề cần thiết mà lập trình viên front end phải đối mặt
Mục đích của hầu hết tự động hóa là để giảm giao tiếp không cần thiết. Bất cứ nơi nào nó được sử dụng, nó phải được thực hiện với một kênh thích hợp (email) và ở định dạng thích hợp (thông số kỹ thuật, hình ảnh, video).
Hầu hết phát triển phụ trợ là CRUD và cần ít hoặc không cần giao tiếp sau khi lập mô hình. Các chiến lược như bộ nhớ đệm và cải thiện hiệu suất yêu cầu thảo luận nhóm, nhưng ngoài thời điểm quyết định, không cần thông số kỹ thuật pixel hoàn hảo.
Giao diện người dùng trên máy tính để bàn và thiết bị di động được phân định rõ ràng theo màn hình và sự kiện. Wireframe / specs đóng vai trò như kinh thánh của nhà phát triển giao diện người dùng.
Không như vậy với giao diện người dùng web, nơi các SPA có quá nhiều phần tử là mốt mới nhất. Khách hàng hiếm khi vượt ra ngoài việc cung cấp wireframe, không phải là pixel hoàn hảo. Yêu cầu của họ thường mơ hồ và hình ảnh động khiến họ khó hơn.
Sau khi cung cấp một vài phiên bản đầu tiên, họ biết những gì họ không muốn. Sau mười phiên bản nữa, họ có ý tưởng về những gì họ thực sự muốn.
Đến lúc đó, cơ quan hết giờ. Người đứng đầu tội nghiệp của chúng tôi đang đấu tranh cho việc thanh toán của họ, và trong nhận thức sâu sắc, công việc của họ cũng vậy.
Câu chuyện không khác lắm trong trường hợp của các nhà phát triển frontend dùng nội bộ. Các nhóm không thể thống nhất về một định dạng lý tưởng để truyền đạt giao diện người dùng mong muốn. Thường xuyên hơn không, các yêu cầu phụ trợ và phản hồi không được ghi lại đầy đủ hoặc hoàn toàn không được ghi lại. Nếu không có API thực, các nhà phát triển giao diện người dùng phải lãng phí rất nhiều thời gian để khai thác dữ liệu giả mạo. Khi API thực xuất hiện, các thay đổi luôn không thể tránh khỏi do định dạng không được thống nhất.
Mặc dù có khả năng của họ, những người ở frontend thường phụ thuộc vào các nhà phát triển phụ trợ để cung cấp ngay cả những công việc nhỏ nhất.
3. Big Wigs Make the Changes; Small Devs Suffer From Them
Điều này đúng trong bất kỳ doanh nghiệp nào trên thế giới. Tuy nhiên, trong trường hợp của các nhà phát triển giao diện người dùng web, điều này xảy ra thường xuyên hơn nhiều.
Trong bất kỳ lĩnh vực phát triển phần mềm nào khác, kinh nghiệm trước đây của bạn cung cấp cho bạn những tài sản cần thiết nhất: Thư viện và mô-đun mà bạn đã tạo. Đó là những thứ có thể tái sử dụng. Một khi bạn thành thạo chúng, bạn có thể mở rộng quy mô công việc của mình để đạt được những cơ hội tốt hơn.
Ngay cả khi khả năng tương thích bị hỏng, mã của bạn cần được sửa chữa tối thiểu. Nó chỉ là các tệp gói và hình ảnh đám mây mà bạn cần chiến đấu. Bạn hoàn toàn có thể sửa lỗi cho những thứ bạn không viết mã.
Nếu không có gì hoạt động, bạn luôn có thể quay trở lại thế giới không phải JS, nơi mọi thứ vẫn như cũ trong một thời gian dài.
Không phải như vậy với giao diện người dùng web.
Các gói giao diện người dùng web có bán kính lớn nhất. Điều này là do những điều sau đây:
1.Họ đang đối mặt với khách hàng.
2.Những thay đổi trong bất kỳ điều nào sau đây có thể kích hoạt giao diện người dùng của bạn ngừng hoạt động:
- Tiêu chuẩn trình duyệt (hay còn gọi là HTML)
- Cập nhật trình duyệt
- Thay đổi khung
- Các thay đổi về Javascript
Ví dụ về các cuộc khủng hoảng mà các nhà phát triển giao diện người dùng phải đối mặt hàng ngày:
- Những thay đổi về quyền riêng tư? Yêu cầu người phía trước triển khai hộp đồng ý. Tải không nhanh? Đổ lỗi cho họ.
- Mạng quảng cáo mới nhất của bạn đang ẩn video sản phẩm của bạn? Bắt người giao diện người dùng đã thay đổi nó lần cuối.
- Lượt truy cập trước bản cập nhật cuối cùng của Google? Hãy đổ lỗi cho người giao diện người dùng đã thay đổi các thẻ meta SEO.
Nguyên nhân sâu xa của tất cả những cuộc khủng hoảng này là mọi thứ chỉ được thử nghiệm trong quá trình sản xuất. Đây cũng là một lý do chính tại sao nhiều công ty quyết định không thuê một nhân viên bình phong nội bộ và quyết định dựa vào các đại lý không chỉ rẻ hơn mà còn dễ bị đổ lỗi.
Trải nghiệm duyệt web đã giảm 100 lần trong thập kỷ qua, do cuộc chiến giữa các quy định của chính phủ và các công ty kiểm soát web và quảng cáo. Tuy nhiên, mỗi khi thậm chí một người dùng không trả tiền phàn nàn, người đứng đầu sẽ cắn viên đạn.
Phần lớn cuộc chiến diễn ra trên các trang phát hành GitHub của các thư viện / khung mã nguồn mở phổ biến: Angular, React, Vue, v.v. Nhưng họ không chịu trách nhiệm giải trình trực tiếp cho mọi vấn đề của nhà phát triển giao diện người dùng, bởi vì chúng là mã nguồn mở. Do sự thờ ơ của họ, rất khó để theo dõi vấn đề của một người giao diện người dùng trung bình trước những thay đổi cấp cơ sở lớn hơn.
Nếu bạn đã tham gia vào chuyến tàu của khung công tác mới nhất, bạn sẽ đóng góp cho các trang vấn đề GitHub hoặc câu trả lời của StackOverflow. Nhiệm vụ của bạn phải ngồi sau. Cơ hội duy nhất của bạn để ở một vị trí ổn định là dự báo các vấn đề trong cơ sở mã của bạn dọc theo dòng của những thay đổi cấp gốc đó.
Nếu bạn không lên tàu đủ sớm (tức là bạn đang tìm kiếm các câu hỏi SO lâu đời về một vấn đề), bạn có thể đã trở thành người thượng cổ. Trong thế giới frontend, câu này gần như là một câu sáo ngữ:
Đó là năm 20xy, bạn thân, bạn vẫn sử dụng khung 20x (y-1) ?!
Không cần phải nói, những người ở frontend trên web chiến đấu vì sự sống còn của họ khó hơn so với các lập trình viên đồng nghiệp của họ. Các cuộc phỏng vấn của họ chứa đầy những lựa chọn vô cùng chủ quan và các tiêu chuẩn dễ bay hơi, và hầu hết các nhà phát triển có năng lực thường phải đối mặt với sự từ chối đáng sợ.
Kết luận
HTML được phát minh để trở thành một tiêu chuẩn tạo giao diện người dùng dựa trên khai báo. Thay vào đó, nó liên tục bị buộc phải được xử lý bởi các nhà sản xuất trình duyệt, những người muốn cung cấp tính mới và các lập trình viên công nghệ lớn, những người muốn sự đồng nhất trong mọi thứ.
Đáng buồn thay, giao diện người dùng không phải lúc nào cũng dành cho một trong hai. Các doanh nghiệp thường muốn giao diện người dùng của họ có thể dự đoán được, đồng thời bắt mắt và hiệu quả. Đương nhiên, họ không hiểu những thách thức công nghệ mà một người làm việc trước phải đối mặt.
Mặc dù không phải là người của giao diện người dùng web, tôi đã cố gắng liệt kê ra những vấn đề cấp cao mà mọi nhà phát triển giao diện người dùng phải đối mặt. Mặc dù nhiều vấn đề trong số đó cũng tồn tại trong các miền phần mềm khác, nhưng bản chất thực tế của giao diện người dùng khiến chúng trở thành thách thức nhiều hơn đối với các nhà phát triển giao diện người dùng web.
Đó ít nhất là ý kiến của tôi từ kiến thức hạn chế của tôi về phát triển giao diện người dùng.
Nếu bạn có thêm bất kỳ điều gì cần bổ sung hoặc có ý kiến khác, vui lòng bình luận.
Bài viết gốc tại đây.
Hiện tại khóa học Web Frontend tại Techmaster Vietnam vẫn liên tục tuyển sinh các lớp tiếp theo. Và trong tình hình dịch bệnh phức tạp, lớp sẽ chuyển sang học hình thức trực tuyến có tương tác, thời lượng và chất lượng không đổi, vẫn đảm bảo việc làm cho học viên tốt nghiệp.
_Chi tiết khóa học: https://frontend.techmaster.vn/
Liên hệ tư vấn: Mr Thịnh - 0987273764 (zalo).
Bình luận