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ì? Sau cùng, bạn cần phải hiểu mình đang làm 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ụ chính mà một nhà phát triển Java thực hiện. Nhưng trước tiên chúng ta hãy làm quen với một công cụ như Jira. Hoặc hãy làm mới ký ức của chúng ta nếu nó đã quen thuộc với bạn. Jira là một công cụ tương tác với người dùng, mặc dù trong một số trường hợp nó còn được sử dụng để quản lý dự án. Nói cách khác, việc phát triển 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 (giao) cho các nhà phát triển, những người sẽ chịu trách nhiệm thực hiện chúng. Ví dụ: theo nhiệm vụ, chúng tôi muốn nói đến việc thêm một số chức năng. Khi tiến trình tiến triển, các nhà phát triển và các chuyên gia khác sẽ thêm nhận xét về ai đã làm gì và họ đã dành bao nhiêu thời gian—họ theo dõi thời gian. Điều này được thực hiện để theo dõi thời gian đã sử dụng: chi bao nhiêu và vào việc gì. Lý tưởng nhất là việc này được thực hiện mỗi ngày một lần: vào buổi tối trước khi rời đi, bạn theo dõi 8 giờ của mình cho những nhiệm vụ mà bạn đã dành chúng. Chức năng của Jira rộng hơn nhiều so với mô tả ở trên, nhưng điều này sẽ đủ để hiểu ban đầu. Vậy trách nhiệm của một nhà phát triển Java là gì?

1. Phát triển các giải pháp mới

Trước khi tạo và triển khai một cái gì đó, bạn cần phải nghĩ ra nó, phải không? Như tôi đã nói, điều này có thể đơn giản như một nhiệm vụ Jira sẽ được giao cho bạn và bạn sẽ làm việc để phát triển một giải pháp mới, lưu ý rằng bạn đã dành bao nhiêu thời gian và vào việc gì trong Jira. Đây cũng có thể là một cuộc thảo luận trong cuộc gọi nhóm: mọi người sẽ 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. Thứ nhất, nghề lập trình viên là một lĩnh vực rất sáng tạo, vì bạn cần nghĩ ra những cách độc đáo để giải quyết vấn đề bằng cách sử dụng các công cụ tiêu chuẩn. Thông thường, một vấn đề có thể có nhiều cách giải quyết khác nhau: theo đó, mọi thứ đều phụ thuộc vào “tinh thần sáng tạo” của người phát triển, nền tảng kiến ​​thức và kinh nghiệm tích lũy được. Ở đây bạn có thể thể hiện tất cả sự sáng tạo và thiên tài của mình, nhưng điều quan trọng chính là không lạm dụng nó: trong trường hợp này, mã sẽ trở nên quá phức tạp và không thể đọc được và kết quả là sau khi bạn rời đi, sẽ không ai hiểu hết nó là gì và làm thế nào nó hoạt động. Và bạn sẽ cần phải viết lại mọi thứ từ đầu. Và họ có thể nhớ đến bạn. Và hơn một lần. Và đây khó có thể là những lời nói ấm áp, tử tế. Bạn có cần nó không? Thứ hai, nhà phát triển phải linh hoạt theo nghĩa là bạn không nên mắc kẹt trong một giải pháp và trở nên khép kín với những giải pháp khác. Giống như, bạn chỉ cần làm theo cách này và không làm gì khác. Điều này có thể xảy ra vì nhiều lý do: ví dụ: bạn muốn chứng minh quan điểm của mình hoặc bạn đã phát triển và triển khai giải pháp của mình mà bạn khá gắn bó và tất nhiên không muốn thừa nhận rằng đó không phải là giải pháp phù hợp. tốt nhất. Điều này có thể làm bạn 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ở với những điều mới (“cởi mở”), ngay cả khi bạn phải loại bỏ chức năng mà bạn đã viết trong nhiều tuần và bạn rất tự hào. Tôi nhớ có lần tâm trạng cả ngày được tạo nên bởi bảng thời gian của ai đó trong Jira với nhận xét: “Tôi đã xóa chức năng chết non của mình. Tôi đã khóc"

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

Đây là bước hợp lý nối tiếp bước trước - triển khai chức năng mới. Tất cả công việc trong dự án được chia thành các nhiệm vụ trong jira mà các nhà phát triển nhận được khi họ làm việc. Có nhiều cách tiếp cận khác nhau cho vấn đề này - “phương pháp luận”, bạn có thể đọc thêm về những gì bạn có thể đọc trong bài viết này trên JavaRush . Theo quy định, nhiệm vụ có "Ước tính" - thời gian dự kiến ​​sẽ hoàn thành. Nó do chính bạn đặt ra khi bạn đảm nhận nhiệm vụ, hoặc do trưởng nhóm hoặc trong quá trình lập kế hoạch, các nhà phát triển cùng nhau ước tính nó. Thời điểm này rất hiếm khi được đoán chính xác vì có nhiều yếu tố khác nhau ảnh hưởng đến sự phát triển. Ví dụ, lập trình viên quen thuộc hay không quen thuộc với công nghệ này, kinh nghiệm chung của anh ta là gì, những cạm bẫy khác nhau có thể xuất hiện trong quá trình phát triển, v.v. Do đó, nếu bạn không đáp ứng thời hạn này khi phát triển chức năng thì sẽ không có điều gì xấu xảy ra. Đây chỉ là những ước tính chung. Nhưng một lần nữa, không phải tất cả các dự án đều có ước tính nhiệm vụ và đối với tôi, sẽ dễ dàng hơn nhiều nếu không có nó, đặc biệt là khi Thủ tướng không chọc ghẹo bạn vài lần một ngày với câu hỏi “Các ước tính ở đâu? ” Theo đó, bạn nhận một nhiệm vụ, phát triển chức năng cần thiết, tải nó lên một nhánh chung trong GIT và trong jira thay đổi trạng thái của nhiệm vụ thành “Sẵn sàng để xem xét” , nghĩa là sẵn sàng để xem (kiểm tra) và cầu nguyện rằng nó không được trả lại cho bạn cùng với những nhận xét về việc sửa đổi.

3. Viết bài kiểm tra chức năng

Người kiểm tra mã của bạn - người đánh giá - thích chức năng bạn đã phát triển, nhưng anh ta có một câu hỏi: các bài kiểm tra cho nó ở đâu? Và anh ấy trả lại nhiệm vụ cho bạn để sửa đổi. Kiểm thử là một phần quan trọng của bất kỳ ứng dụng Java nào. Bằng cách chạy chúng, bạn có thể ngay lập tức biết ứng dụng đang hoạt động không chính xác ở đâu. Ví dụ: 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 và không nhận thấy điều này trong quá trình phát triển. Bằng cách chạy thử nghiệm, anh ta sẽ có thể thấy các thử nghiệm thất bại (những thử nghiệm không hoạt động chính xác). Điều này sẽ cho anh ta biết rằng có điều gì đó bị hỏng ở một phần khác của hệ thống. Do đó, anh ấy sẽ không tải những thay đổi có thể xảy ra lên máy chủ mà sẽ tiếp tục tinh chỉnh giải pháp của mình. Vâng, tất nhiên là ít nhà phát triển yêu thích thử nghiệm, nhưng không thể phủ nhận lợi ích mà chúng mang lại cho ứng dụng. Thông thường, khách hàng tự chỉ định mức độ bao phủ kiểm thử cần tuân thủ (ví dụ: 80%). Vì vậy, bạn cần biết cá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 AQA (người kiểm tra tự động hóa) xử lý các bài kiểm tra mở rộng (từ đầu đến cuối) hơn. Bạn có thể đọc thêm về họ và các đại diện khác của ngành CNTT trong bài đánh giá của tôi .

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

Đây cũng là một nhiệm vụ rất phổ biến và thường xuyên của một nhà phát triển Java. Nhiệm vụ chính của QA và AQA là bắt lỗi. Nghĩa là, họ tìm kiếm những chỗ mà chương trình hoạt động không đúng, tạo ra sự cố trong Jira và đổ lỗi cho ai đó. Ví dụ: trưởng nhóm, người này sẽ lần lượt quyết định giao việc này cho nhà phát triển nào, tùy thuộc vào tải trọng và mức độ quen thuộc của họ với phần này của hệ thống. Sau đó, nhà phát triển tìm kiếm lỗi, dành hàng giờ trong trình gỡ lỗi , sử dụng mô tả sự cố của các chuyên gia QA để lặp lại tình huống xảy ra lỗi. Tiếp theo, nhà phát triển tìm thấy lỗi, sửa lỗi và gửi để xem xét. Chà, có thể nhà phát triển không thể tái tạo lại lỗi và anh ta sẽ trả lại nhiệm vụ cho chuyên gia QA kèm theo nhận xét về lỗi đó. Có vẻ như sẽ không mất nhiều thời gian để tìm và sửa lỗi, nhưng có một số sắc thái. Mọi thứ 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, kinh nghiệm và kiến ​​thức về các vấn đề lý thuyết. Đôi khi một lỗi có thể được tìm thấy và sửa trong 20 phút, đôi khi có thể mất tới ba ngày. Theo đó, loại nhiệm vụ này đặc biệt khó đánh giá trước, trừ khi nhà phát triển sau khi đọc mô tả sẽ hiểu ngay điều gì, ở đâu và đã sai ở đâu. Trong trường hợp này, anh ta sẽ có thể đoán thời gian ít nhiều chính xác.

5. Đánh giá mã

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

6. Phân tích mã

Vì dự án được viết đồng thời bởi nhiều người có suy nghĩ khác nhau 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ứ sẽ dần trở nên hỗn độn. Để cải thiện mã, đôi khi mọi người tạo các nhiệm vụ để phân tích, có thể là một mô-đun hoặc toàn bộ ứng dụng, để tìm ra các sai sót và gắn cờ chúng, sau đó tạo một nhiệm vụ tái cấu trúc dựa trên những nhận xét này. Phân tích này cũng hữu ích trong các tình huống mà một số phím tắt đơn giản hơn không thể nhìn thấy được từ khi bắt đầu phát triển nhưng bây giờ chúng có thể được nhìn thấy. Ví dụ, logic tương tự thường được lặp lại trong một số phương thức và theo đó, nó có thể được chuyển sang một phương thức riêng biệt và được sử dụng lại nhiều lần. Chà, hoặc một số 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. Mặc dù theo tôi, việc phân tích một lượng lớn mã có thể là một công việc nhàm chán.

7. Tái cấu trúc mã

Phần tiếp theo của phân tích là tái cấu trúc mã. Nó có thể đã lỗi thời, không còn cần thiết, viết kém, khó đọc, v.v. Bạn phải luôn cố gắng đạt được sự hoàn hảo (mặc dù nó không tồn tại) và mã cập nhật, loại bỏ mọi thứ không cần thiết, vì điều này chỉ khiến bạn bối rối và ngăn cản bạn nhìn thấy bản chất của chức năng. Không cần phải nói rằng bạn khó có thể nhìn thấy những nhiệm vụ này khi bắt đầu dự án: chúng chỉ xảy ra ở các giai đoạn phát triển sau này, khi ứng dụng được trau chuốt và hoàn thiện. Ở đây, có thể sẽ phù hợp nếu tham khảo ý kiến ​​đồng nghiệp về cách họ sẽ thực hiện và những cạm bẫy mà họ nhìn thấy. Bản chất của 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ụ: 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 cái cũ, viết cái của riêng bạn và kiểm tra các bài kiểm tra. Nếu bạn đã làm mọi thứ một cách chính xác mà không thực hiện thay đổi đối với các bài kiểm tra thì chúng sẽ hoạt động như trước. Sau khi mọi thứ đã được giải quyết trong mã, chúng tôi sẽ gửi nó để xem xét và đi uống 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 của một dự án nào đó đã được phát triển trong một thời gian dài. Bạn cần phải làm quen với nó hoặc thực hiện một số nhiệm vụ cụ thể, chẳng hạn như bắt lỗi. Bạn sẽ điều hướng dự án như thế nào? Kéo các thành viên trong nhóm của bạn cứ năm phút một lần? Và nếu họ bận hoặc vào cuối tuần thì sao? Đây là lý do tại sao tài liệu tồn tại để một người không quen với chức năng này có thể truy cập, tìm đúng trang và nhanh chóng tìm ra phần ứng dụng mà anh ta quan tâm. Nhưng ai đó cũng phải điền vào tài liệu ^^ Nếu dự án có tài liệu mà nhà phát triển phải hỗ trợ thì khi triển khai chức năng mới, họ sẽ mô tả nó và với nhiều thay đổi và tái cấu trúc khác nhau, họ sẽ cập nhật tài liệu. Các tình huống cũng có thể xảy ra khi một chuyên gia riêng biệt, một người viết kỹ thuật, được thuê để viết, hỗ trợ và kiểm soát tài liệu. Nếu một chuyên gia như vậy tồn tại, 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. Tham gia vào các cuộc biểu tình khác nhau

Các nhà phát triển dành nhiều thời gian 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à “daily calls” (cuộc họp hàng ngày), trong đó bạn cần kể lại 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 cần có cuộc gọi trực tiếp, chẳng hạn như với chuyên gia QA, để anh ta có thể hiển thị/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 sắc thái và yêu cầu với nhà phân tích kinh doanh hoặc tổ chức. các vấn đề với một PM. Do đó, 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 anh ta vẫn phải tìm được ngôn ngữ chung với những người khác (ít nhất là một chút). Thứ hạng của nhà phát triển càng cao thì anh ta càng cần nhiều thời gian để giao tiếp và ít thời gian viết mã hơn. Trưởng nhóm phát triển thậm chí có thể dành một nửa hoặc thậm chí nhiều hơn thời gian làm việc của mình cho các cuộc trò chuyện và cuộc họp cũng như viết mã ít thường xuyên hơn (điều này có thể dẫn đến mất đi một chút khả năng nắm bắt). Nhưng nếu bạn cũng là người thích nói chuyện, bạn có thể dễ dàng phát triển từ vị trí trưởng nhóm lên vị trí quản lý và hoàn toàn quên mất mã, giao tiếp cả ngày 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 cuộc phỏng vấn

Nếu bạn làm việc cho một công ty outsourcing hoặc outstaffing, bạn sẽ phải thường xuyên trải qua các cuộc phỏng vấn bên ngoài, khi bạn cần được “bán” cho khách hàng (khi đó bạn có thể được phỏng vấn bởi một người từ phía khách hàng) và các cuộc phỏng vấn nội bộ, để nâng cao thứ hạng của bạn trong công ty. Tôi gọi đây là yếu tố tốt để phát triển, vì được phỏng vấn thường xuyên nên kiến ​​thức của bạn phải luôn ở dạng vững vàng: bạn sẽ không bị gò bó và thư thái, vì nếu thư giãn trong lĩnh vực CNTT, bạn hoàn toàn có thể bay ra khỏi hiện trường. Khi bạn trở thành một nhà phát triển có kinh nghiệm hơn, bạn sẽ có thể đến được phía bên kia: không phải vượt qua mà tiến hành các cuộc phỏng vấn. Tin tôi đi, bạn sẽ rất ngạc nhiên nếu nhìn nó từ góc độ này, bởi vì việc thực hiện các cuộc phỏng vấn có thể còn đáng sợ hơn việc vượt qua. Bạn cần có chiến lược phỏng vấn của riêng mình, danh sách câu hỏi và có 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 đưa ra phản hồi, bởi vì dựa vào nó, một người có thể nhận được hoặc không nhận được lời đề nghị hoặc khuyến mãi đã chờ đợi từ lâu như vậy. Chà, và ngược lại: bạn có thể bỏ lỡ một ứng viên thực sự yếu kém cho một vị trí mà anh ta không tương ứng, và sau đó bạn có thể được hỏi: làm sao bạn lại bỏ lỡ anh ta với trình độ hiểu biết như vậy? Vì vậy, khi trải qua một cuộc phỏng vấn, hãy nhớ rằng người đối diện với bạn cũng đang gặp khó khăn và có thể anh ấy cũng đang gặp 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 ở đây. Cảm ơn mọi người đã đọc xong: like và học Java ^^