Phải làm gì khi bạn phải đối mặt với nhiệm vụ lập trình mà bạn chưa bao giờ làm?

Tôi bắt đầu sự nghiệp với tư cách là một nhà phát triển .NET cách đây 3 tháng và sau một kế hoạch đào tạo dài về các công nghệ, mô hình và khái niệm đa dạng, các nhà phát triển đang giám sát tôi đã quyết định rằng tôi sẵn sàng tham gia một trong nhiều dự án mà công ty xử lý.

Tôi rất vui mừng khi cuối cùng có thể bắt đầu viết mã. Hiện tại nhóm tôi đã tham gia khá nhỏ vì bắt đầu với một dự án mới, điều này thật tuyệt vì tôi được tham gia vào toàn bộ vòng đời của dự án. Đây là một dự án SPA dựa trên web với sự hỗ trợ sử dụng API ASP.NET MVC / ASP.NET và trong khuôn khổ Durandal và các thư viện liên quan.

Vấn đề của tôi là sau khi có một cuộc họp với các đồng nghiệp của tôi và thiết lập các nhiệm vụ và ước tính cho tháng tiếp theo, tôi thấy mình ở một vị trí mà tôi không biết liệu tôi có khả năng đảm nhận bất kỳ nhiệm vụ nào không.

Tôi chưa bao giờ thực hiện bất kỳ nhiệm vụ nào được tạo và tôi không biết nên tiến hành như thế nào.

Ví dụ, một trong những nhiệm vụ được tạo là tạo ra một cơ chế xử lý lỗi chung cho toàn bộ ứng dụng.

Làm thế nào để một người thường tiến hành khi phải đối mặt với các nhiệm vụ mà anh ta chưa bao giờ thực hiện?

Có một số điều bạn có thể và nên làm để chuẩn bị cho nhiệm vụ:

• Hãy suy nghĩ về vấn đề và vẽ một số sơ đồ. Hãy chắc chắn rằng bạn biết vấn đề là gì mà bạn đang cố gắng giải quyết.
• Hãy nghiên cứu về những gì bạn đang cố gắng làm. Internet là một nguồn thông tin có giá trị. Tôi không nói hãy hỏi Stack Overflow - Tôi đang nói hãy nghiên cứu về cách những người khác đã giải quyết vấn đề như của bạn hoặc tiếp cận nó. Đây là những gì google nghĩ ra: "Xử lý ngoại lệ như một mối quan tâm toàn hệ thống" . Cá nhân, tôi luôn cố gắng học hỏi từ người khác.
• Cuối cùng, và điều này có thể là quan trọng nhất, hãy nói chuyện với những người khác trong nhóm của bạn để hiểu rõ hơn và định hướng về những việc cần làm. Tôi luôn muốn thấy các kỹ sư mới đến yêu cầu hướng dẫn về các dự án.

Không biết làm thế nào để làm một cái gì đó sẽ không bao giờ thực sự kết thúc. Mỗi ngày tôi gặp phải những vấn đề mà tôi chưa bao giờ giải quyết trước đây. Có khả năng tìm ra cách giải quyết vấn đề mới là vô cùng quan trọng. Ngay cả những vấn đề cũ cũng không bao giờ hoàn toàn cũ - trong lập trình, hầu như luôn có một bước ngoặt mới hoặc yêu cầu giải pháp của bạn hoạt động theo cách mới hoặc khác.

Đây là lý do tại sao tôi là một kỹ sư; Tôi thích tìm ra những thứ mới.

Không bao giờ ngừng học hỏi những điều mới. Học hỏi là những gì làm cho bạn tốt hơn.

Không có giải pháp hoàn hảo, nhưng một số điều có thể giúp:

• Chia nhỏ các nhiệm vụ thành các đơn vị nhỏ nhất có thể - chia nhỏ chúng cho đến khi bạn có những việc bạn có thể làm.

• Hoàn thành nhiệm vụ trước mắt hoặc vấn đề trong tay để đảm bảo bạn thực sự hiểu nó. Sau đó làm một số phân tích và lặp lại.

• Chọn nhiệm vụ đơn giản nhất trước tiên, ngay cả khi nó có vẻ quá đơn giản chỉ để lấy đà . Một số người thích nhiệm vụ khó khăn nhất vì vậy 'công việc khó khăn' không được thực hiện. Tôi đã thấy rằng "nhiệm vụ đơn giản nhất" thường hoạt động tốt hơn khi bạn chỉ đang tìm cách để có được động lực và tôi đã thấy "đầu tiên khó khăn nhất" dẫn đến các dự án bị đình trệ trước khi chúng có được động lực thực sự.

• Yêu cầu giúp đỡ trong việc lựa chọn đúng nhiệm vụ và cách tiếp cận để bắt đầu.

• Tìm kiếm một người cố vấn có thể cung cấp cho bạn thông tin phản hồi liên tục (lý tưởng hàng ngày) trong một hoặc hai tuần.

• Đặt nhiều câu hỏi nhưng tập trung vào việc lịch sự với đồng đội. Luôn hỏi xem họ có thời gian không, và chú ý đến các dấu hiệu bằng lời nói và phi ngôn ngữ thông thường mà họ không có thời gian ngay lúc đó.

• Giữ một danh sách đang chạy về các vấn đề bạn đang gặp phải và sau đó trong scrum hàng ngày hoặc tại một thời điểm thường xuyên bạn chọn, hãy giải quyết chúng với những người khác.

• Đừng sợ hỏi những câu hỏi cơ bản nhất. Giả định của người khác có thể khó thách thức nhưng nếu bạn không thể tiếp tục với những gì bạn đưa ra, bạn phải đặt câu hỏi lại.

• Nếu bạn biết mục tiêu, hãy làm hết sức có thể cho đến khi bạn gặp khó khăn và sau đó đăng tiến trình và câu hỏi lên Stack Overflow.

Tất nhiên bạn không biết làm thế nào để viết một "cơ chế lỗi chung". Không ai biết cách viết "cơ chế lỗi chung" cho đến khi một số yêu cầu được xác định. Có vẻ như tất cả những gì bạn có là khái niệm của ai đó rằng "cơ chế lỗi chung" bằng cách nào đó được yêu cầu để bắt đầu dự án này.

Cá nhân, tôi sẽ đẩy lùi quan niệm này. Viết "chung chung" bất cứ điều gì trước khi thực hiện các yêu cầu thực tế của người dùng hầu như luôn luôn lãng phí thời gian. Và vì nó chung chung , theo định nghĩa, nó không dành riêng cho công ty hoặc ứng dụng của bạn, vì vậy có lẽ có một cái gì đó đã có sẵn sẽ đáp ứng khoảng 95% nhu cầu của bạn.

Nhưng vì bạn là thành viên cơ sở, đẩy lùi có thể không phải là một ý tưởng tuyệt vời. Vì vậy, bạn cần nói chuyện với những người nghĩ rằng họ cần một "cơ chế lỗi chung" và tìm hiểu những dịch vụ mà họ đang mong đợi cơ chế này sẽ cung cấp. Sau đó tìm kiếm trên mạng để xem nếu một cái gì đó đã được viết sẽ đủ. Nếu bạn tìm thấy một cái gì đó, đề xuất chỉ đơn giản là sử dụng nó. Họ có thể sẽ không đồng ý, bởi vì bất kỳ ai yêu cầu "cơ chế lỗi chung" đều có khả năng bị một trường hợp xấu không được phát minh ở đây.

Nếu thất bại, bước tiếp theo là xác định giao diện cho cơ chế lỗi và được các bên liên quan chấp thuận. Sau đó, việc thực hiện có thể sẽ không đáng kể.

=================

PS Có một số lập trình viên nghĩ rằng cách để bắt đầu bất kỳ dự án nào là bằng cách viết một "nền tảng" để cung cấp tất cả các dịch vụ chung sẽ cần cho các mô-đun ứng dụng. Điều này thường phá hủy trong nhiều tháng của công việc tái tạo công việc tầm thường đã có sẵn miễn phí. Cho đến khi bạn đạt đến giới hạn hiệu suất của các giải pháp khả dụng, không có lý do gì để viết các dịch vụ "nền tảng". Cũng không có lý do để viết các trình bao bọc xung quanh các API hiện có. Nếu bạn cấu trúc lại liên tục, trình bao bọc chính xác theo yêu cầu của ứng dụng của bạn sẽ xuất hiện một cách kỳ diệu.

Tôi nghĩ rằng bạn đang chịu đựng nhiều lo lắng hơn là thâm hụt kỹ năng. Tại một số điểm, không phải mọi thứ mới? Bạn đã bao giờ được giao một nhiệm vụ và không thể giải quyết nó ở một mức độ nào đó? Bạn được trả tiền để tìm hiểu mọi thứ.

Sử dụng nhóm của bạn - Nếu bạn thuộc nhóm tốt, bạn sẽ có thể yêu cầu trợ giúp. Có những điều bạn sẽ biết rằng ngay cả những người cao cấp nhất cũng sẽ không biết. Yêu cầu giúp đỡ không phải là một dấu hiệu của sự yếu đuối (không hơn là chạy đến một số trang web câu hỏi.).

Tìm kiếm - Một tìm kiếm trên web về xử lý lỗi chung không có gì? Bạn có thể không tìm thấy một giải pháp toàn bộ. Bạn sẽ phải làm việc với nó và làm cho nó phù hợp với ứng dụng của bạn.

Prototype - Thay đổi quan điểm của bạn vào các nhiệm vụ từ khâu sản xuất đến nguyên mẫu. Chỉ cần có được một cái gì đó để làm việc và xây dựng từ đó. Khi bạn đạt đến điểm bạn có thể sử dụng nó, sau đó bắt đầu nghĩ về nó như là sản xuất. Bây giờ bạn sẽ không thấy nhiệm vụ như một thứ mà bạn thậm chí không biết bắt đầu từ đâu.

Vượt qua nó - Chỉ làm những việc bạn biết cách làm sẽ trở nên nhàm chán. Nó cũng dẫn bạn vào một cái bẫy chỉ cần vũ phu ép buộc một số giải pháp bằng cách lặp đi lặp lại những điều tương tự (Nếu bạn muốn lặp lại mọi thứ, hãy làm việc trên một dây chuyền lắp ráp.). Hãy chuẩn bị để phạm sai lầm. Những người nói với bạn rằng họ biết tất cả mọi thứ, không bao giờ yêu cầu giúp đỡ hoặc thực hiện tìm kiếm, chỉ là nói dối.

Đó là trò đùa cũ về các bác sĩ vẫn "hành nghề" y học; họ cũng không có câu trả lời.

Hãy vui mừng vì bạn không làm điều gì đó bạn đã làm hàng trăm lần trước đây. Bạn đã tìm thấy niềm vui của việc phát triển phần mềm (đối với tôi, dù sao, YMMV) - học cách lái xe trong khi bạn đi xuống đường cao tốc với tốc độ phi thường. Đây là loại điều mà một nhà phát triển tuyệt vời sống và vượt trội.

Quá trình cá nhân của tôi là một cái gì đó như thế này:

• Nghiên cứu. Tìm hiểu xem và làm thế nào vấn đề này, hoặc một vấn đề tương tự, đã được giải quyết trước đây. Ngay cả khi bạn chỉ có thể tìm thấy thông tin về các giải pháp cho các ngôn ngữ hoặc nền tảng khác nhau, nó vẫn có thể cực kỳ nhiều thông tin.
• Nguyên mẫu. Cách tuyệt đối tốt nhất để làm điều gì đó đúng là làm sai trước. Xây dựng một giải pháp, làm mọi thứ theo ý bạn, dựa trên nghiên cứu của bạn. Cố gắng làm cho nó phù hợp với các yêu cầu chính, xem xét các yêu cầu phụ trợ. Đừng bận tâm làm cho nó đẹp hoặc hoàn hảo hoặc có thể mở rộng hoặc linh hoạt hoặc biểu diễn, chỉ cần làm cho nó hoạt động. Ghi chép các bài học kinh nghiệm - những gì đã hoạt động, những gì không, các rào cản tiềm năng, vv Sau đó ném mã đi. Nếu bạn lo lắng về việc tìm kiếm một kẻ ngốc vì mất quá nhiều thời gian, hãy làm điều này vào thời gian của riêng bạn. Nó có lợi cho cá nhân bạn, về mặt kiến ​​thức.
• Thiết kế. Kết hợp kiến ​​thức bên ngoài của bạn (nghiên cứu) với kiến ​​thức cá nhân (bài học nguyên mẫu đã học) và xây dựng một thiết kế về những gì bạn nghĩ sẽ là Cách đúng để thực hiện nó.
• Hợp tác. Tìm một thành viên nhóm cao cấp, cho họ thấy thiết kế đề xuất của bạn, nhận phản hồi. Hiển thị nó cho người khác, nhận phản hồi của họ. Tinh chỉnh thiết kế của bạn.
• Lặp đi lặp lại. Nếu bạn vẫn không chắc chắn về giải pháp của mình, hãy đảm bảo đánh giá ngang hàng là một phần của chu trình lặp. Đưa việc thực hiện của bạn đến một thành viên nhóm cao cấp thường xuyên để nhận phản hồi.
• Hãy hạnh phúc - bạn đã nâng cao kiến ​​thức và sự nghiệp của mình, và bạn phải làm điều gì đó mới mẻ và thú vị thay vì điều gì đó cũ kỹ và nhàm chán mà bạn đã làm hàng ngàn lần trước đây. Cố gắng làm cho dự án tiếp theo của bạn trở thành một thách thức lớn hơn.

Và cuối cùng, đừng quá lo lắng về ngoại hình. Là người quản lý nhóm phát triển, tôi muốn có một người có thể chứng minh rằng họ có thể học bất cứ điều gì họ cần học khi họ cần, hơn là người có thể chứng minh rằng họ đã biết một điều chúng tôi đang cố gắng làm ngay bây giờ. Cái trước sẽ hữu ích hơn cho bất cứ điều gì chúng ta kết thúc vào ngày mai, hoặc tháng tới, hoặc năm tới.