Tại sao họ không dạy những điều này trong trường học? [đóng cửa]

Trong suốt mùa hè, tôi đã may mắn được tham gia Google Summer of Code. Tôi đã học được rất nhiều (có lẽ nhiều hơn những gì tôi đã học được trong tổng số các môn học đại học của mình). Tôi thực sự tự hỏi tại sao họ không dạy một số điều tôi đã học sớm hơn ở trường. Đến tên một vài:

• kiểm tra đơn vị
• kiểm soát phiên bản
• phát triển nhanh

Đối với tôi, dường như họ dành một lượng thời gian đáng kể để dạy những thứ khác như cấu trúc dữ liệu và thuật toán. Trong khi tôi vẫn nghĩ rằng những điều này rất quan trọng để học từ sớm, tại sao họ không dạy thêm ba điều này trước chúng? Hay là trường tôi không dạy nhiều thứ này?

Đừng hiểu sai ý tôi, tôi không nghĩ rằng các trường đại học luôn muốn dạy những mốt lập trình thịnh hành nhất, nhưng các giáo sư của tôi có nên dạy tôi điều gì đó khác ngoài "vẽ một sơ đồ trước khi bạn bắt đầu viết mã không?"

Câu trả lời đơn giản nhất cho câu hỏi của bạn là các lĩnh vực khoa học máy tính và phát triển phần mềm đều rất mới và chưa được hiểu rõ lắm. Mặc dù tất cả các ngành khoa học và kỹ thuật đang tiến bộ nhanh chóng hơn trong thời hiện đại, các lĩnh vực khác có nhiều kinh nghiệm hơn để rút ra và có sự hiểu biết được chia sẻ rộng rãi hơn về cách chúng hoạt động.

Ví dụ, bất chấp những tiến bộ gần đây trong khoa học vật liệu, các kỹ sư dân dụng đã biết cách xây dựng vòm không bị đổ trong khoảng 2000 năm, và đây là điều có thể được dạy và học trong trường đại học mà không gây tranh cãi gì nhiều. Mặc dù tôi hoàn toàn đồng ý với bạn về các kỹ thuật mà các nhà phát triển phần mềm nên học, nhưng thỏa thuận này dựa trên kinh nghiệm cá nhân và lý luận không chính thức. Để trở thành "phương pháp hay nhất" được xã hội chấp nhận, chúng ta cần dữ liệu định lượng có thể rất tốn kém để thu thập: kiểm soát phiên bản giúp ích được bao nhiêu? Nó giúp ích như thế nào? Kiểm tra đơn vị? Chúng ta có thể lý luận về hiệu quả của các kỹ thuật khác nhau, nhưng thực sự để chứng minh hiệu quả một cách rõ ràng sẽ rất tốn kém. Chúng tôi cần chạy một dự án phần mềm hoàn chỉnh, thực tế từ đầu đến cuối, nhiều lần, với các nhóm lập trình viên có chuyên môn tương đương, sử dụng các kỹ thuật khác nhau. Ít nhất thì chúng tôi cũng cần nhiều dữ liệu về các dự án hiện có mà những dự án đó sẽ không muốn phát hành.

Các kỹ sư xây dựng có những cây cầu hàng nghìn năm tuổi để xem xét, với rất nhiều thông tin. Mặt khác, các nhà phát triển phần mềm chỉ có một vài thập kỷ thông tin, hầu hết đều được giữ bí mật, vì có rất ít động lực để các tổ chức đối chiếu và công bố thông tin về hiệu quả của các nhà phát triển của họ, ngay cả khi họ đang thu thập (mà hầu hết đều không 't).

Cũng có một số trường hợp nhầm lẫn. Phát triển phần mềm, hay "kỹ thuật" phần mềm, thực sự là một thứ khác với khoa học máy tính. Các nhà phát triển phần mềm cần có kiến ​​thức về khoa học máy tính, nhưng làm việc ở ranh giới của độ phức tạp của thuật toán hoặc lý luận về tính song song không phải là điều mà một lập trình viên đang làm việc sẽ làm hàng ngày; tương tự như vậy, một "nhà khoa học máy tính" thực sự sẽ viết hàng tấn mã vứt đi không hoạt động hoặc không làm bất cứ điều gì thú vị và sẽ không được hưởng lợi nhiều từ sự nghiêm ngặt như một sản phẩm phần mềm thực tế.

Sự xuất hiện của internet và cộng đồng mã nguồn mở có thể cung cấp đủ dữ liệu để bắt đầu trả lời những câu hỏi này một cách dứt khoát, nhưng ngay cả khi câu trả lời có sẵn vào ngày mai, có lẽ sẽ mất 100 năm để chúng có thể thâm nhập vào xã hội quốc tế đến mức mọi người đồng ý về những gì nên được dạy trong trường học.

Cuối cùng là một số cân nhắc kinh tế. Đã một thời gian tương đối ngắn vì hầu như tất cả mọi người tham gia vào phát triển phần mềm đều có quyền truy cập dễ dàng vào các máy chuyên dụng để chạy bất kỳ công cụ phát triển nào họ muốn. Cách đây vài thập kỷ, việc dành hẳn một chiếc máy chỉ để chạy các bài kiểm tra của bạn, hoặc thậm chí chứa một lịch sử vô hạn về mã nguồn, dường như sẽ đắt đỏ đối với rất nhiều người.

Bởi vì giáo viên của chúng tôi:

1. Chưa bao giờ thử kiểm tra đơn vị,
2. Không biết cách sử dụng kiểm soát phiên bản và
3. Thậm chí chưa nghe nói về "phát triển nhanh nhẹn".

Học sinh nên tự giải quyết vấn đề của mình. Chúng tôi đã làm điều đó, và hóa ra tốt, phải không?

Leonardo da Vinci đã viết,

Những người say mê thực hành mà không có khoa học giống như một người phi công đi vào một con tàu mà không có bánh lái hay la bàn và không bao giờ có bất kỳ sự chắc chắn nào về nơi mình sẽ đi. Thực hành luôn phải dựa trên kiến ​​thức lý thuyết vững chắc.

Các trường tốt dạy cả lý thuyết (cấu trúc dữ liệu, thuật toán, v.v.) cũng như thực hành (kiểm thử đơn vị, kiểm soát phiên bản, v.v.). Điều này đòi hỏi một hỗn hợp giảng viên thích hợp để cả hai mặt của đồng tiền này có thể được giảng dạy đúng cách. Một đội ngũ giảng viên hoàn toàn gồm các loại lý thuyết mà không có kinh nghiệm thực tế sẽ không làm được. Tương tự, một khoa hoàn toàn gồm các học viên sẽ không làm được. Bạn cần sự kết hợp, và những trường tốt có điều đó.

Khoa học máy tính luôn có phần mâu thuẫn; Phần nói về máy tính không phải là khoa học và phần đó là khoa học không phải về máy tính.

Các trường đại học có xu hướng dựa nhiều hơn vào phần cuối của 'khoa học' (thuật toán, hình ảnh dữ liệu, trình biên dịch, v.v.) vì những thứ đó 'vượt thời gian' hơn nhiều so với các phương pháp hay nhất trong ngành hiện tại, có xu hướng phát triển và thay đổi từ năm này sang năm khác. Ví dụ: Kiểm soát phiên bản, đã trải qua những thay đổi đáng kinh ngạc trong 5 hoặc 10 năm qua, nhưng big-O vẫn là big-O và băm, btrees và đệ quy vẫn hữu dụng như 40 năm trước. Ý tưởng của họ nói chung là cung cấp cho bạn đủ nền tảng để sau đó bạn có thể chọn các công cụ như git và hiểu ý nghĩa của nó khi bạn được thông báo rằng cơ cấu dữ liệu cơ bản là một biểu đồ có hướng xoay vòng của hàm băm SHA-1 và các nhà phát triển đã làm việc chăm chỉ để tối ưu hóa số lượng cuộc gọi tổng hợp sao cho nó bị ràng buộc.

Bây giờ, hãy nghĩ về nơi bạn đã học tất cả những điều bạn phải biết để hiểu câu cuối cùng đó - nếu câu trả lời là 'đại học', họ đang làm một công việc ổn.

Mọi thứ đều là một mốt đang trôi qua. Bạn sẽ học được nhiều hơn trong năm đầu tiên ở trường đại học so với tất cả những năm học đại học. Khoa học máy tính không liên quan gì đến máy tính.

Trường cao đẳng cung cấp cho bạn một hộp công cụ đầy đủ các công cụ. Đây là một tuốc nơ vít, đó là một cờ lê lưỡi liềm. Bạn CÓ THỂ sử dụng từng công cụ một lần khi học đại học. Đó là khi bạn bước vào thế giới thực là khi bạn thực sự tìm ra những gì bạn có. Bạn sắp xếp những thứ hữu ích khỏi phần còn lại, những thứ bạn muốn để ở nhà trên bàn làm việc, đề phòng, và những thứ bạn cất trong túi hàng ngày.

Tqm, Iso, Cmm, Agile, v.v ... Đây đều là những mốt họ sẽ đến và họ sẽ đi, không có cái nào thành công hơn chỉ là lẽ thường. Tất cả các kỹ sư và công ty thành công đều sử dụng một số hương vị chung, đó là điều đã làm cho họ thành công, ít người cần một cái tên cho nó. Vấn đề là bạn không thể bán thông thường, một nhà quản lý không thể chứng minh giá trị của họ đối với công ty bằng cách đào tạo và mua thông thường mà không có một cái tên hấp dẫn. Đặt một cái tên lên đó mà cấp trên của họ đã đọc trong một số bài báo hoặc tạp chí và người quản lý sẽ giữ công việc của họ và bạn giữ lại công việc của bạn. Rất ít trong số các công ty tuyên bố thực hiện theo các thông lệ này. Hầu hết viết séc cho một nhà tư vấn, và nhận chứng chỉ hàng năm và hoặc trọn đời của họ cho một câu lạc bộ nào đó để họ có thể đặt hình ảnh trên trang web của họ hoặc nhãn trên hộp sản phẩm của họ. Nhiều người sẽ lập luận rằng điều này hiếm khi xảy ra ... đã từng có, đã thấy nó, nó xảy ra. Đây là một phần của kinh doanh, đôi khi bạn phải cắt giảm các góc để duy trì lợi nhuận và giữ cho cửa mở và đèn sáng. Những tín đồ khó tính của tất cả những cách làm này đều cho rằng cái cuối cùng là lỗi mốt và cái này thì không, cái cuối cùng thực sự quá đắt để theo, cái này thì không. Cái cuối cùng là giả bạn vừa thuê một nhà tư vấn, cái này là thật. Giống như các ngôn ngữ lập trình, chúng cũng sẽ phát triển. Cái cuối cùng là giả bạn vừa thuê một nhà tư vấn, cái này là thật. Giống như các ngôn ngữ lập trình, chúng cũng sẽ phát triển. Cái cuối cùng là giả bạn vừa thuê một nhà tư vấn, cái này là thật. Giống như các ngôn ngữ lập trình, chúng cũng sẽ phát triển.

Khả năng hiểu được thực tế của doanh nghiệp, hệ thống trường đại học và vai trò của bạn trong đó là chìa khóa. Giống như bất cứ điều gì trong cuộc sống, hãy chọn những trận chiến của bạn. Không phải trường đại học hay doanh nghiệp hay chính phủ hay bất kỳ ai khác có nhiệm vụ dạy bạn muốn bạn cần hoặc muốn biết. Nhiệm vụ của bạn là tìm ra số một. Tương tự như vậy, bạn không thể đổ lỗi cho bất kỳ ai khác vì đã cung cấp cho bạn thời gian để làm điều này, bạn phải làm điều đó. Bạn sẽ ngã ngựa, bạn không phải là nạn nhân, hãy đứng dậy và quay trở lại, không có lời bào chữa nào cả, cuộc sống không công bằng với nó. Hãy tận dụng lợi thế của các tờ rơi, đừng giả vờ độc lập. Và chắc chắn phải trả các khoản phí của bạn, không làm cho một công ty khô cạn các tài liệu phát tay, mà không cho họ thứ gì đó (tốt nhất của bạn vào thời điểm đó?).

Tại sao mọi người nghĩ cmm hoặc nhanh nhẹn hoặc bất kỳ cái nào khác là lỗi mốt? Tại sao họ nghĩ rằng họ không? Tại sao giáo sư dạy bạn lập trình theo cách đó? Để tránh gotos hoặc để tránh hằng số hoặc để tránh điều này và điều kia? Có phải vì nó tạo ra mã đáng tin cậy hơn không? Mã hoạt động tốt hơn? Giảm thiểu lỗi của con người? Hay là vì việc chấm điểm các bài báo / chương trình dễ dàng hơn giúp họ có nhiều thời gian hơn để nghiên cứu? Có phải vì họ không biết cách lập trình và họ chỉ theo dõi cuốn sách của ai đó về chủ đề này? Họ có dạy bạn rằng bạn không thể có mã hiệu suất cao, đáng tin cậy, có thể bảo trì được không? Bạn thậm chí không thể "chọn bất kỳ hai" can thiệp có thể bảo trì được cả với hiệu suất cao và đáng tin cậy? Đôi khi bạn hy sinh độ tin cậy cho hiệu suất. Đôi khi bạn không quan tâm đến độ tin cậy hoặc hiệu suất, bạn chỉ muốn nhận được từ phiên bản 117.34. 2 chương trình phần mềm kế toán khác lên phiên bản 118.0.0. Mô hình kinh doanh của bạn là từ việc bán các bản nâng cấp phiên bản và hỗ trợ công nghệ và theo như các nhà phát triển phần mềm, bất kỳ rô bốt cũ nào cũng sẽ làm điều đó có thể viết cùng một mã theo cùng một cách. Thay thế một cái bị cháy bằng cái mới ra trường và tiếp tục bán các bản nâng cấp.

Không có câu trả lời chung cho những câu hỏi này, bạn phải tìm ra ý kiến ​​của mình, sống với nó và bảo vệ nó. Thay đổi suy nghĩ của bạn, sống với nó và bảo vệ nó.

Hỏi mọi thứ ... liệu tôi có thực sự bị bỏng nếu chạm vào nồi nóng trên bếp không? Liệu những ảnh hưởng tâm lý sợ hãi sẽ gây ra nhiều tổn thương hơn là chỉ bị bỏng? Có cách nào an toàn để kiểm tra câu trả lời mà không bị thương không?

Khi có đủ khả năng, tôi sẽ mua và cuối cùng làm tan chảy các bóng bán dẫn, nắp, điện trở, v.v. trong phòng ký túc xá của tôi, tất cả đều có mùi hôi đặc biệt. Sẽ rẻ hơn và dễ dàng hơn rất nhiều nếu chỉ mua một bộ khuếch đại cho dàn âm thanh của bạn hơn là cố gắng chế tạo một chiếc mỗi ngày sau lớp bóng bán dẫn đầu tiên của bạn. Linus là một trường hợp ngoại lệ, dĩ nhiên việc mua một hệ điều hành sẽ dễ dàng hơn là viết một hệ điều hành ... Bạn có thể làm được nhiều việc hơn mặc dù những gì bạn học được trong thời gian đó khác với những gì Linus học được.

Thế giới trong và ngoài trường đại học sẽ áp dụng những công thức này (cmm, nhanh nhẹn, v.v.) để giải quyết vấn đề và khi công thức tiếp theo xuất hiện, họ sẽ bỏ chúng nhanh như vậy. Bạn không cần phải sử dụng kiểm soát phiên bản để thành công, có nhiều thành công cũng như không (thực ra là do thời đại của ngành công nghiệp có nhiều thành công hơn mà không có kiểm soát phiên bản cho đến nay). Tương tự như vậy, bạn có thể thành công với thử nghiệm tối thiểu (hãy xem những tên tuổi thực sự lớn trong ngành máy tính làm ví dụ). Bạn có thể thành công bằng cách kiểm tra mã của riêng mình, cũng như thành công khi tuân theo quy tắc mà bạn không bao giờ được kiểm tra mã của chính mình. Bạn có thể thành công khi sử dụng emacs và bạn có thể thành công khi sử dụng vi. Bạn phải quyết định cách kết hợp nào phù hợp với mình và nếu may mắn bạn sẽ tìm được nơi làm việc phù hợp với mình.

Khi bạn bước ra khỏi trường đại học và bước vào thế giới thực, hãy lắng nghe và làm việc cùng và tranh luận với những người "tính giờ cũ". Họ có nhiều thập kỷ đến hàng thế kỷ kinh nghiệm tổng hợp, những cái bẫy mà họ đã rơi vào mà bạn có thể tránh và hoặc tự mình kiểm tra (có thể bạn nhận ra rằng bạn không cần phải chạm vào nồi nóng để biết nó sẽ làm bỏng bạn). Hầu hết sẽ từng thấy ít nhất một hoặc hai mốt này đến rồi đi, và cụ thể là chúng bị bỏng nặng như thế nào, và họ đã làm gì để phục hồi sau nó. Họ biết nhiều cách khác nhau để kiểm tra mọi thứ, và cả tên của các phong cách kiểm tra đã từng xuất hiện. Cái gì hiệu quả, cái gì không. Rủi ro ở đâu và làm thế nào để tránh lãng phí thời gian cho một tiếp tuyến. Khi bạn trưởng thành và bạn trở thành bộ đếm thời gian cũ, hãy chuyển nó về phía trước. Trả tiền cho những gì bạn đã học bằng cách cố gắng dạy những người theo sau bạn. Hãy nhớ dạy chúng CÁCH câu cá, đừng chỉ cho họ một con cá. Và đôi khi bạn phải để họ thất bại thì họ mới thành công, giữ cho họ không bị bỏng quá nặng.

Điều tôi thực sự muốn nói ở đây là ngay bây giờ chúng ta đang ở trong một tình huống hiếm hoi mà chúng ta có thể chứng kiến ​​sự tiến hóa của một vũ trụ song song (và có lẽ ảnh hưởng đến nó). Đúng vậy, khoa học máy tính là một ngành khoa học trẻ so với vật lý học. Nhưng đồng thời nó đã phát triển hơn nhiều lần. Tùy thuộc vào nơi bạn làm việc và người bạn làm việc cùng, bạn có thể quan sát các kỹ sư phần cứng. Ngôn ngữ lập trình trong thế giới phần cứng chắc chắn không mới, nhưng nó không phát triển nhanh như thế giới phần mềm. Phần mềm đã có một vài thập kỷ khởi đầu. Phần cứng luôn coi các kỹ sư phần mềm là công dân hạng hai. Việc của chúng ta thì dễ, việc của họ mới khó. (Lưu ý rằng tôi thực sự là cả một kỹ sư phần cứng và phần mềm). Điều thú vị là ngay bây giờ họ vẫn đang giải quyết những vấn đề mà chúng ta cho là các vấn đề ở trẻ sơ sinh hoặc trẻ sơ sinh. Tại sao tôi cần sử dụng kiểm soát phiên bản, tôi là người duy nhất làm việc trên chip này. Trải nghiệm của bạn với gcc hoặc các trình biên dịch rẻ tiền khác hoặc IDE miễn phí không thể so sánh với các công cụ đắt tiền mà tôi sử dụng, nếu công ty cho rằng bạn đủ xứng đáng để sử dụng nó hoặc thậm chí biết cách sử dụng nó, họ sẽ mua cho bạn một bản sao. Và một danh sách dài những lời bào chữa khác. Tôi rất vui khi học cả vhdl và Verilog và trở nên hiệu quả trong cả hai trong vòng một tuần so với điều mà một kỹ sư phần cứng như vậy hầu như không dám (mặc dù bằng tốt nghiệp của tôi nói rằng kỹ sư điện chức danh nghề nghiệp của tôi là kỹ sư phần mềm). Tôi muốn học những ngôn ngữ này, khi các công cụ có sẵn cho tôi, tôi ở lại văn phòng đến đêm và tự học. Từ thời điểm đó, kỹ sư đó đặc biệt nhận ra rằng những gì tôi đang nói là đúng, ngôn ngữ chỉ là cú pháp, các nguyên tắc cơ bản về lập trình đều giống nhau, tất cả các công cụ đều làm được điều tương tự. Táo và táo của nó không phải táo và cam.

Nhìn chung, mặc dù vẫn khó để gửi thông điệp rằng một trong hai ngành song song này có nhiều kinh nghiệm hơn về ngôn ngữ, thói quen lập trình, kiểm soát nguồn, kiểm thử, công cụ, môi trường lập trình, v.v. hơn ngành còn lại. Vấn đề tôi đang cố gắng giải quyết là sử dụng các thiết kế phần cứng khi chúng đang được phát triển, tạo các trình mô phỏng chức năng giá cả phải chăng mà chúng tôi có thể kết hợp với một mô phỏng (máy ảo) của bộ xử lý để chúng tôi có thể bắt đầu kiểm tra phần cứng và phát triển thử nghiệm và phần mềm có thể phân phối rất lâu trước khi chúng ta sử dụng silicon. Không có gì "mới" về điều này, nhưng chúng tôi không có cơ chế để lấy mã mới nhất, theo dõi các thay đổi trong mã để xem chúng ta cần tập trung thời gian vào đâu. Không có cơ chế theo dõi tài liệu xác định giao diện người dùng (lập trình) với phần cứng. Một bản sao vàng nằm trong hộp thư đến của ai đó ở dạng nhị phân và chỉ thay đổi khi, bạn không cần phải đọc Verilog để tìm hiểu điều gì đang xảy ra. Chờ đã, Verilog đó bao nhiêu tuổi? Lỗi mà tôi đã dành cả tuần cho bạn, bạn đã tìm ra cách đây ba tuần và đã sửa? Vì vậy, chúng ta chỉ cần bay đến một điểm nghỉ mát nào đó và tổ chức tiệc tùng trong sáu tháng chờ những người phần cứng hoàn thành nhiệm vụ của họ và ném nó qua tường cho chúng ta, hay chúng ta nhân cơ hội này để cố gắng kiên nhẫn và lạc quan và dạy họ rằng họ có những phương pháp thông thường không xâm phạm đến mức cho phép họ thực hiện công việc của mình, sao lưu công việc cũng như chia sẻ nội dung của họ để đồng nghiệp đánh giá ... Verilog đó bao nhiêu tuổi? Lỗi mà tôi đã dành cả tuần cho bạn, bạn đã tìm ra cách đây ba tuần và đã sửa? Vì vậy, chúng ta chỉ cần bay đến một điểm nghỉ mát nào đó và tổ chức tiệc tùng trong sáu tháng chờ những người phần cứng hoàn thành nhiệm vụ của họ và ném nó qua tường cho chúng ta, hay chúng ta nhân cơ hội này để cố gắng kiên nhẫn và lạc quan và dạy họ rằng họ có những phương pháp thông thường không xâm phạm đến mức cho phép họ thực hiện công việc của mình, sao lưu công việc cũng như chia sẻ nội dung của họ để đồng nghiệp đánh giá ... Verilog đó bao nhiêu tuổi? Lỗi mà tôi đã dành cả tuần cho bạn, bạn đã tìm ra cách đây ba tuần và đã sửa? Vì vậy, chúng ta chỉ cần bay đến một điểm nghỉ mát nào đó và tổ chức tiệc tùng trong sáu tháng chờ những người phần cứng hoàn thành nhiệm vụ của họ và ném nó qua tường cho chúng ta, hay chúng ta nhân cơ hội này để cố gắng kiên nhẫn và lạc quan và dạy họ rằng họ có những phương pháp thông thường không xâm phạm đến mức cho phép họ thực hiện công việc của mình, sao lưu công việc cũng như chia sẻ nội dung của họ để đồng nghiệp đánh giá ...

Hãy nhớ rằng các kỹ sư phần cứng đã rời trường đại học với một hộp công cụ mới sáng bóng giống như bạn đã làm. Bạn đã học 17 ngôn ngữ lập trình khác nhau, trong đó bạn chỉ có thể sử dụng một ngôn ngữ, những ngôn ngữ còn lại trong sự nghiệp của bạn sẽ được phát minh sau khi bạn rời trường đại học. Khi rời đại học, họ có thể cho bạn biết những gì họ biết về giải tích và thuyết tương đối có bao nhiêu electron trong mỗi nguyên tố và tính toán điện tích xung quanh bề mặt Gauss. Nhưng phần lớn sự nghiệp của họ là một, không, và hoặc và không (này, chúng ta có những điểm chung đó, tất cả những gì bạn thực sự cần biết về máy tính, một, không, và hoặc không phải kỹ sư phần cứng hoặc phần mềm). Được ban cho các định luật cơ bản của vật lý, giải tích, các electron sẽ không thay đổi nhanh như các ngôn ngữ lập trình. Nhưng các nguyên tắc cơ bản của lập trình là giống nhau trên tất cả các ngôn ngữ và sẽ tiếp tục được duy trì trong tương lai. Bạn đã rời trường đại học biết điều đó hay bạn đã nghĩ rằng java khác và tốt hơn C ++ vì cái này, cái kia và cái kia?

Giống như bất kỳ hoạt động kinh doanh nào khác, công việc của các trường đại học là duy trì lợi nhuận. Họ phải thuê những học giả phù hợp để mang lại cả những sinh viên phù hợp và những khoản tiền nghiên cứu phù hợp và những loại nghiên cứu phù hợp để làm cho trường đại học có lãi. Họ phải cung cấp các lớp học phù hợp để mang lại những sinh viên phù hợp và tạo ra những sinh viên tốt nghiệp phù hợp để khi nhiều thập kỷ trôi qua, các nhà tuyển dụng gần trường đại học và hy vọng ở xa sẽ công nhận rằng trường đại học này tạo ra những nhân viên có năng suất và có lợi nhuận. (có và đôi khi bạn phải thu hút những vận động viên phù hợp trong môn thể thao phù hợp để có được thời lượng truyền hình phù hợp và lượng công nhận tên tuổi và doanh thu thể thao phù hợp). Một số trường đại học sẽ dạy C ++ và Java, một số thì không. Một số sẽ phát minh ra CMM, và một số sẽ dạy Agile, một số thì không. Nếu trường đại học có bất kỳ giá trị nào thì ở đó có một số thứ để bạn học hỏi. Họ sẽ không dạy bạn mọi thứ cần học, nhưng họ sẽ có một thứ hữu ích. Tìm hiểu điều gì đó khi bạn ở đó, thu thập một số lượng hợp lý các dạng công cụ khác nhau trong hộp công cụ của bạn. Rời khỏi trường đại học và kiếm một công việc. Nếu hộp công cụ của bạn tệ có thể tìm trường đại học khác và không bao giờ đề cập đến trường đầu tiên. Nếu đó là một hộp công cụ tốt, hãy sử dụng những công cụ đó và tự tạo một số công cụ mới theo thời gian của riêng bạn. Nếu đó là một hộp công cụ khá tốt, hãy nói những điều tốt đẹp về trường đại học đó và những học giả giỏi mà bạn đã học được cái này cái kia và trả lại cho trường những gì họ đã cho bạn. Mặc dù bạn không có được mọi công cụ có thể có trong danh mục phổ quát các công cụ của trường đại học, bạn sẽ bỏ qua một tập hợp con nhất định. Ngay cả khi bạn chưa tốt nghiệp ...

Tôi đã dạy những điều này khi còn là Trợ lý tại Học viện Công nghệ Oregon. Họ được dạy, chỉ là một cách thưa thớt.

Câu trả lời đơn giản nhất là bạn đang nghiên cứu khoa học máy tính và những thứ bạn liệt kê không thực sự liên quan đến lĩnh vực học thuật của khoa học máy tính. Phát triển phần mềm có thể là thứ mà bạn làm với khoa học máy tính, thứ gì đó được xây dựng dựa trên các khối của những gì bạn đã học ... nhưng Khoa học máy tính và phát triển phần mềm không giống nhau.

Các lớp học đã dạy bạn kiểm soát phiên bản hoặc cách viết các bài kiểm tra đơn vị hiệu quả ... sẽ dạy bạn cách kinh doanh , cụ thể là phát triển phần mềm (tốt).

trời ơi đừng để tôi bắt đầu

Tôi đã từng có trưởng khoa cs tại một trường đại học danh tiếng nói với tôi rằng lập trình hướng đối tượng chỉ là một 'mốt nhất thời' nên họ không cung cấp bất kỳ lớp học nào để vượt qua những thứ tưởng tượng như C ++

về lý do tại sao họ không dạy những điều này, tốt, trường đại học ở đó để dạy bạn những nguyên tắc cơ bản của kỷ luật, không nhất thiết phải là những phương pháp hay nhất của ngành

Điều quan trọng với các trường đại học là họ cần dạy những thứ thực sự phổ biến. Một cái gì đó như phát triển nhanh vẫn còn khá mới và mặc dù nó được nói đến nhiều trên Internet nhưng nó không được sử dụng ở mọi nơi, vì vậy việc dạy nó cho cả lớp sinh viên có khả năng chỉ mang lại lợi ích cho một vài người đã đến các cửa hàng nhanh.

Tuy nhiên, kiểm soát phiên bản là điều mà ngày nay không thể bào chữa được. Đó là điều mà mọi người cần hiểu, đó là một công cụ gần như hữu ích như một trình biên dịch và CVS đã tồn tại khoảng hơn 20 năm. Các khái niệm ít nhất cần được hiểu bởi bất kỳ lập trình viên nào rời trường đại học. May mắn thay, nếu bạn làm bất kỳ công việc nhóm nào trong trường đại học, bạn có thể đủ may mắn để tiếp cận với một người đã biết về kiểm soát phiên bản và thuyết phục nhóm của bạn sử dụng nó. Tôi biết tôi rất vui vì người đó đã ở trong nhóm của tôi.

Kiểm tra đơn vị cũng khá nhiều và không thể chấp nhận được. Điều duy nhất mà tôi muốn nói ở đó là cuốn sách vẫn đang trong quá trình phát triển theo hướng thử nghiệm và việc tiếp tục bảo hiểm mã 100% đôi khi có thể gặp nhiều rắc rối hơn giá trị của nó. Nhưng kiểm thử đơn vị là cực kỳ có giá trị và nên được học trong một khóa học kỹ thuật phần mềm. Tôi tưởng tượng rằng một số thứ này đang tiến vào một số trường đại học nhưng vẫn chưa đến được tất cả chúng.

Tại sao không, thực sự? Kinh nghiệm lấy bằng CS của tôi cũng khá giống nhau. Lý do là những người dạy lập trình không lập trình, theo như tôi có thể nói. Không bắt buộc phải dạy những thứ đó để được công nhận, giáo viên không quen thuộc với nó, và sinh viên không bao giờ phát triển các dự án có ý nghĩa như một phần của bài học của họ. Không có động lực để thực sự dạy lập trình, trái ngược với việc dạy lý thuyết CS hoặc cú pháp Java.

Các nhà khoa học máy tính nghĩ rằng họ là nhà toán học không phải kỹ sư và vì vậy họ thích dạy các phần toán học hơn là các phần kỹ thuật. Kiểm tra, kiểm soát phiên bản và tài liệu không còn lỗi mốt nữa so với bất kỳ lĩnh vực kỹ thuật nào khác.

Nó phụ thuộc vào các trường đại học. Tôi tốt nghiệp năm 2003, từ một người Úc. Trong thời gian đó, chúng tôi đã học UML, Kiểm thử đơn vị, XP (và các Phương pháp Agile khác), cùng với tất cả những thứ chính thức như Z, Thuật toán và Cấu trúc dữ liệu, Hệ điều hành, v.v.

Tuy nhiên, họ không đề cập chi tiết đến việc kiểm tra đơn vị, nhiều hơn chỉ trả tiền dịch vụ cho một bài giảng. Sẽ thật tuyệt nếu học được cách viết bài kiểm tra đơn vị hiệu quả, thay vì chỉ "Kiểm tra đơn vị là gì".

Liên quan đến việc kiểm soát phiên bản, chúng tôi đã sử dụng nó (CVS) trong các dự án lập trình của mình từ năm thứ 2 trở đi.

Tôi cũng rất đồng ý với những gì Glyph đã nói. CS là một lĩnh vực chưa trưởng thành, thực sự mới chỉ tồn tại trong vòng 50 năm trở lại đây, đến nỗi chúng ta không biết mình nên học gì và đâu chỉ là mốt đã qua. Hãy cho nó 150 năm, sau đó mọi thứ có thể sẽ ổn định hơn. Số lượng các dự án thế giới thực thất bại cho thấy rõ ràng đây là một ngành công nghiệp chưa trưởng thành. Hãy tưởng tượng nếu 80% dự án xây dựng thất bại!

Tất cả những điều đó có thể dễ dàng được đề cập (một cách nông cạn) trong một lớp duy nhất về thực tiễn phát triển phần mềm. Nó không phải là một phần của hầu hết các chương trình giảng dạy về CS, bởi vì đó không phải là nội dung của CS, mặc dù tôi nghĩ rằng một số thông tin về nội dung đó hữu ích. Trường tôi đã có một lớp học như vậy; nó không bao gồm kiểm soát phiên bản, nhưng nó bao gồm UML, thu thập yêu cầu, phương pháp phát triển (linh hoạt và thác nước khác nhau), thử nghiệm đơn vị, thử nghiệm tích hợp, v.v. và yêu cầu chúng tôi làm việc theo nhóm 4-5 người để phát triển dự án (một cách tách Clue khá đơn giản trong Java). Nếu bạn cảm thấy cần phải học thêm các lớp Kỹ thuật phần mềm, chúng sẽ có sẵn dưới dạng môn tự chọn.

Mặc dù không bao giờ có quyền kiểm soát phiên bản được đề cập một lần trong bất kỳ lớp học nào mà tôi tham gia, hầu hết bạn bè của tôi đều sử dụng nó cho các dự án cá nhân, bài tập trên lớp, v.v., vì vậy không phải là chúng tôi đã không tiếp xúc với nó. Những người không tự nhặt nó đã bị một bạn cùng lớp ép sử dụng nó trong quá trình làm bài tập nhóm.

Đại học là để dạy các khái niệm và lý thuyết, bởi vì đó là những thứ mà bạn khó có thể tự học được. Kiểm soát phiên bản là một công cụ và khá dễ sử dụng. Sử dụng nó một chút, đọc một số hướng dẫn trên web, và bạn đã sẵn sàng. Nếu bạn cần các bài giảng và bài tập về nhà để tìm ra cách kiểm tra điều gì đó từ SVN, bạn sẽ gặp rất nhiều khó khăn với những thứ thực sự rất khó.

Hãy nhớ rằng có rất nhiều cách để học những thứ ở đại học ngoài các lớp học; tận dụng điều đó. Bạn đang trả rất nhiều tiền để tham gia các lớp học và sử dụng các cơ sở, vì vậy hãy mua nó cho tất cả những gì xứng đáng và tham dự các cuộc họp LUG và ACM, tham gia vào các nhóm dự án (luôn có một số ME xây dựng một robot cần người lập trình), hoặc một công việc quản trị máy chủ của bộ phận Nhân văn. Chọn một máy tính từ đế tải của tòa nhà Kỹ thuật Vật liệu, tải xuống Linux iso với kết nối internet ký túc xá nhanh của bạn và chơi xung quanh.

Tôi nghĩ vấn đề là các trường đại học không cảm thấy rằng họ cần phải dạy bạn trở thành một người chuyên nghiệp, mà thay vào đó tập trung vào khía cạnh học thuật của lập trình. Tôi đã nghĩ rằng ít nhất phải có sự tham khảo về các phương pháp và kỹ thuật mới nhất được sử dụng trong ngành, vì những điều này cũng được quan tâm trong học thuật.

Trong khóa học của mình, chúng tôi đã được dạy về Quy trình phần mềm cá nhân, bao gồm những thứ như ghi lại thời gian dành cho các dự án, nhận xét tốt, v.v., nhưng không đề cập đến các nguyên tắc cơ bản chuyên nghiệp như kiểm soát phiên bản.

Bạn đã nêu tên 3, một số trong số đó tôi nghĩ không quan trọng đối với sự hiểu biết về hệ thống máy tính (ví dụ: kiểm soát phiên bản). Những điều này là một phần của công việc và bạn có thể trở thành một lập trình viên / nhà khoa học máy tính giỏi mà không cần phải biết về nó.

tương tự đối với kiểm thử đơn vị - tại sao lại chọn kiểm thử đơn vị? Chắc chắn kiểm tra khả năng sử dụng, kiểm tra hệ thống, kiểm tra chấp nhận người dùng và kiểm tra nghiệm thu nhà máy là quan trọng hơn? Chà, chúng trừ khi bạn coi công việc của mình đã hoàn thành sau khi mã được chuyển đến bộ phận bảo trì :)

Hãy nghĩ về những khái niệm khác mà tôi sử dụng hàng ngày, điều đó sẽ chẳng có ích gì đối với một sinh viên sắp học về các nguyên tắc cơ bản của phần mềm và hệ thống máy tính:

• thực hành bình luận tốt
• tuân thủ các tiêu chuẩn (không chỉ các tiêu chuẩn quốc tế, mà còn cả các tiêu chuẩn mã hóa nhóm)
• tài liệu
• kiểm soát thay đổi (không nhất thiết phải giống như kiểm soát phiên bản về việc lưu trữ sự khác biệt, điều này nói thêm về điều gì và lý do tại sao bạn thay đổi điều gì đó)
• phát triển khả năng sử dụng

Trên đây là tất cả những "kỹ năng mềm" mà bạn không cần phải viết code tốt.

Tuy nhiên, nếu bạn thiếu các kỹ năng "khó", như cấu trúc dữ liệu và thuật toán, thì cơ hội viết mã tốt của bạn là không thể.

Tôi đã học tất cả những thứ đó trong trường Đại học. Có lẽ nó phụ thuộc vào các khóa học bạn chọn? Các khóa học của tôi rất đa dạng (Thiết kế phần mềm, Thiết kế giao diện người dùng, Thương mại điện tử, AI, Lập trình chức năng, v.v.). Thiết kế phần mềm đã tiếp xúc với các mẫu thiết kế và kiểm thử đơn vị (một dự án lớn liên quan đến nhiều thứ khác nhau). Thiết kế giao diện người dùng ... chúng tôi là một nhóm ba người làm việc trong một dự án. Chúng tôi không thể làm bất cứ điều gì mà không có kiểm soát phiên bản, vì vậy chúng tôi đã nhận được điều đó. Và sự phát triển nhanh nhẹn là điều mà các giáo sư của chúng tôi liên tục nói với chúng tôi, nhưng họ đã để tùy từng nhóm sử dụng nó.

Tôi thấy rằng nhiều sinh viên Đại học đã tham gia các khóa học "dễ" hoặc các khóa học mà họ sẽ cho điểm trung bình cao. Những người khác tập trung vào những gì họ muốn học và phần lớn đang khám phá để tìm ra lĩnh vực mà họ sẽ quan tâm. Và sau đó, có những người biết chính xác những gì họ quan tâm ... điều đó là tốt, ngoại trừ họ có xu hướng không đa dạng hóa các khóa học của mình.

Để trả lời tại sao những điều này không phải là những điều đầu tiên được dạy: Các chương trình đại học thường đào tạo bạn trở thành sinh viên Thạc sĩ. Chỉ khi bạn bắt đầu chọn các khóa học của riêng mình (thường xảy ra trong những năm sau này), bạn mới có thể chọn học về những thứ được sử dụng bên ngoài học thuật. Đây là lý do tại sao họ tập trung vào các thuật toán, cấu trúc dữ liệu, trình bày cho bạn những vấn đề chưa được giải quyết, v.v.

Cá nhân tôi nghĩ rằng nó là tốt khi họ đang làm điều này. Lập trình không dễ dàng như nhiều người trong chúng ta vẫn nghĩ; nhiều người phải vật lộn với nó. Tôi thà rằng những người này trước tiên phải hiểu cách hoạt động của vòng lặp for trước khi tìm ra con quái vật là Perforce.

Họ không dạy những chủ đề như vậy bởi vì hầu hết các trường đều mang tính học thuật, không phải thương mại. Có nghĩa là, chúng được thiết kế để dạy các ý tưởng và lý thuyết, không phải đào tạo bạn thành một nghề nghiệp. Toàn bộ khái niệm về QA không liên quan gì đến khoa học máy tính ngoài việc vượt qua một bằng chứng toán học. Bên cạnh đó, các quy trình thực hành và phát triển QA rất khác nhau giữa các nhà phát triển này với các nhà phát triển tiếp theo, vì vậy việc dạy chúng ở trường là một sự lãng phí thời gian và tiền bạc của bạn.

Tôi đã học tất cả những thứ đó vào năm thứ nhất, ngoại trừ sự phát triển nhanh nhẹn.

Tất cả là về việc chọn đúng trường, IMHO. Nếu bạn lọt vào top 10, bạn sẽ học được tất cả những thứ đó một cách nhanh chóng.

Đối với CS Education nói chung, về cơ bản chúng tôi đang yêu cầu các giáo sư dạy rất nhiều (ngôn ngữ của mọi hương vị, cấu trúc dữ liệu, hiệu quả thời gian chạy, cách mọi thứ thực sự hoạt động ở cấp độ bit). Tôi muốn đặt ra câu hỏi, Tại sao bọn trẻ không tự tìm hiểu thêm về Kỹ thuật phần mềm?

Cũng giống như sinh viên, mỗi trường đại học là khác nhau. Một số trường cao đẳng, hay chính xác hơn, một số giáo sư không chịu thay đổi hoặc lười biếng. May mắn thay hầu hết là không. Các lý thuyết, khái niệm, lịch sử, v.v. là quan trọng và sống còn đối với bất kỳ chương trình giảng dạy CS nào. Nhưng cũng vậy, sinh viên chuẩn bị cho môi trường làm việc của họ. Không có gì đáng ngạc nhiên, các trường cao đẳng cộng đồng trong khu vực của tôi cung cấp các khóa học CS rất hiện tại và áp dụng. Không quá nhiều với các trường đại học lớn, lâu đời và có uy tín.

Đơn giản là vì cấu trúc dữ liệu và thuật toán tạo thành cốt lõi của máy tính và do đó quan trọng hơn nhiều. Kiểm thử đơn vị, kiểm soát phiên bản và phương pháp luận nhanh nhẹn chỉ là những công cụ của thương mại (và nếu cần, người ta dự kiến ​​sẽ bắt chúng vào công việc).

Tôi nghĩ rằng các chương trình CS tốt nên dạy các nguyên tắc cơ bản sẽ làm cơ sở cho tất cả các chương trình giáo dục lập trình trong tương lai. Các phương pháp luận phát triển như Agile, và các công cụ kiểm soát phiên bản giống như mốt nhất thời; họ đến và đi. Ngoài ra, chúng có xu hướng được sử dụng trong môi trường công nghiệp chứ không phải học thuật, vì vậy tôi nghĩ rằng hiếm khi các trường đại học bao gồm những thứ như những thứ mà bạn có thể sẽ học trong công việc. Tôi không nói nó đúng, nhưng đó có lẽ là tâm lý học.

Tôi đồng ý với những gì bạn đang nói. Tôi mới bắt đầu làm việc trong thế giới phát triển phần mềm và tôi đã bắt đầu tìm hiểu về phát triển nhanh, điều mà tôi chưa bao giờ được dạy ở trường đại học.

Thực tế của vấn đề có thể là các chuyên gia đại học không theo kịp các kỹ thuật phát triển mới hơn nhiều như họ cần. Họ cũng có thể cảm thấy rằng có những điều khác, quan trọng hơn trong chương trình học của họ.

Các giảng viên đại học không biết về cách viết phần mềm, họ chỉ nghiên cứu nó, giảng dạy nó, và thỉnh thoảng viết ra một số đoạn mã chỉ hoạt động cho đến khi bài báo được xuất bản.

Chỉ vì những người như Titus mà chúng tôi đang nhận được bất kỳ học giả nào thực sự tìm hiểu lập trình - Đọc nhận xét của anh ấy về chủ đề đó tại đây

Khi còn là sinh viên, tôi đã đọc sách trong thư viện về Lập trình Cực đoan, chúng tôi đã thảo luận về nó breifly trong các lớp học - chính các lớp học yêu cầu chúng tôi tuân theo "Mô hình thác nước" của phát triển phần mềm, trong đó "biên dịch" là một bước của nó sở hữu.

Tất cả những gì tốt đẹp nhất với sự nghiệp của bạn, tôi hy vọng bạn tốt nghiệp bằng cấp của mình, thật tuyệt khi có các chữ cái sau tên của bạn. :)

Tất cả ba điều bạn đề cập (kiểm thử đơn vị, kiểm soát phiên bản, phát triển nhanh) đều được dạy ở một mức độ nào đó trong chương trình Khoa học Máy tính của Đại học Groningen. Đó có phải là một điều tốt hay không, tôi sẽ để lại như một câu hỏi mở; nhưng không đúng là không có trường đại học nào dạy bạn những thứ "thực tế".

Những điều này dựa trên kinh nghiệm hạn chế của tôi trong một chương trình CS trước khi tôi chuyển đổi chuyên ngành và kinh nghiệm của tôi khi là thực tập sinh tại một công ty phần mềm lớn. Kiểm thử đơn vị không được dạy vì hầu hết các chương trình mà bạn phải tạo không đủ lớn để cần kiểm tra tự động, bạn cần có một bộ đầu vào cụ thể để có thể kiểm tra mọi thứ theo cách thủ công. Việc dạy bạn cách tự động kiểm tra cũng có thể can thiệp vào việc phân loại dự án của bạn vì hầu hết các dự án đều được phân loại bằng các tập lệnh chạy kiểm tra tự động, chỉ cần xem nhanh mã để đảm bảo bạn không có int foo1; int foo2; và bạn sử dụng thụt lề thích hợp.

Tôi không biết tại sao kiểm soát phiên bản không được dạy nhưng một phần của nó có lẽ là quy mô của các dự án. Tôi chưa bao giờ có bất kỳ dự án nào đủ lớn để kiểm soát phiên bản, và nói chung tôi có nghĩa là hơn 1000 dòng mã và mất cả học kỳ để viết. Tôi đoán họ nghĩ rằng bạn sẽ dạy nó cho chính bạn nếu bạn cần nó. Bất kỳ dự án nhóm nào mà tôi có đều được cho là các dự án lập trình theo cặp, và tại sao lại sử dụng kiểm soát phiên bản nếu cả hai của bạn trên cùng một máy tính?

Tôi không biết tại sao phát triển nhanh không được dạy nhưng nó có thể quay trở lại điều tương tự với kích thước chương trình. Trong khi phát triển nhanh nhạy là phổ biến với phần mềm mới chạy trên máy tính cá nhân và máy chủ nhỏ, nó thường không được sử dụng trên các hệ thống như máy tính lớn của IBM hoặc trong các lĩnh vực có vấn đề như ngân hàng hoặc y tế, nơi tài liệu là vua. Nó cũng có thể liên quan đến thực tế là phát triển adgile không phải là khoảng 20 năm trước đây khi rất nhiều giáo sư được đào tạo.

Lý do chính là nhiều (hầu hết?) Các trường đại học tự coi mình có mục tiêu khác với trường thương mại. Vì vậy, họ muốn dạy học sinh cách học và các nguyên tắc cơ bản của môn học. Ngoài ra, các thuật toán và cấu trúc dữ liệu sẽ áp dụng cho bất kỳ ngôn ngữ lập trình nào và không phụ thuộc vào các công cụ cụ thể (có thể vẫn được sử dụng sau khi tốt nghiệp).

Trong Khoa học Máy tính, điều đó có nghĩa là các thuật toán, cấu trúc dữ liệu, lý thuyết máy tính, lý thuyết trình biên dịch, v.v. Nội dung bạn đang liệt kê không phải là hiểu cách lập trình, cách giải quyết vấn đề, v.v. Đó là về thực hành lập trình (mà, tình cờ, là một cuốn sách tuyệt vời cho bất kỳ ai đang học đại học với ý định làm việc như một lập trình viên). Bây giờ, phần lớn điều này sẽ không được sử dụng ở vị trí mã đầu vào, khiến một số người nghĩ rằng nó không hữu ích. Tôi không đồng ý. Tôi nghĩ rằng nó có thể cực kỳ hữu ích. Tuy nhiên, không có nghĩa là sau khi bạn lấy bằng CS, bạn biết mọi thứ bạn cần để làm việc như một lập trình viên.

Điều này cũng không có nghĩa là những thứ bạn đề cập không hữu ích. Họ đang. Bạn sẽ gặp khó khăn khi làm lập trình viên nếu không học chúng, và tôi nghĩ chúng nên được dạy ở trường đại học, ít nhất là ở một mức độ nhất định. Tôi sẽ xem xét việc giảng dạy kiểm soát phiên bản, kiểm thử đơn vị, v.v., giống như cách tôi xem xét một chương trình đại học về nghệ thuật, và việc giảng dạy chổi sơn là gì và loại nào nên được sử dụng cho các trường hợp khác nhau.

Tôi nghĩ rằng nó phụ thuộc vào loại chương trình Khoa học Máy tính mà bạn đang tham gia, có những chương trình hướng tới phía Nghiên cứu và Khoa học và có những chương trình hướng tới phía Thực hiện. Tôi đặc biệt từ chối một số trường chỉ có các giáo sư ở lại trong giới hàn lâm. Nếu bạn không có các giáo sư đã không "sử dụng" những gì họ dạy, tất cả đều nằm trong đầu họ, theo nghĩa đen.

Plug: Sau khi lấy bằng BS trong Comp Sci và MS trong Soft Eng tại Đại học DePaul, tôi chủ yếu được giảng dạy bởi các giảng viên / giáo sư dạy bán thời gian, điều này rất ổn vì tôi muốn họ tham gia vào một giai thoại ngày trước và liên hệ nó với lớp. Ngoài ra, đây là trường học chủ yếu dành cho người đi làm / bán thời gian, hầu hết sinh viên đều có việc làm trong việc sử dụng những gì họ đang học.

Quá trình học vẫn bắt đầu với tất cả lý thuyết, nhưng sau đó chúng tôi thường được hỏi "có bao nhiêu bạn thực sự sử dụng điều này trong công việc của mình?" và câu trả lời điển hình là "chúng tôi sử dụng nó nhưng theo cách rút gọn hoặc đơn giản hơn" và sau đó chúng tôi đi vào các tình huống thực tế thực tế.

Trong quá trình kiểm tra đơn vị đi học của tôi luôn có mặt. Mặc dù họ bắt đầu bạn sử dụng Java, họ đã bắt chúng tôi sử dụng ANT và JUnit cho tất cả các dự án. Đó là một khởi đầu tốt về cấu hình xây dựng và thử nghiệm đơn vị.

Và Lập trình cực đoan đã được đưa vào khoảng 3 hoặc 4 trong số các lớp học mà tôi đã tham gia. Tôi nhớ tất cả họ đều bắt đầu với 12 khía cạnh khác nhau, từ lập trình cặp đến thử nghiệm đơn vị (xem ở trên). Và bây giờ có vẻ như trọng tâm là Agile.

Vì vậy, câu trả lời nhanh chóng là có, có những trường học có cách tiếp cận thực dụng hơn những trường khác.

Kiểm thử đơn vị và kiểm soát phiên bản đều được giảng dạy trong các khóa học Khoa học máy tính năm thứ 2, nơi tôi học đại học. Kiểm thử đơn vị nằm trong phần kiểm thử cũng bao gồm sự khác biệt giữa hộp trắng và hộp đen và một phần tốt các điểm trong bài tập lập trình năm thứ 3 giúp xử lý lỗi tốt có thể dễ dàng đến từ kiểm thử đơn vị.

Tôi nghĩ rằng phát triển nhanh có thể khó dạy trong một môi trường học thuật. Trong khi tôi đã tìm hiểu về phương pháp Waterfall trên lý thuyết, tôi đã không nhìn thấy nó trong thực tế cho đến sau khi tôi tốt nghiệp và chuyển sang thế giới thực có thể hoàn toàn khác với học thuật, ví dụ: vào năm thứ 3, tôi mắc tất cả những lỗi kỳ lạ. và gần như vượt qua một nhiệm vụ mà tôi chưa bao giờ chạm đến trọng tâm của những gì nhiệm vụ đã cố gắng dạy tôi về Semaphores.

Ngoài ra, nhanh nhẹn đã tồn tại được bao lâu và ý bạn là hình thức nhanh nhẹn nào? Có nhiều cách triển khai khác nhau của nó so với những gì tôi đã thấy.

Tôi không nghĩ lập trình nhanh là lỗi mốt, nhưng đồng thời tôi cũng khó nghĩ ra cách mà giáo viên có thể đưa cho bạn các dự án để bạn học nó .. Trừ khi họ cho bạn dự án A xây dựng, dự án B mở rộng trên a. Vấn đề là thời gian và phạm vi. Trong một khóa học 4 tháng, nó sẽ là khó khăn.

Các phương pháp kiểm tra phiên bản và kiểm tra đơn vị luôn thay đổi và phụ thuộc vào ngôn ngữ hoặc người xác định chúng.

Cấu trúc dữ liệu và bí danh là thứ có thể được thực hiện trong một thiết lập lớp. Thành thật mà nói, họ phải mất nhiều công sức hơn để hiểu sau đó là kiểm thử đơn vị và lập phiên bản. Hãy cố gắng nhớ một phần của trường đại học là dạy bạn dạy chính bạn. Ảnh ghép không hoàn toàn có cùng nhiệm vụ. Hoặc ít nhất là không đến mức tương tự. IMHO.