Các nhiệm vụ điển hình của nhà phát triển Java trong một dự án

Trách nhiệm điển hình của nhà phát triển Java là gì? Rốt cuộc, bạn cần hiểu bản thân đang dấn thân vào điều gì và cuối cùng bạn sẽ làm gì, phải không? Hôm nay tôi muốn nói về mười nhiệm vụ quan trọng mà một nhà phát triển Java thực hiện. Nhưng trước tiên, hãy làm quen với một công cụ có tên là Jira. Hoặc làm mới bộ nhớ của bạn về nó, nếu bạn đã quen thuộc với nó. Jiralà một công cụ để tổ chức các tương tác của con người, mặc dù trong một số trường hợp, nó cũng được sử dụng để quản lý dự án. Nói cách khác, một dự án được chia thành các nhiệm vụ nhỏ được mô tả trong công cụ này. Các nhiệm vụ này được giao cho các nhà phát triển, những người chịu trách nhiệm thực hiện chúng. Ví dụ, một nhiệm vụ có thể là thêm một số chức năng. Khi một nhiệm vụ được thực hiện, các nhà phát triển và các chuyên gia khác sẽ thêm nhận xét về việc ai đã làm gì và họ đã dành bao nhiêu thời gian. Điều này được thực hiện cho mục đích theo dõi thời gian — để biết đã dành bao nhiêu thời gian cho những nhiệm vụ nào. Lý tưởng nhất là việc này được thực hiện mỗi ngày một lần: Trước khi rời bàn làm việc vào buổi tối, bạn cho biết mình đã dành bao nhiêu thời gian trong 8 giờ làm việc cho các nhiệm vụ khác nhau. Còn nhiều điều về chức năng của Jira hơn những gì được mô tả ở trên, nhưng điều này sẽ đủ cho sự hiểu biết ban đầu.

1. Thiết kế giải pháp mới

Trước khi bạn tạo và thực hiện một cái gì đó, bạn cần khái niệm hóa nó, phải không? Như tôi đã nói trước đây, đây có thể đơn giản là một nhiệm vụ trong Jira được giao cho bạn, vì vậy bạn làm việc để thiết kế một giải pháp mới, ghi lại trong Jira bạn đã dành bao nhiêu thời gian và làm gì. Công việc này cũng có thể diễn ra trong một cuộc thảo luận trong cuộc gọi hội nghị nhóm: mọi người có thể bày tỏ ý kiến ​​​​của mình và đề xuất phương pháp mà họ cho là tốt nhất. Và ở đây tôi muốn lưu ý một vài điểm. Đầu tiên, phát triển phần mềm là một nghề rất sáng tạo, vì bạn cần sử dụng các công cụ tiêu chuẩn để tìm ra những cách giải quyết vấn đề mới. Một nhiệm vụ thường có thể có nhiều giải pháp khác nhau. Theo đó, mọi thứ phụ thuộc vào sự sáng tạo của nhà phát triển, thứ chịu ảnh hưởng nhiều từ kiến ​​thức và kinh nghiệm tích lũy của họ. Bạn có thể thể hiện tất cả sự sáng tạo và thiên tài của mình tại đây, nhưng điều quan trọng là đừng lạm dụng nó. Nếu bạn làm như vậy, mã sẽ trở nên quá phức tạp và không thể đọc được. Kết quả là sau khi bạn rời đi, sẽ không ai hiểu đầy đủ những gì bạn đã mã hóa và cách thức hoạt động của nó. Và họ sẽ phải viết lại mọi thứ từ đầu. Và họ có thể hồi tưởng về bạn. Nhiều hơn một lần. Và chưa chắc đã có những lời ấm áp, tử tế được nói ra. Bạn có cần điều đó không? Thứ hai, một nhà phát triển phải duy trì sự linh hoạt về tâm lý theo nghĩa là bạn không nên bám vào một giải pháp duy nhất và trở nên khép kín với những người khác. Như thể bạn phải làm điều gì đó theo một cách duy nhất và không có lựa chọn nào khác. Bạn có thể rơi vào cái bẫy này vì nhiều lý do. Ví dụ, giả sử bạn muốn chứng minh rằng quan điểm của mình là đúng. Hoặc có lẽ bạn đã thiết kế và triển khai giải pháp quen thuộc của riêng mình — tất nhiên, bạn sẽ không muốn thừa nhận rằng nó không phải là tốt nhất. Những tình huống này có thể khiến bạn khá mù quáng. Trên thực tế, bạn cần có khả năng thừa nhận sai lầm của mình và luôn cởi mở, ngay cả khi bạn phải loại bỏ chức năng mà bạn tự hào và đã viết mã hơn một tuần. Tôi nhớ một lần một đồng nghiệp đã làm rạng rỡ một ngày của mọi người như thế nào bằng cách để lại nhận xét theo dõi thời gian này trong Jira: "Tôi đã loại bỏ tính năng thai chết lưu của mình. Và thương tiếc."

2. Viết chức năng mới

Bước này - triển khai chức năng mới - theo logic sau bước trước. Tất cả công việc liên quan đến một dự án được chia thành các nhiệm vụ trong Jira, sau đó được phân bổ cho các nhà phát triển dựa trên khối lượng công việc của họ. Có nhiều cách tiếp cận khác nhau đối với quy trình này, được gọi là "phương pháp", mà bạn có thể đọc chi tiết hơn trong bài viết này trên CodeGym . Theo quy định, các nhiệm vụ có ước tính, đó là thời gian dự đoán cần thiết để hoàn thành chúng. Nó được đặt bởi bạn, nhà phát triển khi bạn nhận nhiệm vụ hoặc bởi trưởng nhóm hoặc trong quá trình lập kế hoạch, được nhóm phát triển chung đặt. Lần phỏng đoán này rất hiếm khi chính xác, vì có rất nhiều yếu tố khác nhau ảnh hưởng đến quá trình phát triển phần mềm. Ví dụ, liệu một lập trình viên có quen thuộc hay không quen thuộc với công nghệ liên quan, kinh nghiệm tổng thể của anh ấy hoặc cô ấy, nhiều cạm bẫy không lường trước được, v.v. Vì vậy, nếu bạn không đạt được tất cả các ước tính thời gian của mình khi viết mã, thì đó không phải là ngày tận thế. Đây chỉ là những ước tính chung. Điều đó nói rằng, không phải tất cả các dự án yêu cầu ước tính thời gian. Cá nhân tôi thấy sống thiếu nó dễ dàng hơn nhiều, đặc biệt là khi Thủ tướng không làm phiền tôi vài lần một ngày với câu hỏi "ước tính thời gian của bạn ở đâu?" Vì vậy, bạn nhận được một nhiệm vụ,Sẵn sàng để xem xét " trong Jira và cầu nguyện rằng các thay đổi mã của bạn không bị trả lại để sửa đổi cùng với nhận xét.

3. Kiểm tra viết

Người đánh giá, tức là người kiểm tra mã của bạn, thích chức năng bạn đã triển khai, nhưng cô ấy có một câu hỏi dành cho bạn: các bài kiểm tra liên quan ở đâu? Vì vậy, cô ấy gửi lại nhiệm vụ cho bạn để sửa đổi. Các bài kiểm tra là một phần thiết yếu của bất kỳ ứng dụng Java nào. Bằng cách chạy thử nghiệm, bạn có thể xác định ngay những nơi ứng dụng không hoạt động chính xác. Ví dụ: một nhà phát triển thực hiện một số thay đổi trong một phần của hệ thống, dẫn đến thay đổi hành vi ở phần khác, nhưng anh ta không nhận thấy điều này khi viết mã. Bằng cách chạy thử nghiệm, anh ấy sẽ có thể thấy rằng một số thử nghiệm nhất định không thành công, nghĩa là chúng không tạo ra kết quả như mong đợi. Điều này cho anh ta biết rằng có thứ gì đó bị hỏng ở đâu đó trong hệ thống. Biết được điều này, anh ấy sẽ không thực hiện các thay đổi vi phạm đối với máy chủ và thay vào đó sẽ tiếp tục làm việc để gỡ lỗi mã của mình. Đúng, khá ít nhà phát triển thích viết bài kiểm tra, nhưng không thể phủ nhận những lợi ích mà chúng mang lại cho quá trình phát triển phần mềm. Bản thân khách hàng thường cho biết mức độ bao phủ thử nghiệm mà họ muốn duy trì (ví dụ: 80%). Điều đó có nghĩa là bạn cần phải biếtcác loại bài kiểm tra khác nhau và có thể viết chúng. Các nhà phát triển Java chủ yếu viết các bài kiểm tra đơn vị và kiểm tra tích hợp, trong khi các bài kiểm tra mở rộng hơn (từ đầu đến cuối) được xử lý bởi các chuyên gia tự động hóa kiểm tra và QA.

4. Tìm và sửa lỗi

Đây cũng là một nhiệm vụ rất phổ biến, thường xuyên đối với các nhà phát triển Java. Công việc chính của các chuyên gia QA và test automation là bắt lỗi. Nói cách khác, họ tìm kiếm những nơi mà chương trình hoạt động không chính xác, sau đó họ tạo các tác vụ trong Jira và giao chúng cho ai đó. Ví dụ: đối với trưởng nhóm, người này sẽ quyết định sẽ giao họ cho nhà phát triển nào, tùy thuộc vào khối lượng công việc và mức độ quen thuộc của họ với các phần liên quan của hệ thống. Sau đó, nhà phát triển được chỉ định tìm kiếm nguyên nhân cốt lõi của lỗi, dành hàng giờ trong trình gỡ lỗi, bằng cách sử dụng mô tả lỗi do các chuyên gia QA cung cấp để tái tạo các điều kiện xảy ra lỗi. Sau khi nhà phát triển tìm thấy lỗi và sửa nó, anh ta sẽ gửi bản sửa lỗi để xem xét. Đôi khi nhà phát triển không thể tái tạo lỗi, vì vậy anh ta gửi nhiệm vụ lại cho chuyên gia QA cùng với nhận xét giải thích. Có vẻ như sẽ không mất nhiều thời gian để tìm và sửa một lỗi, nhưng có một số sắc thái. Tất cả chủ yếu phụ thuộc vào mức độ quen thuộc của nhà phát triển với phần mã này cũng như kinh nghiệm và kiến ​​thức lý thuyết của anh ta. Đôi khi một lỗi có thể được tìm thấy và sửa trong 20 phút, và đôi khi có thể mất ba ngày. Điều này có nghĩa là loại nhiệm vụ này đặc biệt khó ước tính trước, trừ khi nhà phát triển, khi đọc mô tả, ngay lập tức hiểu được lỗi là gì, ở đâu và như thế nào. Trong trường hợp này,

5. Đánh giá mã

Như đã đề cập ở trên, ngay sau khi bạn hoàn thành một nhiệm vụ, nó sẽ được gửi đi để xem xét. Nếu nó vượt qua bài đánh giá, thì nó sẽ đi vào nhánh chính. Nếu không, nó sẽ được trả lại cho nhà phát triển với các nhận xét cần được giải quyết. Tất nhiên, bạn hiểu rằng tất cả mã của bạn đều được kiểm tra bởi các nhà phát triển đồng nghiệp, không phải bởi một số quyền lực cao. Điều đó nói rằng, không phải ai cũng được phép thực hiện đánh giá mã — chỉ những nhà phát triển có kinh nghiệm nhất được rèn luyện qua thực tiễn trong thế giới thực, những người này mới có thể phân biệt được mã tốt và mã xấu. Đánh giá mã thường được thực hiện bằng công cụ trợ giúp như Crucible. Người đánh giá xem qua mã và, nếu cần, để lại nhận xét về một số dòng nhất định. Có thể có nhiều loại bình luận. Ví dụ, một số là quan trọng. Nếu chúng không được giải quyết, thì người đánh giá sẽ không cho phép mã được cam kết. Các nhận xét khác, chẳng hạn, chỉ đơn giản là nhận xét về cách tiếp cận đã chọn. Những nhà phát triển này có thể lắng nghe, ghi chú hoặc bỏ qua. Một nhóm có thể tạo các quy tắc và quy trình riêng để đánh giá mã, thống nhất về điều gì đáng chú ý và điều gì không, khung thời gian nào nên được phân bổ để hoàn thành đánh giá mã, v.v. Chỉ kinh nghiệm thôi là chưa đủ để tiến hành đánh giá: bạn vẫn cần phát triển nhiều về kỹ năng kỹ thuật của bạn và đọc nhiều sách khác nhau (ví dụ: "Clean Code").

6. Phân tích mã

Vì một số người có suy nghĩ khác nhau đồng thời viết mã cho dự án nên mã và cách tiếp cận của họ sẽ khác nhau. Và theo thời gian, mọi thứ dần biến thành một mớ hỗn độn. Để cải thiện mã, đôi khi các tác vụ được tạo để phân tích một mô-đun nhất định hoặc toàn bộ ứng dụng, tìm và lưu ý các thiếu sót, sau đó tạo tác vụ tái cấu trúc dựa trên phân tích này. Phân tích như vậy cũng hữu ích trong các tình huống mà khi bắt đầu phát triển, nhóm không thể thấy một số giải pháp đơn giản hơn, ngắn gọn hơn, nhưng giờ họ đã thấy chúng. Ví dụ, logic thường được lặp lại trong một số phương pháp. Theo đó, nó có thể được trích xuất thành một phương pháp riêng biệt, sau đó có thể được sử dụng lại nhiều lần. Hoặc có lẽ một lớp đã trở nên quá cồng kềnh, hoặc một số mã đã trở nên khó bảo trì hoặc lỗi thời, hoặc... Nhiệm vụ phân tích giúp cải thiện chất lượng của mã và ứng dụng. Điều đó nói rằng, đối với tôi, việc phân tích một lượng lớn mã có thể nhàm chán.

7. Tái cấu trúc code

Phần tiếp theo của phân tích mã là tái cấu trúc. Mã có thể lỗi thời, lỗi thời, viết kém, khó đọc, v.v. Bạn phải luôn phấn đấu cho sự hoàn hảo (mặc dù nó không tồn tại) và mã cập nhật, loại bỏ bất kỳ thứ gì thừa, bởi vì thứ thừa chỉ dẫn đến nhầm lẫn và cản trở khả năng xem mã đang làm gì. Rõ ràng là bạn khó có thể nhìn thấy những nhiệm vụ này khi bắt đầu một dự án: bạn sẽ gặp chúng ở các giai đoạn phát triển sau này khi ứng dụng đang được trau chuốt và hoàn thiện. Ở đây, có thể thích hợp để tham khảo ý kiến ​​của đồng nghiệp về những gì họ sẽ làm và những cạm bẫy mà họ nhìn thấy. Về cơ bản, những nhiệm vụ như vậy tương tự như việc phát triển chức năng mới. Ví dụ: giả sử bạn nhận được nhiệm vụ chỉnh sửa một số chức năng mà không thay đổi hành vi của nó. Để làm điều này, bạn xóa mã cũ, viết mã của riêng bạn và kiểm tra các bài kiểm tra. Nếu bạn đã làm đúng mọi thứ, thì không cần thực hiện bất kỳ thay đổi nào đối với các bài kiểm tra, tất cả chúng sẽ vượt qua như trước. Sau khi mọi thứ trong mã hoạt động như bình thường, chúng tôi gửi nó để xem xét và nhâm nhi một ít cà phê :)

8. Viết tài liệu

Hãy tưởng tượng rằng bạn là một nhà phát triển mới trong một số dự án phát triển phần mềm dài hạn. Bạn cần tự làm quen với cơ sở mã hoặc thực hiện một số tác vụ cụ thể, chẳng hạn như chẩn đoán lỗi. Làm thế nào bạn sẽ điều hướng dự án? Làm phiền đồng đội của bạn cứ sau năm phút? Và nếu họ bận hoặc đó là cuối tuần thì sao? Đây chính là lý do tại sao chúng tôi có tài liệu — để một người không quen thuộc với mã có thể truy cập, tìm trang liên quan và nhanh chóng tìm ra điều gì đang diễn ra trong phần ứng dụng mà cô ấy quan tâm. Nhưng ai đó phải tạo tài liệu, haha. Nếu một dự án có tài liệu mà các nhà phát triển phải hỗ trợ, thì khi họ triển khai chức năng mới, họ sẽ mô tả nó và cập nhật tài liệu cùng với bất kỳ thay đổi mã hoặc tái cấu trúc nào. Bạn cũng có thể gặp các tình huống khi một nhân viên riêng biệt — một người viết kỹ thuật — được thuê để viết, duy trì và giám sát tài liệu. Nếu có một chuyên gia như vậy, cuộc sống của các nhà phát triển bình thường sẽ dễ dàng hơn một chút.

9. Các cuộc họp khác nhau

Rất nhiều thời gian của các nhà phát triển dành cho các cuộc họp, đàm phán và lập kế hoạch khác nhau. Ví dụ đơn giản nhất là cuộc họp đứng hàng ngày, nơi bạn cần báo cáo những gì bạn đã làm ngày hôm qua và những gì bạn sẽ làm hôm nay. Ngoài ra, bạn sẽ cần có các cuộc điện thoại trực tiếp, chẳng hạn như với người kiểm tra, để họ có thể chứng minh/giải thích các sắc thái của việc tái tạo lỗi hoặc thảo luận về các yêu cầu và chi tiết với nhà phân tích kinh doanh hoặc nói về các vấn đề của tổ chức với một Thủ tướng. Điều này có nghĩa là mặc dù một nhà phát triển có thể là một người hướng nội, thích sự cô độc, nhưng cô ấy vẫn cần có khả năng tìm thấy điểm chung với những người khác (tốt, ít nhất là một chút). Xếp hạng của nhà phát triển càng cao, cô ấy càng cần dành nhiều thời gian hơn cho việc giao tiếp và càng ít thời gian viết mã. Trưởng nhóm phát triển có thể dành một nửa, hoặc thậm chí nhiều hơn, ngày làm việc của mình cho các cuộc trò chuyện và họp một mình và có thể viết mã ít thường xuyên hơn (có thể khiến anh ta mất đi một chút năng lực mã hóa của mình). Nhưng nếu bạn chỉ thích nói chuyện, với tư cách là trưởng nhóm, bạn có thể chuyển sang làm quản lý và hoàn toàn quên việc viết mã, thay vào đó, bạn sẽ dành cả ngày để giao tiếp với nhiều nhóm, khách hàng và những người quản lý khác.

10. Thực hiện/vượt qua phỏng vấn

Nếu bạn làm việc cho một công ty gia công hoặc thuê ngoài, bạn sẽ thường phải trải qua các cuộc phỏng vấn bên ngoài, nơi bạn sẽ cần "bán" mình cho khách hàng (bạn có thể được phỏng vấn bởi một người làm việc cho khách hàng), cũng như nội bộ. những người leo lên các cấp bậc trong công ty. Tôi gọi đây là một cơ hội tốt để phát triển bởi vì các cuộc phỏng vấn thường xuyên sẽ buộc bạn phải giữ cho kiến ​​thức của mình luôn sắc bén: bạn sẽ không trở nên chai lì và mềm yếu. Rốt cuộc, nếu bạn yếu về CNTT, bạn hoàn toàn có thể rời khỏi lĩnh vực này. Khi bạn trở thành một nhà phát triển có kinh nghiệm hơn, bạn sẽ có thể thấy mình ở phía bên kia bàn phỏng vấn, thực hiện các cuộc phỏng vấn thay vì vượt qua chúng. Tin tôi đi, bạn sẽ rất ngạc nhiên khi nhìn nó từ vị trí này, bởi vì đặt câu hỏi phỏng vấn có thể đáng sợ hơn là trả lời chúng. Bạn cần có chiến lược phỏng vấn của riêng mình, danh sách các câu hỏi và thời gian để đặt câu hỏi về tất cả các chủ đề cần thiết trong một giờ. Và sau đó, bạn có trách nhiệm cung cấp phản hồi sẽ ảnh hưởng đến quyết định tuyển dụng và liệu ứng viên có nhận được lời đề nghị hoặc khuyến mãi đã được mong đợi từ lâu hay không. Hoặc, bạn có thể cho phép một ứng viên rõ ràng yếu kém nhận được một vị trí mà cô ấy không đủ tiêu chuẩn, và sau đó bạn có thể được hỏi, "làm sao bạn có thể cho phép cô ấy được tuyển dụng với trình độ kiến ​​thức đó"? Vì vậy, khi ngồi ghế nóng trong một cuộc phỏng vấn, hãy nhớ rằng người ngồi trước mặt bạn cũng đang đối mặt với thử thách và có thể bị căng thẳng. bạn có trách nhiệm cung cấp phản hồi sẽ ảnh hưởng đến quyết định tuyển dụng và liệu ứng viên có nhận được lời đề nghị hoặc khuyến mãi đã được mong đợi từ lâu hay không. Hoặc, bạn có thể cho phép một ứng viên rõ ràng yếu kém nhận được một vị trí mà cô ấy không đủ tiêu chuẩn, và sau đó bạn có thể được hỏi, "làm sao bạn có thể cho phép cô ấy được tuyển dụng với trình độ kiến ​​thức đó"? Vì vậy, khi ngồi ghế nóng trong một cuộc phỏng vấn, hãy nhớ rằng người ngồi trước mặt bạn cũng đang đối mặt với thử thách và có thể bị căng thẳng. bạn có trách nhiệm cung cấp phản hồi sẽ ảnh hưởng đến quyết định tuyển dụng và liệu ứng viên có nhận được lời đề nghị hoặc khuyến mãi đã được mong đợi từ lâu hay không. Hoặc, bạn có thể cho phép một ứng viên rõ ràng yếu kém nhận được một vị trí mà cô ấy không đủ tiêu chuẩn, và sau đó bạn có thể được hỏi, "làm sao bạn có thể cho phép cô ấy được tuyển dụng với trình độ kiến ​​thức đó"? Vì vậy, khi ngồi ghế nóng trong một cuộc phỏng vấn, hãy nhớ rằng người ngồi trước mặt bạn cũng đang đối mặt với thử thách và có thể bị căng thẳng. Bất kỳ cuộc phỏng vấn nào cũng gây căng thẳng cho cả ứng viên và người phỏng vấn. Có lẽ chúng ta sẽ kết thúc ngay tại đây. Cảm ơn mọi người đã đọc bài viết này. Để lại một lượt thích và tiếp tục học Java :)