programacion - ¿Qué prácticas de codificación OOP siempre debe tener tiempo para hacer?

estandares de programacion (19)

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

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 tomar atajos. 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 excelente 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.

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 descartables (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 estoy predicando al coro.

Como todos los demás han sugerido que estas recomendaciones no son específicas de OOP:

Asegúrese de comentar su código y usar variables con nombres sensatos. 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.

Por lo general, los hacks tienden a ser intrincados y poco intuitivos, por lo que algunos buenos comentarios son esenciales.

También recomendaría que, si generalmente tiene que trabajar con 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

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

Prueba unitaria, prueba unitaria, prueba unitaria. 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.
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.
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 hay innumerables otros "deberes", pero si tuviera que elegir mi top tres, esa sería la lista.

Edite en respuesta al comentario: esta es precisamente la razón por la que debe 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 en la que estar.

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

No es 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.

No es una práctica de OOP, sino de sentido común ;-).

Si tienes prisa, y tienes 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 que sepa por qué se eligió la solución por el momento.

No importa qué tan rápido lo quiera una compañía, casi siempre trato de escribir código lo mejor que puedo.

No creo que tome más tiempo y generalmente ahorra mucho tiempo, incluso a corto plazo.

No recuerdo haber escrito código alguna vez y nunca lo volví a ver, 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 (para algunos grado), la separación de las preocupaciones y la cohesión parecen ahorrar tiempo.

Esto incluye crating muchas clases más pequeñas que la mayoría de las personas (Una preocupación por clase, por favor) y a menudo extrae datos de inicialización en archivos externos (o matrices) y escribe pequeños analizadores para esos datos ... A veces incluso escribiendo pequeñas GUI en lugar de editar datos por 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.

Nombrando 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 verbos para los métodos, naturalmente, ayuda a la encapsulación y la modularidad.

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 script en su código OOP.

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

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 este:

Utilice el control de fuente y escriba comentarios de confirmación. De esta manera tienes un poco de documentación si alguna vez te preguntas "¿qué diablos pensé cuando escribí esto?"
Escriba código o documento limpio. 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
Prueba de unidad. 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).
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.

Pruebas unitarias: te ayuda a dormir por la noche :-)

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 encaja perfectamente con 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.

[inserte aquí una advertencia específica no específica de OOP]

Separación de inquietudes, pruebas unitarias y esa sensación de que si algo es demasiado complejo probablemente no se haya conceptualizado del todo todavía.
Esbozo UML: esto ha aclarado y ahorrado cualquier cantidad de esfuerzo desperdiciado tantas veces. Las fotos son geniales, ¿no? :)
Realmente pensando en is-a''s y has-a''s. Hacer esto bien la primera vez es tan importante.

no hay clase pública con variables públicas variables (estructura-como).

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.

Use el control de Fuente .

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

En casi un año en mi proyecto actual, finalmente establecí una compilación automatizada que impulsa cualquier compromiso nuevo al servidor de prueba y, hombre, desearía haberlo hecho desde el primer día. El error más grande que cometí desde el principio fue oscurecer . 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.

Una práctica real de OOP a la que siempre le dedico tiempo es el Principio de Responsabilidad Individual , porque se vuelve mucho más difícil refactorizar adecuadamente el código más adelante cuando el proyecto está "en vivo".
Al apegarme a este principio, encuentro 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 los requisitos, otras no, y el todo puede no estar del todo claro.

Este tipo de clases son estresantes de mantener porque nunca estás seguro de qué se romperá tu "solución".