En primer lugar, quiero decir que estoy acostumbrado a hacer programación de procedimientos como mi pasatiempo: estoy tratando de aprender OOP en un par de idiomas y entender la teoría , pero no la práctica.
Tengo un proyecto favorito que quería construir, específicamente en PHP con un backend de base de datos (no me importaba cuál). Mi razón principal era que la aplicación se usara en cualquier dispositivo, por lo que una aplicación web parecía la opción lógica.
Entiendo que para construir PHP WebApps mantenibles, debe usar OOP, clases, marcos, bibliotecas, etc. Esto suena lógico, así que decido probar algunos de los más populares. Sin embargo, después de todo un fin de semana de solo probarlos y tratar de completar los tutoriales, me siento confundido y frustrado tratando de adaptar los tutoriales a mi pequeño proyecto.
Decidí, principalmente por una prueba de concepto, construir la aplicación en otro programa (Microsoft Access), y logré mis objetivos principales en solo un par de horas, excepto el elemento web.
Mi pregunta es, ¿debería seguir el camino de lo que sé, luego intentar implementar las prácticas de codificación correctas, o debería comenzar con las buenas prácticas de codificación y tratar de evitarlo? Para este proyecto, me gustaría que fuera Open Sourced en GitHub, por lo que estaría abierto a otras personas que usan y cambian mi código, pero también sé que si el código está mal escrito, sería difícil reunir codificadores para ayudar.
fuente
Respuestas:
Las mejores prácticas son en su mayoría sugerencias y propuestas recopiladas de la experiencia para ayudar a que los proyectos * sean más fáciles de realizar.
Los aspectos clave de este en mi humilde opinión es la parte de la experiencia. Aunque estas mejores prácticas son buenas maneras para que las personas con más experiencia lo compartan con los principiantes, creo que todavía se necesita un nivel mínimo de experiencia para comprender realmente lo que hace que esta sea una mejor práctica. Hacer lo contrario equivale a seguirlos ciegamente como un estado de derecho que, al final, creo que ralentizará su aprendizaje a medida que lentamente permita que otros piensen por usted.
En cualquier caso, lo más importante que debo hacer en un proyecto de software para mí es ... bueno ... terminarlo, enviarlo ... en pocas palabras, ¡hacerlo funcionar!
Cualquier cosa antes de ese punto es vaporware, un producto de tu imaginación. Solo una vez que tiene algo que funciona puede evaluar realmente si es lento, difícil de mantener, difícil de probar, etc. El proceso de hacer que funcione expondrá cosas para las cuales, tal vez, existe una mejor práctica que lo ayudaría a repensarlo. de manera que sea más fácil alcanzar esa meta.
Entonces sí, comience con lo que sabe primero, tome nota de las cosas que hace que son difíciles. Cuando golpeas una pared, da un paso atrás y mira esa pared, aprende de qué está hecha. En muchos casos, se dará cuenta de que USTED es la raíz del problema. Su falta de comprensión de alguna parte del problema que está tratando de resolver, su falta de conocimiento sobre cómo puede aprovechar mejor las herramientas que tiene o su ignorancia de otras herramientas que están justo debajo de su nariz todo el tiempo pero que no estaban listas para comienzan su dominio.
Al mismo tiempo, sigue leyendo sobre nuevas formas de hacer las cosas. Lea estas mejores prácticas e intente ver si se aplican a algo que le resulte difícil en su proyecto. Si no, recuerde su existencia y revíselos de vez en cuando. Mantente curioso. Con el tiempo verá que las observaciones realizadas anteriormente simplemente hacen clic naturalmente con el conocimiento que adquiere aquí.
Por último, experimente con lo que ha aprendido y vea si simplifica las cosas. sigue así y eventualmente leerás las mejores prácticas para lo que son. Solo consejos simples de personas que han sufrido y aprendido una manera de hacerlo más fácil. Diablos, incluso puede estar en desacuerdo con algunos de ellos y ver que su camino realmente funciona mejor para usted. Pero sin conocimiento estás caminando ciego.
buena suerte
fuente
TL; DR
Nunca lo sabrás todo. Casi siempre hay más profundidad y amplitud en torno a cada "cosa" individual que puedes conocer. Aprende sobre la marcha. Aplique las "mejores prácticas" que considere relevantes ahora. Cometer errores. Solo trata de evitar cometer errores realmente costosos . Encuentre mentores si su proyecto puede conducir a errores costosos.
Y ahora la respuesta larga ...
1. "El software de trabajo es la medida principal del progreso". ( Manifiesto ágil )
Si puede ver los límites de su conocimiento, ¡eso es increíble! ¡Persigue los bordes! ¡Seguir aprendiendo! Pero tenga en cuenta que podría aprender y analizar para siempre .
Construye algo.
2. Aprender y cometer errores; pero no hagas los "malos". *
Sigue empujando los límites de tu conocimiento / habilidad. Usted va a cometer errores. Puedes aprender de ellos. Pero, no necesitas ser imprudente .
El tiempo que pasa buscando y trabajando con desarrolladores y mentores más experimentados debe aumentar en proporción al valor comercial y al perfil de riesgo del proyecto.
Si está haciendo una pequeña CLI para usted : haga que funcione como quiera.
Si está escribiendo el portal web de un banco: Rodéese de desarrolladores muy experimentados.
3. Las "mejores prácticas" deben escribirse entre comillas y hablarse con un guiño.
Las "prácticas" se promueven a "mejores prácticas" cuando se observa que tienen éxito en lograr X en al menos algunos casos. Alguien reconoce el beneficio de la Práctica A para lograr el Beneficio X y declara que la práctica es una "mejor práctica" en Internet. Otros están de acuerdo, a menudo por una buena razón. Pero, a partir de ese momento, generalmente perdemos de vista por qué algunas prácticas son "mejores prácticas" y otras son "antipatrones" o "apestosas".
El problema es que una "mejor práctica" nunca es egoísta. Los "antipatrones" no son en realidad diabólicos en sí mismos. Y, incluso un "hedor" solo a veces proviene de la podredumbre. A veces, ese olor es solo un queso delicioso y delicioso ...
No practica cosas como "inyección de dependencia" (DI) porque la "inyección de dependencia" es inherentemente valiosa para el negocio. Ni siquiera es remotamente esencial para construir un producto que funcione. Logra algo que quizás desee en su producto final. Pero, también podría hacer que su trabajo tarde más sin ningún beneficio ...
Hmm ...
Entonces, ¿debería seguir las "mejores prácticas"? ¿Incluso si no los entiendes? ... Err ... sí. Quiero decir, no. Pero si. Pero, solo los que realmente se aplican a usted y su software y su propósito.
¡ Invoca al POAP ! (Sí. Mi blog).
Por lo tanto, es posible que no comprenda todos los matices de DI, por ejemplo. Pero, si comprende la intención, sabrá si "debería" usar DI, y entenderá implícitamente mejor DI.
Y, una vez que haya lanzado el producto, puede reflexionar sobre si DI (o lo que sea) fue realmente beneficioso. Si es así, articule por qué por escrito. Si no, articule por qué por escrito ...
Lectura adicional / Algo relevante:
La parálisis de análisis es una cosa. Necesitas analizar y aprender; pero, también necesitas hacer cosas. Equilibrar.
Siempre puedes sentirte como un codificador de vaqueros .
* En realidad se va a hacer grandes errores si lo hace notar nada. Pero, eres humano, supongo. Entonces, te perdonamos por adelantado ... O, al menos, lo hago. Tal vez. ... Bueno ... ya veremos.
fuente
¿Quizás intentes lo mejor pero aún así envías algo? Hay dos fuerzas diferentes entre cómo los usuarios evalúan la calidad y el atractivo de un producto y cómo los desarrolladores detrás de él evalúan la calidad del código. Intenta hacer que estas dos fuerzas sean lo más armoniosas posible. Centrarse demasiado en uno a expensas del otro suele ser la forma en que termina con las rutas más contraproducentes.
fuente
Bueno, en primer lugar, sugeriría que adoptar buenas prácticas de codificación no es una falsificación ... El truco es comprender el propósito de cada práctica y cómo implementarla adecuadamente.
Los entornos de desarrollo rápido de aplicaciones son seductores, porque puedes hacer mucho en muy poco tiempo. Construí todo un sistema de contabilidad en Access una vez. Pero usted mismo lo dijo: no puede llevar una aplicación como esa a la web sin una reescritura, y las herramientas que necesita allí son realmente diferentes.
Hay razones por las que ya nadie usa herramientas de diseño visual como Access o Visual Basic. Tienden a aislarlo del código que realmente logra algo. El acceso es una buena herramienta, pero requiere lo que las aplicaciones web están específicamente diseñadas para evitar: la instalación. La personalización de su apariencia puede ser difícil; incluso si no lo necesita en la web, una aplicación de Access siempre se parecerá mucho a cualquier otra aplicación de Access. La mayoría de las personas que escriben su primera aplicación de Access no saben lo suficiente como para escribir una buena aplicación, y Access hace que sea fácil escribir una mala.
Así que ahora está resignado a aprender una nueva tecnología para obtener su aplicación en la web. ¿Deberías construirlo de la manera correcta desde el principio? Por supuesto. Pero aprender un nuevo entorno de desarrollo y filosofía es como aprender cualquier otra cosa; tienes que inclinarlo por un tiempo para hacer las cosas bien.
Por eso creo que has planteado una falsa dicotomía. Nadie aprende todas las "mejores prácticas" primero. Los aprenden a medida que avanzan. Pero para ser productivo en cualquier lenguaje OOP, creo que necesitará saber algo de OOP, o al menos cómo funcionan fundamentalmente las clases.
Por lo que vale, no creo que PHP sea su mejor opción. PHP es atractivo porque es "superficial", lo que significa que no tienes que saber mucho para escribir un programa de trabajo. Las mejores prácticas se dejan en gran medida al desarrollador, lo que significa que PHP no lo ayudará a escribir programas "buenos". Esto no es necesariamente algo malo, pero sí significa que, al igual que Access, también puede estar abandonando PHP para una plataforma más robusta.
fuente
Considere la POO como un patrón más que puede aplicar en el momento adecuado. OOP no es un marco que pueda resolver metódicamente todas las tareas. Tal cosa no existe en la ingeniería de software.
También tenga en cuenta que lo que la gente dice ser buenas prácticas a veces es cuestionable. A menudo he visto desarrolladores inexpertos que adoptan patrones de programación muy complicados que no eran necesarios para el problema dado. La complejidad del código debe ser apropiada para la complejidad del problema. La simplicidad es un valor importante.
Los artículos en la web, las declaraciones de expertos de la industria y el asesoramiento de colegas de alto rango pueden estar equivocados. He visto esto mucho.
Por lo tanto, le recomiendo que aplique la solución más simple que resuelva su problema. Probablemente, esto abarcará el uso de uno de los marcos populares en su espacio. Dentro de esta restricción, puede elegir libremente qué tipo de código le gusta. No piense simplemente que su forma de hacerlo es apropiada para su caso.
Además, comprenda por qué se recomiendan ciertas técnicas. Por ejemplo, OOP se trata de encapsulación. Puede encapsular de otras maneras (los procedimientos también se refieren a la encapsulación).
Un ejemplo negativo: a veces las personas escriben una capa de acceso a datos para abstraer la base de datos. Aquí, la esencia de este patrón es independizarse del almacén de datos concreto y exponer una interfaz más simple a capas de código superiores. Pero si no necesita estos beneficios, no necesita una capa de acceso a datos y puede guardar el trabajo. Sin embargo, muchos expertos recomiendan hacer siempre un DAL, que es una recomendación incorrecta.
Creo que a menudo es divertido trabajar con un buen código. Es divertido porque puedes trabajar en los requisitos reales en lugar de atender las preocupaciones de infraestructura. Si descubres que lo que estás haciendo es demasiado trabajo duro, entonces es probable que hayas elegido un conjunto de patrones incorrecto.
fuente