¿Por qué no enseñan estas cosas en la escuela? [cerrado]

Durante el verano, tuve la suerte de entrar en Google Summer of Code. Aprendí mucho (probablemente más de lo que aprendí en la suma de todos mis cursos universitarios). Sin embargo, realmente me pregunto por qué no enseñan algunas de las cosas que aprendí antes en la escuela. Para nombrar unos pocos:

• examen de la unidad
• control de versiones
• desarrollo ágil

Me parece que pasan una cantidad significativa de tiempo enseñando otras cosas como estructuras de datos y algoritmos por adelantado. Si bien sigo pensando que es muy importante aprenderlos desde el principio, ¿por qué no enseñan más de estos tres antes que ellos? ¿O es solo mi escuela la que no enseña mucho de estas cosas?

No me malinterpretes, no creo que sea deseable que las universidades siempre enseñen las últimas novedades en programación, pero ¿no deberían mis profesores enseñarme algo más que "dibujar un diagrama antes de empezar a codificar"?

La respuesta más simple a su pregunta es que los campos de la informática y el desarrollo de software son muy nuevos y no se conocen muy bien. Aunque todas las disciplinas científicas y de ingeniería están avanzando más rápidamente en los tiempos modernos, otros campos tienen mucha más experiencia en la que basarse y hay una comprensión compartida mucho más amplia de cómo funcionan.

Por ejemplo, a pesar de los avances recientes en la ciencia de los materiales, los ingenieros civiles han sabido durante aproximadamente 2000 años cómo construir un arco que no se caiga, y esto es algo que se puede enseñar y aprender en la universidad con relativamente poca controversia. Aunque estoy completamente de acuerdo con usted sobre las técnicas que los desarrolladores de software deben aprender, este acuerdo se basa en la experiencia personal y el razonamiento informal. Para ser una "mejor práctica" socialmente aceptada, necesitamos datos cuantitativos que pueden ser muy costosos de recopilar: ¿cuánto ayuda el control de versiones? ¿Cómo ayuda? ¿Examen de la unidad? Podemos razonar acerca de la efectividad de varias técnicas, pero en realidad probar esa efectividad de manera concluyente sería muy costoso. Necesitaríamos ejecutar un proyecto de software completo y realista de principio a fin, muchas veces, con grupos de programadores que tienen experiencia equivalente, utilizando diferentes técnicas. Como mínimo, necesitaríamos muchos datos sobre proyectos existentes que esos proyectos no estarían dispuestos a publicar.

Los ingenieros civiles tienen miles de años de puentes para mirar, con mucha información. Los desarrolladores de software, por otro lado, tienen solo unas pocas décadas de información, la mayor parte de la cual se mantiene en secreto, ya que hay poca motivación para que las organizaciones recopilen y publiquen información sobre la eficacia de sus desarrolladores, incluso si la están recopilando (que la mayoría no 't).

También hay cierta confusión de campos. El desarrollo de software, o "ingeniería" de software, es realmente una cosa diferente a la informática. Los desarrolladores de software necesitan un conocimiento práctico de la informática, pero trabajar en los límites de la complejidad algorítmica o razonar sobre el paralelismo no es algo que un programador en activo hará todos los días; De manera similar, un verdadero "informático" escribirá toneladas de código desechable que simplemente no funciona o no hace nada interesante, y no se beneficiará tanto del tipo de rigor que lo haría un producto de software real.

El surgimiento de Internet y la comunidad de código abierto puede proporcionar suficientes datos para comenzar a responder estas preguntas de manera concluyente, pero incluso si las respuestas estuvieran disponibles mañana, probablemente tomará 100 años para que permeen la sociedad internacional hasta el punto en que todos estén de acuerdo en qué debe enseñarse en las escuelas.

Finalmente, hay algunas consideraciones económicas. Ha pasado relativamente poco tiempo desde que casi todos los involucrados en el desarrollo de software tenían acceso fácil y barato a máquinas dedicadas para ejecutar las herramientas de desarrollo que quisieran. Hace unas décadas, dedicar completamente una máquina a ejecutar sus pruebas, o incluso albergar un historial infinito de código fuente, habría parecido frívolo y costoso a mucha gente.

Porque nuestros profesores:

1. Nunca probé las pruebas unitarias,
2. No sé cómo usar el control de versiones y
3. Ni siquiera he oído hablar de "desarrollo ágil".

Los estudiantes deben tomar el asunto en sus propias manos. Hicimos eso y salimos bien, ¿no?

Leonardo da Vinci escribió:

Aquellos que están enamorados de la práctica sin ciencia son como un piloto que se mete en un barco sin timón ni brújula y nunca tiene la certeza de adónde va. La práctica siempre debe basarse en un conocimiento sólido de la teoría.

Las buenas escuelas enseñan tanto teoría (estructuras de datos, algoritmos, etc.) como práctica (pruebas unitarias, control de versiones, etc.). Esto requiere una combinación apropiada de facultades para que ambas caras de esta moneda se puedan enseñar correctamente. Una facultad compuesta completamente por tipos teóricos sin experiencia real no servirá. De manera similar, una facultad compuesta enteramente por practicantes no servirá. Necesitas una mezcla, y las buenas escuelas la tienen.

La informática siempre ha sido algo contradictoria; La parte que trata de las computadoras no es una ciencia y la parte que es una ciencia no se trata de computadoras.

Las universidades tienden a apoyarse más en el extremo 'científico' (algoritmos, estructuras de datos, compiladores, etc.) porque esas cosas son mucho más 'atemporales' que las mejores prácticas actuales de la industria, que tienden a evolucionar y cambiar de año en año. El control de versiones, por ejemplo, ha experimentado cambios asombrosos en los últimos 5 o 10 años, pero big-O sigue siendo big-O, y el hash, btrees y la recursividad siguen siendo tan útiles como lo eran hace 40 años. En general, su idea es brindarle suficientes fundamentos para que luego pueda elegir herramientas como git y comprender lo que significa cuando le dicen que la estructura de datos subyacente es un gráfico dirigido acíclico de hashes SHA-1, y que los desarrolladores han trabajado duro para optimizar el número de llamadas al sistema para que esté vinculado a io.

Ahora, piense en dónde aprendió todas las cosas que tenía que saber para comprender la última oración: si la respuesta es "universidad", están haciendo un buen trabajo.

Todo es una moda pasajera. Aprenderás más en tu primer año fuera de la universidad que en todos tus años en la universidad. La informática no tiene nada que ver con las computadoras.

College te ofrece una caja de herramientas llena de herramientas. Este es un destornillador, que es una llave inglesa. PUEDES usar cada herramienta una vez en la universidad. Es cuando entras al mundo real es cuando realmente descubres lo que tienes. Separas las útiles del resto, las que quieres dejar en casa en el banco de trabajo, por si acaso, y las que guardas en tu bolsillo todos los días.

Tqm, Iso, Cmm, Agile, etc. Estas son todas modas que vendrán y se irán, ninguna de las exitosas es más que sentido común. Todos los ingenieros y empresas exitosos usan algo de sentido común, eso es lo que los hizo exitosos, pocos necesitaban un nombre para ello. El problema es que no se puede vender el sentido común, un gerente no puede demostrar su valor a la empresa capacitando y comprando sentido común sin un nombre llamativo. Ponle un nombre que sus superiores hayan leído en algún artículo o revista y el gerente conserva su trabajo y tú el tuyo. Muy pocas de las empresas que afirman seguir estas prácticas realmente lo hacen. La mayoría escribe un cheque a un consultor y obtiene su certificado anual o vitalicio en algún club para que puedan poner un gráfico en su sitio web o una etiqueta en la caja en la que viene su producto. Muchos dirán que esto es raro ... estado allí, lo he visto, sucede. Todo esto es parte del negocio, a veces tienes que tomar atajos para mantenerte rentable y mantener las puertas abiertas y las luces encendidas. Los seguidores incondicionales de todas estas prácticas han argumentado que la última fue una moda y esta no lo es, la última realmente fue demasiado cara de seguir, esta no lo es. El último fue falso, acabas de contratar a un consultor, este es real. Como los lenguajes de programación, estos también evolucionarán. El último fue falso, acabas de contratar a un consultor, este es real. Como los lenguajes de programación, estos también evolucionarán. El último fue falso, acabas de contratar a un consultor, este es real. Como los lenguajes de programación, estos también evolucionarán.

Su capacidad para comprender las realidades de los negocios, el sistema universitario y su papel en él es la clave. Como todo en la vida, elige tus batallas. No es la universidad ni la empresa ni el gobierno ni el trabajo de nadie más enseñarle lo que necesita o quiere saber. Es su trabajo buscar el número uno. Del mismo modo, no puedes culpar a nadie más por proporcionarte el tiempo para hacer esto, tienes que hacerlo. Te caerás del caballo, no eres una víctima, levántate y vuelve a subir, sin excusas, la vida no es justa con eso. Aproveche los folletos, no pretenda ser independiente. Y ciertamente pague sus deudas, no deje a una empresa seca de folletos sin darles algo (¿lo mejor en ese momento?) A cambio.

¿Por qué la gente piensa que cmm o ágil o cualquiera de los otros es una moda pasajera? ¿Por qué creen que no lo son? ¿Por qué el profesor te enseñó el programa de esa manera? ¿Evitar los gotos o evitar las constantes o evitar esto y aquello? ¿Es porque produce un código más confiable? ¿Código de mejor rendimiento? ¿Reduce el error humano? ¿O es porque es más fácil calificar trabajos / programas dándoles más tiempo para investigar? ¿Es porque no saben programar y solo están siguiendo el libro de otra persona sobre el tema? ¿Le enseñaron que no se puede tener un código de alto rendimiento, confiable y mantenible? ¿Ni siquiera puede "elegir dos" que el mantenimiento interfiera con el rendimiento confiable y alto? A veces sacrifica la fiabilidad por el rendimiento. A veces, no le importa la confiabilidad o el rendimiento, solo desea obtener de la versión 117.34. 2 de otro programa de software de contabilidad a la versión 118.0.0. Su modelo de negocio se basa en la venta de actualizaciones de versión y soporte técnico y, en lo que respecta a los desarrolladores de software, cualquier robot antiguo puede escribir el mismo código de la misma manera. Reemplace el quemado por uno recién salido de la universidad y siga vendiendo actualizaciones.

No existen respuestas universales a estas preguntas, hay que averiguar cuál es tu opinión, vivir con ella y defenderla. Cambia de opinión, vive con ello y defiéndelo.

Cuestiona todo ... ¿realmente me quemaré si toco la olla caliente en la estufa? ¿Los efectos psicológicos del miedo causarán más daño que el simple hecho de quemarse? ¿Existe una forma segura de probar la respuesta sin lastimarse?

Cuando podía pagarlo, compraba y eventualmente fundía transistores, tapas, resistencias, etc. en mi dormitorio, todos los cuales tienen un mal olor distintivo. Es mucho más barato y fácil comprar un amplificador para su estéreo que intentar construir uno el día después de su primera clase de transistores. Linus es la excepción, por supuesto, es más fácil comprar un sistema operativo que escribir uno ... Puede hacer más, aunque lo que aprende en ese tiempo es diferente de lo que aprendió Linus.

El mundo dentro y fuera de la universidad adoptará estas fórmulas (cmm, ágil, etc) para la resolución de problemas y cuando salga el próximo las descartarán igual de rápido. No tiene que usar el control de versiones para tener éxito, hay tantos éxitos con como sin (bueno, en realidad, debido a la era de la industria, hasta ahora hay muchos más éxitos sin control de versiones). Del mismo modo, puede tener éxito con un mínimo de pruebas (mire los nombres realmente importantes en la industria informática como ejemplos). Puede tener éxito probando su propio código, así como tener éxito siguiendo la regla de que nunca debe probar su propio código. Puede tener éxito usando emacs y puede tener éxito usando vi. Tienes que decidir qué combinación funciona para ti y, si tienes suerte, encontrar un lugar para trabajar que te convenga.

Cuando salga de la universidad y entre en el mundo real, escuche, trabaje y discuta con los "veteranos". Tienen décadas o siglos de experiencia combinada, trampas en las que han caído y que puede evitar o probar por su cuenta (tal vez se dé cuenta de que no tiene que tocar la olla caliente para descubrir que lo quemará). La mayoría habrá visto al menos una o dos de estas modas ir y venir, y en particular, lo mucho que se quemaron y lo que hicieron para recuperarse. Conocen muchas formas diferentes de probar cosas, y también conocen los nombres de los estilos de prueba que han ido y venido. Qué funciona, qué no. Dónde está el riesgo y cómo evitar perder el tiempo por la tangente. A medida que madura y se convierte en el veterano, páselo hacia adelante. Pague por lo que aprendió tratando de enseñar a los que lo siguen. Recuerda enseñarles CÓMO pescar, no les des un pescado. Y a veces tienes que dejar que fracasen antes de que tengan éxito, evitar que se quemen demasiado.

Lo que realmente quería decir aquí es que ahora mismo nos encontramos en una situación poco común en la que podemos presenciar la evolución de un universo paralelo (y tal vez influir en él). Sí, la informática es una ciencia joven en comparación con la física. Pero al mismo tiempo, ha evolucionado muchas veces. Dependiendo de dónde trabaje y con quién trabaje, es posible que pueda observar a los ingenieros de hardware. Los lenguajes de programación en el mundo del hardware ciertamente no son nuevos, pero no han evolucionado tan rápidamente como el mundo del software. El software tenía algunas décadas de ventaja. El hardware siempre ha pensado en los ingenieros de software como ciudadanos de segunda clase. Nuestro trabajo es fácil, su trabajo es duro. (Tenga en cuenta que en realidad soy un ingeniero de hardware y software). Lo interesante es que ahora mismo todavía están lidiando con lo que consideraríamos problemas elementales o infantiles. ¿Por qué debería usar el control de versiones? Soy el único que trabaja en este chip. Tu experiencia con gcc u otros compiladores baratos o IDE gratuitos no se puede comparar con las costosas herramientas que utilizo, si la empresa pensara que eres lo suficientemente digno para usarlo o incluso saber cómo usarlo, te comprarían una copia. Y una larga lista de otras excusas. Tuve el placer de aprender tanto vhdl como verilog y volverme productivo en ambos en una semana de lo que fue casi un desafío de un ingeniero de hardware (a pesar de que mi diploma decía ingeniero eléctrico, mi puesto de trabajo es ingeniero de software). Quería aprender estos idiomas, cuando las herramientas estaban disponibles para mí, me quedaba en la oficina hasta la noche y aprendía yo mismo. A partir de ese momento, ese ingeniero en particular se dio cuenta de que lo que estaba diciendo era cierto, los lenguajes son solo sintaxis, Los fundamentos de la programación son los mismos, todas las herramientas hacen lo mismo. Son manzanas y manzanas, no manzanas y naranjas.

En general, sin embargo, todavía es difícil enviar el mensaje de que una de estas dos industrias paralelas tiene mucha más experiencia en lenguajes, hábitos de programación, control de fuente, pruebas, herramientas, entornos de programación, etc. que la otra. El problema que estoy tratando de resolver es tomar los diseños de hardware a medida que se desarrollan, crear simuladores funcionales asequibles que podamos vincular con una simulación (máquina virtual) del procesador para que podamos comenzar a probar el hardware y desarrollar la prueba y software entregable mucho antes de que vayamos al silicio. No, no hay nada "nuevo" en esto, pero no tenemos ningún mecanismo para obtener el código más reciente, realizar un seguimiento de los cambios en el código para ver dónde debemos concentrar nuestro tiempo. No hay mecanismo para rastrear la documentación que define la interfaz de usuario (programación) para el hardware. La única copia dorada está en la bandeja de entrada del correo electrónico de alguien en forma binaria y solo cambia cuando, bueno, no tiene que leer el verilog para averiguar qué está pasando. Espera, ¿cuántos años tiene ese verilog? ¿Ese error que pasé toda la semana contigo lo descubrí hace tres semanas y lo solucioné? Entonces, ¿simplemente volamos a algún lugar de vacaciones y festejamos durante seis meses esperando a que la gente de hardware termine su tarea y nos la arroje por la borda, o aprovechamos esta oportunidad para tratar de ser pacientes y optimistas y enseñarles que ellos? hay métodos de sentido común que no son tan intrusivos que les permiten hacer su trabajo, hacer una copia de seguridad de su trabajo y compartir sus cosas para la revisión por pares ... ¿Qué edad tiene ese Verilog? ¿Ese error que pasé toda la semana contigo lo descubrí hace tres semanas y lo solucioné? Entonces, ¿simplemente volamos a algún lugar de vacaciones y festejamos durante seis meses esperando a que la gente de hardware termine su tarea y nos la arroje por la borda, o aprovechamos esta oportunidad para tratar de ser pacientes y optimistas y enseñarles que ellos? hay métodos de sentido común que no son tan intrusivos que les permiten hacer su trabajo, hacer una copia de seguridad de su trabajo y compartir sus cosas para la revisión por pares ... ¿Qué edad tiene ese Verilog? ¿Ese error que pasé toda la semana contigo lo descubrí hace tres semanas y lo solucioné? Entonces, ¿simplemente volamos a algún lugar de vacaciones y festejamos durante seis meses esperando a que la gente de hardware termine su tarea y nos la arroje por la borda, o aprovechamos esta oportunidad para tratar de ser pacientes y optimistas y enseñarles que ellos? hay métodos de sentido común que no son tan intrusivos que les permiten hacer su trabajo, hacer una copia de seguridad de su trabajo y compartir sus cosas para la revisión por pares ...

Recuerde que los ingenieros de hardware dejaron la universidad con una caja de herramientas nuevas y brillantes, como lo hizo usted. Aprendió 17 lenguajes de programación diferentes de los cuales solo puede usar uno, el resto de los lenguajes que en su carrera se inventarán después de que deje la universidad. Cuando dejaron la universidad, pueden decirte lo que saben sobre cálculo y la teoría de la relatividad cuántos electrones hay en cada uno de los elementos y calcular la carga alrededor de una superficie gaussiana. Pero la mayor parte de su carrera es uno, cero y, o y no (oye, tenemos esos en común, todo lo que realmente necesitas saber sobre computadoras, uno, cero y, o no, ingeniero de hardware o software). Concedidas las leyes fundamentales de la física, el cálculo, los electrones no van a cambiar tan rápido como lo hacen los lenguajes de programación. Pero los fundamentos de la programación son los mismos en todos los lenguajes y seguirán siéndolo en el futuro. ¿Dejaste la universidad sabiendo eso o te fuiste pensando que Java es diferente y mejor que C ++ porque esto y aquello y lo otro?

Como cualquier otro negocio, el trabajo de las universidades es seguir siendo rentable. Tienen que contratar a los académicos adecuados para traer tanto a los estudiantes adecuados como a los dólares de investigación adecuados y los tipos de investigación adecuados para que la universidad sea rentable. Tienen que ofrecer las clases adecuadas para traer a los estudiantes adecuados y producir los graduados adecuados para que, a medida que pasen las décadas, los empleadores, tanto cerca de la universidad como, con suerte, lejos, reconozcan que esta universidad produce empleados productivos y rentables. (sí, ya veces hay que atraer a los atletas adecuados en el deporte adecuado para obtener la cantidad adecuada de tiempo en televisión y la cantidad adecuada de reconocimiento de nombres e ingresos deportivos). Algunas universidades enseñarán C ++ y Java, otras nunca lo harán. Algunos inventarán CMM, otros enseñarán Agile, otros no harán ninguna de las dos. Si la universidad tiene algún valor, hay algo que puedes aprender. No te enseñarán todo lo que hay que aprender, pero tendrán algo útil. Aprenda algo mientras esté allí, recopile una cantidad razonable de diversas formas de herramientas en su caja de herramientas. Deja la universidad y consigue un trabajo. Si su caja de herramientas apesta, tal vez encuentre otra universidad y nunca mencione la primera. Si es una buena caja de herramientas, use esas herramientas y construya algunas nuevas en su propio tiempo. Si es una caja de herramientas bastante buena, diga cosas buenas sobre esa universidad y los buenos académicos de los que aprendió esto y aquello y devuélvale a la escuela lo que le dieron. Aunque no obtuvo todas las herramientas posibles en el catálogo universal de herramientas universitarias, se irá con un determinado subconjunto. Incluso si no te gradúas ...

Enseñé estas cosas cuando era adjunto en el Instituto de Tecnología de Oregon. Se les enseña, solo escasamente.

La respuesta más simple es que estás estudiando informática y las cosas que enumeraste no están realmente relacionadas con el campo académico de la informática. El desarrollo de software puede ser algo que haces con la informática, algo que se basa en los bloques de lo que has aprendido ... pero la informática y el desarrollo de software no son lo mismo.

Clases que le enseñaron el control de versiones, o cómo escribir pruebas unitarias efectivas ... que le enseñarían un oficio , a saber, el (buen) desarrollo de software.

oh dios no me hagas empezar

Una vez el decano de cs en una universidad de renombre me dijo que la programación orientada a objetos era solo una 'moda', por lo que no ofrecían ninguna clase sobre fantasías pasajeras como C ++

en cuanto a por qué no enseñan estas cosas, bueno, la universidad está ahí para enseñarte los fundamentos de la disciplina, no necesariamente las mejores prácticas de la industria

Bueno, lo que pasa con las universidades es que necesitan enseñar cosas que realmente son universales. Algo como el desarrollo ágil todavía es bastante nuevo y, a pesar de cuánto se habla en Internet, no se está utilizando en todas partes, por lo que enseñarlo a toda una clase de estudiantes solo beneficiaría a unas pocas personas que aterrizaron en tiendas ágiles.

Sin embargo, el control de versiones es algo que en estos días es imperdonable. Es algo que todo el mundo debe entender que es una herramienta que es casi tan útil como un compilador y CVS ha existido durante más de 20 años. Los conceptos al menos deben ser entendidos por cualquier programador que abandone la universidad. Afortunadamente, si haces algún trabajo en grupo en la universidad, es posible que tengas la suerte de aterrizar con alguien que ya sepa sobre el control de versiones y convenza a tu grupo para que lo use. Sé que me alegro de que esa persona estuviera en mi grupo.

Las pruebas unitarias también son bastante imperdonables. Lo único que diría es que el libro todavía está publicado sobre desarrollo impulsado por pruebas y buscar una cobertura del código del 100% siempre puede ser más problemático de lo que vale la pena. Pero las pruebas unitarias son extremadamente valiosas y deben cubrirse en un curso de ingeniería de software. Me imagino que algunas de estas cosas están llegando a algunas universidades, pero todavía no las han alcanzado a todas.

¿Por qué no? Mi experiencia al obtener mi título de CS fue prácticamente la misma. La razón es que las personas que enseñan programación no programan, por lo que yo sé. No es necesario enseñar esas cosas para la acreditación, los profesores no están familiarizados con ellas y los estudiantes nunca desarrollan proyectos de importancia como parte de sus cursos. No hay motivación para realmente enseñar programación, a diferencia de enseñar teoría de CS o sintaxis de Java.

Los informáticos piensan que son matemáticos, no ingenieros, por lo que prefieren enseñar las partes de matemáticas que de ingeniería. Las pruebas, el control de versiones y la documentación no están pasando de moda más que en cualquier otra disciplina de ingeniería.

Depende de la universidad. Me gradué en 2003, de una universidad australiana. En ese tiempo aprendimos UML, Unit Testing, XP (y otras metodologías ágiles), junto con todas las cosas formales como Z, algoritmos y estructuras de datos, sistemas operativos, etc.

Sin embargo, no cubrieron las pruebas unitarias en gran detalle, sino que simplemente pagaron el servicio de aprobación por una conferencia. Hubiera sido genial haber aprendido a escribir pruebas unitarias efectivas, en lugar de simplemente "Qué es una prueba unitaria".

En lo que respecta al control de versiones, lo usamos (CVS) en nuestros proyectos de programación desde el segundo año en adelante.

También estoy totalmente de acuerdo con lo que dijo Glyph. La informática es un campo tan inmaduro, en realidad solo ha existido en los últimos 50 años, que no sabemos qué deberíamos estar aprendiendo y qué es solo una moda pasajera. Dale 150 años, entonces las cosas podrían calmarse más. La cantidad de proyectos fallidos del mundo real hace que sea obvio que se trata de una industria inmadura. ¡Imagínese si el 80% de los proyectos de construcción fracasaran!

Todo eso se puede cubrir fácilmente (superficialmente) en una sola clase sobre prácticas de desarrollo de software. No es parte de la mayoría de los planes de estudio de informática, porque de eso no se trata la informática, aunque creo que es útil una cierta cobertura de esas cosas. Mi escuela tenía una clase así; no cubría el control de versiones, pero sí cubría UML, recopilación de requisitos, metodologías de desarrollo (varias ágiles y en cascada), pruebas unitarias, pruebas de integración, etc., y nos obligó a trabajar en equipos de 4-5 para desarrollar un proyecto (una copia de Clue bastante simple en Java). Si sintió la necesidad de más clases de Ingeniería de Software, estaban disponibles como optativas.

A pesar de que nunca se mencionó el control de versiones ni una vez en ninguna clase que tomé, la mayoría de mis amigos lo usaban para proyectos personales, tareas de clase, etc., por lo que no es como si no estuviéramos expuestos a él. Las personas que no lo aprendieron por su cuenta se vieron obligadas a usarlo por un compañero de clase en el curso de una tarea de equipo.

La universidad está destinada a enseñar conceptos y teorías, porque esas son las cosas que son difíciles de aprender por su cuenta. El control de versiones es una herramienta y bastante fácil de aprender. Úselo un poco, lea algunos tutoriales en la web y estará listo. Si necesita conferencias y asignaciones de tareas para descubrir cómo verificar algo de SVN, tendrá muchos problemas con las cosas que realmente SON difíciles.

Recuerde que hay muchas formas de aprender cosas en la universidad fuera de las clases; Aprovecha eso. Está pagando mucho para asistir a las clases y usar las instalaciones, así que aproveche todo lo que vale y vaya a las reuniones de LUG y ACM, participe en equipos de proyecto (siempre hay algunos ME construyendo un robot que necesitan un programador) u obtenga un trabajo administrando el servidor del departamento de Humanidades. Recoja una computadora del muelle de carga del edificio de Ingeniería de Materiales, descargue una ISO de Linux con la conexión rápida a Internet de su dormitorio y juegue.

Creo que el problema es que las universidades no sienten que necesitan enseñarte a ser un profesional, sino que se enfocan en el lado académico de la programación. Pensé que debería haber al menos una referencia a los métodos y técnicas más recientes que se utilizan en la industria, ya que estas cosas también son de interés académico.

En nuestro curso, nos enseñaron el Proceso de software personal, que cubría cosas como el tiempo de grabación dedicado a los proyectos, buenos comentarios, etc., pero sin mencionar los fundamentos profesionales como el control de versiones.

Ha nombrado 3, algunos de los cuales no creo que sean tan importantes para la comprensión de los sistemas informáticos (por ejemplo, control de versiones). Estas cosas son parte de un trabajo y puede convertirse en un buen programador / científico informático sin necesidad de saberlo.

de manera similar para las pruebas unitarias: ¿por qué elegir las pruebas unitarias? ¿Seguramente las pruebas de usabilidad, la prueba del sistema, la prueba de aceptación del usuario y la prueba de aceptación de fábrica son más importantes? Bueno, lo están a menos que considere que su trabajo está completo una vez que el código se envíe al departamento de mantenimiento :)

Piense en los otros conceptos que utilizo a diario, que serían de poca utilidad para un estudiante que se adapta a los fundamentos del software y los sistemas informáticos:

• buenas prácticas de comentarios
• Cumplimiento de estándares (no solo internacionales, sino estándares de codificación de equipos)
• documentación
• control de cambios (no necesariamente lo mismo que el control de versiones, que se trata de almacenar diferencias, se trata más de qué y por qué cambió algo)
• desarrollo de usabilidad

Las anteriores son todas "habilidades blandas" que no necesitas para escribir un buen código.

Sin embargo, si le faltan las habilidades "duras", como las estructuras de datos y los algoritmos, entonces su oportunidad de escribir un buen código es casi imposible.

Aprendí todo eso en la Universidad. ¿Quizás depende de los cursos que elijas? Mis cursos fueron muy diversos (Diseño de Software, Diseño de UI, eCommerce, AI, Programación Funcional, etc.). El diseño de software estuvo expuesto a patrones de diseño y pruebas unitarias (un gran proyecto que involucró varias cosas). Diseño de interfaz de usuario ... éramos un grupo de tres personas trabajando en un proyecto. No podríamos hacer nada sin el control de versiones, así que lo conseguimos. Y el desarrollo ágil era algo que nuestros profesores nos hablaban continuamente, pero dejaron que cada grupo lo usara.

Encuentro que muchos estudiantes universitarios tomaron cursos "fáciles" o cursos que les darían un GPA alto. Otros se centran en lo que quieren aprender y están explorando en gran medida para encontrar qué campo les interesaría. Y luego están aquellos que saben exactamente lo que les interesa ... lo cual es bueno, excepto que tienden a no diversificar sus cursos.

Para responder por qué estas cosas no son las primeras cosas que se enseñan: los programas de pregrado generalmente lo capacitan para convertirse en un estudiante de maestría. Solo una vez que comience a elegir sus propios cursos (lo que generalmente ocurre en años posteriores) puede elegir aprender sobre las cosas que se usan fuera de la academia. Es por eso que se enfocan en algoritmos, estructuras de datos, presentarte problemas sin resolver, etc.

Personalmente, creo que está bien que estén haciendo esto. Programar no es tan fácil como muchos de nosotros lo hacemos parecer; mucha gente lucha con eso. Preferiría que estas personas primero entiendan cómo funciona un bucle for antes de descubrir el monstruo que es Perforce.

No enseñan esos temas porque la mayoría de las escuelas son académicas, no comerciales. Es decir, están diseñados para enseñar ideas y teorías, no para entrenarlo en una carrera. Todo el concepto de QA no tiene nada que ver con la informática más allá de aprobar una prueba matemática. Además, las prácticas de control de calidad y los flujos de trabajo de desarrollo difieren enormemente de una casa de desarrollo a otra, por lo que enseñarlos en la escuela es una pérdida de tiempo y dinero.

Aprendí todas esas cosas en el primer año, con la excepción del desarrollo ágil.

Se trata de elegir la escuela adecuada, en mi humilde opinión. Si va al top 10, aprenderá todo eso rápidamente.

En cuanto a la educación informática en general, básicamente estamos pidiendo a los profesores que enseñen mucho (lenguajes de todos los tipos, estructuras de datos, eficiencias en el tiempo de ejecución, cómo funcionan las cosas a nivel de bits). Me gustaría plantear la pregunta: ¿Por qué los niños no se encargan de aprender más sobre Ingeniería de Software?

Al igual que los estudiantes, cada universidad es diferente. Algunas universidades, o más exactamente, algunos profesores se resisten al cambio o son vagos. Afortunadamente, la mayoría no lo son. Las teorías, conceptos, historia, etc. son importantes y vitales para cualquier plan de estudios de informática. Pero también lo es preparar al estudiante para su entorno laboral. No es de extrañar que las universidades comunitarias de mi área ofrezcan cursos de informática muy actuales y aplicables. No tanto con una universidad grande, consolidada y prestigiosa.

Es simplemente porque las estructuras de datos y los algoritmos constituyen el núcleo de la informática y, por lo tanto, son mucho más importantes. Las pruebas unitarias, el control de versiones y la metodología ágil son solo herramientas del oficio (y si es necesario, se espera que uno las aprenda en el trabajo).

Creo que los buenos programas de informática deberían enseñar los fundamentos que servirán como base para toda la educación futura en programación. Las metodologías de desarrollo como Agile y las herramientas de control de versiones son como modas; vienen y van. Además, tienden a usarse en entornos industriales y no académicos, por lo que creo que es raro que las universidades cubran cosas como las que probablemente aprenderá en el trabajo. No digo que sea correcto, pero esa es probablemente la mentalidad académica.

Estoy de acuerdo con lo que dices. Recientemente comencé a trabajar en el mundo del desarrollo de software y ya comencé a aprender sobre desarrollo ágil, algo que nunca me enseñaron en la universidad.

El quid de la cuestión puede ser que los profesores universitarios no se mantengan al día con las nuevas técnicas de desarrollo tanto como deberían. También pueden sentir que hay otras cosas más importantes en su plan de estudios.

Los profesores universitarios no saben cómo escribir software, solo lo investigan, lo enseñan y, ocasionalmente, aprenden un código que solo tiene que funcionar hasta que se publique el artículo.

Es solo gracias a personas como Titus que tenemos académicos que realmente asimilan la programación. Lea sus comentarios sobre ese tema aquí.

Cuando era estudiante, leía libros en la biblioteca sobre Programación extrema, y ​​lo discutimos brevemente en las clases: las mismas clases que exigían que nos amoldemos al "Modelo de cascada" del desarrollo de software, donde la "compilación" es un paso de su propio.

Todo lo mejor con tu carrera, espero que te gradúes, es bueno tener letras después de tu nombre. :)

Las tres cosas que mencionas (pruebas unitarias, control de versiones, desarrollo ágil) se enseñan hasta cierto punto en el programa de Ciencias de la Computación de la Universidad de Groningen. Si eso es bueno o no, lo dejaré como una pregunta abierta; pero no es cierto que ninguna universidad te enseñe las "cosas prácticas".

Estos se basan en mis experiencias limitadas en un programa de informática antes de cambiar de especialización y mi experiencia como pasante en una gran empresa de software. Las pruebas unitarias no se enseñan porque la mayoría de los programas que tienes que crear no son lo suficientemente grandes como para necesitar pruebas automatizadas, tienes garantizado un conjunto específico de entradas para poder probar todo manualmente. Enseñarle cómo automatizar las pruebas también puede interferir con la calificación de su proyecto, ya que la mayoría de los proyectos se califican con scripts que ejecutan pruebas automatizadas, con un vistazo rápido al código para asegurarse de que no tiene int foo1; int foo2; y usa la sangría adecuada.

No sé por qué no se enseñaría el control de versiones, pero parte de esto probablemente sea el tamaño de los proyectos. Nunca tuve un proyecto que fuera lo suficientemente grande para el control de versiones, y en general me refiero a más de 1000 líneas de código y me tomó un semestre entero escribirlo. Supongo que piensan que te lo enseñarás a ti mismo si lo necesitas. Se suponía que todos los proyectos grupales que tenía eran proyectos de programación en pareja, y ¿por qué usar el control de versiones si ambos están en la misma computadora?

No sé por qué no se enseñaría el desarrollo ágil, pero probablemente se remonta a lo mismo con el tamaño del programa. Si bien el desarrollo ágil es común con el nuevo software que se ejecuta en computadoras personales y servidores pequeños, generalmente no se usa en sistemas como los mainframes de IBM o en dominios problemáticos como banca o médicos, donde la documentación es el rey. Probablemente también tenga que ver con el hecho de que el desarrollo ágil no existía hace 20 años cuando se formaba a muchos profesores.

La razón principal es que muchas (¿la mayoría?) Universidades consideran que tienen un objetivo diferente al de una escuela de oficios. Como tal, quieren enseñar a los estudiantes cómo aprender y los principios fundamentales de la disciplina. Además, los algoritmos y las estructuras de datos se aplicarán a cualquier lenguaje de programación y no dependen de herramientas específicas (que pueden estar o no en uso al graduarse).

En Ciencias de la Computación, eso significa algoritmos, estructuras de datos, teoría de la computadora, teoría del compilador, etc. Lo que enumeras tiene menos que ver con comprender cómo programar, cómo resolver problemas, etc. Se trata de la práctica de la programación (que, dicho sea de paso, es un libro asombroso para cualquiera que esté en la universidad y tenga la intención de trabajar como programador). Ahora, gran parte de esto no se utilizará en una posición de mono de código de nivel de entrada, lo que lleva a algunas personas a pensar que no es útil. Estoy en desacuerdo. Creo que puede resultar de gran utilidad. Sin embargo, no significa que después de obtener su título de CS, sepa todo lo que necesitará para trabajar como programador.

Lo que tampoco quiere decir que las cosas que mencionas no sean útiles. Son. Tendrá problemas para trabajar como programador si no los aprende, y creo que deberían enseñarse en la universidad, al menos hasta cierto punto. Miraría la enseñanza del control de versiones, las pruebas unitarias, etc., de la misma manera que miraría una programación de pregrado en arte, y la enseñanza de qué son los pinceles y cuáles deberían usarse para varios casos.

Creo que depende del tipo de programa de Ciencias de la Computación en el que se encuentre, hay los que apuntan hacia el lado de la Investigación y la Ciencia y los hay que apuntan hacia el lado de la Implementación. Me negué especialmente a ciertas escuelas que solo tenían profesores que se quedaban en el mundo académico. Si no tiene profesores que no hayan estado "usando" lo que enseñan, todo está en su cabeza, literalmente.

Plug: Habiendo obtenido una licenciatura en ciencias de la competencia y una maestría en ingeniería suave en la Universidad de DePaul, me enseñaron principalmente instructores / profesores que enseñaron a tiempo parcial, lo cual estuvo bien para mí porque preferiría que vinieran con una anécdota del día anterior. y relacionarlo con la clase. Además, al ser una escuela en su mayoría de viajeros diarios / de medio tiempo, la mayoría de los estudiantes tienen trabajos en el uso de lo que están aprendiendo.

El proceso de aprendizaje aún comienza con toda la teoría, pero luego generalmente nos preguntan "¿cuántos de ustedes realmente usan esto en su trabajo?" y la respuesta típica es "lo usamos pero de una manera más simplificada" y luego nos adentramos en los escenarios prácticos del mundo real.

Durante mi unidad escolar, las pruebas siempre estuvieron presentes. A pesar de que te empezaron con Java, nos hicieron usar ANT y JUnit para todos los proyectos. Lo que fue un buen comienzo en la configuración de compilación y las pruebas unitarias.

Y Extreme Programing se incluyó en aproximadamente 3 o 4 de las clases que tomé. Recuerdo que todos comenzaron con los 12 aspectos diferentes, desde la programación por pares hasta las pruebas unitarias (ver más arriba). Y ahora parece que la atención se centra en Agile.

Entonces, la respuesta rápida es sí, hay escuelas que tienen un enfoque más pragmático que otras.

Las pruebas unitarias y el control de versiones se impartieron en los cursos de Ciencias de la Computación de segundo año en los que fui a la universidad. Las pruebas unitarias se incluyeron en la parte de las pruebas que también incluían diferencias entre la caja blanca y la negra y una buena parte de las calificaciones en las asignaciones de programación del tercer año se destinaron a un buen manejo de errores que pueden provenir fácilmente de las pruebas unitarias.

Creo que el desarrollo ágil puede ser bastante difícil de enseñar en un entorno académico. Si bien aprendí sobre el método Waterfall en teoría, no pude verlo en el campo hasta después de graduarme y mudarme al mundo real que puede ser bastante diferente del académico, por ejemplo, en el tercer año cometo todos los errores extraños casos y casi aprobar una tarea en la que nunca toqué el corazón de lo que la tarea trató de enseñarme sobre los semáforos.

Además, ¿cuánto tiempo ha existido ágil y a qué forma de ágil te refieres? Hay muchas implementaciones diferentes de lo que he visto.

No creo que la programación ágil sea una moda pasajera, pero al mismo tiempo me costaría mucho pensar en una forma en que un profesor podría darte proyectos que te permitan aprenderlo. A menos que te hayan dado el proyecto A build a, el proyecto B amplía a. El problema es el tiempo y el alcance. En un curso de 4 meses sería difícil.

Los métodos de control de versiones y pruebas unitarias cambian constantemente y dependen del idioma o de la persona que los define.

Las estructuras de datos y los algoritmos son algo en lo que se puede trabajar en un entorno de clase. Honestamente, también, requieren un poco más de esfuerzo para comprender que las pruebas unitarias y el control de versiones. Trata de recordar que parte de la universidad es enseñarte a enseñarte a ti mismo. Collage no tiene el mismo mandato. O al menos no en la misma medida. EN MI HUMILDE OPINIÓN.