Làm cách nào tôi có thể cải thiện kỹ năng của mình khi làm việc trên các dự án thực tế, trong trường hợp không có nhà phát triển có kinh nghiệm hơn? [đóng cửa]

Tôi là nhà phát triển chính tại một công ty nhỏ, làm việc với C # và ASP.Net. Đội ngũ của chúng tôi nhỏ, 2-3 người, không có nhiều kinh nghiệm trong phát triển và thiết kế. Tôi không có cơ hội học hỏi từ các nhà phát triển cao cấp hơn, không có ai trong nhóm của tôi hướng dẫn tôi và giúp tôi chọn phương pháp tốt nhất, vì tôi tự chăm sóc hầu hết các dự án.

Làm cách nào tôi có thể cải thiện kỹ năng phát triển phần mềm của mình trong khi thực hiện các dự án thực tế, trong trường hợp không có nhà phát triển có kinh nghiệm hơn?

Có rất nhiều nguồn để học hỏi từ các đồng nghiệp giàu kinh nghiệm hơn: sách, blog của các nhà phát triển khéo léo, Stack Exchange, bài giảng / hội nghị, v.v. Đánh giá mã cũng rất quan trọng và CodeReview.SE là một tài nguyên quý giá.

Chúng ta hãy xem làm thế nào nó có thể làm việc trên một ví dụ.

Thí dụ

Bạn đang đọc một bài đăng trên blog có đề cập đến thuật ngữ "ETL". Bạn không biết ý nghĩa của nó, nhưng từ bài viết này, bạn mơ hồ hiểu rằng đó là một loại quy trình hoặc quy trình làm việc để chuyển dữ liệu từ một số hỗ trợ dữ liệu sang một hỗ trợ khác.

Bạn vào Wikipedia và các tài nguyên khác và có được tầm nhìn chính xác hơn về sự việc. Vẫn chưa rõ ràng khi nào sẽ hữu ích khi sử dụng ETL. Rốt cuộc, có vẻ dễ dàng hơn nhiều để viết một truy vấn SQL sẽ thực hiện tất cả công việc, thay vì dành quá nhiều thời gian để xây dựng một ETL thực sự.

Để trả lời những câu hỏi đó, bạn mượn một cuốn sách về các ETL từ thư viện địa phương của bạn. Nó giải thích rằng một số quy trình tải chuyển đổi trích xuất không dễ thực hiện với một truy vấn SQL đơn giản: không chỉ giai đoạn trích xuất có thể xử lý một số, hỗ trợ dữ liệu đa dạng, không chỉ là cơ sở dữ liệu quan hệ, mà cả bước chuyển đổi có thể rất phức tạp đối với cả xác nhận / chuẩn hóa dữ liệu và ánh xạ dữ liệu.

Bây giờ bạn có một tầm nhìn rõ ràng về ETL là gì, làm thế nào để sử dụng nó và đặc biệt là khi bạn cần một ETL và khi nó không phải là một công cụ thích hợp. Trong khi đó, bạn đã triển khai một ETL nhỏ như một dự án cá nhân. Dự án này cho phép bạn khám phá một số điểm không đủ rõ ràng cho bạn và không được bao phủ bởi một cuốn sách. Những điểm này khá trừu tượng và không liên quan đến mã nguồn, bạn gửi câu hỏi lên Lập trình viên .

Khi bạn có cơ hội xây dựng một công ty trong công ty của mình, bạn bắt đầu tạo nó. Bạn có một vài vấn đề. Một số có liên quan đến mã; bạn gửi câu hỏi trên Stack Overflow . Những người khác có liên quan đến cơ sở dữ liệu; bạn hỏi câu hỏi trên DBA.SE .

Cuối cùng, có một hội nghị được thực hiện bởi một nhà phát triển có kỹ năng cao về cách tối ưu hóa các ETL. Bạn tham dự hội nghị này và nó cung cấp cho bạn những gợi ý quý giá về những cải tiến bạn có thể làm cho dự án của mình.

Bạn cũng bắt đầu theo dõi blog của một nhà phát triển đã làm việc trên các ETL khác nhau trong nhiều năm. Thật thú vị khi thấy các cách tiếp cận khác nhau và thông qua blog này, bạn tìm hiểu về ECCD; bạn quan tâm, vì vậy bạn mượn Bộ công cụ kho dữ liệu ETL của Ralph Kimball, cuốn sách nói chi tiết về quy trình "giải nén, làm sạch, tuân thủ và phân phối". Blog tương tự cũng đề cập đến rất nhiều ứng dụng nhằm tạo ra các ETL mà không cần kỹ năng lập trình. Điều này đặc biệt hữu ích cho ETL bạn đã thực hiện cho công ty của mình, vì sếp của bạn, người không chuyên về công nghệ, liên tục yêu cầu bạn thực hiện một số thay đổi nhỏ đối với những gì bạn đã làm.

Khám phá những điều

IMHO, phần khó khăn, khi bạn không có một người cố vấn hoặc một đồng nghiệp giàu kinh nghiệm hơn, là để khám phá mọi thứ, và bằng cách khám phá, tôi có nghĩa là chuyển từ trạng thái "Tôi chưa bao giờ nghe về điều này" cho "Tôi đã nghe về nó nhưng không biết rõ nó là gì ".

Nếu ai đó xem lại mã của tôi và nói rằng tôi thực sự nên bắt đầu sử dụng một số quy ước về phong cách, với một chút tò mò tôi có thể thấy rằng trong lập trình, có nhiều kiểu viết mã khác nhau, người ta nên gắn bó với một phong cách cho ngôn ngữ và cơ sở mã nhất định, và nhiều ngôn ngữ có các công cụ để thực thi một kiểu (như StyleCop cho C #).

Nếu không ai nói với tôi về phong cách, làm sao tôi biết rằng một thứ như vậy tồn tại?

Đó là nơi các tài nguyên như blog hoặc Stack Exchange rất tiện dụng. Wikipedia sẽ không giúp ích gì (trừ khi bạn dành nhiều ngày vào các trang ngẫu nhiên về lập trình) và sách hiếm khi nói về những điều đó.

Điều tương tự cũng áp dụng cho các mẫu và thực tiễn hoặc những thứ ít liên quan đến mã. Ví dụ, tôi khó có thể tưởng tượng một số nhà phát triển thức dậy vào buổi sáng nói với bản thân rằng anh ta phải học một cái gì đó về ITIL trong khi anh ta không bao giờ trải lòng về ITIL trước đây.

Một khi bạn phát hiện ra một thuật ngữ mới, thật dễ dàng để tìm hiểu về nó. Nếu bạn đã đưa ra một thuật ngữ "hợp đồng mã" mới và bạn là nhà phát triển C #, bạn có thể dễ dàng tự tìm đủ thông tin trên MSDN (hoặc, tốt hơn, trong cuốn sách của Jon Skeet).

Tò mò giúp

Khi tôi làm việc với thực tập sinh, tôi luôn nhận thấy rằng những người giỏi nhất là những người tò mò bên ngoài bài giảng của họ. Họ có thể biết rằng có một thứ gọi là lập trình chức năng ngay cả khi không có giáo viên nào của họ không bao giờ đề cập đến nó, và mặc dù họ có thể không biết bất kỳ ngôn ngữ chức năng nào, họ vẫn có thể giải thích một cách chung chung về FP là gì và nó khác với ngôn ngữ khác như thế nào mô thức. Họ có thể biết về Agile, hoặc về Unicode, hoặc về mô hình tin cậy một phần / hộp cát, chỉ vì họ đang đọc blog và sử dụng Stack Exchange, thay vì chỉ đơn giản là tham dự các bài giảng của họ.

Ngay cả khi họ không có người cố vấn, họ vẫn học tất cả những điều không được kể ở trường đại học.

Tôi đang ở trong một tình huống tương tự: chúng tôi là một nhóm nhỏ và công việc sản phẩm phát triển cốt lõi của chúng tôi chủ yếu là những thay đổi gia tăng trên cơ sở mã đã vài năm tuổi.

Một vài kỹ thuật tôi đang sử dụng để luôn cập nhật và cải thiện kỹ năng của mình.

Trong công việc:

• Đọc: sách, blog, tài liệu PR. Tôi theo một số nguồn cấp dữ liệu RSS. Khi thỏa thuận O'Reilly trong ngày là về một công nghệ mà tôi chưa từng nghe đến, tôi đã đọc qua phần mô tả của cuốn sách. Nếu công nghệ có liên quan nhiều đến bất cứ điều gì tôi đang làm việc, tôi dành năm hoặc mười phút để nghiên cứu nó sâu hơn một chút, tương tự như câu trả lời của MainMa. Tôi lặp lại điều này với một vài nguồn cấp RSS khác nhau.
• Xây dựng kế hoạch đào tạo với quản lý của bạn có thể được hỗ trợ bằng các nguồn lực của công ty (thời gian và / hoặc tiền)
• Trái với xu hướng của hầu hết các lập trình viên, hãy cố gắng nắm bắt sự thay đổi và các tùy chọn thiết kế mới. Thay đổi vì mục đích thay đổi là không tốt , nhưng tôi tin rằng quá thường xuyên các nhà phát triển tránh sử dụng một thiết kế hoặc khung mới vì thay đổi. Đây là một cách tốt để đi bộ và đừng vội vã đưa ra các quyết định ràng buộc, nhưng hãy chú ý đến những cách làm mới. Một số thay đổi có thể có lợi ích bất ngờ: chuyển sang DVCS cho phép tôi thử nghiệm trên cơ sở mã của chúng tôi dễ dàng hơn và thử các công nghệ mới ở đó.
• Một số người thích hội nghị; Tôi đã thấy rằng tiền chi trả rất nhỏ cho thời gian đầu tư.

Ngoài giờ làm việc:

Tôi đã thấy rằng làm việc với các kỹ năng của mình ngoài công việc hàng ngày là rất quan trọng. Sự tự do để thử nghiệm, phạm sai lầm và theo đuổi sở thích khiến tôi tham gia vào CNTT. Nếu tôi chỉ có các dự án tại chỗ của mình và cần giới hạn việc học ở những gì hữu ích ngay lập tức, tôi sẽ nhanh chóng kiệt sức.

• Tham gia vào một dự án không làm việc. Đối với tôi, điều này đang phát triển một trang web chức năng liên quan đến lợi ích cá nhân. Tôi tái cấu trúc một cách tự do, và tích cực cố gắng thử nghiệm các công nghệ khác nhau. Đóng góp cho Nguồn mở cũng sẽ giúp bạn tiếp xúc với mã của người khác. Điều này cũng sẽ cung cấp cho bạn tài liệu tốt để chia sẻ cho các cuộc phỏng vấn với công ty sẽ có nhiều nhà phát triển có kinh nghiệm hơn.
• Trại mã: Nếu có một trại mã trong khu vực của bạn tham dự. Vì những thứ này không trong giờ làm việc và miễn phí, bạn cảm thấy tự do tham dự bất kỳ phiên nào cho các chủ đề mà cá nhân bạn quan tâm. So với các hội nghị thông thường, đây thường là các địa phương và bao trùm các công nghệ rộng lớn, vì vậy tôi tin rằng có giá trị tập trung hơn.

Và đừng quên ghé thăm SO hoặc Lập trình viên. Thường xuyên.

Các câu trả lời ở đây có thể sẽ giúp ích rất nhiều, nhưng tôi muốn nhấn mạnh một điều: không có gì có thể thay thế làm việc với ai đó tốt hơn bạn (tùy tiện và cá nhân, định nghĩa tốt hơn) trong 8 giờ một ngày, 5 ngày một tuần. Điều đó là chắc chắn.

Nếu bạn là kiểu nhà phát triển luôn muốn tốt hơn, luôn muốn học hỏi, thì cuối cùng bạn sẽ phải đến một công ty khác. Điều đó là không thể tránh khỏi, và nên được lên kế hoạch cho.

Khi bạn tìm thấy công ty phù hợp với mình, bạn sẽ thấy rằng bạn có thể tiếp tục phát triển trong đó, hơn là phát triển từ đó.

Phát triển phần mềm là một môn thể thao đồng đội. Giống như một môn thể thao, để chơi ở cấp độ rất cao, bạn cần phải đồng hành và cạnh tranh với những người khác cũng làm như vậy. Tìm kiếm cơ hội để di chuyển xung quanh.

Hãy nhớ rằng thực hành là vĩnh viễn, vì vậy nếu bạn không ngừng nỗ lực hướng tới kỹ thuật và kiến ​​thức tốt hơn, nếu bạn làm việc một mình mà không có nhà phê bình hoặc mô hình vai trò, bạn có thể thấy rằng kỹ năng của mình không phát triển.

Trên toàn thế giới, mọi thứ đang trở nên cạnh tranh hơn, vì vậy hãy chờ đợi sự thích hợp của bạn là tạm thời và chuẩn bị cho loại cơ hội đáp ứng tiêu chí của bạn để đáp ứng công việc, đồng thời, đưa bạn ra ngoài vùng thoải mái để làm việc với một nhóm vượt trội.

Trước khi tôi nhận được bất kỳ lời đề nghị nào, tôi phải nói rằng tôi đã ở một vị trí rất giống nhau chỉ hơn một năm trước.

Nếu bạn đang hoàn thành các dự án, nhưng bạn cảm thấy rằng có rất nhiều không gian để cải thiện, thì đó là một điều tốt.

Có một lần tôi đã không có khả năng kỹ thuật và sự tự tin để hoàn thành dự án. Thường thì tôi sẽ mua một cuốn sách, tôi sẽ đọc một blog khá kỹ thuật và sẽ thấy mình "không chuyên sâu". Tôi nghĩ vấn đề lớn nhất đối với tôi là thực tế là tôi đã không tiếp xúc với bất kỳ ứng dụng doanh nghiệp lớn nào. Rất thường xuyên tôi sẽ làm một cái gì đó tốt, nhưng tôi sẽ không có ai bên cạnh để xác nhận những gì tôi đã làm.

Điều này rất hấp dẫn và đầy thách thức, vì vậy tôi thấy bạn đến từ đâu. Làm thế nào tôi giải quyết vấn đề này? Tôi rời một công ty và gia nhập một nhà phát triển phần mềm được thành lập, điều này đã giúp tôi có được nhiều kinh nghiệm trong năm qua.

Trừ khi bạn muốn rời khỏi công ty, tôi sẽ đề xuất những cuốn sách được viết bởi những người tiên phong trong ngành công nghiệp của chúng tôi. Tôi sẽ bắt đầu với Lập trình viên thực dụng của Andrew Hunt. Cuốn sách chứa hàng tấn tương tự hữu ích rất dễ nhớ. Một vài chương đầu tiên của cuốn sách này đã khuyến khích tôi chọn một ngôn ngữ lập trình rất khác với ngôn ngữ chúng ta sử dụng trong công việc. Tôi đã bắt đầu đọc văn học phi kỹ thuật - Bây giờ tôi tin rằng đọc tiểu thuyết và khoa học viễn tưởng sẽ giúp tôi trở thành một lập trình viên giỏi hơn. Viết bài luận không phải là xa để viết mã sạch. Một số nhà văn là tốt và một số là xấu. Cuốn sách này khiến tôi quan tâm đến những gì tôi viết. Một trong những điều tương tự được gọi là "Windows bị hỏng". Bạn để một chiếc xe bị bỏ rơi trên đường trong nhiều ngày và không có gì xảy ra với nó. Khi bạn phá vỡ một cửa sổ, chiếc xe có thể sẽ bị phá hủy vào ngày hôm sau. Mã cũng không khác. Nếu bạn thấy mã bị hỏng hoặc viết kém, thì hãy sửa nó ngay lập tức, đừng để nó ở đó vì sớm muộn nó sẽ quay lại "ám ảnh" bạn. Khi bạn bắt đầu thực hiện theo cách của mình thông qua cuốn sách này, bạn sẽ nhận được hàng tá các tương tự tương tự sẽ khiến bạn nghĩ về mã theo một cách khác.

Sau đó tôi sẽ đề nghị bạn chuyển sang Clean Code của Robert C. Martin. Cuốn sách này thực tế hơn vì nó buộc bạn phải đọc mã xấu và tốt (sạch). Tác giả sử dụng các mẫu mã từ một trong các dự án nguồn mở. Bạn nói không có ai hướng dẫn bạn. Có một cơ hội hoàn hảo để xem mã của người khác, so sánh nó với mã của riêng bạn và xem bạn có thể cải thiện mã đó như thế nào. Đối với tôi đọc cuốn sách này giống như che giấu ai đó đang làm việc trong một dự án. Cuốn sách cũng nhấn mạnh vào điều khó nhất dễ nhất - tách mối quan tâm. Tác giả đã hỏi những người tiên phong trong ngành của chúng tôi những gì họ coi là một mã "sạch". Khi bạn đọc câu trả lời của họ, bạn sẽ có thể so sánh chúng với ý kiến ​​của riêng bạn về mã sạch là gì.

Cuối cùng, bạn đã xem xét làm việc trên các dự án nguồn mở chưa? Bạn sẽ hợp tác với các nhà phát triển khác, có lẽ nhiều kinh nghiệm hơn, những người sẽ có thể xem lại mã của bạn và chỉ cho bạn một hướng đi đúng đắn.

Như tôi đã nói trong câu trả lời ban đầu của mình, nó sẽ không xảy ra trong đêm. Tôi đã làm điều này trong vài năm nay và hầu như mỗi ngày tôi phát hiện ra rằng tôi đã làm sai.

Chúc may mắn!

Thực hành giải quyết vấn đề. Đọc và làm việc để hiểu mã người khác (github là một tài nguyên tuyệt vời cho việc này) và gửi các cải tiến cho nó. Làm công việc tư vấn thực sự có thể giúp bạn mở rộng bộ kỹ năng của bạn.