php - remove - strip_tags()
Lo que vale la pena invertir tiempo al comenzar un nuevo proyecto (6)
¿Cuánta preparación es demasiado, cuán poco es demasiado poco?
Depende de la experiencia y la complejidad / tamaño del proyecto. Con un enfoque ágil, debe planificar la aplicación más simple que le dé a su cliente (o usuario) algo de valor y que se ajuste a un ciclo de lanzamiento corto (1-3 semanas). Ya tiene un prototipo y maquetas, por lo que sus casos de uso y requisitos son algo claros. Pero aún debe planificar un subconjunto de su aplicación que se realizará dentro de un plazo definido. Si planeas grandes planes por adelantado, enfrentarás algunos problemas difíciles que probablemente te retrasarán. Eso es porque intentas diseñar tu software para el problema. Pero a menudo encontrará una solución mucho más sencilla si realmente tiene que hacer frente al problema o desaparecerá porque algunos requisitos han cambiado o se han simplificado. Imagina que escribes una aplicación de blog. Obviamente quieres un widget WYSIWYG para ello. Por adelantado, dedica tiempo a evaluar las soluciones existentes o incluso a escribir una usted mismo. Al final, resulta que a la mayoría de los usuarios les gusta seguir con el texto plano o solicitar un marcado simplificado. Has pasado 3 días a varias semanas por nada. Comience de manera muy básica y simple, sabrá cuándo la gente necesita algo más sofisticado.
¿En qué aspectos de alto rendimiento debemos centrarnos al inicio de nuestro proyecto?
No estoy seguro acerca de esa pregunta. Si hablas de bases de datos y diseño de OO, entonces no debería ser una gran recompensa. Por lo general, un esquema simple de db se ensambla en minutos y evoluciona con el tiempo (incluida la re-factorización, la normalización). Lo mismo ocurre con su arquitectura. De nuevo, esto depende de su experiencia, si no sabe mucho acerca de la normalización de datos o cómo aplicar MVC (incluso en un nivel muy bajo), debería educarse un poco.
¿Cómo debemos juzgar en qué vale la pena trabajar, código inteligente (no características), en esta etapa de desarrollo?
Mantenlo simple. Aprender un marco de pila completo (como Symfony o Cake) puede ahorrar mucho tiempo, pero todos tienen una curva de aprendizaje decente y se encontrará con problemas que no son triviales (al menos para el escalado / rendimiento). Una base de código abstracta decente no siempre es necesaria ni útil, para mí es suficiente si es comprobable. Con pequeños proyectos de hobby o cosas experimentales, abrazar la simplicidad de php.
¿Vale la pena pasar el tiempo implementando cosas como xCSS y otros sistemas que harían más fácil escribir código limpio desde el principio?
No me malinterpretes, siempre es bueno aprender algo nuevo. Pero el código limpio comienza en su cabeza, la forma en que piensa, maneja y resuelve los problemas. xCSS es solo un juguete que consumirá tiempo para aprender e introducirá otros problemas. También tenga en cuenta que debe encontrar a alguien que pueda usarlo si desea delegar tareas de diseño.
A lo largo de los años, me he vuelto más y más conservador de estas herramientas y bibliotecas. Por lo general, se encontrará con algunas limitaciones o problemas y tendrá que implementar soluciones alternativas feas o tendrá que buscar y entender toda la fuente. Si te da un gran valor, podría valer la pena, pero como dije, xCSS es un juguete.
¿Cómo le explicaría el valor de las tareas de grano fino y cometer pequeños cambios atómicos?
Tal vez esto sea un malentendido de uno de ustedes o de ambos. El grano fino no significa que debe cometer cada método de obtención / establecimiento o cualquier método nuevo por separado. Por lo general, es un compromiso lógico coherente (que debería funcionar).
Ejemplos:
- error # 2134 corregido: contraseña de administrador vacía
- Modelo de libro básico añadido con pruebas.
- Lógica añadida al modelo Book, todas las pruebas que pasan.
- agregó otra prueba de libro
- código base migrado al libro
- archivo funcs_book.php heredado
- Controlador frontal refactorizado para soportar funciones como controlador.
Las confirmaciones y los comentarios deberían facilitar la tarea de descubrir cuándo se introdujeron los errores o cuándo ha cambiado un código base específico. Una buena regla es tener una línea como comentario, lo que es bastante útil para analizar los registros de SCM. Con confirmaciones grandes e incoherentes que tienen comentarios detallados o incluso anónimos, prácticamente se ve obligado a mirar los conjuntos de cambios. También es posible exportar cambios específicos como parches que son fáciles de aplicar a otras sucursales o incluso repositorios.
¿Qué cosas has hecho con tu código que te han llevado a un envío más rápido?
- no tenga miedo de tirar código legado o ilegible (con SCM)
- use librerías de proveedores solo para tareas difíciles o complejas
- refactor regularmente
- No hagas que se vea elegante, hazlo simple
- abraza tu idioma a veces funciona> clase
Creo que el libro solo habla de características mínimas, pero él siente que también se trata del diseño de código.
Piensa holístico. Una GUI simple con características concisas funciona bien porque es accesible y fácil de entender. Es fácil entender un bucle básico para en tres líneas, pero un árbol de objetos abstractos que involucra docenas de indirectas es difícil. Muchos desarrolladores no lo admiten, pero es muy difícil. Gran diseño de código de planificación en el frente está muerto. La refactorización y las pruebas unitarias deben impulsar su diseño en una aplicación en evolución. Sin embargo, tener lápiz y papel a mano para intercambiar ideas durante unos minutos para encontrar una solución siempre es saludable.
Actualizar:
Grandes respuestas hasta ahora todo el mundo! Cada uno ha sido realmente útil para llegar a la raíz del problema y ayudar a asegurar que tanto mi pareja como yo estemos en la misma página. Creo que en gran parte fue que no habíamos hablado de nuestras intenciones reales con los cronogramas de lanzamiento y el flujo de trabajo general.
Al hacer esto, he llegado a una serie de preguntas relacionadas que nunca pensé en abordar y podría hacer más publicaciones más adelante (probablemente en programmers-stack-exchange )
Backstory:
Estoy trabajando en una aplicación web con un amigo de la universidad.
Estamos desarrollando nuestro sitio usando MySQL y PHP, y planeamos usar algo de jQuery para el front-end. Nos dirigimos a celulares y tablet-pc. Eventualmente involucrará una gran cantidad de datos de fuentes múltiples. Prefiero no decir mucho sobre las ideas específicas del proyecto. (Por favor, comenta sobre esto si crees que debería dar más detalles).
Tenemos un prototipo, y tenemos algunas maquetas de GUI. Nuestra idea a la vez nos rasca la picazón y parece ser algo que nunca se intentó antes.
Nuestro problema:
Esperamos seguir los principios del libro "REWORK" de 37signals. Una gran parte del libro es la idea de sacar un producto temprano. Explica por qué debemos centrarnos en el núcleo de nuestro producto y en que debemos ignorar todas las cosas adicionales.
Básicamente, la idea de hacer lo mínimo posible para un producto vendible para que podamos enviar y comenzar a recibir comentarios. Ambos tenemos diferentes puntos de vista sobre lo que esto significa, y nos está llevando a diferentes direcciones.
Creo que el libro solo habla de características mínimas, pero él siente que también se trata del diseño de código. Creo que vale la pena hacer algunas cosas ahora para acelerar las cosas, pero él quiere que nos apresuremos lo más rápido que podamos y saltemos esos problemas por completo.
Quiero hacer un poco de trabajo de preparación debido a la cantidad de ahorro de tiempo que llevaría más adelante. Como comenzar con OO, diseñar un esquema de base de datos completo y dedicar tiempo a configurar cosas como xCSS y desglosar nuestro problema en pasos individuales.
[De la forma en que lo entendí:] Él quiere apurarse incluso si eso significa escribir código horrible / descuidado siempre y cuando el diseño salga por la puerta. No quiere quedarse atascado en la infraestructura de código básico o refactorizar a medida que avanzamos o los principios DRY. Él no quiere pasar el tiempo para decidir qué debe hacerse, solo quiere hacerlo. Él piensa que cometer pequeños cambios en svn es solo una sobrecarga, por ejemplo.
Entiendo que no quiere que nos dejemos atrapar por perder el tiempo haciendo un sistema perfecto, pero creo que esto va demasiado lejos, y no es lo que defiende 37signals.
Es esencialmente un problema de tortuga vs liebre y no sé cómo explicarle que se va a disparar a sí mismo si no hace al menos algunas opciones sencillas de diseño de código de ahorro de tiempo, rompe el problema y funciona. en ella en pequeños trozos discretos.
Él es un buen desarrollador de lo contrario, y es capaz de hacerlo bien.
Mis preguntas:
¿Cuánta preparación es demasiado, cuán poco es demasiado poco?
¿En qué aspectos de alto rendimiento debemos centrarnos al inicio de nuestro proyecto?
¿Cómo debemos juzgar en qué vale la pena trabajar, código inteligente (no características), en esta etapa de desarrollo?
¿Vale la pena pasar el tiempo implementando cosas como xCSS y otros sistemas que harían más fácil escribir código limpio desde el principio?
¿Cómo le explicaría el valor de las tareas de grano fino y cometer pequeños cambios atómicos?
¿Qué cosas has hecho con tu código que te han llevado a un envío más rápido?
Las mejores respuestas:
Aceptaré la respuesta que cambie su mente lo mejor. Siéntase libre de responder cualquier pregunta que haya enumerado, y obtenga puntos de bonificación por ejemplos en nuestros idiomas específicos. Las referencias a otros trabajos de 37 señales pueden ser útiles.
¡Grande ver a otro fan de 37signals!
Aquí hay una cita de su libro en línea, Getting Real :
Las personas a menudo pasan demasiado tiempo al frente tratando de resolver problemas que aún no tienen. No lo hagas ¡Caramba, lanzamos Basecamp sin la capacidad de facturar a los clientes! Dado que el producto se facturó en ciclos mensuales, sabíamos que teníamos una brecha de 30 días para resolverlo
Básicamente, decide una fecha de lanzamiento . Reduzca el alcance total de su aplicación al mínimo que se requiere para lanzar en esa fecha. Esto le ayudará a obtener la aplicación a tiempo, y le dará datos en vivo para trabajar.
Si tiene la parte del alcance resuelta y desea centrarse en los problemas de codificación, debería echar un vistazo a esta sección en particular, Gestión de la deuda :
Está bien [hackear un código malo que aún funciona] de vez en cuando. De hecho, a menudo es una técnica necesaria que lo ayuda a hacer todo el asunto de Get-Real-ASAP. Pero aún debe reconocerlo como deuda y pagarlo en algún momento al limpiar el código de pelos o al rediseñar esa página regular.
En resumen, rechace la implementación de xCSS al principio, pero asegúrese de volver a ella más adelante. Lea los capítulos nueve y diez en "Interfaz" y "Código".
Finalmente, mi cita favorita del libro:
Construye medio producto, no medio producto. Lo que realmente quieres hacer es construir la mitad de un producto que patea el culo.
Espero que ustedes construyan un gran producto que puedan mostrar al mundo. Resolver problemas como estos rápidamente también es otra excelente manera de ahorrar tiempo. :)
Como la intención es lanzarlo rápidamente y desarrollarlo, diría que es de suma importancia utilizar las tecnologías que mejor conozca. Si eres un gran programador de OO, usa OO. Si realmente entiende las bases de datos, dedique unas horas a diseñar el esquema.
Lo único que puede garantizar absolutamente es que el código cambiará. IME aprovechar una carga de código y luego tirar la mitad es un enfoque mucho mejor que tratar de diseñar código elegante para un problema que aún no se comprende del todo. El código descuidado será reemplazado y tiene el doble propósito de liberar algo y ayudarlo a comprender lo que está haciendo.
Demasiada preparación es cuando pasas horas / días buscando algo y no encuentras una respuesta. Solución: Ve con tu primera impresión.
Para decidir en qué trabajar en código, es el código que está directamente relacionado con las características clave.
No, no vale la pena aprender nada (por ejemplo, xCSS) que no conozca bien. Es mejor usar algo que entienda y refine este conocimiento con el tiempo y luego contratar expertos reales .
Habiendo dicho todo lo anterior, lo único con lo que siempre comenzaría es tener capas para mantener separados el DB, la lógica y la interfaz de usuario. Cuando empecé con PHP, me gustaría tener un pequeño marco para hacer todas las cosas tediosas (Db, etc.) No tenía uno, así que finalmente publiqué mi trabajo como código abierto. Por supuesto, sugeriría leer cómo crear Db / Logic / UI usando mi marco como ejemplo.
Diría que el tema principal en el que debe enfocarse para convencer a su amigo es "Estimación y planificación ágiles". Mucha gente cree que ser ágil significa estrictamente sin planificación, lo cual no es cierto. Scrum: un marco de desarrollo de software basado en principios ágiles sugiere que cada proyecto comience con un plan de lanzamiento. La mayoría de sus preguntas serán respondidas en base a la Guía Scrum.
¿Cuánta preparación es demasiado
Demos un paso atrás para entender lo que significa "preparación", tiene un significado más profundo que solo una gran sesión de planificación y diseño. La preparación significaría: Planificación de la liberación de Scrum, Planificación de Sprint o Iteración, Planificación de reuniones diarias de Scrum. Realmente nunca detienes tu trabajo de "preparación", continúa. En el momento en que no puede planificar, ese es el momento en que planea fallar. La planificación de lanzamientos de Scrum generalmente no requiere más del 15-20% del tiempo que una organización consume para crear un plan de lanzamientos tradicional. En esta reunión, le sugiero que escriba una historia de usuario de Business EPIC, y también una historia de usuario de Technical EPIC, y las divida en trozos con bastante rapidez. No necesita entrar en detalles, los detalles se tratarán en Sprint Planning. Durante la Planificación de Sprint, solo prepare las historias de usuario de alta prioridad al nivel de detalle correcto y comprométase a completarlas en su iteración actual. Sprint Planning no debe durar más de 4 horas para una iteración de 2 semanas. Y las reuniones diarias de sincronización de Scrum solo durarían 15 minutos, ya que son solo ustedes dos, podría ser más corto.
que poco es muy poco
Usted sabría que se "preparó" muy poco cuando se vuele con impedimentos cuando en realidad trata de hacer el trabajo, durante la iteración. Cuando las cosas van bien, sabes que pasaste la cantidad correcta de tiempo preparando.
¿En qué aspectos de alto rendimiento debemos centrarnos al inicio de nuestro proyecto?
Intente centrarse en responder a esta simple pregunta a continuación: “¿Cómo podemos convertir la visión en un producto ganador de la mejor manera posible? La historia de usuario de Business EPIC, historia técnica de EPIC: esta sería su visión de producto desde un punto de vista técnico y de infraestructura. Por ejemplo, ¿va a utilizar TDD, plan de integración continua, plan de control de versiones, etc.? Nunca puede ignorarlos, por mucho que lo intente. Otra cosa es averiguar quiénes son los usuarios de sus productos. ROI y penalización de historias de usuarios de alta prioridad. Realice los criterios para su producto, que también se aplicarían a una pequeña parte de su producto. Puedo seguir y seguir, así que me detendré aquí.
¿Cómo debemos juzgar en qué vale la pena trabajar, código inteligente (no características), en esta etapa de desarrollo?
En cuanto al código, lo más valioso para trabajar sería el código requerido para que se codifique, para que la característica de mayor valor funcione y se pueda enviar. Puede hacerlo calculando el ROI y la penalización de no hacerlo. Deberá saber quiénes serán los usuarios, el beneficio de la característica para los usuarios y el impacto en los usuarios si la característica se entrega o no. Mayor ROI y penalización - mayor valor. Sé que es más fácil decirlo que hacerlo, pero ¿quién dijo que el negocio del software era fácil?
¿Vale la pena pasar el tiempo implementando cosas como xCSS y otros sistemas que harían más fácil escribir código limpio desde el principio?
Si quieres ser ágil entonces sí. Código limpio significa menos deuda técnica y mayor calidad de software. Agile sugiere que los desarrolladores presten atención constante a la calidad del código. ¿Por qué? Debido a que las personas que escribieron los principios de Agile habían visto demasiados proyectos fracasados debido a que no se hicieron cargo de la deuda técnica desde el principio en el proceso de desarrollo de software.
¿Cómo le explicaría el valor de las tareas de grano fino y cometer pequeños cambios atómicos?
Una colección de tareas de grano fino asociadas con una historia de usuario, que cuando se realiza en base a los criterios realizados, produciría una porción de software enviable.
Lo explicaría así: Piensa en tu producto como un pastel de múltiples capas. Antes de que empieces a construir el pastel completo, necesitas saber qué sabor tendrá el pastel y cuántos tipos de capas tendrá. El sabor son las pantallas simuladas y las historias de usuario de EPIC, y las capas surgen de la historia de EPIC técnico. Las capas serían Base de datos, middleware, código del lado del servidor, html, máscaras, etc. Ahora construir la torta completa de una sola vez sería una mala idea porque los clientes amantes de la torta a menudo cambian de opinión sobre qué tipo de torta quieren comer. Una tarta entera puede demorar más que una pequeña rebanada, y ¿qué pasa si después de construir la totalidad, digamos una Torta de chocolate, el cliente pide una tarta de zanahoria? Eso haría un poco de torta o código :) En su lugar, ¿por qué no construir una pequeña rebanada vertical a la vez, dejar que el cliente la pruebe, obtener alguna retroalimentación, modificar la siguiente pieza en consecuencia y seguir agregando rebanada por rebanada para crear un todo Pastel, que el cliente realmente quiere !!
¿Qué cosas has hecho con tu código que te han llevado a un envío más rápido?
Se utilizaron diseños desacoplados, se utilizó la herencia de la interfaz más que la herencia de clases, revisión de código, TDD, PMD, estilo de verificación, programación de pares, colaboración con el cliente, y la lista continúa. Todas estas cosas lo llevan a que su producto sea "Hecho". Cuanto más se salte de los artículos anteriores para más adelante, más lejos estará presionando la fecha de envío. Preferiría entregar una rebanada de pastel deliciosa y de alta calidad al cliente, en lugar de una rebanada de baja calidad, aún no hecha.
Encuentra de 5 a 10 personas que crees que estarán interesadas en tu sitio para probarlo. Si no puedes hacer esto, ustedes dos no tienen nada de qué discutir.
Ponerlo frente a los usuarios debe abordar dos problemas:
- Tenga suficientes funciones para que los usuarios obtengan lo que hará su programa.
- Haga que la interfaz de usuario sea atractiva y el rendimiento sea lo suficientemente bueno como para que crean que usted sabe lo que está haciendo.
Los desconocidos totales serán obviamente más críticos y nunca volverán a tu sitio si los pospones. Aquellos más cercanos a ti te darán la segunda o tercera oportunidad. Si desea crear un clon de Facebook, por lo menos debe cargar fotos y compartirlas. Esperando 20 seg. para que la página principal cargue una imagen de su gato, es necesario que el usuario escriba manualmente la ruta completa del archivo y demorar 5 minutos en cargar un archivo jpeg de 100 KB enviará a los usuarios a un clic.
No tengo respuestas específicas a tus puntos, pero en mi opinión, ''demasiado'' es algo que no sea lo que te lleva al ''código de trabajo''
¡Obtenga lo más simple y sensacional de todo lo que esté en funcionamiento lo antes posible!
Deje que el código sea feo; será reemplazado de todos modos Deje que el diseño se vea como la parte inferior de un perro: será reemplazado de todos modos Deje que las cosas no estén validadas y no sean seguras: será reemplazado de todos modos
La idea es poner en funcionamiento un prototipo interno tan pronto como sea posible. Si se puede omitir y aún "usa el núcleo de la idea" en un navegador o lo que sea, entonces omítelo.
Una vez que tienes algo funcionando, no importa lo desagradable, ese es el paso 1 completado.
El paso 2 es circular: vuelve a lo que ya has escrito y hazlo mejor. Luego, vaya al paso 2
La única parte que no me saltaba en el Paso 1 son las pruebas unitarias, y eso es porque uso las pruebas unitarias para dejar de lado mi idea de qué código debería hacer, antes de codificarlo. Una vez que la prueba de la unidad pasa, esa parte está lista - ¡SIGUIENTE!
El paso 2 implica volver a escribir el código para que sea más limpio, y maneja más casos de borde, y se actualiza, mantiene y construye con mayor facilidad. Todo esto involucra las pruebas unitarias (y usualmente implica reescribir las pruebas unitarias)
Básicamente, su amigo tiene razón, excepto cuando se trata de pruebas de unidad / integración