Giờ giải lao #13: Những điều mà mọi người mới lập trình nên biết; 4 cách để kết hợp tư duy thiết kế vào quá trình phát triển của bạn

Những điều người mới lập trình nên biết

Nguồn: Stackoverflow Là một nhà phát triển, bạn sẽ nghe nhiều lý thuyết khác nhau về mã sẽ trông như thế nào. Một số người tin rằng ứng dụng càng có ít dòng mã thì càng dễ đọc. Nhưng điều này chỉ đúng một phần. Tôi thích đánh giá chất lượng mã bằng các tiêu chí sau:

1. Mã phải nhất quán, nhiều thông tin và được ghi chép đầy đủ.
2. Code nên sử dụng tính năng ổn định, hiện đại.
3. Mã không được phức tạp hoặc bị hỏng một cách không cần thiết.

Nếu bạn quyết định giảm số dòng mã mà không đáp ứng được một trong các tiêu chí trên thì điều này sẽ trở thành một vấn đề. Đừng làm thế.

Đọc code của người khác rất khó

Thật vậy, tỷ lệ thời gian dành cho việc đọc và viết mã là hơn 10 trên 1. Nhưng bạn không thể làm gì nếu không đọc mã của người khác. Bạn sẽ phải đọc mã của người khác. Và bạn càng cải thiện kỹ năng của mình sớm thì càng tốt. Hãy thử nghiên cứu mã của người khác bằng cách sử dụng kho GitHub mở. Bạn có thể thực hành bất cứ lúc nào: chỉ cần tìm một dự án phù hợp với mình và đi sâu vào từng dòng. Một cách khác để cải thiện khả năng đọc mã của người khác là bạn bắt đầu sao chép kiểu đó. Khi bạn viết mã theo phong cách của người khác, nó không chỉ cải thiện kỹ năng đọc của bạn mà còn khiến mã đó trở nên quen thuộc hơn với bạn. Hãy thử một lần.

Bạn sẽ không bao giờ viết được mã “hoàn hảo”

Tôi là nhà phát triển solo trong bốn năm trước khi bắt đầu làm việc theo nhóm. Trong phần lớn thời gian này, tôi tin rằng bất kỳ lập trình viên có kinh nghiệm nào cũng viết mã hoàn hảo. Theo tôi, việc học viết code hoàn hảo chỉ là vấn đề thời gian và công sức. Nhưng khi tôi gia nhập nhóm, tôi nhận ra rằng không ai viết được mã “hoàn hảo”. Đúng vậy, mã cuối cùng được đưa vào hệ thống hầu như luôn “hoàn hảo”. Tại sao điều này xảy ra? Đó là tất cả về phân tích mã. Tôi làm việc với một đội ngũ kỹ sư thực sự xuất sắc. Đây là một số lập trình viên có năng lực và tự tin nhất mà tiền có thể thuê. Nhưng mỗi người trong số họ (bao gồm cả tôi) sẽ hoảng sợ thực sự nếu có ai đó đề xuất đưa mã chưa được kiểm tra vào ứng dụng. Ngay cả khi bạn nghĩ mình là Bill Gates tiếp theo, bạn cũng sẽ mắc sai lầm. Tôi thậm chí không nói về lỗi logic, tôi đang nói về lỗi chính tả, thiếu ký tự. Những điều mà bộ não của bạn đôi khi không thể nắm bắt được. Những điều mà chỉ có thể nhận thấy bằng đôi mắt trong trẻo. Cố gắng làm việc với những người chú ý đến từng chi tiết và sẵn sàng phê bình công việc của bạn. Ban đầu sẽ khó chấp nhận những lời chỉ trích, nhưng đó là cách đáng tin cậy duy nhất để cải thiện chất lượng mã của bạn. Cố gắng hết sức để không tỏ ra phòng thủ khi xem xét mã và không bao giờ nhận những lời chỉ trích mang tính cá nhân. Bạn không phải là mã của bạn.

Bạn không nên viết code 8 tiếng một ngày

Không ai có thể cho bạn biết chính xác họ dành bao nhiêu thời gian mỗi ngày để viết mã. Nhưng trên thực tế, rất ít người viết code nhiều hơn 4 tiếng mỗi ngày. Những người không đồng ý với điều này hoặc là ngoại lệ của quy tắc hoặc làm việc cho các công ty đối xử tệ với nhân viên của họ. Lập trình là một công việc căng thẳng và tốn nhiều tinh thần. Hoàn toàn sai lầm khi nghĩ rằng ai đó sẽ viết code 8 giờ một ngày, 5 ngày một tuần. Sẽ có những trường hợp hiếm hoi bạn cần phải hoàn thành đúng thời hạn, nhưng khi tôi nói hiếm khi có nghĩa là gần như không bao giờ. Đừng để công việc đè nặng lên bạn và buộc bạn phải làm thêm giờ. Tôi không gợi ý rằng bạn chỉ làm việc bốn giờ một ngày. Bốn giờ còn lại thường được dành tốt nhất cho những việc như:

• học các công cụ, chức năng, ứng dụng mới;
• thảo luận về quy trình làm việc với đồng nghiệp;
• giúp đỡ đồng nghiệp gặp khó khăn trong công việc;
• lập kế hoạch nhiệm vụ;
• phân tích mã;
• cuộc họp/cuộc họp kinh doanh.

Tôi cũng thực sự khuyên bạn nên nghỉ giải lao thường xuyên trong ngày và tập thể dục (ít nhất là một chút). Những tác dụng tích cực của việc tập thể dục đã được chứng minh từ lâu.

4 cách để kết hợp tư duy thiết kế vào quá trình phát triển của bạn

Source Tech Beacon Để tạo ra sản phẩm đáp ứng nhu cầu của khách hàng, bạn sẽ phải cân nhắc xem họ muốn gì. Nếu bạn đã viết một ứng dụng có điều hướng khó hiểu hoặc giao diện tải dài không cần thiết, hãy chuẩn bị tinh thần cho những thất bại trong tương lai. Là một lập trình viên, bạn có thể phải nghiên cứu sâu hơn về thiết kế của sản phẩm mà nhóm của bạn đang làm việc. Kiểu hợp tác này rất hữu ích vì mỗi người nhận thấy những điều mà người kia có thể không nhận thấy. Tôi cung cấp cho bạn 4 lời khuyên về cách nhà phát triển và nhà thiết kế có thể làm việc cùng nhau.

1. Hãy tham gia ngay từ đầu

Đừng cho rằng thiết kế luôn được ưu tiên hàng đầu và phát triển là thứ hai. Điều này có thể đúng nhưng không có nghĩa là các nhà phát triển không nên tham gia vào quá trình thiết kế. Lập trình viên có thể cung cấp thông tin kỹ thuật quan trọng về cách thực hiện dự án, đồng thời các nhà thiết kế hiểu rõ hơn mong muốn của người dùng. Tốt hơn hết bạn nên tìm hiểu càng sớm càng tốt chức năng nào không thể thực hiện được về mặt kỹ thuật hoặc không đáp ứng yêu cầu của người dùng. Nếu các nhà thiết kế và nhà phát triển làm việc cùng nhau, các vấn đề có thể được phát hiện và giải quyết ngay lập tức thay vì sau khi thiết kế được phê duyệt. Nhiều công ty áp dụng cách tiếp cận hợp tác để phát triển phần mềm. Điều này có nghĩa là các thành viên trong nhóm không chỉ chịu trách nhiệm về giai đoạn hoặc đoạn mã của riêng họ mà còn chịu trách nhiệm tập thể về mọi thứ, từ thiết kế đến thử nghiệm.

2. Tìm hiểu quy trình UX

Những người không quen thuộc với UX (trải nghiệm người dùng) có thể không hiểu tại sao các nhóm thay đổi thiết kế nhiều lần chỉ vì những chi tiết tưởng chừng như nhỏ nhặt. Mỗi bước trong quy trình UX diễn ra vì một lý do: cung cấp trải nghiệm tốt nhất có thể cho người dùng. Vì vậy, điều quan trọng là phải chú ý tạo quy trình UX ngay từ đầu. Nó có thể bao gồm:

• nghiên cứu mục đích của dự án;
• tạo wireframe - một thiết kế đơn giản cho phép bạn xác định các đặc điểm chính của sản phẩm;
• thêm các chi tiết tốt hơn vào thiết kế dự án, chẳng hạn như giao diện người dùng;
• người dùng thử nghiệm các thiết kế. Đây có lẽ là giai đoạn quan trọng nhất của quá trình phát triển UX. Điều này cung cấp thông tin có giá trị về sản phẩm trước khi bạn dành thời gian phát triển nó;
• Lặp lại: Sử dụng phân tích kết quả kiểm tra, lặp lại thiết kế để cải thiện trải nghiệm người dùng.

Các nhóm lặp lại các bước thiết kế và thử nghiệm nhiều lần cho đến khi không còn thay đổi nào hoặc khi thời gian cho phép. Điều này thường có nghĩa là bạn sẽ có nhiều phiên bản thiết kế.

3. Theo dõi quá trình phát triển thiết kế

Sẽ rất tệ khi các nhà thiết kế tạo ra một dự án mà không hỏi ý kiến ​​​​của các nhà phát triển. Nó phản tác dụng. Điều quan trọng đối với DevOps là đặt ra các quy tắc để các nhà phát triển có quyền truy cập vào bản thiết kế ở các định dạng dễ truy cập như PNG hoặc PDF. Sự hợp tác hiệu quả giữa các nhà phát triển và nhà thiết kế là rất quan trọng để triển khai thành công một ứng dụng. Tránh mù quáng bàn giao một thiết kế đã hoàn thiện bằng mọi giá. Tốt hơn là sửa lỗi ngay từ đầu thay vì sửa lỗi ở cuối.

4. Thống nhất về giai đoạn nào dự án sẽ được trình chiếu cho bạn

Khi các nhà phát triển được yêu cầu tạo phiên bản khả thi tối thiểu của sản phẩm (MVP), họ cần biết các yêu cầu đối với phiên bản cuối cùng ngay từ đầu. Điều này là cần thiết để tránh những vấn đề với những kỳ vọng không chính đáng. Nhà thiết kế phải hiển thị cả hai phiên bản thiết kế cho nhà phát triển: cả phiên bản MVP và phiên bản cuối cùng. Điều này sẽ giúp triển khai MVP, có tính đến những gì khách hàng mong đợi thấy trong phiên bản cuối cùng. Khi các nhà thiết kế và nhà phát triển làm việc cùng nhau, họ sẽ thu được nhiều lợi ích. Mỗi người trong số họ đều có kiến ​​thức có thể áp dụng vào kinh nghiệm của người kia. Các nhà phát triển có thể cung cấp cái nhìn sâu sắc có giá trị về những tính năng nào không thể triển khai trong thiết kế. Mặt khác, việc cộng tác với một lập trình viên sẽ giúp nhà thiết kế không cần phải làm lại dự án, do đó sẽ tiết kiệm thời gian cho toàn nhóm.