Cómo mantener organizado su flujo de trabajo de codificación

 

 

 

  • ¡Registro!
  • Listas de verificación de diseño de interfaz inteligente

  • Índice
    1. Principios generales
    2. Una talla no sirve para todos
    3. Tu cliente
    4. Entonces, ¿qué hay en un sitio web como este?
      1. Imágenes
      2. Hojas de estilo
      3. javascript
      4. Plantillas
      5. Activos
      6. La base de datos
      7. El sistema de gestión de contenidos
      8. La sección de administración
      9. El código
    5. El diseño final de la carpeta
    6. Resumen rápido
      1. Otras lecturas

    Vaya, usamos la palabra "organizado" en el título. Es hora de desconectarse, es probablemente lo que muchos pensarían. Ser organizado es un tema algo aburrido, aunque importante. Quizás ayudaría darle un poco de contexto.

     

    Mantengamos la clase e imaginemos que estamos creando un sitio web para un restaurante/café de moda llamado “bEat”, dirigido a la comunidad artística. Es un lugar atmosférico con arte de los años 20 en sus paredes interiores de ladrillo, jazz en vivo y clientes adinerados. Pero no tienen un gran sitio web, por lo que te llamaron para salvar el día. Como diseñador talentoso, estás seguro de que podrás crear un diseño fantástico que les encantará, pero tienen muchas ideas inteligentes sobre la funcionalidad del sitio web y no estás tan seguro de ello. cómo organizar todos los archivos que necesitará su sitio web.

     

    Deben poder editar el contenido ellos mismos, subir imágenes para las publicaciones semanales de su blog y contenido nuevo. Bastante normal hasta ahora. También necesitan conectarse a Twitter, para que las publicaciones de sus blogs se tuiteen automáticamente. Necesitan una aplicación móvil para iPhone y Android porque sus clientes utilizan un teléfono inteligente y quieren ofrecer ofertas especiales y menús directamente en sus teléfonos inteligentes. En el futuro, les gustaría que sus clientes envíen reseñas, con posibles imágenes, enlaces, etc. Un montón de cosas interesantes e interactivas de redes sociales, amigos y videos en línea enviados por los usuarios.

    'Facebook para restaurantes' dicen, a modo de facilitarte la comprensión. Ok, en ese punto, probablemente les dirías que hagan perder el tiempo a otra persona. Pero se entiende la idea.

    Quizás en el pasado haya intentado crear un sitio web más complejo y de vanguardia como este, y el proyecto comenzó con gran entusiasmo, pero terminó en un desastre de pesadilla que no pudo mantener. Su cliente perdió interés cuando empezó a resultar demasiado difícil agregar nuevas funciones y usted empezó a tener que trabajar hasta altas horas de la noche, rastreando errores para los que ni siquiera podía encontrar el archivo relevante.

    Después de un proyecto como ese, no es difícil ver la relevancia de un proyecto de sitio web bien organizado.

    Principios generales

    Mantenga todo simple y claro. No organices demasiado: algunos sitios web y frameworks parecen tener una necesidad masoquista de hacer de todo una abstracción teóricamente perfecta. En términos prácticos, eso normalmente significa que es imposible trabajar con él.

    Si comienzas a crear decenas (o cientos) de archivos pequeños, cada uno de los cuales no contiene más que una pequeña clase o función, definitivamente te estás exagerando. Si sus archivos y carpetas tienen nombres demasiado abstractos o genéricos, entonces las cosas probablemente estén empezando a ponerse un poco tontas. Por ejemplo, si el código para verificar el inicio de sesión de un administrador de un sitio web está almacenado en un archivo llamado WebsiteData/Items/GenericUser/AdminUser/Code/Auth.phpentonces has cometido ambos pecados. ¿Por qué no simplemente una función llamada check_login()en el archivo code/users.php?

    No mezcle diferentes aspectos de su sitio web. Mantenga los módulos de funcionalidad separados y mantenga los diferentes idiomas en archivos separados. Recientemente ayudé en un proyecto en el que un programador pobre y equivocado mezcló CSS , ASP VB Script, JavaScript, HTML y SQL en un gran revoltijo, todo en un único, enorme y mal sangrado archivo. No estoy exagerando. Basta de charla.

    Una talla no sirve para todos

    La profundidad de la jerarquía de carpetas y la cantidad de archivos individuales deben tener sentido para el tamaño del sitio web. Mantenlo en perspectiva.

     

    A continuación se incluye una lista rápida de algunos tamaños aproximados típicos de sitios web y cómo se pueden estructurar las cosas en consecuencia.

    • Sitio web de 1 página . Crea una carpeta para imágenes, un solo archivo para CSS, otro para JavaScript, otro para contenido y otro solo archivo para código. Definitivamente no vale la pena separar la plantilla y el contenido, a menos que tengas requisitos específicos.
    • Sitio web de 5 páginas . Una carpeta para imágenes, un archivo para código CSS, JS. Considere colocar sus archivos de contenido en una carpeta separada. Nuevamente, por lo general no hay mucha necesidad de plantillas aquí. En esta etapa, asegúrese de tener una plantilla para el encabezado y pie de página de su página (y cualquier otro elemento común en todas las páginas).
    • Sitio web de 20 páginas . Una carpeta para imágenes, otra carpeta para cargas y otros archivos relacionados con el negocio (“activos”), otra carpeta para contenido (o es posible que en esta etapa esté utilizando un CMS basado en una base de datos). Su JavaScript, código y hojas de estilo probablemente se estén volviendo lo suficientemente complejos en esta etapa como para considerar colocarlos en una carpeta separada. Nombra las carpetas con algo inmediatamente obvio, por ejemplo css/, javascript/, . code/Asegúrate de que todos los archivos vayan a sus carpetas relevantes. No debería tener un archivo .js perdido, por ejemplo, en la content/carpeta, sólo porque sea conveniente. Si sus plantillas o código no le permiten organizar sus archivos de la manera que necesita, realice una refactorización rápida del código para que funcione. Evite colocar CSS, plantillas, diseño e imágenes de diseño, o JavaScript en (o assets/o uploads/, resources/dependiendo en cómo lo llames). Estos archivos son efectivamente código en el que su cliente nunca debería tener que pensar, y la assets/carpeta es para archivos y medios relacionados con el negocio. Conviértalo en una regla de oro para su flujo de trabajo y cúmplalo.
    • Aplicación web de 20 páginas . Es muy similar a lo anterior, pero en esta etapa definitivamente deberías colocar todo tu código en una carpeta separada. Asegúrese de que no esté dentro de una carpeta donde Apache pueda servir accidentalmente los archivos sin formato cuando algún script-kiddie tenga un retoque.
    • Sitio web de 100 páginas . Deberías estar utilizando un buen CMS para tu contenido en esta etapa. No importa si se trata de un CMS basado en bases de datos o en archivos, pero si es lo último, asegúrese de que los archivos de contenido estén bien organizados y de poder definir metadatos para títulos de páginas individuales, descripciones, etc., o su Los esfuerzos de SEO serán muy difíciles. Probablemente ya estés empezando a tener varias secciones diferentes en tu sitio web. Probablemente necesitarás comenzar a descomponer las hojas de estilo, JavaScript, imágenes de diseño y plantillas en archivos y carpetas separados. Asegúrese de que estas carpetas coincidan entre sí y con las secciones de su sitio web, o lo que tenga más sentido para su sitio web en particular. Usar un lenguaje CSS como Sass o LESS también es una muy buena idea en esta etapa.
    • Sitio web de más de 2500 páginas . Definitivamente deberías pensar en contratar algunas personas dedicadas a ciertos aspectos del sitio web, como un editor de contenido, diseñador, programador y experto en SEO. También querrás que tu contenido esté en un CMS basado en una base de datos en esta etapa, si aún no lo está. Comenzarás a ser el gerente y a que otras personas realicen la mayor parte del trabajo. Asegúrese de contar con sistemas que funcionen sin problemas que le permitan revisar su trabajo y editarlo antes de que entre en funcionamiento.
    • Sitio web de más de 100.000.000 páginas . Eres Microsoft. Ya deberías saber lo que estás haciendo.

    La mayoría de los sitios web pequeños crecen muy rápidamente a más de 20 páginas, si se les da mantenimiento activo; cuando haya agregado un par de páginas de preguntas frecuentes, algunos pequeños fragmentos de contenido para explicar algo con mayor profundidad y uno o dos productos, se suma rápidamente.

     

    En ese sentido, considere estructurar todos sus sitios web pequeños como un sitio web de (aproximadamente) 20 páginas, a menos que sepa que el proyecto es un sitio web rápido y único, como un sitio de información para un próximo evento o una página para su cumpleaños de la esposa. Planifique el crecimiento, pero no una curva de crecimiento tipo palo de hockey .

    Tu cliente

    Debes tener una carpeta para cada cliente, sin relación con el proyecto real en el que estás trabajando para ellos. Dentro de esta carpeta, tendrás una carpeta para cada proyecto. Inicialmente, solo habrá una carpeta llamada website/, pero en poco tiempo, es posible que tenga otras carpetas llamadas logo/, reports/, competitive analysis/, etc. También tiene sentido colocar sus archivos de diseño en esta carpeta, tal vez en design/o graphics/.

    No haga que Apache pueda acceder a esta carpeta. Contendrá información sensible .

    Dependiendo del marco que utilice, es posible que desee colocar el código en esta carpeta para mantenerlo fuera de la carpeta de su sitio web. Podrías llamarlo code/o, si crees que habrá código separado para otros proyectos, website-code/. Si la mayoría de sus otros proyectos están relacionados con el diseño o los negocios, entonces probablemente no tendrán ningún código, aparte de algún script extraño que no necesitaría una carpeta separada.

    Además de la carpeta de trabajo del cliente, es posible que desee tener una carpeta completamente separada para los documentos que no desea que su cliente vea. Es posible que compartas regularmente documentos relacionados con el trabajo con tu cliente y es muy probable que en algún momento quieras darle acceso a toda su carpeta (y algunos clientes te lo pedirán: "¿Puedes comprimir todos mis archivos?" archivos y enviarlos? Sólo quiero asegurarme de tener una copia de todo”). En lugar de arriesgarse a enviarles accidentalmente el archivo "10 cosas que odio de estos chicos.doc", colóquelo en la carpeta privada de su cliente.

     

    Para resumir rápidamente, aquí hay un ejemplo de estructura que estamos viendo actualmente:

    YourBusiness/ Accounts/ Documents/ Customers/ bEat/ Minutes/ 10 things I hate about these guys.doc Proposal.doc CustomerProjects/ bEat/ website/ ... this is the bit we’ll be discussing .... code/ ... and this ... reports/ graphics/

    Entonces, ¿qué hay en un sitio web como este?

    De ahora en adelante, hablaremos de las carpetas “código/” y “sitio web/” enumeradas anteriormente.

    Imágenes

    Hay (casi siempre) dos tipos de imágenes: las que forman parte del diseño y las que forman parte del contenido ofrecido en el sitio web. Este último debería ir a su carpeta de activos (o cargas o medios), tal vez en un pictures/subdirectorio. Para las imágenes de diseño, rara vez necesitarás desviarte del camino trillado: colócalas todas dentro images/.

    Si su diseño es un poco más complejo, es posible que tenga imágenes para botones, íconos, navegación, fondo de página, etc. En ese caso, rápidamente obtendrá más de 10 o 20 imágenes en esta carpeta, así que considere dividirla en subcarpetas. . Todavía está bien tener imágenes de uso general en el nivel superior, pero las subcarpetas te ayudarán a mantener el control de todos tus millones de archivos pequeños. Nombra los archivos con nombres sensatos y fáciles de recordar, como form-warning-icon.png.

    Hojas de estilo

    Para la mayoría de los sitios, no es necesario que sus hojas de estilo sean muy grandes. Para un sitio pequeño, o incluso un sitio más grande, sin muchas secciones diferentes (cada una con un diseño diferente), a menudo te saldrás con la tuya con un solo archivo para tu CSS. Si este es el caso, simplemente nómbrelo main.csso styles.css.

    Aun así, a mucha gente le gusta dividir sus hojas de estilo en varios archivos. Hay maneras diferentes de hacer esto. Una opción popular es una hoja de estilo para el diseño, otra para la tipografía y otra para los colores. Esta es una buena idea, pero se vuelve difícil de manejar en la práctica: terminas definiendo muchas de tus clases 3 (o más) veces y rastrear errores puede ser una pesadilla.

    Creo que una mejor opción es separar los estilos de "diseño" y "contenido". El "diseño" incluye elementos como navegación, encabezado y pie de página, barras laterales, cuadros y secciones. El "contenido" incluye elementos como párrafos, títulos, citas en bloque, listas, imágenes flotantes y enlaces. Si lleva esto un poco más allá, también tiene sentido tener un archivo para estilos de “formularios”. Sin embargo, a medida que el contenido en la web se vuelve mucho más interactivo, la línea entre formularios y contenido (¡sin juego de palabras!) se está borrando rápidamente. Blog sobre salud

     

    De nuevo, llame a las cosas por su nombre y nombre estos archivos como layout.css, content.cssy forms.css. Si les da nombres un tanto vagos como ,,, presentation.csssiempre tendrá que pensar primero antes de decidir en qué archivo buscar.model.csspage.css

    A veces resulta útil tener un archivo CSS individual para páginas especiales que tienen sus propios requisitos de diseño. Esto puede suponer más problemas de los que merece la pena, dependiendo de la complejidad de la página. Si se encuentra navegando entre pestañas en su editor, tratando de encontrar el archivo CSS correcto para un elemento en particular, entonces podría ser mejor simplificar su CSS. Además, considere seriamente usar Sass o LESS para hacer que su CSS sea mucho más hermoso y limpio.

    Probablemente también tendrá hojas de estilo separadas para diferentes medios, y es absolutamente necesario que vayan en archivos separados. Como de costumbre, asígneles un nombre sensato, como print.css .

    Si tiene varios archivos CSS, eso es genial, pero asegúrese de utilizar una herramienta automatizada para fusionarlos todos en un solo archivo antes de publicarlos, o la velocidad de descarga de su sitio web se verá afectada. No fusiones tu CSS bellamente factorizado a mano. Eso es usar un Mechanical Turk para un trabajo que las computadoras hacen fácilmente. Podrías usar Minify (PHP) o Juicer (Ruby) para eso.

    javascript

    Hay mucho en común entre la organización de los archivos JavaScript y CSS de muchos sitios web. Ambos tienen propósitos similares (pero diferentes), ambos son entregados al navegador para que los interprete, ambos interactúan con el DOM (cuando se usan apropiadamente), a menudo interactúan entre sí. JavaScript se usa a menudo para agregar funcionalidad exactamente al mismo conjunto de elementos que se usa para diseñar CSS.

    Generalmente terminarás teniendo tu archivo de biblioteca JavaScript ( jquery.js, mootools.jsetc.), un par de widgets (por ejemplo datepicker.jsy dropdown.js) y algún código específico del sitio (por ejemplo my-image-slider.js). Definitivamente tiene sentido mantenerlos en archivos separados, aunque a menudo tendrás tan poco JavaScript específico del sitio que tiene sentido tener solo un archivo para esa parte.

    Coloque todos estos archivos en una carpeta llamada JavaScript/. Suponiendo que utiliza una biblioteca de terceros como jQuery, muy rara vez creará un sitio lo suficientemente complejo como para subdividir más esta carpeta.

    Plantillas

    Las plantillas no son contenido, no son código y no son presentación. Las plantillas pueden tener ciertos aspectos de todas esas cosas, pero sólo una mínima pista, cuando se usan correctamente. Puede resultar útil pensar en sus plantillas como esqueletos. El código del lado del servidor completa estas plantillas con contenido (contenido de la base de datos, mensajes de error, valores de campos de formulario, etc.) y el navegador aplica una apariencia estética para lograr el resultado final.

     

    Por supuesto, sus plantillas pueden tener algún fragmento de texto legible por humanos, para un botón, menú desplegable o lo que sea. Está bien: ese tipo de texto tiende a estar estrechamente asociado con la función de la página, más que con el contenido.

    Coloque las plantillas en una templates/carpeta. A pesar de lo que dije anteriormente, las plantillas son en realidad código del lado del servidor (son confidenciales), así que asegúrese de que no sean accesibles públicamente.

    Si su sitio web envía correos electrónicos, tenga un par de subcarpetas en esta carpeta para plantillas de correo electrónico HTML y de texto sin formato. Si su sitio web es más que un simple sitio web de folletos, necesitará muchas plantillas para las diferentes páginas y pantallas de su aplicación. Si tiene una versión para teléfono inteligente de su sitio, tenga una subcarpeta para él. Estructura estas subcarpetas adecuadamente. He aquí un buen ejemplo:

    templates/ blog/ sidebar.tpl post.tpl comment.tpl emails-plaintext/ subscribe.tpl change-password.tpl emails-html/ subscribe.tpl change-password.tpl social/ twitter-feed.tpl facebook-sidebar.tpl mobile/ base.tpl contact.tpl customer-profile.tpl friend.tpl homepage.tpl reviews.tpl base.tpl contact.tpl customer-profile.tpl friend.tpl homepage.tpl reviews.tpl

    Activos

    Este es un nombre que realmente no me gusta, aunque las alternativas no son necesariamente mucho mejores. Esta es la carpeta donde coloca todo el audio, video, documentos, imágenes y cualquier otro contenido no textual (o no HTML), generalmente específico de la empresa, que desea que esté disponible públicamente en su sitio web.

    Algunas alternativas de nombres son uploads/, resources/, files/, media/. O podrías dividirlo en carpetas principales separadas, llamadas pictures/, audio/etc., pero eso se complica bastante rápido. Sin embargo, suele ser bueno tener subcarpetas para diferentes tipos de archivos.

    Tiendo a usar resources/personalmente, pero es un poco abstracto. No es un muy buen nombre, aunque mejor que assets/(¿qué somos, contables?). Sin embargo, assets/es casi un estándar de la industria, y si tuviera que empezar de nuevo, probablemente eso sería lo que usaría. Entonces, por el bien de este artículo, sigamos con eso.

    Si se trata sólo de un sitio web para una pequeña empresa sin preocupaciones masivas de gestión de contenidos, entonces la seguridad de estos documentos no es una preocupación. Si es así, entonces deberías tener esos documentos confidenciales en una carpeta completamente diferente.

    Si tiene un sitio web de mayor escala que necesita acceso basado en permisos a diferentes contenidos disponibles, entonces debería utilizar algún tipo de sistema de gestión de documentos.

    En vista de esto, es perfectamente seguro hacer que esta carpeta sea accesible públicamente desde su sitio web. Su cliente debería poder cargar elementos en esta carpeta por sí mismo y vincularlos a través del CMS.

    Si no tiene muchos documentos que no sean web, entonces no tiene sentido subdividir más esta carpeta. Sin embargo, si tiene muchos de estos archivos, tiene sentido tener subcarpetas con nombres como photos/, pdfs/etc.videos/

     

    La base de datos

    Este artículo no trata realmente sobre el diseño de bases de datos, por lo que no trataremos mucho de esto aquí. Pero es importante mantener su base de datos bien estructurada. Haría bien en utilizar un ORM en casi todas las situaciones: muy pocos sitios web tienen requisitos de datos lo suficientemente inusuales como para necesitar algo que un ORM no pueda lograr. De todos modos, cualquier buen ORM puede lograr prácticamente cualquier cosa que la base de datos subyacente pueda lograr.

    SQLite es una excelente opción para la mayoría de los sitios web, porque es fácil de implementar, existe como un archivo simple en su sistema de archivos (pero es una base de datos relacional con todas las funciones) y es fácil de realizar copias de seguridad (no es necesario importar/exportar, a menos que desee (Para: simplemente use una solución de copia de seguridad de archivos estándar. Por supuesto, ya tiene una, ¿verdad?)

    Nombra tu base de datos del mismo modo que le pusiste a la carpeta de tu proyecto. No tenga una base de datos separada para cada aspecto de su sitio web, pero sí tenga una base de datos separada para cada sitio web que desarrolle. Como siempre, manténgalo simple, use palabras cortas y completas como nombres y no abarrote las cosas con todo tipo de prefijos y sufijos adicionales.

    El sistema de gestión de contenidos

    Estos bebés generalmente se encargan de organizarse solos. Pero utilice un CMS que esté decentemente estructurado y bien codificado. Si utiliza un CMS basado en archivos, coloque todo su contenido en un subdirectorio, por ejemplo content/.

    La sección de administración

    Casi todo el mundo guarda los archivos administrativos en admin/, cuando es necesario. Si tienes una sección de administración, haz lo mismo. No tenga código duplicado, imágenes, JavaScript, etc. para el administrador. Obviamente, para las partes de la sección de administración que son diferentes, necesitará tener código adicional, etc. Pero debe ser parte de la misma base de código y estar factorizado de manera que pueda usar las funciones auxiliares desde cualquier parte del sitio web.

    Para reflexionar: es posible que no necesites una sección de administración en absoluto. Por ejemplo, si su cliente necesita cargar y editar fotos, ¿por qué no proporcionar un enlace de "editar" justo al lado de la foto? Lo mismo ocurre con las publicaciones, comentarios, etc. Por supuesto, asegúrese de tener una autorización y autenticación sólidas.

    El código

    Uf. ¿Dónde empiezo? El desarrollo de software es un campo completo de conocimiento en sí mismo, y el software se encuentra entre las cosas más difíciles de mantener organizadas en el universo conocido. Ni siquiera comenzaré a cubrir todo el terreno aquí.

    Sin embargo, las reglas siguen siendo las mismas: si es posible, no ocultes archivos en lo más profundo de una jerarquía, nombra tus archivos usando sustantivos cortos y concretos. Utilice subcarpetas cuando sea necesario, pero para la mayoría de los sitios web no debería tener tanto código. Mantente al tanto de ello. Asegúrese de utilizar los mismos nombres para las mismas cosas; si ha llamado a la tabla de la base de datos users, no nombre el archivo relevante members.php. Nombralo users.php.

     

    Una buena factorización es, con diferencia, el aspecto más importante para mantener el software organizado y cubre todos los niveles de su código, desde las carpetas hasta los nombres que elige para sus variables. Es el factor decisivo más importante que separa a los programadores competentes de los inexpertos. Ve a aprender todo sobre esto.

    Algunas cosas para guardar en sus propios archivos y carpetas independientes:

    • Tu modelo de datos. Si tiene mucha lógica adjunta a cada tipo de objeto, probablemente querrá tener un archivo separado para cada clase principal.
    • Tus “puntos de vista” (como los llama Django). Estos son "controladores" en lenguaje MVC. Brevemente, una "vista" es cualquier código específico de una URL en particular.
    • Clases y funciones de uso general.
    • Tu código de biblioteca. Probablemente esto ni siquiera debería estar dentro de la carpeta de su proyecto o cliente; debería tener una colección de código de biblioteca que utilice en todo el sistema, para no tener que administrar múltiples copias de lo mismo.
    • Código de biblioteca de terceros.

    Utilice un sistema de control de versiones, como SubVersion . Para obtener información sobre el control de versiones, tómese el tiempo de leer la guía de control de versiones para diseñadores web .

    Los archivos aquí a menudo tendrán archivos correspondientes en su carpeta de plantillas, aunque no siempre habrá una coincidencia uno a uno. Sin embargo, cuando lo haya, utilice el mismo nombre para ambos archivos.

    Mantenga su código fuera de cualquier carpeta de acceso público. ¿Realmente quieres que todos encuentren todos los inevitables agujeros de seguridad en tu código? No mezcle HTML, CSS o Javascript con el código del lado del servidor, ni viceversa.

    El diseño final de la carpeta

    Por supuesto, debes considerar la situación dada para determinar qué es lo mejor para el proyecto. El siguiente ejemplo no está completo y existe únicamente para darle una idea de lo que hemos discutido.

    bEat/ website/ images/ boxes/ /* often still necessary for IE... */ red-bottom-left.png red-bottom-right.png red-top-left.png red-top-right.png navigation/ navigation-sprite.png background.png logo.png page-background.png twirly-list-dot.png css/ layout.css content.css print.css mobile.css javascript/ jquery.js datepicker.js site.js assets/ pictures/ videos/ pdfs/ templates/ blog/ emails-plaintext/ emails-html/ social/ mobile/ *.tpl content/ code/ *.php reports/ graphics/

    Lo mismo, en forma más breve:

     

    bEat/ website/ images/ css/ javascript/ assets/ templates/ content/ code/

    Es cierto que parece bastante básico cuando lo reduces a eso. Pero las consecuencias de hacerlo mal pueden costar mucho tiempo y esfuerzo. Puede descargar la plantilla de carpeta de proyecto de muestra (.zip), un sitio web PHP esquelético, con una única página de contenido, basada en la biblioteca de plantillas H2O.

    Quizás te guste más la siguiente alternativa. Tiene la ventaja de mantener todo para un solo proyecto dentro de un solo proyecto, a costa de poner todos los archivos estáticos en un nivel más profundo. Si pasas mucho tiempo trabajando con CSS y JavaScript, puede que no te resulte tan útil, pero es una cuestión de qué es importante para tu proyecto y para tu negocio.

    bEat/ website/ static/ /* name it "public/" if you prefer */ images/ css/ javascript/ assets/ content/ templates/ code/

    Resumen rápido

    • Mantenlo ordenado. No vuelvas locos a todos con tu necesidad de tener un diseño de carpeta perfecto, pero evita colocar archivos en ubicaciones convenientes pero incorrectas.
    • Utilice nombres de archivos sensatos. Las palabras concretas que traen a tu mente una imagen (relevante) son las mejores. Siempre que sea posible, utilice palabras únicas para nombrar sus archivos, pero no a toda costa.
    • A menudo (pero no siempre) cuando necesitas usar dos palabras para nombrar un archivo de forma única, es una señal de que debes crear una subcarpeta. En lugar de images/navigation-*.png, podrías estar mejor con images/navigation/*.png.
    • Evite saturar los nombres de sus archivos con todo tipo de prefijos y sufijos adicionales.
    • Administrar su propio tiempo de forma eficaz le ayudará a encontrar tiempo para organizar los archivos de su sitio web. ¡Recuerde el cuadrante 2!

    Por supuesto, no somos perfectos y las sugerencias aquí definitivamente no son la única (ni la mejor) manera de hacer las cosas. ¿Cómo organizas los archivos de tu propio sitio web? ¡Háganos saber en los comentarios!

    Otras lecturas

    • Un flujo de trabajo simple desde el desarrollo hasta la implementación
    • Potentes consejos, herramientas y trucos de flujo de trabajo para diseñadores web
    • Mejora de la legibilidad del código con guías de estilo CSS
    • 35 herramientas de codificación útiles y bibliotecas de JavaScript para desarrolladores web

    (vf, il, mrn)Explora más en

    Cómo mantener organizado su flujo de trabajo de codificación

    Cómo mantener organizado su flujo de trabajo de codificación

    Principios generalesUna talla no sirve para todosTu clienteEntonces, ¿qué hay en un sitio web como este?El diseño final de la carpetaResumen rápido¡Regist

    programar

    es

    https://pseint.es/static/images/programar-como-mantener-organizado-su-flujo-de-trabajo-de-codificacion-771-0.jpg

    2024-05-20

     

    Cómo mantener organizado su flujo de trabajo de codificación
    Cómo mantener organizado su flujo de trabajo de codificación

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Update cookies preferences