Những điều tồi tệ nhất mà các nhà phát triển thiếu kinh nghiệm quên suy nghĩ là gì? [đóng cửa]

Là một nhà phát triển trẻ, tôi sẽ thấy hữu ích khi nhận được một số lời khuyên liên quan đến những điều cần suy nghĩ để phát triển một ứng dụng chất lượng cao. Trong các khóa học đại học của tôi, hầu hết các giáo viên đều nhấn mạnh đến xác nhận đầu vào và một số nói về mối quan tâm bảo mật, nhưng không ai nói về tầm quan trọng của một số thứ khác, như đăng nhập chẳng hạn.

Một số sai lầm mà các nhà phát triển thiếu kinh nghiệm có xu hướng mắc phải có thể dẫn đến sự thất vọng cho các nhà phát triển có kinh nghiệm hơn là gì?

Tôi thấy điều chính mà các nhà phát triển mới quên là trong thế giới thực, họ thường làm việc như một phần của một nhóm. Điều này thể hiện chính nó là ..

• Kiểm tra mã phá vỡ bản dựng
• Không sử dụng lại mã đã có
• Làm mọi thứ theo cách của họ chứ không phải giống như mọi người khác - điều này khiến cho việc bảo trì tốn kém

Điều đó không có nghĩa là mã của họ không bị cô lập, nhưng họ không hoạt động trong sự cô lập nữa.

1. Các xét nghiệm.
2. Các xét nghiệm.
3. Nhiều xét nghiệm hơn.
4. Kiểm soát nguồn
5. Thuế phù hợp với bất kỳ chương trình nào bạn đang nhắm mục tiêu.

Trên Windows, các loại thuế này là :

• Xử lý môi trường DPI cao
• Hồ sơ người dùng chuyển vùng
• Chuyển đổi người dùng nhanh
• Remote Desktop (ví dụ: bạn không muốn sử dụng bộ đệm đôi khi RDP có hiệu lực
• Chơi độc đáo với Quản lý lưu trữ phân cấp
• Nhiều màn hình
• Windows 64 bit

Trên hầu hết mọi nền tảng, bạn sẽ phải đối phó với:

• Unicode
• Bản địa hóa
• Quản lý điện năng

Theo kinh nghiệm của tôi, một điều gần như tất cả các nhà phát triển thiếu kinh nghiệm không nhớ là bạn (hầu như luôn luôn) làm việc trong môi trường thương mại. Mã của bạn phải tốt, nhưng không hoàn hảo. Điều quan trọng nhất không phải là sự hoàn hảo, đó là mã của bạn được gửi đi.

Nói cách khác, việc cung cấp một đoạn mã hoàn hảo ba tháng sau khi công ty của bạn phá sản là không tốt cho bất cứ ai.

Theo tôi, đây là một trong những cách quan trọng nhất trong đó phát triển trong thế giới thực khác với phát triển như được dạy ở trường đại học.

Câu hỏi thực sự rộng; để trả lời chi tiết là ... nhiều sách.

Đây là danh sách kiểm tra định nghĩa hệ thống chung để giúp bạn bắt đầu -

• Các tài nguyên quan trọng trong hệ thống là gì và các yêu cầu đối với chúng có thể thay đổi như thế nào?
• Khả năng hiệu suất của hệ thống là gì và làm thế nào chúng có thể cần phát triển?
• Những lĩnh vực yêu cầu có thể trở nên không cần thiết và có thể tháo rời?
• Có khả năng cần phải có các phiên bản khác nhau của hệ thống với các khả năng khác nhau không?
• Các tác động về nhân lực và tài nguyên máy tính là gì nếu những thay đổi được xác định xuất hiện?
• Hệ thống mới sẽ có tác động gì đối với các hệ thống hoạt động hiện tại?
• Những lĩnh vực chức năng nào có cơ hội lớn hơn đòi hỏi phải thay đổi ánh sáng kinh nghiệm với hệ thống?
• Người dùng tương lai của hệ thống là ai?
• Những người duy trì hệ thống trong tương lai là gì?
• Những cải tiến trong tương lai mà người dùng trong tương lai của hệ thống có thể xác định là gì?
• Làm thế nào để hệ thống phù hợp với kế hoạch tổng thể của người dùng và họ dự kiến ​​sẽ phát triển như thế nào?

Việc tách rời sạch hệ thống trên máy phát triển của một người và máy đích, để người ta không kết thúc với các tình huống "Chà, nó hoạt động trên máy của tôi".

Và làm thế nào nhanh chóng bạn có thể xây dựng lại bộ máy phát triển của bạn?

• Bạn có biết những gói bạn yêu cầu?
• Bạn có một giải pháp nút nhấn để xây dựng lại cơ sở dữ liệu của bạn?
• Bạn có giải pháp nút ấn để kiểm tra tính toàn vẹn trên mã nguồn không?

Tôi nghĩ rằng nó có thể là thiết kế - tức là cách tiếp cận suy nghĩ về những gì bạn sẽ làm trước khi bạn làm nó.

Quá nhiều lập trình viên thiếu kinh nghiệm (hãy nhớ khi bạn mới bắt đầu) muốn nhảy vào và làm gì đó, sau đó thêm một chút và quảng cáo thêm một chút và thêm một chút nữa. Cách tiếp cận này có thể hoạt động nếu bạn dự định thực hiện theo cách đó (mỗi bit có thể được kiểm tra khi bạn thực hiện), nhưng hầu hết các lập trình viên thiếu kinh nghiệm chỉ tập trung vào phần họ đang viết .. vì vậy tất cả các bổ sung có xu hướng bị hack trên đầu trang Và chúng ta đều đã thấy mã được phát triển như thế!

Tổ chức là điều tiếp theo, thường thì họ quá tập trung vào mã họ đã viết để nhớ cách họ đã làm nó và những gì được yêu cầu. Vì vậy, họ quên gói hoặc ghi lại một phụ thuộc cần thiết. Họ cũng có xu hướng đặt những thứ mà họ rơi xuống, tôi đã chỉ trích một thiếu niên tuần trước đã kiểm tra mã của anh ấy trong thư mục gốc bao gồm 3 wsdls, 2 trong số đó là cùng một tệp và một bộ dll của bên thứ 3 mà anh ấy đã cam kết một thư mục con và thư mục gốc. Mã không được định dạng theo bất kỳ tiêu chuẩn nào bạn có thể nghĩ ra và có một số chức năng có mặt nhưng không bao giờ được gọi.

Rõ ràng là anh ta đã làm cho nó hoạt động nhưng nó không gọn gàng, và điều đó có nghĩa là cài đặt và bảo trì, sẽ gây rắc rối.

Tôi nghĩ rằng sự khác biệt lớn nhất là trong kỹ thuật mã hóa. Mọi người có một cách tiếp cận hơi khác nhau, nhưng các nhà phát triển thiếu kinh nghiệm có xu hướng tạo ra mã:

• không xử lý các trường hợp ranh giới
• dài hơn mức cần thiết
• có đặc điểm hiệu suất xấu trong các tình huống có liên quan
• phân tách mối quan tâm kém
• thiếu các kỹ thuật tự bảo vệ như sử dụng const, niêm phong, chỉ đọc, v.v.
• cách lẻ bóng trả về dữ liệu và bộ sưu tập dữ liệu
  • điều này càng chứng tỏ sự thiếu kinh nghiệm với một nền tảng

Bởi vì bạn đã hỏi những điều tồi tệ nhất, sau đó câu trả lời của tôi như sau:

1. Quên suy nghĩ về việc vệ sinh bộ máy phát triển từ các phần mềm gián điệp, phần mềm độc hại và virus trojan.
2. Quên suy nghĩ về việc tạo một bản sao lưu thường xuyên được lưu trong các kho lưu trữ an toàn ở các vị trí địa lý khác nhau.

Người lớn nhất của tôi là nhớ lập kế hoạch cho sự linh hoạt. Trong các lớp học, các yêu cầu hầu như luôn được đặt ra ngay từ đầu và không bao giờ thay đổi. Trong phần mềm, điều này thường ngược lại: bạn nhận được một bộ yêu cầu mơ hồ và chúng thay đổi thường xuyên (thậm chí hàng ngày). Điều tốt nhất mà bạn có thể làm để giúp với điều này là mã hóa linh hoạt: khớp nối lỏng lẻo, các chức năng nhỏ có thể được sử dụng đáng tin cậy trong nhiều tình huống và tránh những thứ mã hóa cứng nhất có thể.

Theo thời gian, bạn có khả năng tìm hiểu a) những thứ có khả năng thay đổi nhất, và ngược lại những gì có khả năng sẽ không, và b) làm thế nào để dự đoán các yêu cầu thay đổi và lập kế hoạch cho chúng.