¿Cómo practicar deliberadamente la ingeniería de software? [duplicar]

48

Acabo de terminar de leer este artículo reciente . Es una lectura muy interesante, y hace algunos grandes puntos. El punto que específicamente me llamó la atención fue este:

  

La diferencia estaba en cómo pasaron este tiempo [igual]. Los jugadores de elite   Estaban gastando casi tres veces más horas que los jugadores promedio.   sobre la práctica deliberada - el trabajo incómodo y metódico de   estirando tu habilidad.

Este artículo (si no quieres leerlo) trata sobre los violinistas. Por supuesto, siendo un ingeniero de software, mi mente se dirigió hacia la capacidad del software. Por supuesto, hay algunos individuos con talento muy natural por ahí, pero una y otra vez, son esas personas las que amplían sus habilidades a través de la práctica deliberada que realmente se vuelven excepcionales en su oficio.

Mi pregunta es: ¿cómo se haría para practicar las "escalas" de la ingeniería de software y la informática? Cuando practique el piano, pasaré más tiempo en escalas y menos en una canción divertida. ¿Cómo puedo hacer lo mismo en el desarrollo de software?

Para evitar las respuestas tempranas, no creo que "trabajar en un proyecto de código abierto" y respuestas similares sea realmente correcto. Claro ... eso puede mejorar tus habilidades, pero podrías fácilmente quedarte atascado enfocándote en algo que no es importante para tu oficio en general. Puede convertirse en el equivalente a aprender "Twinkle Twinkle Little Star" y nunca poder jugar a Chopin.

Otra vez, pregunto: ¿cómo sugeriría que alguien practique deliberadamente la ingeniería de software?

    
pregunta JasCav 12.11.2011 - 22:21

6 respuestas

24

Hay una diferencia entre lo que hacemos como ingenieros de software y lo que haría un violinista (o cualquier otra cosa que requiera práctica física). Un violinista pasa horas practicando metódicamente porque está enseñando a su cerebro patrones muy específicos de cómo interactuar con un instrumento.

Practicar ingeniería de software también implica patrones de aprendizaje. Cuantos más proyectos hagas, más aprenderás (con suerte) sobre qué funciona y qué no. No existe una receta estándar para escribir un gran software (es por eso que algunas personas comparan nuestra profesión con un "oficio" en lugar de ciencia pura). Así que mi consejo # 1, escribe el código, luego escribe más código. Y no pienses que si lo que estás trabajando es divertido, no te está enseñando mucho. Yo digo que escoja algo que sea divertido; mantendrá su interés por más tiempo y podrá disfrutar mucho más.

No tienes que unirte a un proyecto de código abierto si no quieres. Solo establece una meta para ti, algo te interesará y simplemente comienza a codificar. Ni siquiera necesita terminarlo, así que no se desilusione si a mitad del proyecto decide dejarlo e ir a otra cosa. Lo más importante es que al alejarse de ese proyecto, debe alejarse con mejores habilidades y más conocimiento de la tecnología que utilizó.

Consejo # 2, lea Pragmatic Programmer . La principal ventaja de ese libro es que, al mismo tiempo que piensa en cómo escribir una pieza de software, de vez en cuando debe retroceder y revisar su proceso para pensar en escribir una pieza de software. Cada vez que trabaje, no lo guarde en un estante y muévase, sino que eche un vistazo y piense en formas en que podría haberlo hecho mejor. No tienes que ir y realmente rehacerlo, pero al pensarlo, ejercitarás tu cerebro para reconocer los patrones que mencioné en la introducción.

Consejo # 3, hable con otras personas que sienten pasión por escribir código. Escucha lo que han hecho y cómo se acercaron a las cosas. Y explícales lo que estás haciendo. Tengo pocos amigos en el trabajo y, periódicamente, me limitaba a entrar en su cubo y dibujar rápidamente el diseño del software en el que estoy trabajando. Algunas veces solo asienten, pero otras veces, podrían decir, bueno, si mueve este cuadro aquí y se deshace de esta clase, podría ahorrarse 2 días de trabajo y obtener ventajas A, B y C.

Consejo # 4, después de haber realizado algunos proyectos y encontrado algunos patrones. Regrese y lea libros como el famoso libro GoF . Si ya ha trabajado, a) reconocerá algunas de las cosas de las que hablan los autores yb) descubrirá diferentes formas en que podría haber abordado sus proyectos.

Consejo # 5, siempre sigue leyendo y desafiándote a ti mismo. Nunca te pongas en el modo que ahora conozco la tecnología X, por lo tanto soy un experto. No importa cuánto creas que hayas aprendido, solo recuerda, hay infinitamente más para que puedas absorber, por lo que, en general, aún no sabes mucho. Sigue leyendo blogs; aprender un nuevo lenguaje. Por ejemplo, he estado leyendo sobre F # y la programación funcional, aunque principalmente programo en C ++ y he comenzado a aplicar conceptos funcionales a mi código orientado a objetos. En algunos lugares, esto simplificó enormemente el uso de varios subprocesos y la sincronización de datos.

    
respondido por el DXM 12.11.2011 - 22:43
8

Nada de lo anterior es ingeniería de software. Solo se trata de una programación aleatoria.

La Ingeniería de Software (SE) es una disciplina de ingeniería relacionada con un enfoque sistemático, riguroso y disciplinado para el diseño, desarrollo, operación y mantenimiento del software, y el estudio de estos enfoques; Es decir, la aplicación de la ingeniería al software.

En particular, el software se puede diseñar cuando se aplican técnicas de ingeniería. Para aprender tales técnicas, lo mejor es estudiar un Master de SE relevante. Cuando te enseñas a ti mismo, puedes aprender sobre programación, pero no puedo imaginar que aprendas ingeniería por tu cuenta.

Ejemplo: El programador viene y comienza a escribir código, optimizar código, etc. (todo lo que le importa a un programador es código y nada más que código). Los proyectos complejos a menudo llegan tarde, el presupuesto se excede hasta unos pocos órdenes de magnitud y el software no resuelve bien los requisitos. Esto se conoce como crisis de software. La respuesta a eso es la disciplina SE.

SE llega y quiere entender el dominio del problema como lo primero. Se aplica un enfoque de ingeniería, en particular, Ingeniería de requisitos (RE) (obtención de requisitos - > análisis de requisitos - > especificación de requisitos - > validación de requisitos).

El resultado de RE suele ser un conjunto de modelos, como el modelo contextual, el modelo de comportamiento y el modelo de proceso empresarial. A partir de estos modelos, SE entiende el problema comercial y diseña una solución de software.

El diseño normalmente significa que SE traduce los modelos de requisitos en una arquitectura de sistema basada en componentes y luego diseña los componentes de cada componente individualmente. Esto da como resultado una especificación determinada de límites de componentes, interfaces de componentes y clases para componer componentes.

El siguiente paso es alguien que llega a estas interfaces (generalmente generadas automáticamente) y crea su implementación. Esa persona puede ser un programador. Finalmente, SE sigue con la validación del software donde todo se prueba en comparación con el diseño y los requisitos originales.

En SE, los proyectos suelen tener un plan de proyecto que permite a los ingenieros planificar, controlar y monitorear proyectos. En particular, el software se diseña a tiempo, dentro del presupuesto, según las especificaciones.

Durante la fase de implementación del software, se produce documentación para cada artefacto y se generan muchos elementos de configuración (CI). Estos deben ser gestionados de alguna manera. Por lo general, en SE, hay un repositorio de Administración de configuración de software (SCM) y Administración de cambios. Otra parte de SE es Software Process (SP), es decir, RUP, Scrum, DSDM, Crystal, Waterfall, ...

SP debe documentarse y seguirse rigurosamente como en la documentación, sin excepción, para que los resultados sean siempre reproducibles. (ISO 9000). Esto se refiere a la calidad del software.

Otro tema de SE es Medición y estimación de software, que le permite medir la eficiencia de su SP, el rendimiento del equipo, el tamaño estimado del proyecto (LOC - Líneas de código), es decir, COCOMO, la entrega estimada del proyecto (días hábiles) y similares.

Todavía hay mucho más en SE de lo que describe esta breve respuesta. Aplicar enfoques de SE en lugar de solo escribir código es la forma en que practicas SE.

Debido a que SE sigue siendo un campo emergente, sucede que los no ingenieros se llaman a sí mismos ingenieros. A menos que estén aplicando enfoques de ingeniería, no son más que programadores.

Para obtener más información, consulte Ingeniería de software por Ian Sommerville y www.ieee.org / www.computer.org. En estos recursos, la SE es la disciplina de la ingeniería. En Stack Overflow y en muchas empresas, desafortunadamente, toman prestado el término SE y lo usan como otro nombre para la programación.

    
respondido por el user42242 04.11.2012 - 02:02
6

Dos cosas que vienen a la mente son Project Euler y Google AI Challenge . Especialmente si lo hace en un idioma que no sea el idioma de su trabajo diario, este tipo de problemas están lo suficientemente restringidos para ampliar sus habilidades, pero también lo suficientemente simples como para tener enfoques claros.

He estado haciendo el desafío de la IA este año, y lo que más me fascina es que el problema es lo suficientemente simple como para ser resuelto con algoritmos básicos, pero alcanzará el límite de tiempo por turno si lo hace. El camino ingenuo. Debe comprender no solo la parte básica de los conceptos básicos, sino también las razones subyacentes detrás de ellos para que funcione dentro de las restricciones de tiempo.

    
respondido por el Karl Bielefeldt 12.11.2011 - 22:42
3

Después de escribir un bloque de código que funciona y pasa una prueba, pregúntese "¿puede este código ser mejor?". En este contexto, mejor no significa necesariamente más rápido o más eficiente, aunque eso es parte de ello. La claridad del código también es importante: puede alguien mirarlo y entender lo que está haciendo. Pregúntese si enviaría ese código a un posible empleador como representante de su mejor trabajo.

No solo hagas esto por tu propio código personal. Visite sitios como este y responda preguntas que requieran que proporcione un ejemplo de trabajo. Escribir un código que algún día pueda ser copiado y usado por personas que solo están aprendiendo puede ser un poderoso motivador. Asegúrate de hacer esto con tu nombre real para no tener más remedio que reclamarlo como propio.

Otra forma de hacer esto, y veo que lo eres, es escribir un blog que requiera que proporciones un código. Nuevamente, esto te obliga a escribir un código que estará en el ojo público, abierto a la crítica.

Cuando escribes un código que será leído y analizado por otros, creo que es el equivalente a practicar escalas.

    
respondido por el Bryan Oakley 12.11.2011 - 22:32
3

Un enfoque podría ser tomar un proyecto no trivial relativamente (por ejemplo, más de 1000 líneas) y trasladarlo a otros idiomas. Encontrará que esto resalta muchas suposiciones hechas por su idioma.

Otro enfoque podría ser determinar un proyecto más grande, al menos 10KLoC según su estimación, y comenzar a escribirlo, escribirlo rápidamente. Sigue escribiéndolo, y luego, una vez cumplida su meta, mantenlo. Esto le enseñará acerca de cómo administrar las bases de código que mutan con el tiempo.

Sólo algunos pensamientos.

    
respondido por el Paul Nathan 12.11.2011 - 22:38
1

¿Cómo practica un escritor escribir libros?

Bien, lo que quise decir es que escribir código no es como dominar un instrumento musical. El rol de un programador es más un escritor o un compositor que trata de encontrar el acorde correcto. Así que deberías preguntarte cómo estos profesionales practican su oficio. En realidad, creo que nuestra profesión tiene más en común con aquellos que con otras disciplinas de ingeniería.

Un escritor practica la escritura escribiendo libros y un compositor practica la composición al componer música, por lo que un programador debe practicar la programación por programación.

    
respondido por el onemasse 13.11.2011 - 09:36

Lea otras preguntas en las etiquetas