¿Obtener una revisión por pares para mi nuevo complemento?

¿Cuál es la mejor manera de que un desarrollador experimentado de WordPress eche un vistazo a mi plugin y haga críticas constructivas? He escrito código para resolver algunas de mis preguntas en este sitio, y creo que también podrían ser útiles para otros. Sin embargo, como lo harían con mis primeros complementos públicos de WordPress, y he visto muchos ejemplos no tan buenos en el directorio público de WordPress, me gustaría saber "dónde estoy parado" y cómo puedo mejorar mis complementos. He leído la lista de mejores prácticas y todavía necesito aplicar algunas de ellas, pero también me gustaría una respuesta a la pregunta más general "¿Es esta una buena manera de resolver este problema?"

Acabo de volver a leer la discusión relacionada sobrewp-hackers (no me di cuenta de que los participantes también estaban tan involucrados en este sitio, y que la pregunta de "mejores prácticas" es un resultado directo). No estoy seguro de que un sistema así cubra mis necesidades, y estoy de acuerdo con las preocupaciones de Paul :

Cuando leí los comentarios originales sobre este hilo la semana pasada, pensé que el propósito era armar un proceso de revisión por pares en el que el desarrollador de complementos pueda ofrecer consejos a otros desarrolladores de complementos como revisión de su código. Originalmente tomé este consejo como algo similar a "Bueno, su código funciona, pero este conjunto de rutinas que ha escrito sería mejor si se conectara a este filtro WP y probara esta técnica (vea el complemento xxx como ejemplo) ". El objetivo que pensé era compartir el conocimiento de desarrollo de complementos de WP y hacer que cualquier desarrollador mediocre de complementos sea un mejor desarrollador. Como yo.

Este sería un alcance diferente al de hacer una revisión de la lista de verificación punto por punto, sería más una "tutoría". Parece que hay muchas personas dispuestas a hacer esto, y (aún mejor) muchas de ellas participan aquí en este sitio, entonces, ¿cómo podemos transformar toda esa energía en algo concreto?

Mi ejemplo actual son tres complementos que escribí para resolver mi problema de "cambio de tamaño de imagen" . Escribí largos comentarios introductorios a cada complemento, lo que (espero) hace que sea más fácil entender mis intenciones sin leer el código completo. ¿Hay algo más que pueda hacer para que otros puedan verlo más fácilmente? Ignore mi solicitud concreta actual. No solo es demasiado pronto para ellos, sino que cambié de opinión y no quiero estropear la discusión general con mi situación específica.

La forma más fácil es un enfoque de dos pasos:

1. Libere su complemento al público. Una vez que esté en vivo, comenzará a recibir comentarios de los usuarios finales además de los desarrolladores. Si lo desea, publíquelo como una versión "beta" y haga hincapié en eso en el archivo Léame.
2. Pedir. Hay desarrolladores veteranos de WordPress en todas partes: aquí, en la lista de WP-Hackers, en trabajos de WordPress , acosando a @wordpress en Twitter, etc. Es solo cuestión de lanzar su complemento y pedir comentarios.

En general, siga los mismos pasos que seguiría si un desarrollador observara un parche Core:

• Escribelo
• Documentarlo
• Póngase en contacto con un desarrollador (ya sea a través de uno de los canales anteriores o directamente si puede) y solicite comentarios

En cuanto a transformar el tipo de "tutoría" que ocurre en este sitio en algo más concreto, sería un proceso orgánico. Como ya ha mencionado, los esfuerzos para crear una especie de proceso de revisión de complementos antes de revisar cualquier cosa parecen haberse estancado. La única manera de conseguir cualquier cosa fuera de la tierra es en realidad empezar a hacerlo. Así que no solo hable de encontrar un desarrollador veterano y obtener comentarios, salga, encuentre uno, obtenga sus comentarios y escriba cómo fue el proceso.

Luego se puede repetir con futuros complementos y futuros desarrolladores. Pero tienes que comenzar en alguna parte ...

Después de un rápido vistazo a https://gist.github.com/675437 vi algunos puntos menores, principalmente sobre la legibilidad:

• Escriba buena documentación de código: Docblocks ... y comentarios en línea siempre que algo no esté absolutamente claro.
• Dividir las funciones de looong en funciones separadas más cortas. Son más fáciles de leer y abordar en los comentarios de los revisores.
• Alinee sus operadores de asignación, agregue espacios en blanco entre paréntesis.
• ¡80 caracteres de longitud de línea, por favor! Eclipse todavía no puede ajustar largas líneas. :(
• Mantenga su código »izquierda«, guarde las sangrías. En vez de:

.  

public function checkUrl()
{
    if (is_404()) {
        // code
    }
}

… escribir …

public function checkUrl()
{
    if ( ! is_404() ) {
        return;
    }
    // code
}

He escrito un nuevo complemento esta noche ... y me preguntaba si podría hacer exactamente su pregunta. Buen tiempo. :)

Simplemente me hizo pensar en Appscan: http://www01.ibm.com/software/rational/products/appscan/source/ ; http://www-01.ibm.com/software/rational/products/appscan/source/features/ versión de prueba de light: http://www-01.ibm.com/software/awdtools/appscan/express/

Esto puede hacer php y uno puede poner reglas adicionales para verificar las cosas. De esa manera, una parte puede automatizarse (como algunas mejores prácticas como en la respuesta de toscho), puede verificar la seguridad, los estándares de codificación, las optimizaciones, etc.

Solo digo: si una herramienta puede verificar el 80%, entonces el 20% de las verificaciones manuales para un gurú sería menor. También ayudaría a generar informes de cumplimiento para el uso de un complemento dentro de una gran empresa que exige este tipo de cosas en torno a código adicional.

Automatizamos las cosas para otras personas, ¿por qué no para nosotros mismos?