Cómo particionar un problema en partes más pequeñas comprensibles?

Question

No estoy seguro si es posible dar consejos generales sobre este tema, pero por favor trate. Es difícil de explicar mi caso, porque es demasiado compleja para explicar. Y eso es exactamente el problema.

Me parecen tropezar constantemente en una situación en la que trato de diseñar una parte de mi proyecto, pero tiene muchas cosas a tener en cuenta de que no soy capaz de obtener una comprensión de la misma.

¿Hay algún consejo o consejos generales sobre la manera de mirar a mi sistema en pedazos más pequeños a la vez? ¿Cómo encontrar porciones más pequeñas que podrían ser diseñados de forma individual por su cuenta?

Answer 1

Sus objetivos principales son:

• alta cohesión : Código (métodos, campos, clases) dentro de una sola pieza / módulo / partición deben interactuar intensamente; debe tiene sentido de estos elementos para saber el uno del otro. Si usted encuentra que algunos de ellos no interactúan mucho con el resto, es probable que pertenecen a otro lugar o deben formar su propia partición. Si encuentra el código externo a interactuar intensamente con la partición y saber demasiado acerca de su funcionamiento interno, es probable que pertenece el interior. El ejemplo típico se encuentra en el código OO escrita en el estilo de procedimiento, con objetos "tontas" de datos y código de "manager" que opera en ellos, pero realmente deberían formar parte de los objetos de datos.
• Acoplamiento débil : Interacción entre piezas / módulos / particiones debe sólo ocurren a través de las API, estrechos y bien definidos bien documentados. Trate de identificar este tipo de API y ver qué código se necesita para ponerlos en práctica y qué código van a utilizar.

Answer 2

Crear un glosario.

En otras palabras, identificar los términos que sean significativos para el dominio del proyecto - no desde el punto de vista del programador, pero a partir de un usuario, que está familiarizado con el tema

.

A continuación, defina los términos como precisamente y discretamente que pueda. Una buena definición en esta forma puede servir como una especie de pseudocódigo.

Ya que no han identificado aún el dominio de su problema, voy a elegir un ejemplo al azar. En un sistema de personal civil, es posible que tenga términos como:

• tocho : un período de servicio (desde la fecha de inicio para poner fin a la fecha) en un determinado grado y escalón
• empleado : una serie de palanquillas asociados con un SSN particular,
• grado y escalón : fila y columna en la programación general de la república

Y así sucesivamente. Esto no es para identificar las unidades funcionales, como parece que usted está tratando de hacer, pero es un buen paso preparatorio antes de hacerlo, de modo que usted puede expresar sus pasos funcionales en términos bien definidos.

Answer 3

Es útil para abordar un problema de descomposición tanto de arriba hacia abajo y de abajo hacia arriba.

Si usted está teniendo problemas para dividir un problema grande en dos o problemas más pequeños, trate de pensar en los problemas más pequeños posibles que necesitan ser resueltos. Una vez que las gestiona, puede empezar a ver la manera de combinarlos en problemas más grandes a medida que se acerca a su problema original grande.

Answer 4

Cuando me encuentro copiar y pegar trozos de código con ajustes mínimos que darse cuenta de que es una "partición" y luego crear una clase, método, función, o lo que sea.

En realidad, el enfoque orientado a objetos es todo lo que se trata todo esto. Trate de pensar de su aplicación ya que las cosas tangibles que hacen cosas. Escribir código de pseudo describiendo lo que las cosas son y lo que hacen, me parece un montón de "particiones" de esta manera.

Answer 5

Aquí está un ejemplo, tipo de conjetura salvaje.

La gente suele subestimar el tiempo que les llevará a hacer el trabajo. Si su proyecto es grande, lo más probable es que necesita varias personas para trabajar en él, para que pueda probar la planificación con esto en mente. Ahora una persona puede esperar para mantener una sola área en la cabeza, por lo que tendrá que explicarle exactamente qué tipo de tarea que tiene que hacer.

Así que yo diría que debe tratar de escribir una descripción del trabajo que debe abarcar tanto como sea posible para una persona a concentrarse en serio. Repetir, hasta que haya roto su proyecto en partes que quería. Como ventaja, ya está listo para armar su equipo. Pero si se entera de las piezas son pequeñas, tal vez usted todavía será capaz de hacerlo por sí solo.