Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - página 4
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Y qué pasa con tu estructura clara si a mitad, o incluso cerca del final del proyecto, el cliente cambia de repente:
Se trata de una buena prueba para saber si su proyecto está preparado y es resistente al cambio.
Este es el problema, y por eso estoy en este hilo.
Quiero encontrar una respuesta sobre cómo diseñar (o cómo meter al cliente en ese marco), de manera que se satisfagan sus deseos y no se rompa el proyecto.
SZY porque la moneda tiene dos caras, con una se puede cambiar el proyecto, con otra se puede decir "No como parte de este proyecto no se puede hacer", la verdad está en algún lugar en el medio.
Lo mejor es diseñar el desarrollo de tal manera que la mayoría de los deseos esenciales del cliente sean realizables.
Ningún programador normal dibuja diagramas de flujo hoy en día. Todo esto son tonterías teóricas pensadas para ser enseñadas a los escolares, pero no para trabajar en proyectos reales.
Todo depende de lo que se ponga en el papel.
No soy partidario de escribir, pero a veces hay que trazar una estructura general sobre el papel. Es cómodo y rápido, es como un boceto para un joyero, la imagen general debe ser clara.
Quizá por eso hay muchos programadores no normales porque no dibujan diagramas de flujo.
Hoy en día, ningún programador normal dibuja diagramas de flujo. Todo esto son tonterías teóricas pensadas para enseñar a los escolares, pero no para trabajar en proyectos reales.
Hoy en día, ningún programador normal dibuja un diagrama de flujo.
Supongo que por eso hay muchos programadores anormales, porque no dibujan diagramas de flujo.
Yo no lo llamaría tan tajantemente "tonterías teóricas". Dibujar "cuadrados con flechas" en papel se utiliza mucho en la programación. Tomemos como ejemplo el UML, lleno de "flechas con cuadrados". :) Así que, también los diagramas de bloques en las etapas iniciales pueden ser útiles...
He intentado diseñar con UML, es un sinsentido (IMHO).
Todos estos cuadrados y flechas puedo mantenerlos perfectamente en mi cabeza, pero las abstracciones no caben en mi cabeza, así que las esbozo.
HI Si se profundiza, el cerebro humano está bien adaptado para memorizar imágenes, mapas, patrones de comportamiento, pero no para construir abstracciones, la abstracción es lo más difícil que puede hacer una persona.
Así que la humanidad siempre ha intentado formalizar la abstracción en algo más familiar.
El cerebro humano está bien adaptado para recordar imágenes, mapas, patrones de comportamiento, pero no para construir abstracciones; las abstracciones son la tarea más difícil para un ser humano.
ZZZI Por eso la humanidad siempre se esfuerza por formalizar la abstracción en algo más familiar.
Estoy de acuerdo.
Tengo mis propios métodos para agudizar mi propio cerebro en esta área, incluso tengo un desarrollo de software (que puedo compartir en ocasiones), pero el desarrollo es muy lento (aunque se nota a posteriori).
--
En cierto sentido, toda y cualquier programación es un trabajo de abstracción, pero hay una enorme variación en el nivel y la habilidad del manejo práctico de los conceptos abstractos.
Estoy de acuerdo.
Tengo mis propios métodos para agudizar mi propio cerebro en esta área, incluso tengo desarrollos de software (puedo compartirlos en alguna ocasión), pero el desarrollo ha sido muy lento (aunque se nota a posteriori).
--
En cierto sentido, toda y cualquier programación es un trabajo con abstracciones, pero hay una gran diferencia en el nivel y la habilidad del uso práctico de las abstracciones.
No nos interesa la abstracción por la abstracción, ¿verdad?
Creo que como no estamos evolutivamente mejor adaptados a la abstracción... (discutible, al menos mejor que los demás habitantes de este planeta), deberíamos intentar construir muletas.
Por ejemplo, la gente inventó una técnica como la lluvia de ideas.
A menudo me cuesta nombrar una entidad, darle un nombre sucinto que sea lo suficientemente comprensible y extremadamente corto. Cuando esto se consigue, la abstracción se asimila fácilmente.
Lo siento, no puedo escribir mucho ahora (no es conveniente hacerlo desde el móvil), no tendré tiempo de hacerlo cuando llegue allí. No puedo escribir mucho ahora (no es conveniente en el teléfono). No tendré tiempo.
Siento no poder escribir mucho ahora (no es conveniente desde el móvil), no tendré tiempo cuando llegue. Mejor mañana.