¿Cómo planificar mi proyecto basado en web antes de iniciar el código?

Question

Mi amigo y yo comenzamos a trabajar juntos como socios. Hemos decidido crear el sitio web Kick-as * después del sitio web. Tenemos las ideas escritas como 100 de ellas (sí, elegimos mejor y más fácil entre ellas primero).

Mi amigo hace el diseño de diseño y organiza las cosas, y mi parte es la gestión de codificación y servidor.

El pequeño problema que estoy enfrentando es la falta de experiencia en planear un proyecto. Lo que hago es, simplemente empiezo el código de inmediato y junto con el código hago DB, como cuando necesito una tabla lo hago.

Sé que este es un enfoque muy malo para un proyecto de tamaño mediano.

Aquí en stackoverflow vi muchos codificadores con experiencia. Necesito aprender mucho de ustedes :)

Así que puede ayudarme a planificar un proyecto y qué estándares/estructuras/marcos de codificación usar (código PHP).

Gracias de antemano.

Answer 1

Comience definiendo el alcance. Escribe un párrafo en una página e intenta describir tu sitio web. Un enfoque de arriba hacia abajo sería comenzar a pensar en la funcionalidad que le gustaría implementar y refinarla agregando más detalles.

Un enfoque de arriba hacia abajo (también conocido como diseño paso a paso) es esencialmente la descomposición de un sistema para obtener información sobre sus subsistemas de composición. En un enfoque descendente, primero se formula una visión general del sistema, especificando pero sin detallar ningún subsistema de primer nivel. Luego, cada subsistema se refina con mayor detalle, a veces en muchos niveles de subsistemas adicionales, hasta que toda la especificación se reduce a elementos básicos. Un modelo de arriba hacia abajo a menudo se especifica con la ayuda de "cajas negras", que facilitan la manipulación. Sin embargo, las cajas negras pueden no dilucidar los mecanismos elementales o ser lo suficientemente detalladas como para validar de manera realista el modelo. http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design.

Hay muchos otros enfoques, sin embargo.

http://en.wikipedia.org/wiki/Software_project_management#Software_development_process

Una vez más, el paso más importante es ser capaz de poner su idea en palabras; antes de poder hacer eso adecuadamente, ni siquiera consideraría comenzar a escribir una línea del código.

Answer 2

Algunos pensamientos de alguien que ama las abstracciones.

Descubre lo que tus sitios web tendrán en común. Una vez que haya identificado las características comunes principales, busque marcos o bibliotecas que traten con la mayor cantidad de ellos posible (además de llenar sus otros criterios), como el código DB estándar.

Para las características comunes de que no se puede encontrar ningún código listo para usar (siempre existen en sitios web personalizados), usted tendrá la oportunidad de escribir una biblioteca común para usarla en sus sitios web. Esta podría ser una plantilla para su marcado, una biblioteca JavaScript o un componente reutilizable del lado del servidor, o todos juntos.

Según su descripción, parece que disfruta de una gran libertad en el proceso creativo (en lugar de obtener una especificación de requisitos entregada y solicitada para implementarla).Yo diría que tampoco hay que planear, "comenzar a codificar de inmediato" es muy divertido y no del todo malo. La experiencia será tu mejor amigo, y cuando llegues al sitio web n. ° 100, tendrás mucha. Al crear su segundo sitio web, sus experiencias con el primero le ayudarán a evitar cometer algunos de los errores que cometió, y descubrirá nuevas similitudes que no anticipó en la fase de planificación. Solo asegúrese de tomarse el tiempo, mover el código común a una sola biblioteca, y regresar y editar su primer sitio web para usarlo. Haga esto varias veces y habrá aprendido lecciones que valen mucho.

Answer 3

En cuanto a la codificación estándar/estructura/marcos, recomiendo zend framework coding standard, MVC structure y Zend Framework.

Una breve guía para una arquitectura MVC. La idea es ayudarlo a recordar ideas (mientras su cerebro está utilizando el código) y tener documentos para futuros programadores.

• Diseñe la base de datos. Haz un diagrama de ER. Ponlo en un documento.
  describen brevemente las razones detrás del diseño de los temas importantes (¿por qué elige una relación polimórfica, ¿por qué utilizar este punto de vista, lo selecciona esperas que son más trickey etc.). Esto cambiará a medida que codifique (y no hay nada que pueda hacer). Documenta los cambios. Para hacer frente a los cambios, utilice un sistema de control de versiones para la base de datos como rails migrations.

• Diseño de la estructura de su sitio web (secciones, páginas, enlaces, página flujos etc.). Documentarlo. (Como: "el Sitio 2 secciones, esta sección está hecha de ...", etc.)
  En base a esta crea un documento que describe los controladores y puntos de vista. ("un controlador para artículos, con una vista de lista y una vista de artículo, también edita y crea vistas, pero solo para administradores", etc.).
  Describa cómo va a exigir la autenticación y la autorización (en el nivel de controlador y vista). Quién está permitido donde.
  Describa cómo se protege contra los principales ataques web (xss, csrf) cuando sea necesario. (ejemplo: "escapo todas mis variables de vista usando htmlentities para la protección xss y ...")

• Diseñe sus modelos y funciones secundarias (envío de correos electrónicos, trabajos en segundo plano, etc.). Estos serán la mayor parte del código. Documente cada uno y describa los principales problemas (por ejemplo, cómo se manejarán las zonas horarias, cómo este determinado modelo se conectará al servicio monetario, cómo ese modelo debe analizar y manipular algún archivo crone, qué algoritmo usará para decidir los 5 primeros artículos, dependiendo de su aplicación) describen lo que las bibliotecas que utiliza, cómo y para qué fines (ejemplo:. "vamos a usar curl para el desguace de SO y hacer rss feed")
  Describe cómo se protege frente a las principales web ataques donde sea necesario (sql-injection, xss).

Como codifica, las cosas cambian. Su conocimiento sobre los trabajos discretos de su sistema evoluciona y usted comienza a mejorar el diseño basado en la nueva iluminación encontrada. Documenta tus cambios.