Consejos Programación

Archivado
Buenas, vengo aquí a escribir mi post anual sobre el mismo tema :-|

Escribo aquí pues es donde mayor concentración de programadores de calidad hay, aunque corro el riesgo a que ferdy me vuelva a dar de palos. (/me hides)

Bueno al grano, llevo 4 años en el mundo de la programación y realmente podría decir que no se hace ni la O con un canuto. Siento que este post sea un tocho, pero quiero resumiros un poco mi experiencia :)

Me recomendaron C# (con Vs.NET) ya que me dijeron que era la polla y tal. Como con el manual que tenia no me enteraba de nada, cogí un un libro de C, aprendí lo que son funciones, bucles, etc. Luego ya vi que entendía el libro de C# (aunque me deje muchas cosas en el tintero porque no las entendía, tipo atributos o delegates) y me puse a leerlo. Yo era un ignorante del mundo de la programación, asi que abría el Vs.NET, y escribía tonteriillas usando winforms, nada serio ni nada grande, la tipica interfaz de un solo form que te ayudaba con cualquier cosilla. No tenia realmente miedo a nada, tiraba codigo ahi por tirar.

Luego me pasé a linux (hace 3 años), pues por inercia pasé a Mono, aunque en ese momento mono no estaba muy allá y la documentación era casi nula, y yo como buen novato, pues estaba un poco estancadete sin documentación. Así que aunque hice cosillas, no duré mucho.

Aquí fue ya cuando conocí python (que en un principio me chocó esto de los lenguajes dinámicos) y lo toqué poco, toqué un poco más de C para hacer algoritmos básiquillos. Aqui fue cuando ya empece a no saber qué quería, tocaba un poco de algun lenguaje pero no me quedaba contento.

Elegí python finalmente, pero empecé a leer y a leer y a leer y a leer, y a leer tanto que ahora me encuentro que se de patrones de diseño y muchas más cosas, pero no practico nada. Entonces pues se muchas cosas pero no se como aplicarlas.

La verdad es que programo bastante poquito, creo medio conocer la causa, pero quiero creer lo contrario. Vereis, creo que prefiero un lenguaje algo más estricto que python, tipado estatico... vamos algo como C#, que a mi forma de ver, es un lenguaje bastante bonito. C++ tambien está bien, pero queda descartado ya que a mi me dificultaría más el aprendizaje. No es que me disguste python, pero como lenguaje prefiero otros.

En este momento pensareis, por qué sigues usandolo? Tiene una comunidad enoooorme, casi todo lo que sale para linux (sobre todo gnome) está hecho en python, y eso es algo que me encanta, también tiene librerías para todo. En resumen, es un lenguaje idóneo para lo que quiero programar.

C# (con mono) sin embargo, no tiene tanta comunidad (o no he visto nada realmente), apenas tiene librerías y no veo tampoco mucho software que use mono, y eso ya me gusta menos, ya que pienso que la ayuda siempre viene bien para ir aprendiendo.

Por qué no simplemente programo más y ya? Mi verdadero problema ahora mismo es que no veo la forma de "atacar" algo más grande de lo que acostumbro, yo me lio a tirar código por aquí y por allá, luego me doy cuenta que no vendría mal una variable por aquí, un metodo por acá y me encuentro con codigo que no lo entiende ni dios y es absolutamente malo. O sea, no sabría estructurar algo más grande que un Hello World. Con algoritmos no tengo problema, pero si no se "conectar" varios algoritmos entre si y varias clases entre si, pues no hago nada.

Bueno, eso es todo, no sé como continuar o si deberia hacer algunos cambios.

Gracias por leerme, y ferdy, guaarda el palo, que te veo con las intenciones asesinas :P

EDITO: Se me olvidaba algo importante, estoy haciendo el modulo DAI (Desarrollo de aplicaciones informáticas), aqui damos Java, pero la verdad es que preferiria mucho antes C# o Python, y por otro lado por ahora no he aprendido nada, es escribir programas estúpidos que no hacen nada, y de eso ya se.

EDITO2: Bah, escribo un tochaco y no lo que queria preguntar en un principio, y es que creo que quiero ir demasiado rapido y aprender de forma muy rapida, y eso tambien me está frenando, que pensais?
Si de verdad te quieres divertir, métete de lleno en los lenguajes funcionales, por ejemplo, Lisp o ML. Na, es coña.

Proponte hacer un programa más gordo que te obligue a organizarte, en el lenguaje que prefieras, será por lenguajes.
Hola arch-man :P

Con algo pequeño 100-300~ lineas, pues ya me sale fatal y en forma de spaguetthi, asi que algo más gordo pues no quiero ni mirar.

A ver si encuentro algun proyectillo facil, pero tampoco se si tendré nivel :P

Gracias.
Lo que necesitas es un poco de paciencia a la hora de afrontar un programa, supongo. Llevo varios años programando pero la verdad es que mi situación ha sido parecida hasta ahora...cogía un poco de aquí y de allá, de este lenguaje y de otro, que si vb, que si pascal, pero al final no sabía más que hacer copy pastes de ejemplos y de hacer algoritmos.
La verdad es que meterme en la carrera que me he metido me ha ayudado, empezando desde lo más bajo (ensamblador) pasando por C (profundizando bastante en él) y ahora dando conceptos acerca de la POO gracias a java, lo que a la vez me ha permitido asomarme al mundillo de C++ y Qt para el desarrollo de aplicaciones gráficas bajo linux (en esto no llevo más de un par de semanas, pero van saliendo cosas).

Yo no llevo mucho en Linux (a penas unos 8 o 9 meses) pero me da la impresión de que lo que manda aquí es python y C++, usado conjuntamente con las librerías gráficas correspondientes a cada escritorio, generalmente Qt para KDE y gtk para gnome.

Quizá deberías tirar por ahí, pero mejor deja que te aconsejen los expertos (yo desde luego no lo soy).
wolas arch-man.

Si lo que quieres es programar bien, lo que necesitas es ponerte con la Programacion Orientada a Objetos (POO). Te ayudará a estructurar mejor tu codigo, hacerlo mas modulable, mas facil de reutilizar... y te valdrá tanto para c#, c++, java, python y un monton de lenguajes más.

Saludos [bye]
El futuro es la programacion orientada a objetos. (POO)

Yo estoy casi acabando la ingenieria tecnica de informatica de gestion y todo y que no hemos realizado grandes proyectos, me ha ayudado mucho la carrera a comprender que mundillo es este y sobretodo este tipo de programacion. Yo era como tu (sabia hacer algun algoritmo y nada mas, eso si, en la forma de un pastijo)

pero despues de esto gracias a asignaturas como ingenieria del software y estructuras de datos y algoritmos puedo decir que si me dan las especificaciones de las clases de cualquier lenguaje y una brebe introduccion de como se ha de estructurar el lenguaje podria meterme en el.

En tu caso es lo que te han comentado los otros compañeros de EOL. Yo recomendaria hacer una carrera tecnica (aunque sea duro y mientras hagas la carrera, aprendes, aunque asi no te lo parezca). luego ya es cuestion de cada uno el centrarse en un lenguaje concreto (o como dice uno de mis profesores, sed mercenarios, asi no tendreis problemas)

no se si he respondido tu cuestion... [+risas]
Kacique, arch-man es amuchamu, el que predica con la palabra de arch :P

Yo conozco la POO, pero de ahi a aplicarla en algo grande, pues ya no tanto, o sea, practica.

El_RapEro, más o menos es así (en mi opinion), python y c++ es lo más usado en linux, aunque es más usado python a la hora de aplicaciones de escritorio. C++ es un lenguaje fantástico, eso siempre lo digo y siempre lo diré, pero en mi caso creo que me estorbaría más de lo que me ayudaría, ya que tendría que estar más pendiente de como hacer las cosas en vez de simplemente programar.

Quizás me equivoco, o no :P

Un saludo.

EDITO: Shackpack, la carrera no es ahora mismo una opción, estoy cursando un grado superior, y no podría cursar la tecnica hasta terminar esto :)
Fox escribió:EDITO: Shackpack, la carrera no es ahora mismo una opción, estoy cursando un grado superior, y no podría cursar la tecnica hasta terminar esto :)



si estas haciendo ahora la superior ya lo tienes dominado, jejeje, mis compañeros que lo cursaron (el grado superior) se han paseado como aquel que dice por la carrera XD

Y lo de aplicarla es lo que te han dicho, plantearte un diseño del programa. decidir como distribuir las tareas y asignar clases responsables de llevarlas a cabo (has comentado que ya has tocado algo de patrones de diseño, entonces ya lo tienes todo para poderlo llevar a cabo ^_^)

lo mas importante es plantear la aplicacion SIN escribir ni una linea de codigo, este ya vendra a su debido tiempo

Asignate un tiempo a esta tarea y en poco tiempo ya tendras alguna cosilla
lo mas importante es plantear la aplicacion SIN escribir ni una linea de codigo, este ya vendra a su debido tiempo


Si si.... seguro.... he oido que los mejores programas se han hecho sin escribir ni una línea de código. Je.

- ferdy
Ferdy escribió:Si si.... seguro.... he oido que los mejores programas se han hecho sin escribir ni una línea de código. Je.

- ferdy


A ver bruto, no lo tomes al pie de la letra. Obviamente un programa no se hace susurrandole al procesador [sonrisa]

Me estaba refiriendo a la fase del proyecto donde el "equipo" de programacion determina que funcionalidades ha de tener el programa. En ese momento se realiza un estudio y se hacen unos esquemillas muy monos para planificar el proyecto. por lo tanto, en esta fase del proyecto no podras escribir (o no se deberia) escribir ninguna linea de codigo

agur yogur!
La ingeniería del software es como las colonias, está bien para olerla, pero no hay que tragarsela. Y tu pareces haber tragado mucha ingeniería del software.

- ferdy
Ferdy escribió:La ingeniería del software es como las colonias, está bien para olerla, pero no hay que tragarsela. Y tu pareces haber tragado mucha ingeniería del software.

- ferdy


pos un poco >.< este mismo miercoles me examine de "ampliacion de ingenieria del software".

Aun tengo pesadillas

pero si estuviesemos en los mundos de yupie seria lo ideal, lo que como me han comentado algun profesor que si no se sigue asi aparecen churros de programas que luego no hay quien los toque

salut
Fox escribió:Kacique, arch-man es amuchamu, el que predica con la palabra de arch :P

Yo conozco la POO, pero de ahi a aplicarla en algo grande, pues ya no tanto, o sea, practica.


jajajaj no se porque, al dar a responder, el primer mensaje que me salia era el tuyo diciendo hola arch-man, creí que el que preguntaba era un tal arch-man [qmparto]

La POO es muy facil de aplicar tanto en cosas grandes como pequeñas, si no ves los objetos que necesitas por iluminacion divina debes empezar con la ingenieria de software, como te han comentado. Con los Casos de Uso podrás ir viendo las cosas mas claras y de ellos podras sacar una aproximación del modelo de tu proyecto.

bye fox [bye]
Shackpack escribió:A ver bruto, no lo tomes al pie de la letra. Obviamente un programa no se hace susurrandole al procesador [sonrisa]

Me estaba refiriendo a la fase del proyecto donde el "equipo" de programacion determina que funcionalidades ha de tener el programa. En ese momento se realiza un estudio y se hacen unos esquemillas muy monos para planificar el proyecto. por lo tanto, en esta fase del proyecto no podras escribir (o no se deberia) escribir ninguna linea de codigo

agur yogur!

Yo estoy contigo tio, antes mejor tener claro y esquematizado que es lo que vas a programar y luego solo tienes que escribir el código.

(PD: me voy a hacer la práctica de SOB :p )
Yo creo que hay que adoptar un punto medio. Ni hay que ponerse a programar directamente ni hay que realizar un proceso de ingeniería inmenso. Todo en su justa medida, y sobre todo, dependiendo del proyecto. Pero básicamente para mi gusto lo que nunca debe faltar es una recolección y análisis precisos de los requisitos (usease, decir exactamente QUÉ tiene que hacer el programa), un diseño de la arquitectura y de la división en módulos con sus interfaces, y por supuesto, la programación de los módulos. Pero sin exagerar ni montar las miles de actividades, artefactos, diagramas, etc que proponen Proceso Unificado y similares.
En serio, re-leed el hilo, y decidid si lo que habeis dicho tiene algún sentido. El chavalote quiere aprender a programar, y vosotros le decís que empiece definiendo casos de uso, desuso, requisitos, auditoría, ....

Ja ja ja.

El chaval lo que necesita es escribir miles de líneas de código que hagan todo tipo de cosas. Entonces, y solo entonces, sabrá programar y podrá dedicarse a la ingeniería de software (si es que quiere).

Por otro lado:

El futuro es la programacion orientada a objetos. (POO)


¿El futuro? Más bien es el pasado, el GoF fue escrito ya en 1994, hace la friolera de 14 años.

- ferdy
Fox escribió:Buenas, vengo aquí a escribir mi post anual sobre el mismo tema :-|

Cuando he entrado dudaba de si sería un hilo nuevo o un bump. :D


Parece claro que quieres usar C# (realmente no creo que importe realmente el lenguaje que utilices si "conoces" ambos, pero como lo que yo conozco es C# te hablaré sobre eso, intentando no alejarme de la temática del foro). Pero para qué tipo de aplicaciones ¿Web/escritorio? Me ha dado la impresión de que quieres hacer aplicaciones de escritorio para linux, pero estaría bien que lo confirmases para que podamos aconsejarte mejor.

Sobre la comunidad, de mono lo mejor sería que tires de http://www.go-mono.com/monologue/. Creo que también existe mono-hispano. Si realmente te da igual la plataforma y lo que quieres es simplemente aprender, tienes a la gente de alt.net, que es prácticamente centrada en windows, pero es gente que en general utiliza bastantes herramientas open source (nhibernate/active record, nant, nunit/mbunit/xunit.net/, cc.net, rhino mocks,...).

Si lo que programas es una mierda, no pasa nada. Intenta refactorizar el código para mejorar aquello que no te gusta. Te puede interesar aprender algo de TDD/BDD (más o menos lo contrario a lo que te proponía alguno por aquí :D) y refactoring (te recomendaría algún libro, pero como dices que lo que realmente quieres es poner lo que sabes en práctica...) e intentar aplicarlo, y ver si realmente obtienes mejores resultados. Lo importante es que programes y aprendas de cómo lo hace otra gente. Puedes descargarte algún proyecto open source (preferentemente alguno que uses y te interese), compilarlo, intentar entender qué hace el código poco a poco, hacer alguna modificación, e intentar añadir alguna pequeña funcionalidad. Si llegas a algo productivo, mandar parches es una buena forma de que otros desarrolladores vean tu código y te corrijan. ;)

Un saludo.
Pues mi recomendación es que cualquier programa más o menos grande, te definas una arquitectura por capas.
Buenas, por aquí estoy :P

Estoy en un ciber café (estoy pasando fuera el finde :P), aprovecho que mi novia quiere mirar el correo para mirar qué me habeis escrito por aquí.

Estoy de acuerdo que es necesario pensar un poco antes de tirar código, aunque estoy de acuerdo con ferdy, lo que quiero es aprender a programar, a sentirme cómodo tirando código sin marearme en hacer 40 mil diagramas, ya que posiblemente lo que haré será bastante básico.

Gracias a todos por vuestras respuestas.
definirte una arquitectura no requiere hacer ni un solo dibujito y te ayudará a seccionar la aplicación por niveles. Con ello tendrás programas más modulares y fáciles de interpretar.

Una muy común es la arquitectura de tres capas: http://es.wikipedia.org/wiki/Arquitectu ... es_niveles
Pues yo estoy con Ferdy (aunque en principio pudiera parecer que tiro piedras contra mi propio tejado ya que soy Ing. Informatico).
El chaval quiere aprender a programar: ahi no hay que hacer ni un puñetero caso de uso, ni ingenieria de requerimientos, ni absolutamente nada.
Tiene que pensar algo que le apetezca hacer, una aplicación de escritorio o cualquier chorrada que se le ocurra y hacerla. Tirar lineas como un tonto. Así se aprende a programar.

Si algún día está integrado en un equipo de trabajo profesional (en España pocos) entonces ya echará UML's, ya hará estudios de requerimientos y de todo tipo. y con suerte será un buen profesional y ganará pasta de la buena. Pero eso es otra cosa completamente distinta
Según esto del primer post yo entendí que ya sabe programar y lo que buscaba era aumentar la calidad de sus proyectos.
Fox escribió:Por qué no simplemente programo más y ya? Mi verdadero problema ahora mismo es que no veo la forma de "atacar" algo más grande de lo que acostumbro, yo me lio a tirar código por aquí y por allá, luego me doy cuenta que no vendría mal una variable por aquí, un metodo por acá y me encuentro con codigo que no lo entiende ni dios y es absolutamente malo. O sea, no sabría estructurar algo más grande que un Hello World. Con algoritmos no tengo problema, pero si no se "conectar" varios algoritmos entre si y varias clases entre si, pues no hago nada.


Pero bueno, si vosotros decis que siga tirando código inmantenible, que así sea [qmparto]

[bye]
Buenas por aquí.

No, no sé programar, o eso diría yo.

Yo he estado pensando que estaría bien un termino medio, ni hacer unos diagramas de la ostia pero tampoco tirar codigo sin pensar. Al menos pensar un poco que clases creo que podria usar y mas o menos diseñarlas (por encima), asi al menos aunque luego este remodelando las clases para que cumplan lo que quiero hacer, al menos no estaré tirando código sin pensar.

Yo he tomado una decisión definitiva, me explico:

Como dispongo de bastante tiempo libre, voy a seguir 2 "frentes".

Por un lado voy a seguir con mi python como hasta ahora, hacer programillas de escritorio y tal y por otro lado, voy a seguir un frente más serio, voy a dedicarme a aprender C++, voy a hacer problemas sobre estructuras de datos y aprender a hacer las cosas "desde abajo". ¿Por qué? Un buen amigo me ha dicho que lo bueno de C++ es que es dificil, y eso me ayudará a pensar y aprender, ya luego todo será un paseo.

Así que, es mi decisión definitiva, esta NO va a cambiar, pero si moldearse con vuestras opiniones.

Gracias.
(mensaje borrado)
No son dos frentes, para hacer buen software, detrás debe de haber una ingeniería(proceso de), salvo que quieras hacer un programa que calcule factoriales o una calculadora o similares de poca envergadura que tardas mas en la ingeniería que en la codificación (matas moscas a cañonazos), para todo lo demás siempre es bonito tener un esquema, trazabilidad y esas cosas para poder ver el impacto de los cambios, lo malo es que estas preguntando en software libre, donde no se suele llevar eso.

c++ no es mas difícil que otro lenguaje, y para aprender POO yo no lo usaría,al igual que para aprender imperativo no usaría c

Fox escribió:Buenas por aquí.

No, no sé programar, o eso diría yo.

Yo he estado pensando que estaría bien un termino medio, ni hacer unos diagramas de la ostia pero tampoco tirar codigo sin pensar. Al menos pensar un poco que clases creo que podria usar y mas o menos diseñarlas (por encima), asi al menos aunque luego este remodelando las clases para que cumplan lo que quiero hacer, al menos no estaré tirando código sin pensar.

Yo he tomado una decisión definitiva, me explico:

Como dispongo de bastante tiempo libre, voy a seguir 2 "frentes".

Por un lado voy a seguir con mi python como hasta ahora, hacer programillas de escritorio y tal y por otro lado, voy a seguir un frente más serio, voy a dedicarme a aprender C++, voy a hacer problemas sobre estructuras de datos y aprender a hacer las cosas "desde abajo". ¿Por qué? Un buen amigo me ha dicho que lo bueno de C++ es que es dificil, y eso me ayudará a pensar y aprender, ya luego todo será un paseo.

Así que, es mi decisión definitiva, esta NO va a cambiar, pero si moldearse con vuestras opiniones.

Gracias.
No voy a aprender la POO usando C++, yo he usado la POO en python, he hecho mis cositas usando OO, incluso patrones.

Por otro lado, no veo que tiene la POO en C++ que sea más dificil que java, c# o python.

Un saludo.
Vereis, creo que prefiero un lenguaje algo más estricto que python, tipado estatico... vamos algo como C#, que a mi forma de ver, es un lenguaje bastante bonito.

Quieres algo "estricto" y de "tipado estático" y encima te gusta programar para Linux... Lo que necesitas es C. Hablo de ANSI C de toda la vida ( http://es.wikipedia.org/wiki/ANSI_C ) (punteros, paso de parámetros por referencia, asignación dinámica de memoria, ...) y una vez que lo domines podrías pasar a C++.

No quiero entrar en la típica guerra de lenguajes de programación, pero C es FUNDAMENTAL (yo no programaría en C# para Linux).

Nota, me ha parecido que venía a cuento esto que leí el otro día:
http://labloguera.net/blogs/aclemente/a ... mbres.aspx

Espero que te sirva de ayuda.
Saludos.
Yo tambien te recomendaría Ansi C y de ahi, con el tiempo, C++.

PD: Muy bueno el artículo de arriba
ikiu escribió:No son dos frentes, para hacer buen software, detrás debe de haber una ingeniería(proceso de), salvo que quieras hacer un programa que calcule factoriales o una calculadora o similares de poca envergadura que tardas mas en la ingeniería que en la codificación (matas moscas a cañonazos), para todo lo demás siempre es bonito tener un esquema, trazabilidad y esas cosas para poder ver el impacto de los cambios, lo malo es que estas preguntando en software libre, donde no se suele llevar eso.

BS.
Si empleas más tiempo en la "ingeniería" (lo que sea que es eso) que en la "codificación" tu proyecto está condenado al fracaso.
lo malo es que estas preguntando en software libre, donde no se suele llevar eso


Entiendo que tu amplia experiencia en proyectos de software libre te avala para hacer esa afirmación.... ¿verdad?

- ferdy
bastian escribió:
ikiu escribió:No son dos frentes, para hacer buen software, detrás debe de haber una ingeniería(proceso de), salvo que quieras hacer un programa que calcule factoriales o una calculadora o similares de poca envergadura que tardas mas en la ingeniería que en la codificación (matas moscas a cañonazos), para todo lo demás siempre es bonito tener un esquema, trazabilidad y esas cosas para poder ver el impacto de los cambios, lo malo es que estas preguntando en software libre, donde no se suele llevar eso.

BS.
Si empleas más tiempo en la "ingeniería" (lo que sea que es eso) que en la "codificación" tu proyecto está condenado al fracaso.


Si codificas sin emplear tiempo en "ingeniería" tu proyecto estará condenado al fracaso (parece que la gente no entiende que en un proyecto tan importante es la "ingeniería" como la codificación porque un proyecto no es estático etc)

Ferdy escribió:Entiendo que tu amplia experiencia en proyectos de software libre te avala para hacer esa afirmación.... ¿verdad?

- ferdy


Si
Es decir, NO.

- ferdy
ikiu escribió:Si codificas sin emplear tiempo en "ingeniería" tu proyecto estará condenado al fracaso (parece que la gente no entiende que en un proyecto tan importante es la "ingeniería" como la codificación porque un proyecto no es estático etc)

Precisamente porque un proyecto no es estático, es muy difícil preveer cómo evolucionará por medio de un análisis previo. A no ser que por ingeniería te refieras a otra cosa que lo que se ha comentado antes, claro, pero no me da esa impresión. Yo considero que el diseño va integrado al desarrollo y es parte de ese proceso de ingeniería. Si quieres un proyecto que pueda adaptarse a los cambios y no quedarte con un montón de documentación desfasada, es mucho más util una metodología agil que una en cascada.

PD: Yo no he dicho que tengas que tirarte a programar sin pararte a pensar un minuto en las decisiones importantes de arquitectura a nivel general, lo que mantengo es que es un error intentar definir completamente el comportamiento de las distintas clases a través de diagramas, etc antes de tirar una sola línea de código.
Ferdy escribió:Es decir, NO.

- ferdy


Lo que digas, para que discutir.
Exacto. Si tuvieras experiencia real, sabrías que existen proyectos de ingeniería en casi cualquier proyecto grande de software libre. Otra cosa es que no sean iguales a los que aprendiste en la universidad.

- ferdy
Ferdy escribió:Exacto. Si tuvieras experiencia real, sabrías que existen proyectos de ingeniería en casi cualquier proyecto grande de software libre. Otra cosa es que no sean iguales a los que aprendiste en la universidad.

- ferdy


ikiu escribió:siempre es bonito tener un esquema, trazabilidad y esas cosas para poder ver el impacto de los cambios, lo malo es que estas preguntando en software libre, donde no se suele llevar eso.



Pero vamos, que te insisto, tu mismo.
La realidad es justo lo contrario. Se suele llevar.

- ferdy
Tienes razón vivo en un error gracias por abrirme los ojos.
A mandar.
Nada nada, ésto tenéis que solucionarlo a futbolines, ya no hay vuelta atrás.

Personalmente (y creo que sintetizando por unos sitios, y ampliando por otros todo lo expuesto hasta el momento) pienso que un modelo de desarrollo tipo catedral viene bien en proyectos en los que se desarrolla de forma cíclica. Se habla con el cliente, se definen los requisitos, se firman, y de ahí p'alante con análisis, diseño y codificación hasta cerrar el proyecto, y si el cliente desea hacer cambios, ya hablaremos de reabrirlo, o a tirar de mantenimiento. Si se reabre la verdad es que se agradece un montón conservar algo de documentación detrás, aunque sea un mísero diagrama de clases.

En caso de un proyecto más "vivo", es evidente que no tiene utilidad terminar hoy una documentación que por alteración en los requisitos quedó desfasada la semana pasada, pero precisamente por esto es más útil un pequeño núcleo de documentación actualizada que ayude a coordinar el trabajo, definir tareas y mejorar la integración.

Por otro lado, ésto son labores de ingeniería, muy útiles para coordinar proyectos, pero si la idea original es aprender a desenvolverse en un lenguaje concreto, o aprender a programar en general, tanto monta que da lo mismo toda la ingeniería que le eches por delante.
En general, los procesos de ingeniería son distintos, obviamente. Pues no suele existir un 'cliente'. Y el desarrollo funciona alrededor de otro tipo de objetivos.

PD: A futbolines no.... a billares no diría yo que no.

- ferdy
Exacto. Si tuvieras experiencia real, sabrías que existen proyectos de ingeniería en casi cualquier proyecto grande de software libre. Otra cosa es que no sean iguales a los que aprendiste en la universidad.


¿Y puedes poner un ejemplo de algún proyecto del que se pueda obtener aparte del código ese proceso de ingeniería? La verdad es que es algo que me interesaría bastante :)
Si. En las listas de correo, donde se discuten los casos de uso/desuso, los requisitos, etc etc.

Pero tampoco tengo muy claro qué andas buscando. Si pretendes ver bonitos diagramas de cajas, no creo que los haya en ningún sitio.

- ferdy
No, no quiero ver diagramas de cajas, pero me imagino que el proceso de ingeniería se documentará de algún modo, ¿no?
Oh, mira por ejemplo git, lee la lista de correo y verás el proceso de ingeniería. También puedes echar un vistazo a Documentation/.

- ferdy
44 respuestas
Archivado
Volver a Software libre