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

Durante el verano, tuve la suerte de ingresar a Google Summer of Code. Aprendí mucho (probablemente más de lo que aprendí en la sum de todos mis cursos universitarios). 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 time enseñando otras cosas como estructuras de datos y algorithms por adelantado. Aunque sigo pensando que es muy importante aprender 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 esto?

No me malinterpreten, no creo que sea deseable que las universidades siempre enseñen las modas más novedosas de progtwigción, ¿pero no deberían mis profesores enseñarme algo más que "dibujar un diagtwig antes de comenzar 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 poco conocidos. Aunque todas las disciplinas científicas y de ingeniería están avanzando más rápidamente en los times modernos, otros campos tienen mucha más experiencia para aprovechar y existe una comprensión compartida mucho más amplia de cómo funcionan.

Por ejemplo, a pesar de los recientes avances en la ciencia de los materiales, los ingenieros civiles han sabido durante 2000 años cómo build 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 totalmente de acuerdo con usted acerca de 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: ¿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 que la efectividad concluyente sería muy costosa. Tendríamos que ejecutar un proyecto de software completo y realist de principio a fin, en numerosas ocasiones, con grupos de progtwigdores que tienen experiencia equivalente, utilizando diferentes técnicas. Por lo less, necesitaríamos muchos datos sobre proyectos existentes que esos proyectos no estarían dispuestos a lanzar.

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

También hay una confusión de campos. El desarrollo de software, o "ingeniería" de software, es realmente una cosa diferente de 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 el razonamiento sobre el paralelismo no es algo que un progtwigdor en funcionamiento haga todos los días; del mismo modo, un verdadero "científico de la computación" escribirá toneladas de código descartable que simplemente no funciona o no hace nada interesante, y no se beneficiará tanto del tipo de rigor que tendría un producto de software real.

El surgimiento de Internet y la comunidad de fuente abierta puede proporcionar suficientes datos para comenzar a responder estas preguntas de manera concluyente, pero incluso si las respuestas estuvieran disponibles mañana, probablemente les llevará 100 años impregnar a la sociedad internacional hasta el punto en que todos estén de acuerdo en qué debería enseñarse en las escuelas.

Finalmente hay algunas consideraciones económicas. Ha sido un time relativamente corto ya que casi todos los involucrados en el desarrollo de software tenían acceso barato y fácil a máquinas dedicadas para ejecutar cualquier herramienta de desarrollo que quisieran. Hace algunas décadas, dedicar completamente una máquina a solo ejecutar sus testings, o incluso albergar una historia infinita de código fuente, habría parecido frívolamente caro para muchas personas.

Porque nuestros maestros:

  1. Nunca he probado testings 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 resultó bien, ¿verdad?

Leonardo da Vinci escribió,

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

Las buenas escuelas enseñan tanto la teoría (estructuras de datos, algorithms, etc.) como la práctica (testings unitarias, control de versiones, etc.). Esto requiere una mezcla apropiada de facultad para que ambos lados de esta moneda puedan ser enseñados apropiadamente. Una facultad compuesta completamente de types teóricos sin experiencia real no servirá. Del mismo modo, una facultad compuesta en su totalidad de profesionales no lo hará. Necesitas una combinación, y las buenas escuelas tienen eso.

La informática siempre ha sido un tanto contradictoria; La parte que trata de las computadoras no es una ciencia, y la parte que es una ciencia no es sobre computadoras.

Las universidades tienden a inclinarse más hacia el lado de la 'ciencia' (algorithms, estructuras de datos, comstackdores, etc.) porque esas cosas son mucho más 'intemporales' 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 sorprendentes en los últimos 5 o 10 años, pero el big-O sigue siendo grande-O, y hashing, btrees y recursion siguen siendo tan útiles como lo eran hace 40 años. Su idea es, en general, proporcionarle fundamentos suficientes para que luego pueda get herramientas como Git y comprender lo que significa cuando le dicen que la estructura de datos subyacente es un gráfico acíclico de hashes SHA-1, y que los desarrolladores han trabajado duro. para optimizar el número de llamadas de sistema para que esté vinculado.

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

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

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

College te proporciona una caja de herramientas llena de herramientas. Este es un destornillador, que es una llave inglesa. PODRÍAS usar cada herramienta una vez en la universidad. Cuando ingresas al mundo real es cuando realmente descubres lo que tienes. Separe los útiles del rest, cuáles quiere dejar en casa en el banco de trabajo, por si acaso, y los que tiene en el bolsillo todos los días.

Tqm, Iso, Cmm, Agile, etc. Estas son todas las modas que vendrán e irán, ninguno de los exitosos son más que solo sentido común. Todos los ingenieros y compañías exitosos usan un poco 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 probar su valor para la empresa entrenando y comprando sentido común sin un nombre pegadizo. Ponle un nombre que sus superiores hayan leído en algún artículo de noticias o revista y el gerente conserve su trabajo y tú mantengas el tuyo. Muy pocas de las compañías que afirman seguir estas prácticas realmente lo hacen. La mayoría escribe un cheque a un consultor, y obtienen su certificate anual y de por vida a algún club para que puedan poner un gráfico en su website o una label en la caja de su producto. Muchos argumentarán que esto es raro … estado allí, lo he visto, sucede. Todo esto es parte del negocio, a veces tienes que tomar atajos para seguir siendo 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 es, la última realmente era demasiado costosa de seguir, esta no lo es. El último fue falso, acabas de contratar a un consultor, este es real. Al igual que los lenguajes de progtwigción, estos también evolucionarán.

Su capacidad para comprender las realidades de los negocios, el sistema universitario y su rol en él es la key. Como cualquier cosa en la vida, elige tus batallas. No es la universidad, el negocio o el gobierno ni el trabajo de nadie más para enseñar lo que quieres o lo que quieres saber. Es su trabajo search el número uno. Del mismo modo, no puedes culpar a nadie por darte el time para hacerlo, tienes que hacerlo. Te caerás del caballo, no eres una víctima, te levantarás y volverás a upload, sin excusas, la vida no es justo. Aproveche los folletos, no pretenda ser independiente. Y ciertamente pague sus deudas, no deje que la compañía se quede sin folletos, sin darles algo (¿es 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 progtwig de esa manera? ¿Para evitar gotos o evitar constantes o evitar esto y lo otro? ¿Es porque produce un código más confiable? ¿Código de mejor performance? Reduce el error humano ¿O es porque es más fácil calificar los trabajos / progtwigs, lo que les da más time para investigar? ¿Es porque no saben cómo progtwigr y simplemente están siguiendo el libro de otra persona sobre el tema? ¿Le enseñaron que no puede tener un código de alto performance, confiable y confiable? Ni siquiera puede "elegir dos" interferencias mantenibles con un performance fiable y de alto performance. Algunas veces sacrificas la confiabilidad por el performance. A veces no le importa la confiabilidad o el performance, solo desea get desde la versión 117.34.2 de otro progtwig de software de contabilidad hasta la versión 118.0.0. Su model de negocio consiste en vender actualizaciones de versiones y soporte técnico y, en lo que respecta a desarrolladores de software, cualquier viejo robot que pueda escribir el mismo código de la misma manera. Reemplace el quemado con el recién salido de la universidad y siga vendiendo actualizaciones.

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

Cuestione todo … ¿realmente me quemaré si toco la olla caliente en la estufa? ¿Los efectos psicológicos de tener miedo causarán más daño que simplemente quemarse? ¿Hay una forma segura de probar la respuesta sin lastimarse?

Cuando pudiera pagarlo compraría y eventualmente derretiría transistores, tapas, resistores, etc. en mi dormitorio, todos los cuales tienen un mal olor característico. Es mucho más barato y más fácil comprar un amplificador para su estéreo que tratar de build uno el día posterior a su primera class de transistor. Linus es la exception, por supuesto, es más fácil simplemente comprar un sistema operativo que escribir uno … Se puede hacer más, aunque lo que se aprende en ese momento es diferente de lo que aprendió Linus.

El mundo dentro y fuera de la universidad adoptará estas fórmulas (cmm, ágil, etc.) para resolver problemas y, cuando salga la siguiente, los eliminará igual de rápido. No es necesario utilizar el control de versiones para tener éxito, existen tantos éxitos como sin ellos (bueno, en realidad debido a la antigüedad de la industria, hay muchos más éxitos sin control de versiones hasta el momento). Del mismo modo, puede tener éxito con testings mínimas (vea ejemplos realmente grandes en la industria informática). Puede tener éxito al probar su propio código, así como tener éxito al seguir 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 esté de acuerdo contigo. Con el time, lo que funciona para usted cambiará, desde herramientas hasta idiomas, pasando por el estilo de progtwigción, miedos, control de versiones, documentation, etc. Se casará y tendrá hijos, y decidirá si desea esconderse en la esquina de esa gran empresa con el gran package de seguro de salud con el trabajo aburrido y disfrute de sus hijos en lugar de ser el progtwigdor más destacado en la pequeña empresa.

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 que podrías evitar o probar por tu count (tal vez te das count de que no tienes que tocar la olla caliente para descubrir que te quemará). La mayoría habrá visto al less una o dos de estas modas ir y venir, y en particular qué tan mal fueron quemadas, y qué hicieron para recuperarse de ella. Ellos conocen muchas maneras diferentes de probar cosas, y los nombres de los styles de testing que también han venido y se han ido. Lo que funciona, lo que no funciona. Dónde está el riesgo y cómo evitar perder el time en una tangente. A medida que maduras y te conviertes en el viejo timer, pásalo. Pague por lo que aprendió tratando de enseñar a los que lo siguen. Recuerde enseñarles CÓMO pescar, no les dé pescado. Y a veces tienes que dejar que fallen antes de que tengan éxito, evitando que se quemen demasiado.

Lo que realmente quería decir aquí es que ahora nos encontramos en una situación excepcional en la que podemos presenciar una evolución de un universo paralelo (y quizás influir en él). Sí, la informática es una ciencia joven en comparación con la física. Pero al mismo time 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 progtwigción en el mundo del hardware ciertamente no son nuevos, pero no han evolucionado tan rápido como el mundo del software. El software tuvo algunas décadas de ventaja. Hardware siempre ha pensado en los ingenieros de software como ciudadanos de segunda class. Nuestro trabajo es fácil, su trabajo es difícil. (Tenga en count que en realidad soy un ingeniero de hardware y software). Lo interesante es que en este momento todavía están lidiando con lo que consideraríamos problemas elementales o infantiles. ¿Por qué necesitaría usar el control de versiones, soy el único que trabaja en este chip? Su experiencia con gcc u otros comstackdores baratos o IDEs gratuitos no puede compararse con las costosas herramientas que uso, si la compañía considera que usted es lo suficientemente bueno como para usarlo o incluso saber cómo usarlo, le comprarán una copy. Y una larga list de otras excusas. Tuve el placer de aprender tanto vhdl como verilog y ser productivo en ambas dentro de una semana de lo que era casi un reto de un ingeniero de hardware (a pesar de que mi diploma dice ingeniero eléctrico, mi título de trabajo es ingeniero de software). Quería aprender estos idiomas, cuando las herramientas estaban disponibles para mí, me quedaba en la oficina en la noche y aprendía por mí mismo. A partir de ese momento, ese ingeniero, en particular, se dio count de que lo que estaba diciendo era cierto, los lenguajes son solo syntax, los fundamentos de progtwigción son los mismos, las herramientas hacen lo mismo. Sus manzanas y manzanas no son manzanas ni naranjas.

En general, sigue siendo difícil enviar el post de que una de estas dos industrias paralelas tiene mucha más experiencia en lenguajes, hábitos de progtwigción, control de fonts, testings, herramientas, entornos de progtwigción, etc. que la otra. El problema que estoy tratando de resolver es tomar los layouts de hardware a medida que se desarrollan, crear simuladores funcionales asequibles que podamos unir con una simulación (máquina virtual) del procesador para que podamos comenzar a probar el hardware y desarrollar la testing y software entregable mucho antes de que vayamos al silicio. No, no hay nada "nuevo" en esto, pero no tenemos un mecanismo para get el último código, rastrear los cambios en el código para ver dónde necesitamos enfocar nuestro time. No hay ningún mecanismo para rastrear la documentation que define la interfaz del usuario (progtwigción) con el hardware. La única copy dorada está en la bandeja de input de alguien en formatting binary y solo cambia cuando, bueno, no tienes que leer el verilog para saber qué está pasando. Espera, ese verilog es la edad? ¿Ese error que pasé toda la semana contigo descubrió hace tres semanas y lo arreglaron? Entonces, volamos a un lugar de vacaciones y celebramos durante seis meses esperando que la gente del hardware termine su tarea y se la tiremos a la panetworking, o aprovechamos esta oportunidad para tratar de ser pacientes y optimistas y enseñarles que hay methods de sentido común que no son tan intrusivos que les permiten hacer su trabajo, hacer una copy de security de su trabajo y compartir sus cosas para su revisión por pares …

Recuerde que los ingenieros de hardware abandonaron la universidad con una caja de nuevas herramientas shinys como usted. Aprendió 17 diferentes lenguajes de progtwigción, de los cuales solo puede usar uno, el rest de los idiomas que utilizará en su carrera se deviseán después de que deje la universidad. Cuando salieron de la universidad pueden decir lo que saben sobre el cálculo y la teoría de la relatividad, cuántos electrones hay en cada uno de los elementos y calcular la carga alnetworkingedor de una superficie gaussiana. Pero la mayor parte de su carrera profesional es uno, cero y, o no (hey, tenemos todo en común, todo lo que realmente necesita saber sobre computadoras, uno, cero y, o no, ingeniero de hardware o software). De acuerdo con las leyes fundamentales de la física, el cálculo y los electrones no van a cambiar tan rápido como lo hacen los lenguajes de progtwigción. Pero los fundamentos de la progtwigción son los mismos en todos los idiomas y continuarán en el futuro. ¿Saliste de la universidad sabiendo eso o te fuiste pensando que Java es diferente y mejor que C ++ porque esto y aquello y el otro?

Como cualquier otro negocio, el trabajo de las universidades es mantenerse rentable. Deben contratar a los académicos correctos para que aporten tanto los estudiantes correctos como los dólares de investigación adecuados y los types de investigación adecuados para que la universidad sea rentable. Tienen que ofrecer las classs correctas para atraer a los estudiantes correctos y producir los graduados adecuados para que, a medida que pasen las décadas, los empleadores cercanos a la universidad y, con suerte, muy lejos reconozcan que esta universidad produce empleados productivos y rentables. (sí, y algunas veces debe atraer a los atletas correctos en el deporte adecuado para get la cantidad correcta de time de televisión y la cantidad correcta de reconocimiento de nombre e ingresos deportivos). Algunas universidades enseñarán C ++ y Java, otras nunca lo harán. Algunos deviseán CMM, otros enseñarán Agile y otros no. Si la universidad tiene algún valor, hay algo allí para que aprendas. 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 varias forms de herramientas en su caja de herramientas. Sal de la universidad y consigue un trabajo. Si tu caja de herramientas apesta, tal vez encuentres otra universidad y nunca menciones la primera. Si es una caja de herramientas aceptable, use esas herramientas y construya algunas nuevas en su propio time. Si es una caja de herramientas bastante buena, diga cosas buenas de esa universidad y de los buenos académicos que aprendió de esto y de lo que le devolvió a la escuela por lo que le dieron. Aunque no haya obtenido todas las herramientas posibles en el catálogo universal de herramientas universitarias, se irá con un cierto subset. Incluso si no te gradúas …

oh dios, no me hagas comenzar

una vez tuve al decano de cs en una universidad de buena reputación que me decía que la progtwigción orientada a objects era solo una 'moda', así que no ofrecían ninguna class de fantasías pasajeras como C ++

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

La respuesta más simple es que estás estudiando ciencias de la computación y las cosas que enumeró 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 control de versiones, o cómo escribir testings efectivas de unidades … que le enseñarían un oficio , a saber, (buen) desarrollo de software.

Bueno, la cosa 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 lo mucho que se habla en Internet, no se usa en todas partes, por lo que enseñarlo a toda una class de estudiantes solo podría beneficiar a unas pocas personas que aterrizaron en tiendas ágiles.

Sin embargo, el control de versiones es algo que hoy en día es inexcusable. Es algo que todo el mundo necesita entender es una herramienta que es casi tan útil como un comstackdor y CVS ha existido por más de 20 años. Los conceptos al less deben ser entendidos por cualquier progtwigdor que abandone una universidad. Afortunadamente, si haces algún trabajo en grupo en la universidad, puedes tener la suerte de aterrizar con alguien que ya conozca 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 testings unitarias también son casi inexcusables. Lo único que diría es que el libro todavía está en desarrollo impulsado por testings y que el 100% de cobertura de código siempre puede ser más problemático de lo que vale. Pero las testings unitarias son extremadamente valiosas y deberían includese en un curso de ingeniería de software. Me imagino que algo de esto está llegando a algunas universidades, pero aún no las ha alcanzado a todas.

¿Por qué no, de hecho? Mi experiencia al get mi CS fue casi la misma. La razón es que las personas que enseñan progtwigción no progtwign, hasta donde sé. No es necesario enseñar eso para la acnetworkingitación, los profesores no están familiarizados con él, y los estudiantes nunca desarrollan proyectos de ninguna importancia como parte de su trabajo de curso. No hay motivación para enseñar progtwigción realmente, en lugar de enseñar teoría CS o syntax Java.

Los informáticos piensan que son matemáticos y no ingenieros, por lo que prefieren enseñar las partes matemáticas que las piezas de ingeniería. Las testings, el control de versiones y la documentation no son modas pasajeras más de lo que lo son en cualquier otra disciplina de ingeniería.

Depende de la universidad. Me gradué en 2003, de una universidad australiana. En ese momento aprendimos UML, Unit Testing, XP (y otras metodologías Agile), junto con todas las cosas formales como Z, Algorithms and Data Structures, Operating Systems, etc.

Sin embargo, no cubrieron las testings unitarias con gran detalle, sino que simplemente pagaron el service de pase por una conferencia. Hubiera sido fantástico haber aprendido a escribir testings unitarias efectivas, en lugar de simplemente "¿Qué es una testing de unidad?".

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

Estoy muy de acuerdo con lo que dijo Glyph también. CS es un campo tan inmaduro, realmente solo en los últimos 50 años, que no sabemos lo que deberíamos aprender y lo que es solo una moda pasajera. Dale 150 años, entonces las cosas podrían estarse asentando más. La cantidad de proyectos fallidos en el mundo real hace que sea obvio que se trata de una industria inmadura. ¡Imagínese si el 80% de los proyectos de construcción fallaran!

Todo eso se puede cubrir fácilmente (superficialmente) en una sola class sobre prácticas de desarrollo de software. No forma parte de la mayoría de los currículos de CS, porque de eso no se trata CS, aunque sí creo que es útil cierta cobertura de eso. Mi escuela tenía tal class; no cubría el control de versiones, pero cubría UML, recostackción de requisitos, metodologías de desarrollo (varios ágiles y en cascada), testings unitarias, testings de integración, etc., y requería que trabajáramos en equipos de 4-5 para desarrollar un proyecto (una estafa bastante simple de Clue en Java). Si sentía la necesidad de más classs de Ingeniería de Software, estaban disponibles como optativas.

A pesar de que nunca mencioné el control de versiones una vez en ninguna class que tomé, la mayoría de mis amigos lo usaban para proyectos personales, asignaciones de classs, etc., por lo que no es como si no estuviéramos expuestos a él. Las personas que no lo recogieron por su count se vieron obligadas a usarlo por un compañero de class en el curso de una asignación 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 count. El control de versiones es una herramienta y bastante fácil de usar. Úselo un poco, lea algunos tutoriales en la web y ya está todo listo. Si necesitas conferencias y asignaciones de tareas para averiguar cómo sacar algo de SVN, vas a tener muchos problemas con las cosas que en realidad SON difíciles.

Recuerde que hay muchas maneras de aprender cosas en la universidad fuera de las classs; aprovecha eso. Estás pagando mucho para asistir a las classs y usar las instalaciones, así que ordeña todo lo que vales e ir a reuniones de LUG y ACM, participa en equipos de proyectos (siempre hay algunos ME que crean un robot que necesitan un progtwigdor) u obtén un trabajo administrando el server del departamento de Humanidades. Traslade una computadora desde el muelle de carga del edificio de Ingeniería de Materiales, descargue una ISO de Linux con su rápida connection a internet en el dormitorio y juegue.

Creo que el problema es que las universidades no sienten que deben enseñarle a ser un profesional, sino que se centran en el lado académico de la progtwigción. Pensé que al less debería haber references a los últimos methods y técnicas que se utilizan en la industria, ya que también son de interés académico.

En nuestro curso, nos enseñaron Proceso de software personal, que abarcaba cosas como el time de grabación en proyectos, buenos comentarios, etc., pero no mencionaba los fundamentos profesionales como el control de versiones.

Aprendí a todos aquellos en la Universidad. Tal vez depende de los cursos que elija? Mis cursos fueron muy diversos (layout de software, layout de interfaz de usuario, comercio electrónico, inteligencia artificial, functional programming, etc.). Software Design tuvo exposition a patrones de layout y testings unitarias (un gran proyecto que involucró varias cosas). Diseño de UI … éramos un grupo de tres personas trabajando en un proyecto. No podríamos hacer nada sin el control de la versión, así que lo conseguimos. Y el desarrollo ágil fue algo de lo que nuestros profesores nos hablaron continuamente, pero lo dejaron en manos de cada grupo para usarlo.

Encuentro que muchos estudiantes universitarios tomaron cursos o cursos "fáciles" que les darían un GPA alto. Otros se enfocan 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 en lo que están interesados ​​… lo cual es bueno, excepto que tienden a no diversificar sus cursos.

Para responder por qué estas cosas no son lo primero que se enseña: los progtwigs de pregrado generalmente te entrenan para convertirte en un estudiante de máster. Solo cuando comienzas a elegir tus propios cursos (lo que generalmente ocurre en años posteriores) puedes elegir aprender sobre cosas que se usan fuera de la academia. Es por eso que se enfocan en algorithms, estructuras de datos, presentando problemas sin resolver, etc.

Personalmente creo que está bien que ellos estén haciendo esto. La progtwigción no es tan fácil como muchos de nosotros lo hacen parecer; muchas personas luchan con eso. Prefiero que estas personas primero entiendan cómo funciona un bucle for antes de descubrir el monstruo que Perforce es.

No enseñan estos 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 formarlo en una carrera. El concepto completo de QA no tiene nada que ver con la informática más allá de pasar una testing matemática. Además, las prácticas de QA y los flujos de trabajo de desarrollo difieren enormemente de una casa de desarrollo a la siguiente, por lo que enseñarlos en la escuela es una pérdida de time y dinero.

Aprendí todo eso en primer año, con la exception del desarrollo ágil.

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

En cuanto a CS Education en general, básicamente le pedimos a los profesores que enseñen tanto (idiomas de todos los gustos, estructuras de datos, eficiencias de time de ejecución, cómo funcionan realmente las cosas en el nivel de bits). Me gustaría plantear la pregunta: ¿por qué los niños no se encargan de aprender más acerca de la ingeniería de software?

Has nombrado 3, algunos de los cuales no creo que sean tan importantes para entender los sistemas informáticos (por ejemplo, control de versiones). Estas cosas son parte de un trabajo, y puede convertirse en un buen progtwigdor / informático sin necesidad de saberlo.

de manera similar para las testings unitarias, ¿por qué elegir testings unitarias? Sin duda, la testing de usabilidad, la testing del sistema, la testing de aceptación del usuario y la testing de aceptación de fábrica son más importantes. Bueno, lo son a less que considere que su trabajo se completa una vez que el código se envía al departamento de mantenimiento 🙂

Piense en los otros conceptos que uso a diario, que serían de poca utilidad para un estudiante que llega a un acuerdo con los fundamentos del software y los sistemas informáticos:

  • buenas prácticas de comentarios
  • cumplimiento de normas (no solo internacionales, sino estándares de encoding por equipos)
  • documentation
  • control de cambios (no necesariamente lo mismo que control de versiones que trata de almacenar diferencias, esto es más acerca de qué y por qué cambió algo)
  • desarrollo de usabilidad

Lo anterior son todas las "habilidades blandas" que no necesitas escribir un buen código.

Sin embargo, si te faltan las habilidades "duras", como las estructuras de datos y los algorithms, entonces tus posibilidades de escribir un buen código son casi imposibles.

Al igual que los estudiantes, cada universidad es diferente. Algunas universidades, o más exactamente, algunos profesores son resistentes al cambio o son flojos. Afortunadamente la mayoría no lo son. Las teorías, conceptos, historia, etc. son importantes y vitales para cualquier plan de estudios de CS. Pero también lo está preparando para su entorno de trabajo. No es sorprendente que las universidades comunitarias de mi área ofrezcan cursos de CS muy actuales y aplicables. No tanto con la universidad grande, establecida y prestigiosa.

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

Creo que los buenos progtwigs de CS deben enseñar los fundamentos que servirán como base para toda la educación de progtwigción futura. Las metodologías de desarrollo como Agile y las herramientas de control de versiones son como modas; ellos vienen y van Además, tienden a ser utilizados 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 estás diciendo. Recientemente comencé a trabajar en el mundo del desarrollo de software y ya comencé a aprender sobre el desarrollo ágil, algo que nunca me enseñaron en la universidad.

El hecho es que los profesores universitarios no se mantienen actualizados con las técnicas de desarrollo más nuevas tanto como deberían. También pueden sentir que hay otras cosas más importantes en su plan de estudios.

Los profesores de la universidad no saben cómo escribir software, solo lo investigan, lo enseñan y, ocasionalmente, descifran un código que solo debe funcionar hasta que se publique el documento.

Es solo por personas como Titus que estamos recibiendo académicos que realmente entienden la progtwigción. Lee sus comentarios sobre ese tema aquí.

Cuando era estudiante, leía libros en la biblioteca sobre Extreme Programming, y lo discutíamos brevemente en classs: las mismas classs que exigían que cumpliéramos con el "Modelo de cascada" de desarrollo de software, donde la "compilation" es un paso de su desarrollo. propio.

Todo lo mejor en tu carrera, espero que te gradúes, es bueno tener cartas después de tu nombre. 🙂

Las tres cosas que menciona (testings unitarias, control de versiones, desarrollo ágil) se enseñan hasta cierto punto en el progtwig de Ciencias de la Computación de la Universidad de Groningen. Si eso es algo 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 progtwig de CS antes de cambiar de especialización, y en mi experiencia como pasante en una gran compañía de software. Las testings unitarias no se enseñan porque la mayoría de los progtwigs que tiene que crear no son lo suficientemente grandes como para necesitar testings automatizadas, se garantiza un set específico de inputs para que se pueda probar todo manualmente. Enseñarle cómo automatizar las testings también puede interferir con la sorting de su proyecto, ya que la mayoría de los proyectos se clasifican con scripts que ejecutan testings automatizadas, con un vistazo rápido al código para asegurarse de que no tenga int foo1; int foo2; y usa la sangría apropiada.

No sé por qué el control de versiones no se enseñaría, pero parte del mismo es probablemente el tamaño de los proyectos. Nunca tuve ningún 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 tardé todo un semestre para escribir. Supongo que creen que lo enseñarás a ti mismo si lo necesitas. Todos los proyectos grupales que tenía se suponían que eran proyectos de progtwigción de pares, y ¿por qué utilizar 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 vuelva a ser lo mismo con el tamaño del progtwig. Si bien el desarrollo adjile es común con el nuevo software que se ejecuta en computadoras personales y pequeños serveres, generalmente no se usa en sistemas como los mainframes de IBM o en dominios problemáticos como el bancario o el médico, donde la documentation es el rey. También probablemente tiene que ver con el hecho de que el desarrollo adgile no fue hace unos 20 años cuando se capacitó a muchos profesores.

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

En informática, eso significa algorithms, estructuras de datos, teoría de la computación, teoría del comstackdor, etc. Lo que enumera no se trata tanto de cómo progtwigr, cómo resolver problemas, etc. Se trata de la práctica de la progtwigción (que, dicho sea de paso, es un libro increíble para cualquiera en la universidad con la intención de trabajar como progtwigdor). Ahora, gran parte de esto no se utilizará en una position mono de código de nivel de input, lo que hace que algunas personas piensen que no es útil. Estoy en desacuerdo. Creo que puede ser extremadamente útil. Sin embargo, no significa que después de get su título de CS, sepa todo lo que necesitará para trabajar como progtwigdor.

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

Creo que depende de qué tipo de progtwig de Ciencias de la Computación se encuentre allí, cuáles son los que apuntan al lado de Investigación y Ciencia, y hay algunos que se orientan hacia el lado de la Implementación. Rechacé especialmente contra ciertas escuelas que solo tenían profesores que se quedaron en el mundo académico. Si no tienes profesores que no hayan "usado" lo que enseñan, todo está en su cabeza, literalmente.

Enchufe: Después de haber obtenido un BS en Comp Sci y un MS en Soft Eng en la Universidad DePaul, los profesores / profesores que me enseñaban a time parcial me enseñaron en su mayor parte, lo cual estaba bien porque prefería que vinieran con una anécdota del día anterior. y relacionarlo con la class. Además, al tratarse de una escuela mayoritariamente conmutada / a time parcial, la mayoría de los estudiantes tienen empleos en el uso de lo que están aprendiendo.

El process de aprendizaje todavía comienza con toda la teoría, pero normalmente nos preguntan "¿cuántos de ustedes realmente usan esto en su trabajo?" y la respuesta típica es "lo usamos pero de una manera simplificada o simplificada" y luego entramos en los escenarios prácticos del mundo real.

Durante mi testing de unidad de esqueuerización siempre estuvo presente. A pesar de que comienzan con Java, nos hicieron usar ANT y JUnit para todos los proyectos. Lo cual fue un buen comienzo para la configuration de compilation y las testings unitarias.

Y Extreme Programing se incluyó en aproximadamente 3 o 4 de las classs que tomé. Recuerdo que todos comenzaron con los 12 aspectos diferentes, desde la progtwigción de pares hasta la testing unitaria (ver arriba). Y ahora parece que el foco está en ágil.

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

Las testings unitarias y el control de versiones se impartieron en cursos de informática de segundo año en los que fui a la universidad. Las testings unitarias cayeron bajo la parte de testing que también incluyó diferencias entre la caja blanca y negra y una buena parte de las marcas en las asignaciones de progtwigción de 3er año fueron para un buen event handling errores que pueden provenir fácilmente de las testings unitarias.

El desarrollo ágil puede ser bastante difícil de enseñar en un entorno académico, creo. 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 de la academia, por ejemplo, en el tercer año hago todo el extraño error casos y casi paso una tarea en la que nunca toqué el corazón de lo que la tarea intentó enseñarme sobre semáforos.

Además, ¿cuánto time ha sido ágil y qué forma de ágil quiso decir? Hay muchas implementaciones diferentes de lo que he visto.

No creo que la progtwigción ágil sea una moda, pero al mismo time sería difícil pensar en la forma en que un profesor podría darte proyectos que te permitan aprenderlo. A less que te hayan dado el proyecto A, proyecto B ampliar en a. El problema es el time y el scope. En un curso de 4 meses sería difícil.

Los methods de control de versiones y testings unitarias cambian constantemente y dependen del idioma o de la persona que los define.

Las estructuras de datos y los algo son algo en lo que se puede trabajar en una configuration de class. Honestamente también, se toman un poco más de esfuerzo para comprender las testings unitarias y el control de versiones. Trate de recordar que parte de la universidad es enseñarle a usted mismo a aprender. Collage no tiene el mismo mandato. O al less no en la misma medida. EN MI HUMILDE OPINIÓN.