Nghỉ giải lao #43. 6 lỗi lập trình khiến bạn không thể có được công việc mơ ước Cách đóng góp cho phần mềm nguồn mở lần đầu tiên

6 lỗi lập trình khiến bạn không thể có được công việc mơ ước

Nguồn: Medium Để tìm việc làm lập trình viên, bạn cần có kho Git. Đây là một trong những điều đầu tiên nhà tuyển dụng sẽ xem xét. Để kho lưu trữ của bạn tạo ấn tượng tích cực, nó phải chứa các dự án có những thay đổi gần đây. Chỉ hiển thị những dự án mà bạn tự hào chứ không phải mọi dòng mã bạn từng viết. Đây là những điều cơ bản khi làm việc với một kho lưu trữ. Hãy nhớ rằng sớm hay muộn ai đó cũng sẽ xem xét mã của bạn để xem liệu bạn có phù hợp với công ty hay không. Đây sẽ là thời điểm quyết định đối với bạn. Sau vài phút, nhà tuyển dụng sẽ quyết định có nên mời bạn phỏng vấn hay không. Và ở đây có cả tin tốt và tin xấu. Tin xấu là một sai lầm đơn giản có thể làm tổn hại đến cơ hội nhận được công việc của bạn. Tin tốt là mọi người thường không muốn đào sâu vào mã. Họ cần hiểu biết chung về mã và kiến ​​trúc của bạn. Vì vậy, bạn không cần phải là thiên tài - bạn chỉ cần là một lập trình viên giỏi. Dưới đây là một số lỗi người mới thường mắc phải. Hãy tránh xa họ và cơ hội phỏng vấn của bạn sẽ tăng lên đáng kể.

Nhận xét lỗi thời

Các lập trình viên có ý kiến ​​​​khác nhau về ý kiến. Một số yêu họ, những người khác ghét họ. Chúng ta không thể đi đến kết luận chung về việc liệu có đáng để bình luận mã hay không và trong trường hợp nào nên làm điều đó. Nhưng mọi người đều nhất trí một điều: nếu bạn có nhận xét, chúng phải khớp với mã của bạn. Bình luận tồn tại để giải thích mã. Khi mã của bạn phức tạp hoặc không rõ ràng, bạn cần trợ giúp để người đọc hiểu nó. Ngoài ra, bạn cần thay đổi nhận xét của mình khi thay đổi mã. Nếu bạn không làm điều này, bình luận của bạn sẽ không còn hữu ích nữa. Một bình luận xấu còn tệ hơn nhiều so với không có bình luận. Tệ hơn nữa, các bình luận sẽ được đánh dấu trong mã. Các IDE hiện đại làm nổi bật các nhận xét bằng màu khác để dễ đọc hơn. Bằng cách thêm nhận xét, bạn đang đặt dấu hiệu “đọc cho tôi” vào mã. Bằng cách này, mọi sự khác biệt giữa nhận xét và mã sẽ dễ dàng được phát hiện. Hãy chọn nhận xét của bạn một cách khôn ngoan và nhớ cập nhật chúng cùng với mã của bạn. Bằng cách này họ sẽ phục vụ bạn tốt.

Sự kết hợp của các thư viện và ngôn ngữ có cùng trường hợp sử dụng

Trước cuộc phỏng vấn đầu tiên, tôi phải giải quyết một vấn đề tuyển dụng. Đó là một ứng dụng web đơn giản, vì vậy tôi đã viết một số mã, tìm kiếm trên Google một vài câu hỏi phức tạp và ứng dụng đã sẵn sàng. Trong cuộc phỏng vấn, nhà tuyển dụng đã hỏi tôi tại sao tôi lại trộn lẫn mã jQuery với JavaScript đơn giản trong toàn bộ mã. Câu trả lời của tôi? “Ừm…” Thành thật mà nói, tôi đã dán một vài đoạn mã từ Stack Overflow. Tôi không nghĩ nhiều về nó. Mã đã hoạt động nên tôi tiếp tục. Lỗi này rất phổ biến ở những nhà phát triển mới. Chúng ta quá tập trung vào việc giải quyết các vấn đề trong công việc mà không chú ý đến cách mình thực hiện nó. Đừng trở thành một trong những người mới rơi vào cái bẫy này. Kiểm tra từng dòng mã và đảm bảo bạn biết lý do tại sao bạn đặt nó ở đó.

Lặp lại mã

Đừng lặp lại chính mình (DRY) là một giáo điều lập trình. Tạo sự trừu tượng cho mã lặp đi lặp lại là bản chất của lập trình. Vâng, lúc đầu có thể khó khăn. Khi bạn muốn giải quyết một vấn đề, bạn sẽ làm nó bằng mọi cách có thể. Sau đó, bạn chuyển sang các nhiệm vụ khác và mã lặp đi lặp lại vẫn ở bên bạn. Bạn có thể bỏ thói quen này bằng cách đặt ra cho mình một bộ quy tắc. Mỗi khi bạn tinh chỉnh một tính năng, hãy đọc lại mã và xem liệu bạn có thể làm gì để thay đổi nó hay không. Hãy nhớ rằng phiên bản đầu tiên của mã thường sai và bạn có thể cải thiện nó. Khi bạn nhận thấy mã trùng lặp, hãy dành thời gian để nghiên cứu nó. Bằng cách này, bạn có thể tìm ra cách tốt nhất để viết lại nó (ví dụ: sử dụng vòng lặp hoặc tạo một hàm mới). Nếu bạn thực hiện việc dọn dẹp này mọi lúc, bạn sẽ có được mã đáng tin cậy và thanh lịch hơn.

Lỗi chưa xử lý

Hầu như không thể tạo ra bất kỳ ứng dụng có ý nghĩa nào luôn hoạt động hoàn hảo. Cho dù bạn đang điền vào cơ sở dữ liệu hay thực hiện lệnh gọi API thì vẫn xảy ra lỗi. Các lỗi chưa được xử lý không chỉ có thể khiến các chức năng riêng lẻ ngừng chạy mà thậm chí có thể khiến toàn bộ ứng dụng bị lỗi. Dự đoán các lỗi có thể xảy ra là dấu hiệu của một lập trình viên có năng lực. Bất cứ khi nào bạn truy cập hoặc cập nhật bất kỳ dữ liệu bên ngoài nào, bạn cần chuẩn bị cho trường hợp xấu nhất. Gắn cờ các vấn đề tiềm ẩn theo cách không làm cho ứng dụng trở nên khó sử dụng. Điều này sẽ cho phép người đọc mã của bạn (và có thể cả bạn) nhanh chóng tìm ra lỗi. Nó cũng sẽ cho nhà tuyển dụng thấy rằng bạn có thể viết mã gắn kết.

Thiếu tính nhất quán

Tính nhất quán là dấu hiệu của phần mềm chất lượng. Nó làm cho mã dễ đọc và bảo trì hơn. Mã được tạo theo kiểu thống nhất sẽ dễ dự đoán hơn và đánh giá hiệu suất của chương trình dễ dàng hơn. Ở mức độ trừu tượng cao hơn, khó đạt được tính nhất quán. Sẽ phải mất nhiều năm để thành thạo nó, vì vậy bạn cần bắt đầu học kỹ thuật này càng sớm càng tốt. Hãy nhớ tạo tiêu đề chỉ bằng một ngôn ngữ. Có lẽ nó phải là tiếng Anh, nhưng trong các dự án cá nhân, bạn có thể đặt tên biến và hàm bằng bất kỳ ngôn ngữ nào miễn là nó luôn cùng một ngôn ngữ. Nếu bạn nhất quán thì việc bạn sử dụng tab hay dấu cách sẽ không thành vấn đề. Tạo hoặc chọn một hướng dẫn về phong cách và luôn bám sát nó. Bạn cũng nên sử dụng một công cụ như Prettier . Nó thực sự giúp giữ cho mã được định dạng một cách nhất quán. Dù bạn sử dụng công cụ và phong cách nào, hãy sử dụng chúng một cách nhất quán. Ngay cả khi bạn viết mã xấu theo một phong cách nhất quán, điều đó thường tốt hơn mã tốt không nhất quán vì nó dễ sửa hơn nhiều.

Hiểu sai về công cụ

Trong một dự án điển hình, bạn có thể sẽ phải sử dụng một số thư viện bên ngoài. Nhiều lập trình viên cài đặt thư viện gần như tự động vì chúng được sử dụng trong mọi dự án. Thư viện bên ngoài rất tuyệt vời vì chúng là cách đã được chứng minh để giải quyết các vấn đề tái diễn. Tuy nhiên, các nhà phát triển mới thường không hiểu họ đang sử dụng thư viện nào và cuối cùng thêm thư viện này chồng lên thư viện khác hoặc triển khai lại một số chức năng hiện có. Mỗi khi bạn cài đặt một thư viện trong dự án của mình, hãy đọc hoặc ít nhất là xem tài liệu. Kiểm tra các phương thức và thuộc tính bạn có thể sử dụng và đảm bảo bạn hiểu vấn đề nào thư viện nên giải quyết và vấn đề nào yêu cầu sử dụng công cụ khác. Bằng cách này, bạn có thể chọn công cụ phù hợp cho công việc và giải thích các lựa chọn của mình.

Cách đóng góp cho phần mềm nguồn mở lần đầu tiên

Nguồn: Jamestucker.dev Một ngày nọ, tôi thấy một tweet từ Evan Yu (người tạo ra Vue.js ) về một kho lưu trữ mới mà anh ấy đang làm việc và nó khiến tôi quan tâm. Tôi quyết định tôi muốn đóng góp cho nó! Điều đáng chú ý là trước đây tôi chưa bao giờ đóng góp cho các dự án nguồn mở và không biết bắt đầu từ đâu. Nhưng nó không thể khó đến thế phải không? Vừa vào kho, tôi lập tức đứng hình. “Mình nên làm cái quái gì đây?” Tôi tự nghĩ. Nếu tôi thực hiện một PR (yêu cầu kéo, yêu cầu hợp nhất), các chuyên gia có thể sẽ xé mã của tôi thành từng mảnh. Tôi sẽ luôn được biết đến trong thế giới phát triển với tư cách là người không biết cách làm việc với nguồn mở đúng cách. Và sự nghiệp của tôi sẽ kết thúc. May mắn thay, tôi đã đọc được một bài báo (tôi không nhớ ở đâu) tác giả khuyên rằng đóng góp đầu tiên của bạn cho kho lưu trữ của người khác nên càng kín đáo càng tốt. Đây có thể là một việc đơn giản như sửa lỗi đánh máy. Và tôi đã làm như vậy. Tôi đã đọc tài liệu về kho lưu trữ, tìm thấy một vài lỗi chính tả, mở một đoạn PR và lạ thay, Evan đã chấp thuận những thay đổi của tôi. Tôi chính thức là người đóng góp cho Vue! Có lẽ tôi nên đưa điều này vào tiểu sử Twitter của mình?

"Điều đó thật tuyệt, nhưng tôi phải bắt đầu như thế nào?"

Được rồi, hãy bắt đầu: Tôi sẽ chỉ cho bạn các bước bạn có thể thực hiện để tạo sự khác biệt.

1. Tìm một dự án

Để có cảm hứng, hãy nghĩ về công nghệ hoặc công cụ yêu thích của bạn. Giả sử bạn làm việc với JavaScript và sử dụng Gatsby rất nhiều ? Kiểm tra kho lưu trữ của họ ! Bạn cũng có thể đóng góp vào một trong các kho lưu trữ của tôi. Đây là danh sách các dự án frontend của tôi. Nếu bạn có thứ gì đó bạn yêu thích hoặc thấy hữu ích, tôi rất muốn bạn bổ sung nó! Cuối cùng, Cơ hội PR đầu tiên tuyệt vời là một kho lưu trữ khổng lồ các dự án nguồn mở dành cho người mới bắt đầu. Có các dự án bằng 22 ngôn ngữ khác nhau!

2. Quyết định cách bạn có thể đóng góp

Kiểm tra dự án. Đọc Readme. Quét các thư mục và tập tin khác nhau. Đạt được sự hiểu biết về cấu trúc của cơ sở mã. Bằng cách này, bạn có thể dễ dàng tìm và sửa lỗi đánh máy! Khi bạn đã hoàn thành việc đó, hãy xem phần Vấn đề của dự án. Ở đó bạn sẽ tìm thấy danh sách các lỗi được phát hiện trước đó hoặc các tính năng được đề xuất. May mắn thay, nhiều dự án liên quan đến các vấn đề dành cho người mới bắt đầu. Tôi nghĩ đóng góp đầu tiên của bạn nên tinh tế nhất có thể, nhưng nếu bạn muốn nhanh chóng được công nhận thì điều đó tùy thuộc vào bạn. Khi bạn tìm thấy thứ gì đó mà bạn có thể thêm vào dự án, bạn sẽ cần phải phân nhánh nó.

3. Tạo một nhánh của dự án

Một nhánh (phân nhánh của một dự án) tạo ra một bản sao chính xác của nó trong kho lưu trữ Github của riêng bạn.

4. Sao chép dự án cục bộ

Sau đó sao chép dự án vào một thư mục cục bộ bằng URL dự án.

git clone <project-url>

Ở đây bạn sẽ tìm thấy URL. Bây giờ dự án đã có trên máy tính của bạn, hãy mở nó trong trình chỉnh sửa. Nếu bạn cho rằng những thay đổi sẽ mất thời gian, hãy đảm bảo đồng bộ hóa bản sao của dự án với bản gốc để bạn luôn biết về những thay đổi. Bạn có thể tìm thấy các lệnh Git chính xác cho việc này tại đây .

5. Tạo một nhánh mới cho những thay đổi của bạn

Đã đến lúc thực hiện những thay đổi/sửa chữa của bạn! Tạo một nhánh mới nơi những thay đổi của bạn sẽ có hiệu lực.

git branch <branch-name>

Bạn có thể gọi nó là bất cứ điều gì bạn muốn, nhưng theo kinh nghiệm của tôi, bạn sẽ có thể thấy mẫu đặt tên các nhánh trong dự án ban đầu. Trong trường hợp này, tôi khuyên bạn nên làm theo mẫu hiện có. Tên nhánh tốt để sửa lỗi đánh máy sẽ là patch/typo-fix . Bạn có thể chuyển sang nhánh này bằng cách sử dụng gitcheck <branch-name> . Bây giờ hãy thực hiện những thay đổi của bạn!

6. Mở PR (Yêu cầu hợp nhất)

Vậy là bạn đã sửa được lỗi đánh máy rõ ràng hoặc cập nhật liên kết bị hỏng. Bạn tự hào về công việc của mình. Bạn muốn cả thế giới biết rằng bạn là một trong những nhà phát triển huyền thoại có thể viết mã, xóa và xem Netflix cùng một lúc. Đẩy các thay đổi của bạn tới kho lưu trữ Github phân nhánh bằng cách sử dụng git push -u Origin <branch-name> . Đi tới kho lưu trữ Github đã phân nhánh của bạn và mở PR (yêu cầu kéo). Lưu ý: Nếu bạn chưa bao giờ thực hiện yêu cầu kéo trước đây, hãy xem video này của Kent Dodds để tìm hiểu cách thực hiện. Đảm bảo nhánh của bạn trỏ đến nhánh chính của kho lưu trữ nguồn. Bây giờ bạn đã sẵn sàng để thêm chi tiết vào PR của mình. Hãy chắc chắn rằng tiêu đề của bạn truyền tải rõ ràng nội dung của PR. Thêm mô tả: Nếu bạn đang khắc phục sự cố hiện có, hãy đảm bảo bao gồm liên kết tới sự cố đó. Khi bạn đã hoàn tất mô tả của mình, hãy gửi PR của bạn để xem xét. Bất kỳ ai có thẩm quyền phê duyệt PR đều có thể xem xét đơn đăng ký của bạn trong vòng vài ngày và thực hiện một trong những thao tác sau:

1. Sẽ hợp nhất các thay đổi ngay lập tức.
2. Nó sẽ yêu cầu bạn thực hiện thay đổi.
3. Sẽ đóng PR của bạn.

Hãy kiên nhẫn vì người tạo kho lưu trữ có thể bận rộn với công việc toàn thời gian hoặc các dự án khác.

Bạn làm được rồi!

Bây giờ bạn là người đóng góp cho dự án nguồn mở! Nó cảm thấy như thế nào? Bạn đã sẵn sàng xây dựng đối thủ cạnh tranh Node.js của riêng mình chưa? Tôi hy vọng rằng bằng việc thực hiện một đóng góp đơn giản, triển vọng cho công việc nguồn mở trong tương lai sẽ trở nên ít khó khăn hơn. Để biết thêm thông tin về đóng góp nguồn mở, hãy xem hướng dẫn nguồn mở .