¿Qué prácticas de codificación OOP siempre debe tener en cuenta?

Question

Tiendo a hacer muchos proyectos en plazos cortos y con muchos códigos que nunca volverán a usarse, por lo que siempre hay presión/tentación de cortar las esquinas. Una regla a la que siempre me apego es la encapsulación/acoplamiento flexible, así que tengo muchas clases pequeñas en lugar de una única clase de Dios gigante. ¿Pero a qué más no debería comprometerme?

Actualización - gracias por la gran respuesta. Mucha gente ha sugerido pruebas unitarias, pero no creo que eso sea realmente apropiado para el tipo de codificación de IU que hago. Las pruebas de usabilidad/aceptación del usuario parecen ser muy importantes. Para reiterar, estoy hablando del MÍNIMO MÍNIMO de estándares de codificación para proyectos de fecha límite imposibles.

Answer 1

No OOP, pero una práctica que ayuda tanto a corto como a largo plazo es DRY, Do not Repeat Yourself. No use la herencia copiar/pegar.

Answer 2

no hay clase pública con variables públicas mutables (struct-like).

Antes de que te des cuenta, te refieres a esta variable pública en todo tu código, y el día que decidas que este campo es computed y debe tener algo de lógica en él ... la refactorización se vuelve desordenada.

Si ese día es anterior a la fecha de lanzamiento, se vuelve más complicado.

Answer 3

No es una práctica de POO, pero tiene sentido común ;-).

Si tiene prisa y tiene que escribir un truco. Siempre agregue un comentario con los motivos. Entonces puede rastrearlo y hacer una buena solución más adelante.

Si nunca tuvo tiempo de regresar, siempre tiene el comentario para saber por qué se eligió la solución por el momento.

Answer 4

Las pruebas unitarias - ayuda a dormir por la noche :-)

Answer 5

Esto es bastante obvio (espero), pero por lo menos yo siempre asegurarse de que mi interfaz pública es lo más correcta posible. Las partes internas de una clase siempre se pueden refactorizar más adelante.

Answer 6

Utilice el control de código fuente.

No importa cuánto tiempo lleve configurar (segundos ...), ¡siempre hará su vida más fácil! (Todavía no está relacionado con OOP).

Answer 7

Para este caso especial (plazos cortos y con muchos códigos que nunca volverán a usarse), le sugiero que preste atención a incorporar algún motor de scripts en su código OOP.

Answer 8

Piensa en las personas (incluso puede ser tu yo futuro) que tienen que leer y comprender el código en algún momento.

Answer 9

Como todos los demás, no tanto las prácticas de OOP, sino también las prácticas de codificación que se aplican a OOP.

1. Unidad de prueba, prueba de unidad, unidad de prueba. Las pruebas unitarias definidas tienen el hábito de mantener a las personas enfocadas en la tarea y no "vagar" sin rumbo entre los objetos.
2. Defina y documente toda la información jerárquica (espacios de nombres, paquetes, estructuras de carpetas, etc.) antes de escribir el código de producción. Esto ayuda a dar cuerpo a las relaciones de objeto y exponer fallas en suposiciones relacionadas con las relaciones de los objetos.
3. Defina y documente todas las interfaces aplicables antes de escribir el código de producción. Si lo hace un líder o un arquitecto, esta práctica también puede ayudar a mantener a más desarrolladores de primer nivel en la tarea.

Probablemente haya muchos otros "deberes", pero si tuviera que elegir mi top tres, esa sería la lista.

Editar en respuesta al comentario: Esta es precisamente la razón por lo que necesita hacer estas cosas por adelantado. Todos estos tipos de prácticas facilitan el mantenimiento continuo. A medida que asume más riesgo en el inicio de un proyecto, es más probable que pase más y más tiempo manteniendo el código. De acuerdo, hay un costo inicial mayor, pero construir sobre una base sólida se paga por sí mismo. ¿Su obstáculo es la falta de tiempo (es decir, tener que mantener otras aplicaciones) o una decisión de más arriba? He tenido que luchar en ambos frentes para poder adoptar este tipo de prácticas, y no es una situación agradable estar en.

Answer 10

Naming. Bajo presión escribirás un código horrible que no tendrás tiempo para documentar o incluso comentar. Nombrar variables, métodos y clases tan explícitamente como sea posible no requiere casi ningún tiempo adicional y hará que el problema sea legible cuando deba solucionarlo. Desde el punto de vista de OOP, el uso de sustantivos para las clases y los verbos de los métodos, naturalmente, ayuda a la encapsulación y la modularidad.

Answer 11

Al igual que todos los demás han sugerido estas recomendaciones no son específicos de programación orientada a objetos:

Asegúrese de que usted comenta su código y utiliza las variables sensiblemente con nombre. Si alguna vez tiene que mirar hacia atrás en el código rápido y sucio que ha escrito, debería ser capaz de entenderlo fácilmente. Una regla general que sigo es; si borraste todo el código y solo te quedaban los comentarios, aún así podrías entender el flujo del programa.

Los hacks suelen ser intrincados y poco intuitivos, por lo que algunos buenos comentarios son esenciales.

También recomendaría que, si normalmente tiene que trabajar a plazos ajustados, obtenga una biblioteca de códigos creada en función de sus tareas más comunes. Esto le permitirá "unir los puntos" en lugar de reinventar la rueda cada vez que tenga un proyecto.

Saludos,

Docta

Answer 12

[repetitivo inserción salvedad específica no-POO aquí]

• separación de las preocupaciones, las pruebas unitarias, y esa sensación de que si algo es demasiado complejo es probablemente no conceptualizado bastante bien todavía.

• UML sketching: esto ha aclarado y ha ahorrado cualquier cantidad de esfuerzo desperdiciado tantas veces. Las fotos son geniales, ¿no? :)

• Realmente pensando en es-a's y has-a's. Hacer esto bien la primera vez es tan importante.

Answer 13

No importa lo rápido que una empresa quiere, yo más o menos siempre trato de escribir código para el mejor de mi capacidad.

No me parece que lleve más tiempo y generalmente ahorra mucho tiempo, incluso a corto plazo.

No recuerdo haber escrito código alguna vez y nunca volver a verlo, siempre hago algunos pases para probarlo y depurarlo, e incluso en esos pocos pases prácticas como la refactorización para mantener mi código SECO, la documentación (hasta cierto punto), la separación de preocupaciones y la cohesión parecen ahorrar tiempo.

Esto incluye encapsular muchas clases más pequeñas que la mayoría de las personas (una preocupación por clase, por favor) y a menudo extraer datos de inicialización en archivos externos (o matrices) y escribir pequeños analizadores para esos datos ... A veces incluso escribiendo pequeñas GUI de editar datos a mano.

La codificación en sí misma es bastante rápida y fácil, la depuración de errores que alguien escribió cuando estaban "bajo presión" es lo que toma todo el tiempo.

Answer 14

Aplicación del principio de responsabilidad única. La aplicación efectiva de este principio genera muchas externalidades positivas.

Answer 15

Aprenda a "refactorizar sobre la marcha". Principalmente desde el punto de vista del "método de extracción". Cuando empiece a escribir un bloque de código secuencial, tómese unos segundos para decidir si este bloque podría ser independiente como método reutilizable y, de ser así, realice ese método de inmediato. Lo recomiendo incluso para proyectos desechables (especialmente si puede volver más tarde y compilar tales métodos en su API de la caja de herramientas personal). No pasa mucho tiempo antes de que lo hagas casi sin pensar.

Espero que ya hagas esto y yo estoy predicando al coro.

Answer 16

En casi un año en mi proyecto actual finalmente configuré una compilación automatizada que empuja cualquier nueva confirmación al servidor de prueba, y hombre, ojalá lo hubiera hecho desde el primer día. El mayor error que cometí desde el principio fue going dark. Con cada función, mejora, corrección de errores, etc., tuve un caso grave de "solo una moral" antes de permitir que cualquiera viera el producto, y literalmente se convirtió en un ciclo de seis meses. Si todos los cambios razonables se hubieran eliminado automáticamente, habría sido más difícil para mí esconderme, y habría estado más encaminado con respecto a la participación de las partes interesadas.

Answer 17

Por supuesto, todo debe ser probado por la unidad, bien diseñado, comentado, controlado en el control de la fuente y libre de errores. Pero la vida no es así.

mi ranking personal es la siguiente: Utilice el control de la fuente

1. y en realidad escribir comentarios comprometerse. De esta manera tienes un poco de documentación si alguna vez te preguntas "¿qué diablos pensé cuando escribí esto?"
2. Escribir código limpio o documento. El código limpio y bien escrito debería necesitar poca documentación, ya que su significado puede entenderse al leerlo. Los hacks son muy diferentes. Escriba por qué lo hizo, qué hace y qué le gustaría hacer si tuviera el tiempo/conocimiento/motivación/... para hacerlo bien
3. Prueba unitaria. Sí, está abajo en el número tres. No porque no sea importante, sino porque es inútil si no tienes los otros dos al menos hasta la mitad. Las pruebas de unidad de escritura es otro nivel de documentación que debe estar haciendo el código (entre otros).
4. Refactor antes de agregar algo. Esto podría sonar como un punto típico "pero no tenemos tiempo para eso". Pero como con muchos de esos puntos, generalmente ahorra más tiempo de lo que cuesta. Al menos si tienes al menos alguna experiencia con eso.

Soy consciente de que gran parte de esto ya se ha mencionado, pero dado que es un asunto bastante subjetivo, quería agregar mi clasificación.

Answer 18

Regrese al código que escribió hace unos días/semanas y dedique 20 minutos a revisar su propio código. Con el paso del tiempo, podrá determinar si su código "fuera del manguito" está lo suficientemente bien organizado para futuros esfuerzos de mantenimiento. Mientras estás allí, busca oportunidades de refactorización y cambio de nombre.

A veces encuentro que el nombre que elegí para una función desde el principio no se ajusta perfectamente a la función en su forma final. Con las herramientas de refactorización, puede cambiar fácilmente el nombre antes de que se generalice su uso.

Answer 19

Una práctica actual de OOP que siempre hago tiempo para es la Single Responsibility Principle, porque se vuelve mucho más difícil refactorizar el código más tarde cuando el proyecto está "en vivo".
Al seguir este principio, me parece que el código que escribo se reutiliza, reemplaza o reescribe fácilmente si no cumple con los requisitos funcionales o no funcionales. Cuando termina con clases que tienen responsabilidades múltiples, algunas pueden cumplir con los requisitos, otras no, y el todo puede no estar del todo claro.

Este tipo de clases son estresantes de mantener porque nunca está seguro de cuál será su "solución".