Sự khác nhau giữa lập trình trong trường học và lập trình trong ngành? [đóng cửa]

Rất nhiều sinh viên khi họ tốt nghiệp và nhận được công việc đầu tiên của họ, cảm thấy như họ không thực sự biết cách lập trình mặc dù họ có thể là những lập trình viên giỏi ở trường đại học.

Một số khác biệt giữa lập trình trong môi trường học thuật và lập trình trong "thế giới thực" là gì?

Trong một chương trình khoa học máy tính đại học truyền thống, bạn chỉ học lập trình. Nhưng thế giới thực không muốn những người chỉ là lập trình viên. Thế giới thực muốn các kỹ sư phần mềm thực sự. Tôi biết nhiều mô tả công việc dường như không thể hiện sự khác biệt này, điều này chỉ gây nhầm lẫn vấn đề. Trong thế giới thực, bạn cần có khả năng:

• Thu thập và phân tích các yêu cầu khi chúng không được cung cấp trực tiếp cho bạn
• Thiết kế và phân tích kiến ​​trúc với khả năng gần như vô tận
• Tạo các kế hoạch kiểm tra và hành động để đánh giá và cải thiện chất lượng của một hệ thống
• Làm việc cộng tác trên một nhóm người có trình độ và kinh nghiệm khác nhau
• Ước tính và lập kế hoạch công việc ngay cả khi bạn không biết chính xác những gì cần xây dựng
• Giao tiếp hiệu quả với các bên liên quan , những người có nhu cầu khác nhau, không nhất thiết phải liên kết
• Đàm phán lịch trình, ngân sách, chất lượng và tính năng mà không làm các bên liên quan thất vọng

Ồ vâng, và bạn cũng phải có khả năng viết mã, mặc dù vậy, trung bình chỉ mất 40 - 60% thời gian của một công cụ phần mềm.

Vì vậy, nó không phải là sinh viên khoa học máy tính mới tinh không biết cách lập trình (thực tế, nhiều người lập trình rất giỏi). Đó là nhiều người trong số họ không biết làm bất cứ điều gì khác.

Tại trường Đại học...

Giáo viên của bạn cung cấp cho bạn:

• Một vấn đề riêng biệt, được xác định rõ ràng, giải pháp có thể được cung cấp trong khoảng thời gian ngắn và được xác định rõ (và nó sẽ bị loại bỏ sau đó)
• Một bộ công cụ được xác định rõ mà bạn đã được giới thiệu trước khi chuyển nhượng
• Một thước đo được xác định rõ ràng cho chất lượng giải pháp của bạn, mà bạn có thể dễ dàng xác định xem giải pháp của mình có đủ tốt hay không

Trong thế giới thực"...

• Vấn đề là mờ, phức tạp và được nhúng trong bối cảnh. Đó là một tập hợp các yêu cầu mâu thuẫn thay đổi theo thời gian và giải pháp của bạn phải đủ linh hoạt và mạnh mẽ để bạn phản ứng với những thay đổi đó trong thời gian chấp nhận được.
• Các công cụ phải được chọn bởi bạn. Có thể đã có một cái gì đó có thể sử dụng được trong cơ sở mã 10 năm của nhóm bạn, có thể có một số dự án nguồn mở hoặc có thể là một thư viện thương mại hoặc có thể bạn sẽ phải tự viết nó.
• Để xác định xem việc lặp lại hiện tại của phần mềm của bạn có phải là một sự cải tiến hay không (vì bạn gần như chưa bao giờ thực hiện với dự án phần mềm), bạn cần thực hiện kiểm tra hồi quy và kiểm tra khả năng sử dụng, điều này thường có nghĩa là mâu thuẫn, phức tạp, mâu thuẫn , yêu cầu nhúng ngữ cảnh một lần nữa thay đổi.

Phần kết luận

Lập trình trong trường học và lập trình trong thế giới thực rất khác nhau đến mức thực sự có rất ít sự chồng chéo. CS sẽ chuẩn bị cho bạn phát triển phần mềm "thế giới thực" như đào tạo điền kinh sẽ chuẩn bị một đội quân cho trận chiến.

Họ phải đối mặt với một khía cạnh khác của vấn đề:

Academia chủ yếu tập trung vào "khoa học lập trình", do đó nghiên cứu cách tạo ra thuật toán cụ thể hiệu quả hoặc phát triển các ngôn ngữ phù hợp để làm cho các mô hình nhất định trở nên biểu cảm hơn. Công nghiệp chủ yếu tập trung vào sản xuất những thứ phải bán. Nó phải dựa vào "các công cụ" không chỉ là ngôn ngữ và thuật toán, mà còn là các thư viện, khung công tác, v.v.

Sự khác biệt về "trọng tâm" này là nguyên nhân khiến một bậc thầy về học thuật trong C thực tế không thể viết ứng dụng windows (vì API của chúng tôi không theo tiêu chuẩn C99!), Do đó cảm giác như "không thể lập trình". Nhưng, trên thực tế, anh ta có tất cả các khả năng để tự tìm hiểu những gì mình đang thiếu. Một cái gì đó - không có các nghiên cứu học thuật thích hợp (không nhất thiết phải được thực hiện ở Academia) - khá khó tìm.

Câu trả lời tốt. Để tôi nói thêm, lập trình học thuật có xu hướng gần giống như đồ chơi. Điều này là tốt cho giảng dạy. Là một giáo viên, bạn đang cố gắng truyền đạt ý tưởng một cách hiệu quả nhất. Nhược điểm là lập trình thực tế quá khác biệt về chất, thật khó để thu hẹp khoảng cách.

Một lĩnh vực khác biệt là trong phân tích hiệu suất. Tôi đã viết nhiều bài viết cố gắng chỉ ra điều này. Phân tích hiệu suất chỉ là bề ngoài về các thuật toán và đo lường. Để làm điều đó thực sự hiệu quả, bạn phải tiếp cận nó như một quá trình gỡ lỗi.

Một lĩnh vực khác biệt là khả năng bảo trì. Điều này bao gồm mọi thứ, từ phong cách đến thiết kế ngôn ngữ dành riêng cho tên miền. Bạn không thể làm điều đó một cách hiệu quả trừ khi bạn thực sự biết những gì bạn đang cố gắng giảm thiểu.

Những điều này không được dạy, và chúng tạo ra sự khác biệt lớn về năng suất.

Trong thế giới học thuật, hầu hết mọi người học ngành khoa học máy tính hoặc các khóa học liên quan. Dijkstra từng quan sát rằng "Khoa học máy tính không hơn gì máy tính so với thiên văn học là về kính viễn vọng". Một người học ngành khoa học máy tính trước hết là học để trở thành một nhà khoa học chứ không phải là một lập trình viên. Là một lập trình viên, anh ta sẽ ở lại một người nghiệp dư, và việc chuyển đổi sang một lập trình viên chuyên nghiệp theo đó là khó khăn.

Cập nhật: Như thể ai đó đang đọc suy nghĩ của tôi: Kỳ vọng tốt nghiệp so với thực tế ...

Tôi thực hiện, hai yếu tố khác:

Quy mô vấn đề : Ở học viện, tôi chủ yếu phải phát triển phần mềm "từ đầu", điều đó có nghĩa là hầu hết thời gian, chương trình lớn nhất tôi gặp phải là chương trình lớn nhất tôi đã viết. Điều này nhấn mạnh khả năng cần thiết để xử lý và đối phó với sự phức tạp xuất hiện từ các phần mềm khác nhau tương tác với nhau. Nếu tôi nhận thức được nỗ lực cần thiết để hiểu được sự phức tạp, tôi có thể đã chọn không tham gia vào ngành này.

Đọc VS Writing : Một tác dụng phụ khác của quy mô vấn đề là thường, trong "thế giới thực", chúng ta tiếp xúc với công việc đã được viết bởi người khác, vì mục đích bảo trì (tôi không bảo trì ở học viện ở bất cứ đâu), mở rộng hoặc đơn giản phân công lao động. Do đó đọc mã trở nên quan trọng hơn nhiều lần so với viết nó.

Một đề xuất cho giáo dục lập trình được cải thiện : Học viện nên tiếp xúc với chúng ta nhiều hơn với các tình huống trong thế giới thực mà không thụt lùi vào đào tạo nghề. Các bác sĩ phải đối mặt với một xác chết vào một lúc nào đó để xem liệu chúng có "được làm cho nó" không (tôi đã nghe câu chuyện về những người bỏ khóa học sau trải nghiệm này). Nếu tôi đã nhìn thấy ở tuổi đôi mươi, một dự án 20K LỘC bao gồm các phong cách lập trình khác nhau, mà tôi phải hiểu trong một ngày và sửa một lỗi trong ba, tôi có thể đã xem xét các lựa chọn nghề nghiệp khác - mặc dù có lẽ là không.

Sự khác biệt lớn nhất mà tôi đã tìm thấy giữa học thuật và lập trình công nghiệp là về sự mạnh mẽ. Hầu hết mọi người đều trải qua nghịch lý "nó hiệu quả với tôi" trong sự nghiệp của họ, và đây là một phần mở rộng của tình trạng này. Trong giới hàn lâm, trọng tâm là các thuật toán và chức năng và ít quan tâm đến khả năng sử dụng và tính ổn định của phần mềm trong các điều kiện hàng ngày.

Ví dụ, tại văn phòng của tôi, chúng tôi có một kỹ sư sẽ lấy phần mềm và là bậc thầy trong việc gây ra sự cố từ các điều kiện góc. Anh ta sẽ nhấp vào một nút nhanh nhất có thể cho đến khi có sự cố xảy ra ... nếu một thao tác mất quá nhiều thời gian, anh ta sẽ chỉ bắt đầu nhấp ngẫu nhiên quanh màn hình (vì thất vọng? IDK ....)

Thay đổi triết lý lập trình của chúng tôi để chúng tôi tạo ra những thứ "Bằng chứng Steve" nói chung đã cải thiện tính ổn định của ứng dụng của chúng tôi.

Tôi không có kinh nghiệm cá nhân với đào tạo lập trình ở trường - tôi là một chuyên gia tiếng Anh. Hỏi tôi về Keats và Byron! - nhưng tôi đã nhận được một vài học sinh mới và đưa họ lên và hướng dẫn họ trong thế giới phát triển phần mềm chuyên nghiệp. Vì vậy, tôi có thể nói từ quan điểm đó.

Kinh nghiệm của tôi là thực sự TẤT CẢ họ nhận được từ việc đi học là một mối quan tâm trong lập trình. Kỹ năng của họ thay đổi từ 0 đến không đáng kể. Khả năng tự định hướng của họ là không có ngay cả ở những người có kỹ năng cao nhất trong số họ. Suy nghĩ của họ không chỉ ở quy mô nhỏ; họ thực sự nghĩ trong thu nhỏ. Một hệ thống bao gồm hơn vài chục dòng mã khiến chúng rơi hoàn toàn thành từng mảnh.

Nhưng bạn biết gì không? Họ có được sự quan tâm , và đó là một vấn đề lớn. Một sự quan tâm là rất nhiều . Tôi có thể làm việc với những người quan tâm. Tôi có thể biến họ thành một nhà phát triển, miễn là họ quan tâm đến tôi. Chết tiệt, đó là tất cả những gì tôi bắt đầu. Điều đó và một sự đánh giá cao cho các tiểu thuyết gia người Mỹ hậu hiện đại.

Trong học viện,

VÒI

• Chúng tôi có thời hạn chủ yếu là để ghi điểm.
• Lỗi không thực sự gây rắc rối, vì hầu hết các dự án không bao giờ được sử dụng trong các ứng dụng trong thế giới thực.

CỘNG

• Chúng tôi có nhiều thời gian để nghiên cứu.
• Việc lắc lư từ các mục tiêu ban đầu không gây ra nhiều rắc rối.

Trong ngành công nghiệp,

• Chúng tôi làm việc trên các dự án sẽ thực sự được sử dụng bởi các tập đoàn.
• Chúng tôi làm việc dưới sự căng thẳng của việc thay đổi yêu cầu của khách hàng.
• Thời hạn hiếm khi linh hoạt, vì điều đó có thể dẫn đến tổn thất tài chính lớn cho cả công ty Phần mềm cũng như các khách hàng.

Kiểm tra này:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

Lập trình học thuật là nhiều hơn về mã nó cho mình. Điều này rất quan trọng trong việc học cách nó hoạt động. Chất lượng mã và kiểm soát sửa đổi không được tính nhiều. Với các ngoại lệ đáng chú ý, mã không có thời gian tồn tại ngoài nhiệm vụ. Phạm vi của các dự án có xu hướng khá hạn chế, và không có khả năng leo.

Trong thế giới thực, bạn nên có càng ít mã gốc càng tốt. Rất nhiều mã được phát triển bởi các đội. Nó là tốt hơn để sử dụng các thói quen thư viện hơn là tự viết mã. Chất lượng mã và kiểm soát sửa đổi trở nên quan trọng hơn. Mã có xu hướng có một cuộc sống vượt xa những gì đã được dự kiến ​​ban đầu. Phạm vi dự án thường khá rộng và có xu hướng leo đáng kể nếu không được quản lý.

Thực ra,

không thể phân biệt đầy đủ giữa lập trình cấp học và lập trình thế giới thực.

Tôi muốn nói rằng sự khác biệt lớn nhất có thể là: trong lập trình thế giới thực - bạn phải biết nhiều hơn lập trình và có thể thích nghi nhanh.

Tùy thuộc vào lĩnh vực bạn đang làm việc, bạn phải tuân thủ luật pháp của ngành đó.

Michael chỉ chạm vào đỉnh của tảng băng trôi bằng cách nêu rõ các nhiệm vụ liên quan đến lập trình, mà tôi sẽ phân loại là công cụ dễ dàng (nếu bạn xứng đáng với số tiền mà bạn đang được trả).

Nói chung, bạn sẽ phải đối mặt với ít nhất một vài thách thức cho mỗi môn học trong một ngành:

• Luật điều chỉnh (ví dụ: bảo mật khách hàng cho y tế)
• Bí quyết môn học (ví dụ: hệ thống hóa đơn thuế, hàng tồn kho, quản lý tài nguyên, chương trình y tế, tiêu chuẩn ngành)
• Các yêu cầu của khách hàng thiếu hoặc không tồn tại hoặc khác với các tiêu chuẩn ngành / luật điều chỉnh

Nếu bạn so sánh một dự án lập trình cấp độ phd nghiên cứu với một thế giới thực, rất có thể chúng rất giống nhau về độ khó, bí quyết cấp đầu vào và như vậy.

Sự khác biệt thực sự duy nhất sau đó là dự án thế giới thực

• có một khách hàng
• có ngân sách (thời gian, tiền bạc, nhân lực)

Đó là trò chơi bóng khác nhau khi người khác đưa ra luật :)

Nếu bạn nhìn vào các môn học về CNTT trong học thuật, bạn sẽ thấy khoảng một nửa thời gian bị lãng phí trong toán học, khoa học, tự chọn, v.v. và nửa còn lại về các môn học như: Thiết kế trình biên dịch, Lý thuyết thuật toán, Kiến trúc máy tính, Tối ưu hóa, Hệ điều hành, Điện tử số và một vài khóa học khác liên quan đến ngành như lập trình C và Lập trình Web.

Hầu hết các chủ đề được đề cập ở trên là những điều dễ hiểu nhưng sẽ không trực tiếp cung cấp một nền tảng vững chắc về những gì được yêu cầu trong CNTT hàng ngày.

Thực hiện các yêu cầu Lập trình web của Microsoft (nghĩa là các khu vực được yêu cầu bởi một người nào đó để trở thành thành viên nhóm làm việc hiệu quả trong một tổ chức):

1- C # .NET hoặc VB.NET

2- ASP.NET

3- HTML và CSS

4- Máy chủ SQL (hoặc cơ sở dữ liệu khác)

5- Thiết kế và lập trình ứng dụng OO

6- Tập lệnh Java

7- Khung MVC

8- Một số tiếp xúc với các công cụ kiểm soát nguồn

9- Một số tiếp xúc với các công cụ kiểm tra tự động

Công cụ theo dõi 10 lỗi

11-Khái niệm thương mại điện tử (tùy chọn)

12-ORM

13-Một số kỹ năng phân tích kinh doanh

14-Một số kỹ năng giao tiếp

15-Có lẽ, một số nguyên tắc cơ bản của điện toán đám mây

Như bạn có thể thấy rằng hầu hết các yêu cầu ở trên hiếm khi được tập trung vào (bạn có thể nhận được 1 khóa học trong một số ít nhất) trong thời gian học cao đẳng / đại học.

Người ta không thể đổ lỗi hoàn toàn cho các tổ chức vì có rất nhiều công nghệ như vậy và họ liên tục thay đổi.

Hầu hết những điều trên từ Microsoft sẽ không giúp được ai đó muốn phát triển ứng dụng trong Java.

Vấn đề thực sự là không phải một trong những ngăn xếp công nghệ cần thiết cho doanh nghiệp ngày nay đã được bao phủ đầy đủ.

Trên đây bao gồm các câu hỏi về sự phù hợp của sinh viên tốt nghiệp với các công việc kinh doanh như lập trình trong môi trường kinh doanh. Nhu cầu nghiên cứu phòng thí nghiệm, vv không được bao gồm trong câu trả lời này. Ngoài ra các lĩnh vực khác đòi hỏi nhiều kỹ năng hơn các yếu tố trên, như Phát triển trò chơi, Phát triển nhúng, Phát triển hệ thống thời gian thực, v.v.

Quy mô & Trọng tâm
Từ kinh nghiệm của tôi, trong môi trường học thuật, nói chung quy mô của ứng dụng bạn đang làm việc nhỏ hơn nhiều, có thể hoàn thành trong một ngày hoặc một tuần, hoặc có thể miễn là học kỳ bởi một hoặc hai progammers- -tất cả mọi thứ bạn viết sẽ là mã vứt bỏ sau thời hạn. Trong thế giới thực, bạn có thể thấy mình đang làm việc trên một ứng dụng mà một nhóm lớn hơn đã mất nhiều tháng, nếu không nói là nhiều năm, để phát triển đầy đủ. Bạn dành nhiều thời gian hơn và gỡ lỗi mã của người khác và cố gắng hiểu cơ sở hạ tầng của một cơ sở mã, tung hứng không phá vỡ các phần hiện có để thêm một số yêu cầu mới hoặc sửa đổi.

Yêu cầu, Tích hợp, Khách hàng
Ngoài ra, có các khía cạnh để phát triển mã, chẳng hạn như phân tích yêu cầu, thử nghiệm tích hợp, v.v ... có xu hướng ít được thể hiện trong các dự án học thuật. Vì mục đích chấm điểm công bằng, thông thường các yêu cầu đã được người hướng dẫn đặt ra cho bạn và nó không được quyết định hợp tác trong các cuộc họp. Bạn không có xu hướng phải "bán khách hàng" theo một cách tiếp cận cụ thể không hoàn toàn như những gì họ muốn, nhưng không giống như mong muốn của họ thực sự khả thi từ quan điểm công nghệ. Trong môi trường học thuật, khách hàng của bạn (học sinh hoặc người hướng dẫn) có xu hướng có một ý tưởng khá cụ thể về những gì họ muốn, trong thế giới thực, bạn có thể gặp những khách hàng không thực sự biết họ muốn gì và phải chọn não để hiểu những gì họ muốn nên được xây dựng.

Bảo trì và bảo trì

Trong học viện (ít nhất là ở cấp đại học), phần mềm được xây dựng với mục tiêu ngắn hạn, thường là để hoàn thành một số bài tập về nhà hoặc dự án dài hạn. Sau khi hoàn thành nhiệm vụ, mã bị vứt đi và không bao giờ gặp lại.

Trong một thiết lập chuyên nghiệp, hầu hết các phần mềm được viết với mục đích sử dụng lâu dài; phần mềm dự định sẽ được sử dụng trong ít nhất một vài năm và cần được xây dựng để dễ dàng bảo trì và cập nhật theo thời gian.

Liên quan đến điều này là công việc bảo trì. Phần lớn các công việc lập trình chuyên nghiệp liên quan đến việc cập nhật hoặc duy trì phần mềm hiện có. Các dự án được gọi là "lĩnh vực xanh" là ngoại lệ, chứ không phải là tiêu chuẩn.