• Conocer a fondo el paradigma de programación con el que trabajas (si ni siquiera sabes que es un paradigma, es porque estás en el comienzo del camino ... muy al comienzo): sus ventajas y desventajas, y alguna metodología de desarrollo aplicable.
  
  
• Conocer cabalmente el lenguaje de programación con el que trabajas. Es decir, sus características y su sintaxis.
  
  
• Conocer tan ampliamente como sea posible las bibliotecas del lenguaje: los componentes, las clases y las funciones que provee.
  
  
• Conoces en profundidad el entorno de desarrollo con el que trabajas (IDE).
  

¿Cómo te das cuenta de tu avance en el aprendizaje?

• Entiendes tu propio código y el de otros leyéndolo al vuelo (si es que está bien escrito).
  
  
• Comprendes que el código debe ser auto-explicativo y lo aplicas tanto como puedes.
  
  
• Eres minimalista en el uso de comentarios, pero no dudas en escribirlos cuando es necesario.
  
  
• Te resulta evidente cuándo debes comentar el código.
  
  
• Escribes programas que compilan o cometes sólo unos pocos errores de este tipo en un programa de tamaño no trivial.
  
  
• Entiendes lo que significan los mensajes de error del lenguaje.
  
  
• Te das cuenta de tus propios errores y los corriges con cierta facilidad.
  
  
• Eres conciente de la necesidad de manejar la complejidad.
  
  
• Entiendes lo que es "análisis y diseño" y lo aplicas.
  
  
• Te diste cuenta que las sesiones de depuración paso a paso o combinadas con puntos de interrupción consumen mucho tiempo y pocas veces te ayudan a corregir errores (a menos que estés comentiendo muchos errores de tiempo de compilación).
  
  
• Comprendes que tienes que poner a trabajar al ordenador por tí tanto como sea posible, automatizando todas las tareas repetitivas y lo haces.
  
  
• Puedes re-usar tu propio código y el de otros.
  
  
• Comprendes que un buen diseño es tolerante a los cambios.
  
  
• Eres conciente de la necesidad y utilidad de las pruebas unitarias.
  
  
• Escribes programas cuyo diseño es tolerante a los cambios.
  
  
• Escribes tus pruebas unitarias metódicamente.
  
  
• Te das cuenta de qué tipo de pruebas unitarias vale la pena escribir en cada caso.
  

¿Qué consideraciones faltan, sobran o te parece que habría que corregir?

Esto parece un típico post de blog, pero en realidad lo acabo de escribir.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

si hay que cumplir con todo eso entonces no se programar
y
dificil encontrar a alguien que sepa programar


de todas maneras todo eso para mi no es programar

Citar:

si hay que cumplir con todo eso entonces no se programar
y
dificil encontrar a alguien que sepa programar

"Todo eso" son 4 cosas, que no es para nada trivial, pero estoy pensando si realmente leiste y entendiste el artículo.

De todos modos estás equivocado,  todos los programadores saben esas cosas.

El problema es la concepción errónea de que juntar 4 formularios y 2 consultas a una tabla es saber programar.

Si no sabes programar no eres un programador, eres un aprendiz. No hay nada de malo en ser un aprendiz. Además todos lo somos.

Una concepción errónea sobre lo que significa saber programar hace que se menosprecie esta disciplina.

Miralo de esta manera, que alguien sepa que puede usar agua oxigenada para desinfectar una herida y sepa cambiar vendajes (eso es curar) no lo convierte en un médico (tampoco en un enfermero). Del mismo modo, que alguien separ algo sobre programación y pueda escribir programas (estoy siendo generoso) no lo hace un programador.

Citar:

de todas maneras todo eso para mi no es programar

Es una pena que no nos expliques, a tu entender, qué significa saber programar ya que esa es la idea de este tema.

Ahh. Otra cosa, estoy necesitando que alguien me ayude a levantar mi autoestima porque me acabo de enterar (me lo ha dicho alguien) que no me puedo considerar un futbolista por el hecho de juntarme con mis amigos cada tanto a jugar un partido de fútbol ... ¡¡¡ pero si yo hago lo mismo que Leo Messi... pateo un balón !!!  

===================
Cómo programar con Gambas

Speed Books: informática libre.

Comentarios
No solo lo que dice Fabian es correcto. Cada programador tiene sus costumbre, pero una que no debe faltar es la de comentar bien las cosas para el día que tengas que volver a ellas a parchearlas, adaptarlas o lo que sea. No muchos comentarios. Solo los suficientes para que al volver a tocar no arregles una cosa y rompas siete.

Logear
Una costumbre para mí muy importante es logear lo que hago. Eso sirve para depuración, pero no solo eso. El hacer rutinas que te dicen al principio lo que van a hacer y al final el resultado de lo que han hecho parece una tontería pero te obliga a programar de una forma muy estructurada y siguiendo al pie de la letra los paradigmas de oops. Un buen log debe hacer ver por que lineas has ido y que variables has ido obteniendo función a función. Cuando estoy haciendo una función y me encuentro que se complica el logueo de lo que quiero hacer es que debo llamar a funciones de un nivel inferior. Es una forma de llamada de atención

Pruebas
Otra cosa importante es el de las pruebas. Hay que probarlo todo y hay que probarlo bien. No solo que se cumplen para lo bien sino también para lo mal. Pongamos que quiero obtener una lista de diez números aleatorios no repetidos. Pues hago una rutina que genere diez números aleatorios no repetido y compruebo que obtengo diez números aleatorios no repetidos. Eso parece estar bien pero falta otra prueba. Si pido once numeros pero solo obtengo aleatorios entre 1 y 10 necesariamente uno debe ser repetido y dar error. Si no es así está mal.

Un ejemplo de marras. Largo de escribir, sencillo de hacer
Quiero hacer altas, bajas y modificaciones de clientes en una tabla

hacer las altas
1. Hago un formulario que muestre la ficha en blanco y un botón aceptar que cuando lo pulsen llame a una funcion AGREGARCLIENTE que aún no he codificado pero estará en una clase de clientes
2. Hago una clase de clientes y me preocupo de que le lleguen los datos del formulario. Entonces creo la función AGREGARCLIENTE en la que llamo a una funcion COMPROBARCLIENTEVALIDO y si está bien llame a una función GRABARDATOS
3. Luego codifico COMPROBARCLIENTEVALIDO donde se comprueban que los datos son correctos, no falta ninguno ni tienen valores incorrectos.
4. Luego codifico GRABARDATOS en el que pregunto si quiero Agregar o modificar. Codifico la parte de agregar y muevo los datos a tabla. Grabo.

hacer modificaciones
Cuando doy de alta bien para hacer las modificaciones hago lo siguiente
1. Al llamar al formulario le paso un parámetro con el código de cliente
2. Al hacer el form_open si hay código de cliente lo carga con lo que ahora el mismo formulario sale lleno de datos.
3. En el botón aceptar indico que quiero modificar mediante alguna variable. Entonces el botón de Aceptar en vez de llamar a AGREGARCLIENTE como antes llama a MODIFICARCLIENTE. No tengo que hacer nada mas salvo los oportunos logueos.
4. En la clase codifico una función MODIFICARCLIENTE. Esta función llama a COMPROBARCLIENTE que ya estába codificado. Si los datos son correctos llama a GRABARDATOS con el código del cliente a modificar
5. Modifico la función GRABARDATOS que ya funcionaba para altas. Ahora recibe un parámetro si se quiere Agregar o modificar. La rutina es básicamente la misma pero si se quiere agregar se hace un cn.create y si se quiere modificar se hace un cn.edit

Como veis al hacer ALTAS hice las rutinas para que también me valieran tanto para agregar como para modificar o borrar. Primero un formulario que cuando yo quiero aparece lleno o vacio. Luego el formulario que pasa los datos correctamente a la clase correspondiente. Luego la rutina que comprueba que los datos a grabar son correctos. Luego la rutina de grabar datos que es válida para el caso de añadir o el de modificar.

Cuatro rutinas de lo general a lo particular. Cada una al entrar loguea lo que hace y el resultado al salir.  En el mejor de los casos todos los logueos dicen OK. En el peor las rutinas según van entrando van escribiendo lo que quieren hacer hasta llegar a COMPROBARCLIENTE donde puedo obtener un FALLO por dato no válido o bien puede que los datos fueran válidos pero al grabar pasó algo y obtengo un error de base de datos de por que no se pudo grabar. Cada función al terminar devuelve el resultado a su padre y este escribe el fallo y devuelve el resultado a su padre.

Ejemplo de la rutina GRABARDATOS

Esta función da de alta un nuevo cliente o modifica el cliente de código=xx
Si da error escribe el error ocurrido. Si no da error escribe Ok. En cualquier caso devuelve true o false de si lo hizo o no a la función que le llamó. Así para todo.

Está claro que el llegar a realizar una aplicación no nos convierte en programadores, al igual que patear un balón no nos hace futbolistas (al menos no buenos futbolistas)
Creo que los que estamos aprendiendo, como muchos de nosotros, estamos muy lejos de ser programadores, pero estamos en el camino y lo bueno es disfrutar el camino. ¿Qué tan buenos programadores podemos llegar a ser?
Dependerá en la capacidad de cada uno, pero principalmente en el esfuerzo que pongamos en ello. Algunos tendrán más o menos talento que otros, pero si no ponemos trabajo y más trabajo de nuestra parte poco podremos lograr.
Cuando un compañero del foro nos asiste con un código que funciona, tratemos de entenderlo, no quedarnos en que hace lo que quiero y ya está.
Sé que no es fácil. YT que a veces el tiempo es poco.
Pero debemos plantearnos si de verdad queremos aprender, que la mayoría de nosotros no somos programadores, pero podemos llegar a serlo.
Gracias y saludos.

===================
Migrando desde visual basic, el Gambas de Ms
Mi blog gambero

Trabajar en Microsoft.....               

Fuera de bromas. Bajo mi punta de vista de usuario sufridor de programas profesionales....

Yo creo que si tienes un problema real en tu vida:
-  algo tedioso y repetitivo que tienes que hacer
-  llevar las cuentas de tu tienda
- controlar algo (que te llevaría mucho tiempo hacerlo a boli y papel)
- etc

Saber programa es:
  tener los conocimientos suficientes como para saber como usar un lenguaje de programación y tu ordenador (una herramienta más), para que te lo resuelva o te facilite la tarea.




¿si tienes que quitar un tornillo? ¿como lo quitas? Con un destornillador
¿si tienes una tarea complicada/tediosa/repetitiva? ¿Como la puedes hacer? Con la ayuda de "tu programa" y tu ordenador.

Quizás eso no sea un programador profesional, pero si un programador...

Nota:
Yo he trabajado con programas "profesionales" hechos por "profesionales", que lo que hacían es:
- darte más trabajo
- te impedían hacer realmente tu trabajo (porque estabas todo el día metiendo datos...),
- y encima no te ayuda ni te avisaban cuando tenias errores ni podías sacar "informes" que realmente le sacaras partido a las horas invertidas en el programa dichoso....

En vez de una herramienta de ayuda era tu "delator"...

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Citar:

Está claro que el llegar a realizar una aplicación no nos convierte en programadores

Claro que si. Lo que pasa es que la segunda aplicación es mejor que la primera y la tercera es mejor que la segunda. Si escuchas lo que te dicen los que saben mas es probable que te ahorres uno de esos pasos pero a programar, como a todo se aprende a base de cometer aciertos y errores.

Lo que ha puesto Fabian está bien. Visto así parece un montón de cosas complicafas a hacer a la vez, pero es que si escribes que para conducir hay que mirar tres espejos, adelante, atrás, a los laos, que con una pierna usas una palanca, con la otra dos palancas, con los dedos las palancas del volante que debes llevar agarrado con dos manos y que solo debes soltar para cambiar de marcha pues también suena fatal.

En definitiva se trata de codificar las cosas pensando en que algo que escriba sirva para varias cosas, bien porque tengo que hacer dos cosas muy parecidas, bien porque quizá esto que hago hoy para esta aplicación tenga que llevarlo mañana a otra aplicación. Tengo que prever como haré cuando en unos meses o años vuelva a ese código a hacerle cambios y para ello dejaré comentarios, etc. Tengo que intentar que el código no quede mezclado entre lo que son simples manejos de controles de formulario que solo sirven para obtener la información que necesito y lo que quiero hacer.

Puro sentido común y lógica.

fabianfv escribió: [Ver mensaje]

Ahh. Otra cosa, estoy necesitando que alguien me ayude a levantar mi autoestima porque me acabo de enterar (me lo ha dicho alguien) que no me puedo considerar un futbolista por el hecho de juntarme con mis amigos cada tanto a jugar un partido de fútbol ... ¡¡¡ pero si yo hago lo mismo que Leo Messi... pateo un balón !!!  

no es solo patear un balon

fabianfv escribió: [Ver mensaje]

"Todo eso" son 4 cosas, que no es para nada trivial, pero estoy pensando si realmente leiste y entendiste el artículo.

fabianfv escribió: [Ver mensaje]

Conocer a fondo el paradigma de programación con el que trabajas (si ni siquiera sabes que es un paradigma, es porque estás en el comienzo del camino ... muy al comienzo): sus ventajas y desventajas, y alguna metodología de desarrollo aplicable.

el problema de  decir conocer a fondo tiene un ambito demasiado amplio donde empieza el fondo y donde termina
un astronomo conoce a fondo la estructura del universo  
y si no la conoce significa que no es un astronomo

apegarse a un paradigma me sirve o me limita

fabianfv escribió: [Ver mensaje]

Conocer cabalmente el lenguaje de programación con el que trabajas. Es decir, sus características y su sintaxis.

volvemos al problema del ambito
y
no es mas simple y efectivo entender el estilo de la sintaxis y entender sus caracteristicas basicas

el conocer es  estatico para conocer basta una guia o un libro pero que conosca algo no significa que lo entienda y lo pueda usar

fabianfv escribió: [Ver mensaje]

Conocer tan ampliamente como sea posible las bibliotecas del lenguaje: los componentes, las clases y las funciones que provee.

volvemos al problema del ambito y al dilema conosco o entiendo

es posible conocer ampliamente las bibliotecas del lenguaje
o es posible conocer y entender como estan organizadas y como podemos usar y para que podrian servirnos las clases y funciones que nos proveen

fabianfv escribió: [Ver mensaje]

 Conoces en profundidad el entorno de desarrollo con el que trabajas (IDE).

volvemos al problema del ambito y al dilema[b] conosco o entiendo
y
conocer a fondo el ide o saber usarlo para  mejorar nuestro desempeño en el desarrollo

fabianfv escribió: [Ver mensaje]

El problema es la concepción errónea de que juntar 4 formularios y 2 consultas a una tabla es saber programar.

4 formularios y  2 consultas es saber programar tal vez si tal vez no
datos insuficientes

el hacer los formularios y las consultas es solo un eslabon de la cadena
talvez el problema era tan simple que se resolvia  solo haciendo los formularios y las consultas
o era tan complejo que requirio  muchos diagramas
nuevos algoritmos varios  prototipos para llegar al final a 4 formularios con 2 consultas
con un codigo desente

fabianfv escribió: [Ver mensaje]

Si no sabes programar no eres un programador, eres un aprendiz

todos somos ignorantes solo que iignoramos diferentes cosas
todos somos aprendices solo que aprendimos a diferentes niveles y/o diferentes cosas

fabianfv escribió: [Ver mensaje]

Es una pena que no nos expliques, a tu entender, qué significa saber programar ya que esa es la idea de este tema.

[b]


el saber programar esta por sobre todo eso de los paradigmas, el lenguaje ,las bibliotecas, y el ide
eso seria solo conocer un lenguaje y un ide eso no es programar
[/b
saber programar es independiente del lenguaje

programar
es un arte


es convertir los problemas en soluciones en forma de algoritmos finitos

luego esos algoritmos convertirlos en el lenguaje  (en este caso gambas)

es que esos algoritmos convertidos en lenguaje sean relativamente óptimos utilizando las sintaxis del lenguaje las características las bibliotecas y blablabl

y finalmente que el programa creado cumpla su propósito  (que solucione el problema original)

tu no has hecho la carrera de informática porque si la hubieras hecho te darías cuenta de cuantos errores has cometido en eso que has escrito ja ja ja. No es importante, solo es una anécdota, solo quiero hacerte ver que realmente las cosas no son como las ves. Seguir un paradigma no limita a nadie nunca. Solo es un conjunto de reglas en la medida que las sigues consigues hacer las cosas mejor o peor.

o por ejemplo esto

Citar:

es que esos algoritmos convertidos en lenguaje sean relativamente óptimos utilizando las sintaxis del lenguaje las características las bibliotecas y blablabl

y finalmente que el programa creado cumpla su propósito (que solucione el problema original)

¿Y el coste? ¿compensa tardar seis meses en hacer algo que se puede hacer en una tarde? ¿Eso no es un factor? ¿compensa que un browser tarde una hora en sacar una página cuando otro lo hace en décimas de segundo? Sacar la saca si pero ¿a que coste? ¿Compensa que no se haya tenido en cuenta que habrá que hacerle parches, corregir bugs, hacerle versiones con mas funcionalidades, etc? ¿Compensa que solo tu que has hecho el programa puedas modificarlo y que nadie mas pueda? ¿Compensa que tengas que escribir código que hicieste para otra aplicación porque adaptarla es mas dificil que hacerlo de nuevo? ¿Compensa no tener en cuenta todos esos factores y muchos mas a la hora de sentarse a escribir?

Estas muy lejos de lo que es la programación profesional que no es mas que hacer las cosas BIEN.

La gente que empieza naturalmente inician aplicaciones y se preguntan si serán capaces de hacerlas. Es un gran logro conseguirlo. La segunda aplicación ya es mejor. La tercera ya se saben capaces y se atreven con mas cosas. Con el tiempo y la experiencia entienden como enfrentarse a un problema y como no hacerlo. Yo hablo desde la experiencia de haber pasado por todas esas fases y por eso suelo explicar a un forero como hacer mejor lo que hace. Se que la mayoría de las veces ni lo leen y que a menudo tampoco lo entienden. Solo quiero ahorrarles en lo posible esas fases pero hay que pasarlas.

Programar es divertido y cuanto mejor programas mas divertido.

esto no es una pelea es solo conversasion

Citar:

no has hecho la carrera de informática

   
ja...

Citar:

te darías cuenta de cuantos errores has cometido en eso que has escrito ja ja ja.

ovbio que esta lleno de errores no esta depurado  ni nada solo son ideas semicompletas

Citar:

solo quiero hacerte ver que realmente las cosas no son como las ves.

ese es el punto al que queria llegar las cosas    realmente las cosas no son como tu  las ves
y tampoco como yo las veo

 

Citar:

Seguir un paradigma no limita a nadie nunca.

los paradigmas no son axiomas
por que entonces existen diferentes paradigmas todos los paradigmas de algun modo tienen fallas y limites e hay cuando se crean nuevos paradigmas

Citar:

Solo es un conjunto de reglas en la medida que las sigues consigues hacer las cosas mejor o peor.

y si haces las cosas distintas logras hacer algo mejor crean nuevas formas de hacer las cosas


lo que no quiere decir que  seguir las reglas sea malo, no siempre es necesario reinventar la rueda
muchas veces es lo mejor segir las reglas las cosas quedan mejor y al final es mas facil


volviendo a los paradigmas para  mi son solo una  manera de organizar  

Citar:

¿Y el coste? ¿compensa tardar seis meses en hacer algo que se puede hacer en una tarde? ¿Eso no es un factor? ¿compensa que un browser tarde una hora en sacar una página cuando otro lo hace en décimas de segundo? Sacar la saca si pero ¿a que coste? ¿Compensa que no se haya tenido en cuenta que habrá que hacerle parches, corregir bugs, hacerle versiones con mas funcionalidades, etc? ¿Compensa que solo tu que has hecho el programa puedas modificarlo y que nadie mas pueda? ¿Compensa que tengas que escribir código que hicieste para otra aplicación porque adaptarla es mas dificil que hacerlo de nuevo? ¿Compensa no tener en cuenta todos esos factores y muchos mas a la hora de sentarse a escribir?

que...
yo dije otra cosa
si no logras ver los procesos, no entiendes como funciona, no saber simplificar el problema a un conjunto finito de pasos
jamas podrás programar bien aunque tengas una enciclopedia en el cerebro con las definiciones de los paradigmas la sintaxis el ide  y ..... eso es conocer un lenguaje pero no es saber programar (aunque eso vaya mas por el lado de análisis pero para que sirve el análisis aislado de la programación)
por eso aunque conozcas el lengueje el ide y todas esas cosas  y logres armar algo  pasaran todos esos problemas de coste tiempo bug y parches y todo lo demas que mencionas por no tener una buena base

Citar:

¿Compensa que solo tu que has hecho el programa puedas modificarlo y que nadie mas pueda?

me detengo en este punto esto es interesante de echo puede que sea altamente conveniente,  desde un punto económico y realmente compense
hasta se podria llamar una ventaja comparativa  

Citar:

Estas muy lejos de lo que es la programación profesional que no es mas que hacer las cosas BIEN.

   no estoy lejos ni cerca  
ademas el bien como dije en este caso es relativo y subjetivo

Citar:

La gente que empieza naturalmente inician aplicaciones y se preguntan si serán capaces de hacerlas. Es un gran logro conseguirlo. La segunda aplicación ya es mejor. La tercera ya se saben capaces y se atreven con mas cosas. Con el tiempo y la experiencia entienden como enfrentarse a un problema y como no hacerlo. Yo hablo desde la experiencia de haber pasado por todas esas fases y por eso suelo explicar a un forero como hacer mejor lo que hace. Se que la mayoría de las veces ni lo leen y que a menudo tampoco lo entienden. Solo quiero ahorrarles en lo posible esas fases pero hay que pasarlas.

una cosa es ayudar y otra es hacer trabajo ajeno