Làm thế nào để tôi đi từ việc có thể viết mã để trở thành một nhà phát triển giỏi?

Tôi thất vọng vì thiếu những giải thích cụ thể về cách đi từ khả năng viết kịch bản (bash, awk) và viết các ứng dụng đơn giản (c, php, python) để thiết kế và phát triển phần mềm lớn hơn, phức tạp hơn. Dường như một mặt có sách ngôn ngữ lập trình và mặt khác có sách quản lý dự án / kỹ thuật phần mềm được thiết kế cho các nhóm lập trình viên.

Tôi đã đọc rất nhiều cả hai. Tôi đã đọc các tác phẩm kinh điển XP / Agile và có hiểu biết lý thuyết đúng đắn về quy trình phát triển phần mềm. Tôi thích đọc mã của người khác và có thể theo dõi nó khá tốt. Nhưng khi tôi có ý tưởng cho một dự án hoặc muốn đi từ "đây là vấn đề / nhu cầu" sang "đây là giải pháp", tâm trí tôi trống rỗng và tôi không biết bắt đầu từ đâu.

Tôi chỉ cần hack nó ra? Có bất kỳ quy trình công việc có cấu trúc nào cho các nhà phát triển riêng lẻ không làm việc theo nhóm hoặc cho một nhà phần mềm lớn không? Tôi thực sự không muốn có PMP hoặc làm việc cho một công ty phần mềm. Tôi chỉ tìm kiếm một quy trình làm việc hiệu quả, hiệu quả.

Theo tôi, bạn trở thành một nhà phát triển giỏi bằng cách có kinh nghiệm và làm việc với nhiều cách làm việc. Bạn đã nói rằng bạn có một vấn đề từ "đây là ý tưởng của tôi" đến "đây là giải pháp của tôi". Đó là một cái gì đó nhiều hơn đối với các phương pháp phát triển phần mềm cũng như là một nhà phát triển có kinh nghiệm.

Sử dụng một phương pháp phát triển phần mềm không chỉ là "hack mã" và các phương pháp này cung cấp các quy trình công việc có cấu trúc. Có gia đình Agile cung cấp cấu trúc tốt cho các nhóm phát triển (hoặc cá nhân) nhỏ hơn mà bạn có thể theo dõi để giúp bạn chuyển từ giai đoạn "ý tưởng" sang giai đoạn "thành phẩm".

Có một vài điều mà tôi đã học được trong nhiều năm từ những người khác và thông qua làm việc trên các dự án khác nhau, chẳng hạn như:

• Làm cho mọi thứ có thể kiểm tra, điều này sẽ làm cho cuộc sống của bạn dễ dàng hơn nhiều;
• Bạn không thể mong đợi có một thiết kế hoàn hảo và có thể thiết kế các ứng dụng doanh nghiệp / tiêu đề trò chơi lớn nhất tiếp theo / chèn thêm ở đây, mà không có kinh nghiệm làm việc đó;
• Thật khó để thiết kế phần mềm tốt nếu bạn chưa có kinh nghiệm làm việc đó và học hỏi từ người khác;
• Bạn sẽ không bao giờ có một thiết kế hoàn hảo ngay lần đầu tiên, ngay cả khi là một nhà phát triển có kinh nghiệm - mọi thứ thay đổi và do đó; thiết kế của bạn cũng có thể;
• Viết mọi thứ xuống: Viết / vẽ / bảng trắng / vẽ tranh / bất cứ điều gì bạn cảm thấy thoải mái, nó làm cho cuộc sống dễ dàng hơn nếu bạn có những điều được viết ra. Chẳng hạn như thiết kế GUI, sơ đồ lớp, v.v. Theo kinh nghiệm của tôi, chỉ cần "hack một cái gì đó cùng nhau" có khả năng thất bại thảm hại;
• Đừng phát minh lại bánh xe, bạn không cần phải làm vậy. Nếu bạn đang cố gắng thực hiện HashMap của riêng mình thì có lẽ bạn đã làm sai điều gì đó. Nghiên cứu mọi thứ, và suy nghĩ trước khi bạn viết mã.

Hy vọng một số điều đó sẽ giúp.

Vâng, theo tôi, như trong bất kỳ ngành nghề nào, để trở thành một chuyên gia giỏi tất cả những gì nó cần - bên cạnh sự hình thành lý thuyết - là kinh nghiệm .

Là một bác sĩ không thể giỏi chỉ với các lớp học ở trường y, hoặc luật sư không thể biết tất cả các khía cạnh chính trị của việc trở thành một người chỉ có bằng cấp, là một nhà phát triển giỏi cần có kinh nghiệm và thời gian.

Kinh nghiệm không đến bằng cách đọc mã bên thứ ba. Nếu bạn có một sinh viên y khoa, anh ấy / cô ấy sẽ có thể chỉ ra rất nhiều thủ tục, điều trị, thuốc men, v.v., nhưng việc áp dụng thực tế những điều này (khi áp dụng một thủ tục, điều gì đáng để chẩn đoán, v.v.) chỉ đến với sự giám sát và kinh nghiệm.

Vì bạn không muốn làm việc cho một công ty lớn (hoặc bất kỳ công ty nào về vấn đề đó), tôi khuyên bạn nên bắt đầu bằng cách phát triển các ứng dụng nhỏ, từng bước một. Tự mình phát triển phần mềm mất rất nhiều thời gian, tin tôi đi.

Một điều khác mà tôi đề nghị với bạn để trở thành một nhà phát triển / kỹ sư phần mềm giỏi, là đóng góp cho phần mềm nguồn mở. Rất nhiều chàng trai đã kiếm được một số tiền kha khá (và kinh nghiệm, btw) bằng cách giúp phát triển phần mềm nguồn mở và đưa ra các tư vấn sau đó. Họ đã tự đặt tên cho mình bằng những đóng góp của họ cho nguồn mở.

Dù sao, tôi nghĩ rằng không có một lối tắt để có được kinh nghiệm, và nó phải được theo đuổi với kỷ luật và kiên nhẫn .

Bạn có thể bắt đầu bằng cách tăng cường mã của người khác. Lấy một số dự án bạn đã có và thêm một tính năng cho nó. Bạn sẽ phải quyết định những gì tính năng sẽ làm, và làm thế nào nó nên làm điều đó. Làm việc trong khuôn khổ của mã hiện có, thiết kế giải pháp của bạn.

Và đừng sợ hack mọi thứ. Rất nhiều sự phát triển mới được thực hiện bằng cách tinh chỉnh (hoặc tốt nhất là viết lại) các nguyên mẫu nhanh và bẩn. Đi trước và sử dụng mọi thực hành tồi tệ nhất và antipotype trong cuốn sách, chỉ cần viết ra một cái gì đó làm những gì bạn muốn. Sau đó, quay trở lại và thiết kế nó đúng cách. Thông thường, tôi thấy mình suy nghĩ "Bạn biết đấy, một cách tốt hơn để làm điều này sẽ là ..." trong khi tôi khó mã hóa một số tham số cấu hình trong sự quái dị ba thủ tục 800 dòng của mình.

Tôi biết hiện tại nó không còn thịnh hành, nhưng các kỹ thuật phân tích có cấu trúc thực sự đã giúp tôi nắm bắt được thiết kế phần mềm. Chơi xung quanh với việc tạo ra một vài biểu đồ bong bóng và DFD để có cảm giác phân tách các vấn đề và thiết kế các phần khác nhau của một hệ thống để làm việc cùng nhau.

Như những người khác đã nói, kinh nghiệm đến từ việc viết mã. Nhưng bạn cũng nên nhờ người khác xem lại mã của mình nếu có thể. Một lập trình viên giàu kinh nghiệm hơn có thể chỉ ra các vấn đề trong mã của bạn và chỉ cho bạn cách làm việc tốt hơn. Đóng góp cho một dự án nguồn mở sẽ cho bạn cơ hội để làm cả hai.

Đối với tôi, nó giúp chia nhỏ một phần mềm lớn hơn thành nhiều phần nhỏ hơn. Và sau đó chia những khối đó thành những phần nhỏ hơn và cứ thế. Mỗi chương trình phần mềm là một tập hợp các mẩu logic nhỏ.

Hãy xem xét một blog, ví dụ. Bạn muốn có thể tạo và chỉnh sửa bài viết mà người khác có thể đọc. Ngay lập tức bạn có thể chia dự án thành các phần quản trị và công cộng. Tối thiểu, quản trị viên sẽ yêu cầu người dùng quản trị viên, trang đăng nhập và phần quản lý blog. Phần để quản lý blog có thể được chia thành giao diện CRUD (Tạo, Đọc, Cập nhật, Xóa). Tạo một bài đăng blog mới sẽ yêu cầu kiểm tra để đảm bảo người dùng quản trị viên có các đặc quyền, biểu mẫu, xác thực mẫu và khả năng lưu vào cơ sở dữ liệu. Và như thế.

Bạn càng phá vỡ một vấn đề hoặc một tính năng, nó càng trở nên dễ quản lý hơn. Đó là sự chia rẽ và chinh phục. Khi bạn đã có thể vạch ra phần mềm của mình như thế này, bạn có thể xem cách các phần mềm khác nhau tương tác với nhau. Bạn có thể lặp lại mã ở đâu? Những gì có thể được trừu tượng hóa? Đây phải là một quá trình lặp lại cả khi bạn lập kế hoạch và khi bạn tự viết mã.

Tôi khuyên bạn nên tìm hiểu bộ tính năng tối thiểu của bạn là gì để bắt đầu và thực hiện điều đó trước khi thêm các phần khác vào nó. Bạn sẽ muốn mã hóa phòng thủ để những thay đổi trong tương lai sẽ không quá khó khăn, nhưng đồng thời, bạn không muốn triển khai một nửa tính năng có thể không bao giờ được hoàn thành. Đó là một khó khăn để đi giữa linh hoạt và sẵn sàng tàn nhẫn giết chết những người thân yêu của bạn, để mượn một tài liệu tham khảo văn học. Làm tốt với hành động cân bằng cụ thể đó chỉ đến từ kinh nghiệm.

Và đó là những gì nó được đưa ra, như các câu trả lời khác đã đề cập: kinh nghiệm. Cách duy nhất để có được nó là chỉ bắt đầu. Đừng lo lắng quá nhiều về việc làm cho nó hoàn hảo ngay từ đầu. Đầu tiên làm cho mã hoạt động, sau đó làm cho nó đẹp, sau đó làm cho nó nhanh.

Ngoài ra, không giống như đoạn này, cuối cùng đừng giải quyết vấn đề bảo mật. Bạn nên có ý tưởng về cách phần mềm của bạn có thể bị xâm phạm, nhưng khi bắt đầu, không bao giờ tin tưởng bất kỳ đầu vào nào của người dùng.

Tôi biết bạn nói rằng bạn không muốn làm việc cho một công ty phần mềm, nhưng đó là một nơi tốt để có được trải nghiệm mà nhiều câu trả lời khác nói về. Và dù bạn có muốn làm việc trong các dự án lớn hay không, tiếp xúc với công việc và phong cách làm việc của người khác là những điều tốt để có.

Bạn không thể tự mình thử lập trình Ghép đôi. Và nếu bạn kết hợp với ai đó thông minh hơn bạn, bạn sẽ nhận được thêm lợi ích từ việc kiếm được các thực tiễn tốt hơn từ họ trong khi có kinh nghiệm về phương pháp đó.

BTW, tôi đã thực hiện việc cố gắng làm việc với các nhóm mà tôi cảm thấy mình dưới mức trung bình về kinh nghiệm, kỹ năng và những thứ tương tự. Nó làm tăng trò chơi của tôi rất nhiều. Làm điều đó một mình khó hơn nhiều hoặc bạn là người "có kinh nghiệm".

Những gì bạn đang tìm kiếm là kỹ năng giải quyết vấn đề . Tôi đã nhận thấy rằng người ta cho rằng nhà phát triển đã có thể làm điều này, điều này thật ngớ ngẩn. May mắn thay, giải quyết vấn đề là một kỹ năng chung, được sử dụng trong toán học, nghiên cứu, cuộc sống hàng ngày và như vậy.

Chủ yếu, bạn nên kết thúc theo phương pháp khoa học, với một số diềm.

1. Bạn có một vấn đề (sử dụng các công cụ và kỹ thuật để giúp xác định điều này)
2. Bạn đưa ra giả thuyết về một giải pháp (mô hình và kinh nghiệm trợ giúp)
3. Kiểm tra giả thuyết (bạn thậm chí có thể không có mã ở đây)
4. Lặp lại bước 2 và 3 cho đến khi giả thuyết được giữ. Bây giờ bạn có một lý thuyết (chương trình làm việc để giải quyết vấn đề)
5. Phát triển một thí nghiệm cho lý thuyết căng thẳng, tìm kiếm lỗ hổng (trường hợp thử nghiệm!)
6. Nếu trường hợp kiểm tra giữ, bạn có một giải pháp! Nếu không, rửa sạch và lặp lại

Lưu ý rằng đây là mức độ khá cao. Mỗi bước thường bao gồm một số bước nhỏ, chẳng hạn như xác định vấn đề thực sự là gì. Ví dụ, nhìn vào việc giải các bài toán đố trong toán học. Bạn thu thập dữ kiện (một công cụ) và xác định những gì thực sự muốn. Sau đó, bạn kiểm tra sự thật của bạn, cố gắng ánh xạ chúng đến giải pháp.

Điều này kết thúc trở thành vấn đề phụ của vấn đề chính. Vì vậy, hãy làm theo các bước một lần nữa. Chúng tôi cần một mục trung gian để có được kết quả cuối cùng, vì vậy nó trở thành vấn đề mới của chúng tôi. Điều này phân tách vấn đề thành các phần nhỏ, dễ hiểu. Khi mỗi phần được giải quyết, các giải pháp được ghép lại với nhau.