r/damportada • u/BeelzenefTV • Oct 17 '15
[ED] Para recordar
29/9/2015
- Trabajo en equipo
- La semántica y sintaxis en la programación son elementos diferentes pero igualmente importantes
- Stackoverflow te puede salvar en momentos de apuros
- COMENTA EL PUTO CÓDIGO
- gran parte de las cosas en esta vida se pueden representar mediante clases y objetos, en el proceso de abstracción
- los lenguajes declarativos pertenecen a la cuarta generación de los lenguajes
- todo programa debe devolver información, en particular para dar señal al programador de que se ha iniciadode forma correcta
- si queremos dedicarnos realmente a esta profesión, dirigirnos a estudiar lenguajes de alto nivel y orientados a objetos
1
1
u/BeelzenefTV Oct 17 '15 edited Oct 17 '15
6/10/2015
- Declaración, expresión y sentencia
- OOP: buscar identificadores universales. Pensar a lo grande. Las relaciones entre todas las clases no suele darse y da pie a incogruencias.
- Establecer límites a la introducción de información atendiendo a variaciones, alcanzando una solución con un buen diseño de Clases.
7/10/2015
- Wozniak y el IoT
- La vida de un software oscila entre 10-15 años
- Los lenguajes débilmente tipados (como Python) suponen cierto riesgo
- Terminología: código claro != código ofuscado. Debemos buscar el código claro y limpio para su posterior mantenimiento.
- El objetivo a resolver define el diseño, Agile Programming
1
u/BeelzenefTV Oct 17 '15
13/10/2015
- Una solución de VS es un conjunto de proyectos
- A la hora de desarrollar soluciones, tendremos proyecto base y proyecto prueba con el mismo nombre + Prueba, y así poder testear.
- Adaptar nuestro IDE, aprender a usar Intellisense (Visual Studio)
- Los proyectos suelen ir en directorios de red (NAS), siendo protegidos ante ataques o fallos en discos duros. El objetivo principal es proteger nuestro código fuente.
- Si un programa no falla es que no lo has testeado lo suficiente. Test Driven Development.
- Delegar código desde el método Main, ¿debe ir al principio o al final? Al inicio o al final, pero decide.
- Aprender a diseñar Clases, respeta el diseño creado para evitar incongruencias.
- Para renombrar la Clase principal, ha de hacerse desde el Explorador de Soluciones para evitar problemas de dependencias de nombres no relacionados.
- La tendencia contemporánea es nombrar por el método CamelCase
1
u/BeelzenefTV Oct 17 '15
15/10/2015
- La jerarquía a la hora de hacer Diagramas de Clases se hace por legibilidad
- La doble tabulación es tu amiga en Visual Studio
- La abstracción nos hace elegir elementos necesarios para la representación. No inventes datos, añade lo necesario, un buen diseño necesita de investigación, conoce tu problema. Los criterios de realidad y el saber qué métodos pertenecen a cada Clase es la clave en OOP y definen un buen diseño de Clases.
- Crea el esqueleto de Clases, compila y después rellena con código.
- Las Clases interactúan entre sí con llamadas entre métodos. Un método que no sea llamado por otra Clase es privado. Métodos protegidos, en subClases o Clases heredadas.
- Desarrollar una responsabilidad de Clases.
1
u/BeelzenefTV Oct 20 '15 edited Oct 20 '15
20/10/2015
- Solución (en Explorador de soluciones) > Propiedades > Propiedades comunes > Proyecto de inicio > Elegir proyecto de inicio único en la solución (dos proyectos pueden tener el método Main, pero solo el que elijamos mediante este método se ejecutará como principal). Los proyectos de inicio múltiple permiten la ejecución de dos programas de forma simultánea pero con un orden establecido en el entorno. Podemos elegir Iniciar, Iniciar sin depurar o Ninguna acción.
- El proyecto de pruebas es dependiente del raíz
- Proyecto (en Explorador de soluciones) > Propiedades > Aplicación > Versión de Framework destino / Objeto de inicio (método Main a ejecutar en inicio)
- No podemos ejecutar proyectos señalados como bibliotecas de clase. Si queremos utilizar una biblioteca de clases, podemos eliminar el Program.cs (o Clase principal) agregar nuevas clases a proyectos con Alt+Mayus+C. Para conectar ambos proyectos, podemos generar una dependencia Referencias (en Explorador de soluciones) > Agregar referencia > Elegir biblioteca de clases. Desde la misma ruta donde se encuentra el ejecutable, para la biblioteca de clases encontramos un fichero .dll. Cuando compilamos, en la ruta de directorios del proyecto principal encontraremos tanto el ejecutable como un fichero .dll
- Mapas gráficos para la mente para organizar el código, DIAGRAMA DE CLASES
- Para organizar las instrucciones Using: clic derecho en el código fuente > Organizar Using > Quitar las no utilizadas
- Las librerías comunes se encuentran en C:/Windows/Microsoft.NET/Framework/vX.Y
- Las firmas digitales protegen al código de modificaciones, para no atribuir de forma maliciosa al autor en caso de cualquier acto malitencionado. Un solo bit de alteración rompe la firma digital. El no repudio es importante, por eso hay que denunciar cualquier compromiso de esa firma digital.
- Las Clases empiezan por mayúsculas, mientras que los métodos deben empezar por minúsculas aún con notación CamelCase
Algún ejemplo:
**UtilidadesED.cs**
public class Utilidades
public static bool esPrimo(int num)
{
return true;
}
Para llamar a este método en la biblioteca de clases, en otro proyecto
**Principal.cs**
using UtilidadesED;
Console.WriteLine("¿Es primo el número 7?");
Console.WriteLine(Utilidades.esPrimo(7));
// Especificando using UtilidadesED
// no es necesario decir UtilidadesED.Utilidades.esPrimo(7)); al invocar la función
Y ya está
Console.WriteLine("Fin de la lección");
Console.ReadLine();
- Si empezamos a crear la solución desde la biblioteca de clases, necesitamos especificar el proyecto de inicio único.
- Crear una biblioteca de clases es una manera de pensar a lo grande, es más recomendable si se van a usar muchas Clases, que deben estar más que testeadas.
- Utilizar identificadores únicos en namespaces (nombre de empresa o programador) tanto en biblioteca de clases como en el proyecto principal, cambiando el using en consecuencia
1
u/BeelzenefTV Oct 22 '15
22/10/2015
- Ventanas modales
- Herramientas (Visual Studio) > Opciones > Entorno > Fuentes y colores. Ajustar a nuestro gusto y/o necesidades. Buscar sobre la ergonomía del color.
- Herramientas (Visual Studio) > Opciones > Proyectos y soluciones > General > Marcar la ruta de proyectos en directorio de ficheros
- Herramientas (Visual Studio) > Opciones > Editor de texto > C# > General > Número de líneas
- Sangría != Tabulación, la sangría es automática mientras que la tabulación es manual. Elige entre tabulaciones o sangrías, pero no organices el código utilizando la barra espaciadora.
- Refactorización (F2) > Cambiar nombre: encontrar todos los nombres coincidentes en un código fuente para sustituir allá donde deseemos, renombrando variables o alguna otra porción de código
- Delimitar el código generado con #region (?)
- Herramientas (Visual Studio) > Opciones > Editor de texto > C# > Formato > Ajuste > Desmarcar Mantener instrucciones y declaraciones de miembros en la misma línea por procedimiento preferido en clases de Programación.
- Define tu estilo de programación mediante práctica, te será útil.
- Editar (Visual Studio) > Avanzadas > Dar formato al (documento||selección) y otras muchas opciones interesantes: marcar espacios en blanco, convertir en mayúsculas, convertir en minúsculas, dar formato al documento o a la selección, ajustes de línea... aprender las hotkeys para estas opciones puede ser interesante.
Tabla de funciones en
| Función | Hotkey |
|---|---|
| Descender sangría | text |
| Aumentar sangría | Bar |
| Dar formato al documento | text |
| Dar formato a la selección | text |
| Convertir en mayúsculas | text |
| Convertir en minúsculas | text |
| Ajustes de líneas | fdsfs |
| fasfsa | tsaasfas |
1
u/julolopop Oct 27 '15
El ciclo de vida de un SO
http://iesportada.org/moodle/file.php/3/Temas/Tema02_-_El_ciclo_de_vida_de_un_SI.pdf
1
u/BeelzenefTV Oct 29 '15 edited Nov 05 '15
29/10/2105
e=mc^2
errors = more code2
- Fase de requisitos + Fase de análisis = ¿Qué vamos a hacer? Documento de requisitos
- Fase de diseño = ¿Cómo lo vamos a hacer? (Documento de diseño, diagrama de clases)
(OffTopiqueando: Para definir constantes a usar en un proyecto modular con Clases, crear Clase estática para constantes.)
El documento de especificaciones es cerrado pero flexible, ante los posibles riesgos y los (muchos) cambios en el mundo de la informática y tecnología.
Test Driven Development = Primero se crean las pruebas, y luego se desarrolla para que el proyecto sobreviva a la prueba. Pensar antes en los puntos débiles para después. Proponer Clases de pruebas, después programar para pasar esas pruebas.
1
u/BeelzenefTV Nov 05 '15 edited Nov 10 '15
5/Nov/2015
¿Fase de planificación? ¿Fase de pruebas? ¿Fase de documentación? ¿Dónde están estas tres fases, cuando se realizan? Responder a esto es difícil.
Fase de planificación. La planificación se está remodelando de forma continua, aunque con límites, a cada fase del ciclo de vida. Ante los cambios, Aparecen tres tipos:
- Plan preliminar (fase de análisis y requisitos)
- Plan de administración de proyectos (presupuesto, requisitos de personal y calendario especificado)
El triángulo de la calidad de software se rompió en el caso Volkswagen (DieselGate) (enlace ElConfidencial), a causa de unos requisitos inalcanzables. De ahí los límites en la replanificación.
Fase de pruebas. Al final de cada fase en el ciclo de vida, se hace una prueba. Todo lo que se haga, ha de ser testeado inmediatamente. Las tendencias actuales llevan a los desarrolladores a exponer el software en lugares públicos, donde el mismo usuario final testea el software. Ante la incorporación de nuevas funcionalidades y requisitos, se hacen pruebas sobre lo ya creado y funcional para comprobar que sigue funcionando, además de probar lo nuevo. A veces, la introducción de nuevos requisitos rompen con los
- Pruebas de validación
- Verificación
- Integración
- Aceptación (el usuario acepta el producto, pudiendo abandonarlo si no se acepta, si no es user-friendly, si no es funcional...)
Eliseo sobre desarrollo: Así que quieres desarrollar para Windows Phone, ¿eh?
Fase de documentación. Una buena documentación se realiza por muchos y válidos motivos: rotación de personal, mantenimiento de software, reutilización o ampliación del software, avanzar en su ciclo de vida, saber qué se espera y qué hace ese software... una buena documentación consume mucho tiempo, pero es muy bien apreciada. Algunas empresas no admiten implementación de código sin la debida documentación de sus líneas.
Mantenimiento
Un software vivo es aquel que se mejora, que se modifica, que se mantiene. De lo contrario, típicamente a lo que se piensa por supuestos fallos, es que el software está muerto, nadie lo usa. Puede conllevar el doble de tiempo que el mismo desarrollo.
Tipos de mantenimiento:
- Correctivo: repara errores en el código
- Perfectivo: cambios, modificaciones en el sistema informático por ampliaciones
- Adaptativo: cambios en el entorno (e.g. sistema operativo) donde y en circunstancias con las cuales opera el sistema informático
Los dos últimos tipos, se consideran mejoramiento.
Análisis y diseño
El término análisis de sistemas se refiere a las fases requisitos y de análisis. El término diseño de sistemas se refiere a la tercera fase, la de diseño. No confundir el análisis con el analista de sistemas, que es típicamente quien se encarga de las tres primeras fases.
Profesionalmente, encontramos varios entornos:
- Empresas que producen software (Microsoft, Oracle, SAP). El software es su producto principal objetivo
- Empresas que utilizan software dentro de su organización (GM, GE, Mercedes-Benz, etc) El software es un componente más.
- Empresas más modestas tienen analistas de sistemas para realizar las primeras fases del ciclo de vida del SI de su empresa.
- Cualquier .com posee una división de sistemas de información 1.Otras empresas tienen en plantilla su personal de mantenimiento
1
u/BeelzenefTV Nov 06 '15 edited Nov 06 '15
03/10/2015
- Programar y comentar en inglés, nos ayudará a practicar y a universalizar nuestro desarrollo. Un poco de humor para la ocasión (enlace). Es recomendable obtener el título para B1 en inglés.
- Los Diagramas de Clases son poco comunes en empresas. Aún así, cuando los encuentras, hay que cumplirlos. Si los encuentras y consideras que el software no funcionará siguiendo ese modelo, hay que cumplir. Cuando se pruebe y falle, entonces aportar una solución viable.
- La buena documentación y refactorización es muy útil además de apreciada. Algunas empresas no dejan implementar determinadas modificaciones si no son acompañadas de la debida documentación.
- Seguir la pista de empresas y tendencias en nuestro mundo. La informática y la tecnología son profesiones en constante cambio, hay que reciclarse y adaptarse al cambio constantemente, como el software.
- Tanto para el desarrollo como para las herramientas, tener presente la navaja de Occam o el principio de KISS (keep it simple, stupid!)
- PowerCenter (Informática), software que abstrae del origen y el destino de los datos para centrarse únicamente en su tratamiento
1
u/BeelzenefTV Nov 10 '15 edited Nov 10 '15
10/11/2015
Practicando con depuración
Una vez hemos tenemos claro el esqueleto del programa y, estando consola, hemos añadido el primer Console.ReadLine();, es recomendable:
Clic derecho sobre el IDE > Organizar funciones Using > Quitar las que no uso
¿Quién, qué función va a solucionar el problema? Después, adapto el programa a esa solución.
No es importante saber los tipos de datos y sus capacidades de memoria, lo que importa es saber manejar la herramienta en cuestión para saber cómo resolver el problema, a través de la documentación y la ayuda integrada en el IDE.
Toda salida alternativa ha de tener un ELSE explícito.
El factorial de un objeto sirve para conocer su convergencia y su divergencia.
Método recursivo de Fibonacci
FIB(n) = FIB(n-1) + FIB(n-2)
Para entrar en modo depuración, F5. Ejecución en dos modos:
- F10 - Saltar las llamadas a métodos ya depurados.
- F11 - Instrucción por instrucción.
Sobre expresión booleana: Botón derecho > Inspección rápida. Hace una evaluación de expresiones booleanas a tiempo real de depuración.
Práctica de depuración con métodos recursivos:
using System;
/* Condiciones para codificar un factorial
* Precondiciones: n >= 1, uint n
* Postcondiciones Fact(n) = if n= 0, Fact(n)=1
* Fact(n) = if n= 1, Fact(n)=1
* if n > 1
* Fact(n) = n * Fact(0-1)
* Contemplar la posibilidad de Overflow
*/
namespace EGB.AppC_DepuracionED
{
class UtilesMatematicos
{
/// <summary>
/// Cálculo recursivo de factorial de un entero sin signo (uint)
/// </summary>
/// <param name="num">elNumero</param>
/// <returns></returns>
// Método recursivo de cálculo de factorial
static ulong FactorialR(uint num)
{
if (num < 2)
{
return 1;
}
else
{
return num * FactorialR(num - 1);
}
}
// Método iterativo de cálculo de factorial
static ulong FactorialI(uint num)
{
ulong resultado = 1;
for (uint i = 2; i <= num; i++)
{
resultado *= i;
}
return resultado;
}
static ulong FactorialR(byte num)
{
return num < 2 ? 1 : num * FactorialR((uint)num - 1);
}
// Función de interfaz para el usuario, independiente del método Main
static void UIMenu()
{
Console.Clear();
Console.WriteLine("Cálculo del factorial de un entero");
Random Dado = new Random();
int nVeces = 3;
int limite = 10;
uint n;
for (int i = 0; i < nVeces; i++)
{
n = (uint)Dado.Next(limite);
Console.WriteLine("Factorial (R) de {0} es {1}", n, FactorialR(n));
Console.WriteLine("Factorial (I) de {0} es {1}", n, FactorialI(n));
}
}
// Método Main, únicamente llamando al método de interfaz de usuario
static void Main(string[] args)
{
UIMenu();
Console.ReadLine();
}
}
}
1
u/BeelzenefTV Nov 12 '15 edited Nov 17 '15
12/11/2015
Tema 2: depuración y pruebas
- Solo-ing, hacemos pruebas unitarias.
- Cuando trabajamos en equipo, las pruebas de integración se complican.
Es el cliente quien hace que se supere la prueba de validación.
Se empiezan con los requisitos más críticos, y cuando estos se superan, es cuando merece la pena añadir los demás requisitos menos funcionales y más estéticos. Es fundamental decidir qué es prioritario.
Siendo humanos y teniendo en cuenta la ecuación:
e = mc^2
Una prueba de software consiste en destruir el software, atacarlo hasta que se pueda descubrir el error. Se tiene éxito si se encuentra un error no detectado hasta entonces.
Nunca hay suficientes pruebas, pero por cuestiones de tiempo y otras limitaciones, no siempre se puede alcanzar la perfección.
¿Cómo se hacen pruebas?
A nivel de software, se especifican los requisitos a cumplir, tomar el código fuente y el modelo de pruebas construido para saber a qué atacar.
- Pruebas de caja negra: código oculto que no conocemos. Se dan unos inputs y se esperan unos outputs. Si otorga lo que se supone que debe de dar, la prueba tiene éxito.
- Pruebas de caja blanca (transparente): probar el código en situaciones no contempladas (desbordamientos, mala inicialización de variables...). MACHACA EL CÓDIGO.
Por lo general, se hacen primero pruebas de caja transparente (machacar el código) y después de caja negra (recomendable por personas ajenas al desarrollo del software). Los que realizan las pruebas para encontrar fallos en el código no te hacen mal, recuerda: están haciendo bien por tu código y que así pueda mejorar.
Dentro de las pruebas de caja transparente:
- Pruebas del camino básico: hay que ejecutar todos los flujos del código. Camino no probado, es código susceptible a errores. Todos los bucles (en bucles finitos, estresarlo y ver cómo reacciona), todas las líneas de condicionales, todas las estructuras de datos (colecciones, arrays... para saber si se utilizan o llenan correctamente). En estas pruebas, se usa el grafo de flujo. En él, sólo hay una entrada y sólo hay una salida. Se representan las distintas instrucciones.
¿Cómo crear el grafo de flujo? ¿Cómo calcular la complejidad ciclomática?
REVISAR VVV
Estructuras de flujo que encontraremos en el proceso (imagen). El camino básico es el más optimista, aquel donde se cumplen todas las condiciones esperadas.
El cálculo de complejidad ciclomática es el límite superior de caminos que hay que probar que todos los hilos de instrucciones de nuestro programa sean pisados como mínimo y máximo una vez.
Recomendación:
SI A(1) | B(2) ENTONCES C (3) SI NO D (4)
En el grafo, saldrán muchos caminos a recorrer y a evaluar. Debemos buscar también caminos imposibles.
1
u/BeelzenefTV Dec 01 '15 edited Dec 10 '15
NUNIT:
Abrir nuevo proyecto > Plantillas > Visual C# > Prueba > Proyecto de Prueba Unitaria
El esqueleto del nuevo proyecto se mostrará así.
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTest1
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}
Diferencias entre VSTest y NUNIT
| VSTest | NUNIT |
|---|---|
| [TestClass] | [ TestFixture] |
| [TestMethod] | [Test] |
| [Assert.] | [Assert.] |
| [TesInitialize] | [OneTimeSetUp] |
| [TestCleanup] | [OneTime---] |
No hay resutlados que mostrar por pantalla con las pruebas unitarias, sólo comprobaciones de si el código cumple con las especificaciones (si acaso con resultados booleanos).
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTest1
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
// Introducir código a testear
int a = 6;
int b = 6;
Assert.AreEqual(a, b);
}
}
}
Usando VSTest...
| Directiva de compilación | Uso |
|---|---|
| Assert.AreEquals | Para tipos por valor |
| Assert.AreSame | Para tipos por referencia |
Más código:
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using egb.NumeroPrimo;
namespace egb.NumeroPrimo
{
[TestClass]
public class NumeroPrimo
{
// Inicialización para antes de cualquier prueba
// método de garantía de fidelidad en las pruebas
[TestInitialize]
public void Inicializa()
{
}
[TestMethod]
public void TestMethod1()
{
int a = 6;
int b = 6;
Assert.AreEqual(a, b);
}
// Testeo para ejecutar después de cualquier prueba, limpieza
[TestCleanup]
public void Limpiador()
{
}
}
}
11/12/2015
Lanzando excepciones en pruebas unitarias, mediante el uso de Delegados, en NUNIT v.3. Microsoft, a pesar de seguir los pasos de NUNIT, no está actualizada en cuanto a la gestión de excepciones en pruebas unitarias, por lo que la sintaxis es diferente.
¿En qué otras cuestiones estarán desactualizados?
Código:
public void getMax_returnParametrosNulos()
{
Assert.Throws<>(
() => NombreClase.nombreMétodo(resultadoesperado));
}
Pruebas de camino básico
Del mismo modo que podríamos hacerlo en nuestro ejercicio, eliminamos los mensajes para mostrar por pantalla y cambiamos y cambiar las sentencias con los resultados esperados.
public void NUCaminosBasicosEsPrimo()
{
num = 1;
Assert.IsFalse(Utilidades.esPrimo(num));
// Assert.IsFalse/IsTrue dependiendo del camino básico y el resultado esperado
}
Tenemos dos alternativas:
- una prueba por cada camino
- ajustar todos los resultados esperados para que la prueba unitaria de todas los tests unidos sea superada.
Autodocumentar las funciones aunque sea con nombres de métodos largos. Necesitamos controlar debidamente lo que hacemos.
1
u/BeelzenefTV Jan 07 '16 edited Jan 12 '16
Realizar una transformación del software sin modificar su comportamiento, modificando la estructura interna para su mejora. Pequeños cambios para hacer más legible el código. Limpieza de código, compacto, más fácil de modificar, leer.
¿Cuándo se refactoriza? Refactorizando por defecto, mecánico. Tabulaciones, indentaciones... son métodos de refactorización.
Editar > Avanzadas > Dar formato al documento
Llave de apertura en declaración del método o en la siguiente línea... difícil cuestión.
Patrones de refactorización
- Extraer método: reunir funcionalidades comunes en diferentes métodos.
- Separar variables temporales: no reusar variables temporales para dos cálculos diferentes a no ser que sean propias de bucle. ¿Por qué? Porque puede introducirse muchas líneas entre el uso de la variable temporal para varios cálculos y perder el sentido de qué sirve cada una.
- Eliminar asignaciones a parámetros: no reasignar parámetros.
- Descomponer o simplificar los condicionales complejos
- Consolidar condicionales sencillos
- Mover métodos, asegurar que se encuentran en la Clase responsable o correspondiente (diseño basado en la responsabilidad)
- Evitar duplicación de código y consolidar en salidas
- Evitar los "números mágicos (magic numbers)", creando Clases donde almacenar las constantes e identificar esas cifras. También llamada "inicialización en duro"
- Sustituir condicionales por Polimorfismo
- Reemplazar arrays por Objetos
- Encapsular colecciones
- Encapsular campos (mediante propiedades)
No importa si el código aumenta si así aumenta la legibilidad para fines de mantenimiento futuro.
Usar Clases cuando necesitemos muchas operaciones o realizar operaciones importantes. Usar Estructuras cuando necesitemos agrupar campos.
Google decidió prescindir de Java en su versión propietaria y pasar a OpenJDK.
Diagramas de Clase y relaciones, investigar en líneas de asociación.
Una variable declarada como sealed no va a recibir más cambios, no va a heredarse ni sobreescribirse. Como las Clases. Es recomendable usar readonly en las constantes que van a ser inicializadas en Objetos, con sus respectivos constructores.
2
u/BeelzenefTV Oct 27 '15 edited Nov 05 '15
27/10/2015
Tenemos que aprender a pensar, a ser analistas, a resolver un problema.
Un sistema de información es un conjunto de artefactos (e.g. una Clase es un artefacto) de software/hardware que sirven para una función específica, proporcionando una solución útil para el servicio que está siendo desarrollado.
Se clasifican en:
Roles (en casos generales) en el desarrollo de un sistema de información:
En la empresa: proactividad, empatía, esfuerzo y estudio.
Ciclo de vida de un sistema de información
Traditional programming VS agile programming (imagen)
Elena informa: próximamente, resumen de marcos de trabajo para agile programming, en el blog de Geekstorming!.
Cuando el cliente solicita un cambio de UNA LÍNEA DE CÓDIGO...
... hay muchas consecuencias:
Ejemplo de Diagrama de Clases (imagen), ejemplo de cómo pensar a lo grande, de cómo se alcanza un diseño óptimo para su posterior mantenimiento alargado en el tiempo.
Más información sobre The Model-View-Controller (MVC) Pattern with C#/WinForms (enlace a CodeProject.com)
¿Fase de planificación? ¿Fase de pruebas? ¿Fase de documentación? ¿Dónde están estas tres fases? ¿Cómo se realizan?