Giữ mã của Cameron tránh xa các nhà thiết kế?

Tôi xây dựng khá nhiều dự án với một người bạn của tôi, nhưng chúng tôi luôn gặp phải những cạm bẫy lặp đi lặp lại. Tôi biết cách viết PHP, Javascript và tất cả những thứ khác (tôi cũng biết CSS và HTML) để tôi có thể thực hiện hầu hết công việc khi xây dựng chức năng thực tế. Tuy nhiên, anh ta không thể, nhưng anh ta có thể làm một việc mà tôi hầu như không thể: thiết kế các trang web.

Nhưng mỗi lần, chúng tôi vấp phải một vấn đề, vì anh ấy không biết viết mã, nên nó thường làm chậm sự phát triển của chúng tôi khá nhiều. Hiện tại đây là quy trình làm việc của chúng tôi:

1. Chúng tôi đưa ra một tính năng
2. Anh ta xây dựng thiết kế mặt trước (nơi nó nên được đặt, nó sẽ trông như thế nào, v.v.)
3. Anh ấy gửi mẫu hoàn chỉnh cho tôi (bản xuất HTML từ Pinegrow)
4. Tôi tìm kiếm những thay đổi anh ấy đã thực hiện, sau đó thực hiện chúng trong trang web thực tế (kể từ vài tuần, tôi sử dụng CakePHP cho nó).
5. khi một cái gì đó không hoạt động như dự định (ví dụ như, nó không hoạt động như chúng tôi đã lên kế hoạch vì một số lý do), tôi khắc phục vấn đề về phía mình, sau đó gửi lại cho anh ấy mẫu
6. rửa và lặp lại

Quá trình này, như người ta có thể tưởng tượng là rất chậm và không hiệu quả. Vì vậy, câu hỏi của tôi là, làm thế nào chúng ta có thể làm cho quá trình này trơn tru hơn? Tôi đã thấy rất nhiều thứ về việc chúng ta nên sử dụng React và sử dụng RESTful và những gì không, nhưng chúng tôi muốn sử dụng CakePHP cho nó. Một số người có thể hướng dẫn tôi một số tài nguyên hữu ích về nó? Tôi đã tìm kiếm điều này trong một thời gian nhưng chưa bao giờ đi đến một giải pháp tốt cho việc này.

Về cơ bản, tất cả các đối tác của tôi có thể làm là thiết kế trang web. Anh ta không thể sử dụng Docker (tôi sử dụng Docker mọi lúc), PHP, Javascript và hầu hết mọi thứ khác (anh ta biết một số CSS, nhưng chủ yếu làm việc với một WYSIWYGbiên tập viên) Tôi sẵn sàng học nó với anh ta, nhưng anh ta không quan tâm (vì vậy tôi tôn trọng điều đó). Tôi hy vọng ai đó ở đây có thể giúp tôi (và có lẽ những người khác đến sau câu hỏi này) với điều này vì tôi nghĩ đó là một điều quan trọng.

Bạn muốn giải phóng Front End Designer của bạn khỏi mã? Bạn muốn tăng tốc độ tích hợp? Bạn muốn sử dụng các kỹ thuật chuyên nghiệp được sử dụng bởi các trang web trơn nhất? Cho đến nay, công cụ tốt nhất cho việc này là:

Sơn.

Có Sơn. Vâng một số chương trình vẽ nào. Hãy để anh ấy chụp ảnh màn hình trang web của bạn, di chuyển mọi thứ xung quanh và thêm những thứ anh ấy tìm thấy ở nơi khác. Điều này sẽ cho phép anh ta làm việc với tốc độ của ý tưởng của anh ta và giải phóng bạn để uốn mã thành bất kỳ hình dạng nào phù hợp nhất với bạn trong khi cung cấp cho anh ta những gì anh ta cần.

Nếu điều đó vẫn còn quá chậm, hãy nói vì khách hàng đang ở trong phòng với cả hai bạn, tôi khuyên bạn nên có một bộ công cụ tiên tiến hơn nhiều:

Giấy, kéo và băng keo.

Có lẽ một cây bút nếu bạn cảm thấy tham vọng.

Tôi đã sử dụng kỹ thuật này để đưa ra quyết định thành công về chủ đề, phong cách, nội dung và các tính năng chính cho một trang web tại bàn trong Bánh mì Panera với một khách hàng trước khi bất kỳ ai nhận ra chúng tôi đã ăn xong.

Điều đó sẽ khiến anh ấy nhanh lên, nó sẽ giải phóng bạn khỏi "mã" của anh ấy, và đó thực sự là cách mạnh mẽ nhất để phát triển giao diện người dùng. Anh ta có thể bắt đầu thực hiện các bài kiểm tra khả năng sử dụng trước khi bạn viết một dòng mã.

Bạn có thể nghĩ rằng "ồ điều này tốt khi bắt đầu nhưng bạn không sử dụng điều này một khi trang web được phát triển". Không đúng. Nó hoạt động tốt như trên các trang web ổn định. Nhưng bây giờ hầu hết các ảnh chụp màn hình đến từ trang web của riêng bạn.

Điều gì sẽ xảy ra nếu Front End Designer của bạn muốn sử dụng một số công cụ tạo mã để thực hiện giả lập của mình? Tốt thôi nhưng đừng suy nghĩ một chút rằng bạn phải sử dụng "mã" của anh ấy. Những gì bạn cần tôn trọng là quyết định của anh ấy về cái nhìn, dòng chảy và cách trình bày. Những gì xảy ra đằng sau bức màn để biến điều đó thành hiện thực không phải là lĩnh vực chuyên môn của anh ấy. Nó là của bạn. Chịu trách nhiệm về điều đó.

Chỉ cần tôn trọng công việc của anh ấy đủ để khi bạn hoàn thành, bạn chỉ cho anh ấy thấy nó diễn ra như thế nào. Hãy để anh ta nitpick tất cả mọi thứ người dùng sẽ trải nghiệm. Hãy chuẩn bị để có được những ý tưởng mới.

Đây là sự phát triển lặp đi lặp lại. Đừng làm nhiều trước khi hỏi. Làm ít nhất có thể. Hỏi càng thường xuyên càng tốt. Đặt đồ chơi trên bàn của bạn để giữ cho anh ấy giải trí trong khi bạn thực hiện ý tưởng mới nhất của anh ấy để anh ấy có thể xem xét nó ngay khi nó tải. Tiếp tục như vậy cho đến khi gặp khách hàng.

Nếu mã mà Front End Designer của bạn tạo ra thực sự có giá trị rắc rối thì bạn cần học cách tích hợp mã của mình với mã của mình. Đối với điều này, tôi khuyến khích bạn học kiểm soát nguồn . Tìm hiểu nó tốt đến mức bạn có thể dạy Front End Designer của mình cách sử dụng nó.

Chỉ khi cả hai bạn có thể sử dụng một công cụ kiểm soát nguồn một cách đáng tin cậy, tôi mới khuyên bạn nên căn cứ kế hoạch tích hợp của mình vào việc hợp nhất mã. Tại thời điểm này, bạn của bạn sẽ xứng đáng được thay đổi tiêu đề từ Front End Designer sang Front End Developer.

Bây giờ ngay cả khi bạn làm điều này, nó sẽ không làm tôi ngạc nhiên nếu kỹ thuật chụp hình nguệch ngoạc trên màn hình vẫn không trở thành cách nhanh nhất để hai bạn hợp tác.

Có lẽ bạn không thể nhận được sự hỗn loạn của tất cả những thay đổi này. Nó đang tạo ra quá nhiều công việc. Chà, nó được gọi là phần mềm vì nó chấp nhận thay đổi. Nếu không, chúng tôi sẽ có một Kỹ sư điện làm điều đó trên một con chip chuyên dụng. Có thể bạn cần phải tiếp cận kiến ​​trúc sư để chuyển logic hành vi của bạn ra khỏi giao diện người dùng để thay đổi giao diện người dùng sẽ không ảnh hưởng đến các quy tắc kinh doanh cốt lõi của bạn. Nếu bạn tăng tốc Nhà thiết kế Front End, bạn cần sẵn sàng theo kịp họ.

Lý do chính đáng duy nhất để buộc Nhà thiết kế Front End tạo mã là vì bạn mệt mỏi và muốn làm chậm chúng. Chà, tôi đoán đó không thực sự là một lý do "tốt".

Về mặt công cụ, quy trình làm việc tối ưu mà tôi thấy là sử dụng Phác thảo và Zeplin. Phác thảo là một công cụ thiết kế thẳng. Tương đương với Photoshop hoặc InDesign, nhưng được tối ưu hóa để thiết kế các ứng dụng và trang web. Zeplin là một công cụ để chia sẻ và phê duyệt các thiết kế trong Phác thảo (hoặc Photoshop). Nó có thể đưa ra các phép đo pixel chính xác và thậm chí các đoạn mã cho CSS hoặc mã bố cục khác và xuất tài sản đồ họa. Sau khi thiết kế được thiết lập, nó được bàn giao cho nhà phát triển. Tại thời điểm này, nhà phát triển chọn nó và xây dựng giao diện người dùng. Sau đó, nó có thể quay trở lại nhà thiết kế cho QA trực quan. Bất cứ điều gì anh ta thấy sai với nó, chỉ nên đăng nhập như một lỗi để được bạn ưu tiên và giải quyết.

khi một cái gì đó không hoạt động như dự định (ví dụ như, nó không hoạt động như chúng tôi đã lên kế hoạch vì một số lý do), tôi khắc phục vấn đề về phía mình, sau đó gửi lại cho anh ấy mẫu

Đó là gốc rễ của những rắc rối của bạn. Dòng chảy của thiết kế phải luôn luôn từ Designer to Developervà không bao giờ đảo ngược. Các sửa đổi và thay đổi nên được thực hiện bởi nhà thiết kế, và sau đó được đẩy tới bạn để thực hiện trong trang web. Bạn luôn có thể tự sửa lỗi nhanh, nhưng hãy cố gắng chấp nhận rằng những sửa lỗi nhanh đó chỉ là tạm thời. Nhà thiết kế cần quay lại các thiết kế của mình và tìm ra giải pháp thích hợp. Sau đó, anh ấy thúc đẩy sự thay đổi cho bạn, và nếu nó xảy ra giống như cách khắc phục nhanh của bạn thì thật tuyệt, nếu không thì bạn cập nhật từ các thiết kế của anh ấy.

Anh ấy gửi mẫu hoàn chỉnh cho tôi (bản xuất HTML từ Pinegrow)

Đừng trở nên nghiện nhận HTML mà bạn có thể làm việc. Sẽ tốt hơn nếu bạn triển khai công nghệ trang web (Bootstrap, CSS, jQuery, React, PHP, v.v .. vv .. vv ..) theo cách bạn cần. Sau đó, bạn tái tạo thiết kế của mình bằng cách sử dụng các công cụ đó. Nếu HTML mà anh ấy cung cấp cho bạn là một khởi đầu nhanh chóng thì thật tuyệt, nhưng sau này khi dự án phát triển thì nó sẽ không được sử dụng nhiều. Bạn sẽ cần tự thực hiện các thay đổi vì chỉ có bạn hiểu công cụ tạo khuôn mẫu của mình (ví dụ: chế độ xem CakePHP, mẫu, plugin, thành phần, v.v., v.v.)

Quá trình này, như người ta có thể tưởng tượng là rất chậm và không hiệu quả.

Luôn luôn là như vậy. Nhà thiết kế không lập trình viên. Họ dành thời gian để tìm ra những gì tốt nhất cho người dùng và đôi khi họ mắc lỗi. Họ không hiểu các khái niệm như các thành phần, khung và như vậy. Là lập trình viên, bạn phải nói chuyện với nhà thiết kế của mình và chia sẻ cách tôi thực hiện những gì bạn thiết kế .

Nhà thiết kế bị kẹt ở giữa. Một mặt họ phải làm hài lòng nhu cầu của lập trình viên, và mặt khác họ phải làm hài lòng nhu cầu của người dùng.

Vì vậy, câu hỏi của tôi là, làm thế nào chúng ta có thể làm cho quá trình này trơn tru hơn?

Tôi đã thấy rằng việc ngồi bên cạnh nhà thiết kế và lập trình ở đó thực sự giúp ích cho việc giao tiếp. Nếu hai bạn đang làm việc từ xa, thì hãy tiếp tục chạy facetime trong vài ngày. Nó thực sự giúp tăng tốc mọi thứ.

Tôi đã thấy rất nhiều thứ về việc chúng ta nên sử dụng React và sử dụng RESTful và những gì không, nhưng chúng tôi muốn sử dụng CakePHP cho nó.

CakePHP là một trong những khuôn khổ tốt nhất trên hành tinh (tiết lộ đầy đủ, tôi thuộc nhóm nòng cốt CakePHP).

Cake là một khung phát triển thỏ, nơi các tính năng được thiết kế để xây dựng trang web một cách nhanh chóng. Tôi biết rằng âm thanh như một doanh số bán hàng, nhưng đây là những gì nó được phân loại là. Có nhiều khung khác được phân loại là thỏ. Java sẽ là một ví dụ về một khung công tác nhiều doanh nghiệp hơn thỏ. Nếu bạn đang sử dụng ngôn ngữ đó, thì tôi đã có một đề nghị thay đổi. Vì bạn đang sử dụng CakePHP. Tôi sẽ tranh luận bạn nên ở lại với nó.

CakePHP làm cho một máy chủ back-end tốt nếu bạn cần API RESTful.

React / Angular / Vue đều là các khung công tác phổ biến và đang thịnh hành, nhưng chúng đã tồn tại rất lâu. CakePHP mặt khác đã được hơn 13 năm. Quan điểm của tôi không phải là một lời chỉ trích. Thực tế là các thư viện JavaScript này có thời hạn sử dụng ngắn. Trong 5 năm tất cả chúng ta sẽ nói về một cái gì đó mới, nhưng tôi nghi ngờ CakePHP vẫn sẽ tồn tại.

Vì vậy tôi nói. Sử dụng React / Angular / Vue ngay bây giờ khi chúng còn nóng, nhưng không được cam kết với chúng. Một cái gì đó mới và tốt hơn sẽ sớm xuất hiện. Tôi nghĩ rằng chúng ta đang sống trong một thế giới hiện tại nơi bạn không thể xây dựng các trang web tốt mà không có chúng.

Một số người có thể hướng dẫn tôi một số tài nguyên hữu ích về nó?

Yêu cầu cho danh sách là lạc đề ở đây. Lấy làm tiếc.

CHỈNH SỬA :

Tôi đã bỏ lỡ phần về theo dõi thay đổi thiết kế.

Yêu cầu nhà thiết kế của bạn lưu đầu ra HTML của anh ấy trong BitBucket (họ có kho riêng tư miễn phí). Sau đó, bạn có thể theo dõi và so sánh bằng cách sử dụng trang web BitBucket. Mỗi khi nhà thiết kế thực hiện một thay đổi lớn, anh ta thêm một chi nhánh mới với số phiên bản.

Nó sẽ tương đối dễ dàng cho anh ta để làm điều này, và điều này sẽ cho phép bạn có một nơi để bình luận về những thay đổi đã nói. Ví dụ; anh ta có thể thực hiện một yêu cầu kéo để cập nhật kho lưu trữ nơi bạn thực hiện đánh giá các thay đổi trước khi chúng được hợp nhất.

Bạn cần tách hai điều này:

1. Thiết kế UX & UI, một hoạt động không mã hóa
2. Thực hiện, chắc chắn là một hoạt động mã hóa

Nhà thiết kế nên sử dụng các công cụ sáng tạo như Marvel chỉ dành cho thiết kế. Không nên quan tâm đến việc thiết kế bất cứ điều gì với mã, HTML, CSS, v.v. Màu sắc, kích thước, tính thẩm mỹ, tương tác, hoạt hình là tất cả những điều anh ta nên tập trung vào.

Lập trình viên sẽ nhận được các tài sản và mô phỏng (với các tương tác và hình ảnh động) và sẽ làm cho nó xảy ra bằng cách lập trình phần mềm. Điều này bao gồm HTML và CSS là tốt. Lập trình viên cũng có thể sử dụng các công cụ tạo bên mình.

Để tăng tốc luồng công việc, tôi khuyên bạn nên sử dụng một công cụ tối thiểu như Trello và liên kết / tài liệu mọi thứ cho mỗi đơn vị công việc.

Làm thế nào chúng ta có thể làm cho quá trình này trơn tru hơn?

Nhấn mạnh vào kiểm soát phiên bản

Phân nhánh phần mềm và Đại học song song

• Làm việc trên không có mã không trong kiểm soát phiên bản. Dấu chấm. Và tôi có nghĩa là đình công cho đến khi dự án hoàn toàn nằm trong một VCS.
• Chi nhánh chính thức, tự do, địa phương
  • Chính thức: phân nhánh cho các bản phát hành và các phần phụ của bản phát hành, sửa lỗi thử nghiệm chính thức, v.v ... Phát triển một kế hoạch kiểm soát phiên bản chính thức, tức là viết nó xuống.
  • Tự do: Ngoài việc đánh số phát hành chính thức gồm 4 phần, chi nhánh nếu ruột của bạn cho bạn biết đó có thể là một ý tưởng tốt.
  • Tại địa phương: Tôi đã giữ một repo cá nhân với các chi nhánh không bao giờ có ý định tiêu thụ đội vì lúc đầu, chúng tôi không có chi nhánh và tôi thường có các thử nghiệm, thăm dò, chỉ trong trường hợp, v.v.

Kỹ sư thoát khỏi API phần mềm trung gian của bạn

Những lợi ích:

• Tính ổn định - ngay cả khi mã cơ bản đang phát triển.
• Mã kiểm tra
• Tái sử dụng
• Một công cụ giao tiếp nhóm
• Đó là một hợp đồng. Một lời hứa về các dịch vụ được thực hiện (ý định chơi chữ)
• Mã hóa trong vương quốc của RẮN == lập trình viên bảo trì hạnh phúc

Đó là câu hỏi, đừng nói nguyên tắc được áp dụng theo cách bắt buộc ám ảnh. Nếu UI đang thao túng một thuộc tính lớp doanh nghiệp, điều đó là sai.

Tất cả mọi thứ và bất cứ điều gì về các đối tượng kinh doanh phải có trong BO nói. Ngay cả những thứ tầm thường có vẻ được thực hiện tốt nhất trong UI - thậm chí là một LỘC. Minuita như thêm 2 giá trị do người dùng cung cấp - tất cả logic liên quan bao gồm xác thực phải nằm trong API lớp nghiệp vụ. Dự phòng IMO đôi khi là OK. Để giảm thiểu sự dư thừa có thể có các đối tượng lớp doanh nghiệp nhỏ, tập trung mà UI được phép truy cập đầy đủ.

Mọi thứ và mọi thứ mà UI cần từ các đối tượng kinh doanh nên được API'ed. Ví dụ, có các phương thức rõ ràng nối (các) đối số của nó với các trình xử lý sự kiện.

Coi chừng khung như một cái nạng

Trong tay của những người không có kỹ năng, các khung và IDE không phải là rào cản đối với các quái vật phim B mà họ tạo ra.

Với các khung như React, bạn có thể nói đó là tất cả các phía máy khách, không có lớp logic nghiệp vụ phía sau. Ý tưởng chính ở đây là tách rời những gì người dùng nhìn thấy từ những gì chương trình làm. Điều đó là có thể. Nó không chỉ là một máy chủ vật lý so với điều trình duyệt của người dùng.

Tôi nghĩ rằng đó là một chỉ báo tốt về sự non nớt trong nghề nghiệp và thực tiễn mà chúng tôi chấp nhận rằng những người thiết kế, không thể làm được.

Điều này sẽ không được chấp nhận trong hầu hết các ngành nghề khác.

Thật hợp lý khi mong đợi một nhà thiết kế chuyên về thiết kế ứng dụng / trang web biết CSS và HTML đủ tốt để cung cấp cho bạn các tệp làm việc và có thể sử dụng được loại đó.

Nhà thiết kế cung cấp trình soạn thảo đồ họa WYSIWYG là nhà thiết kế hình ảnh hoặc đồ họa. Có nhiều loại nhà thiết kế khác nhau.

Tuy nhiên, cũng có nhiều loại cấp độ kỹ năng, khả năng và kinh nghiệm khác nhau. Một người thiết kế đồ nội thất có thể làm điều đó chỉ trên máy tính với các công cụ thiết kế 3D, trong trường hợp đó, kiến ​​thức của họ về cách biến máy tiện hoặc vận hành bộ định tuyến CNC có thể hoàn toàn là lý thuyết. Họ làm thiết kế của họ và sau đó gửi chúng đi để được thực hiện bởi những người khác.

Ngược lại, một số nhà thiết kế chuyên gia có thể kiểm soát toàn bộ quá trình và có khả năng và kiến ​​thức để xây dựng đồ nội thất của họ với mọi chi tiết, thậm chí có thể làm thủ công.

Bạn sẽ không thể thuyết phục bạn của bạn thay đổi cách làm việc của họ. Nếu bạn muốn có một nhà thiết kế web có các kỹ năng HTML và CSS để xây dựng các thiết kế của riêng họ, bạn sẽ cần tìm một thiết kế.