As questões deste tópico são tão amplas e variadas em abordagens possíveis que qualquer resposta realista a perguntas inevitáveis pode apenas apontar o caminho geral.
Muitas pessoas hoje desejam e esperam construir presenças dinâmicas (orientadas por dados) na web, cujas arquiteturas acomodem prontamente novo material, revisão e interação do visitante. O wikiHow, por exemplo, é um site dinâmico. Embora a meta dos projetos de qualidade esteja ao alcance de todas as pessoas diligentes, seria um erro subestimar o que no final é uma tarefa substancialmente desafiadora, especialmente nos objetos técnicos de qualquer projeto em perspectiva. Mesmo as presenças dinâmicas mais simples da web exigem habilidades suficientes em uma variedade de disciplinas.
Ao cumprir metas indispensáveis, ninguém pode se desviar de um bom design de banco de dados. Preparar-nos apenas nesta disciplina é um trabalho substancial (mas não prejudicial). Assim que tivermos um resumo dos objetivos do projeto, devemos imaginar meios sólidos para alcançá-los. Então, temos linguagens de programação ou ferramentas para escolher, com base em uma visão de arquitetura de projeto ideal.
Ver a imagem completa desde o início é a habilidade mais vital de todas.
Passos
Etapa 1. Concentre-se em quais tipos de ferramentas e processos atingirão seus objetivos
Como o núcleo central de qualquer presença dinâmica na web é seu banco de dados e processamento de dados, nosso primeiro objetivo vital é tomar uma decisão de longo alcance sobre um mecanismo de banco de dados. Não é uma boa ideia esperar tomar tal decisão casualmente apenas de uma maneira inicial aparente e razoável.
- O objetivo vital desta primeira decisão é planejar nosso projeto de uma maneira (com ferramentas e motores de banco de dados) que irá atender às suas necessidades ao longo de um futuro, no qual, porque você tomou as decisões iniciais corretas, você irá construa efetivamente sobre sua fundação inicial, de forma eficiente e sem obstrução eventual. Isso significa que, idealmente, por exemplo, o mecanismo de banco de dados que você escolhe não é apenas o mais fácil ou aparentemente simples de implantar hoje; desde o início, deve ser um mecanismo que oferecerá suporte às suas demandas de processamento downstream.
- Às vezes, as considerações comerciais afetam ainda mais essas escolhas. Quais motores são intensivos em frequência (e caros)? Quais motores são virtualmente gratuitos em implementações que sustentam as metas de processamento que seu eventual projeto deve sustentar? Geralmente, o padrão a seguir é selecionar seu mecanismo com base em uma das duas disposições possíveis.
- Para fazer isso, você deve primeiro mapear suas necessidades básicas de mesa. Um profissional nem mesmo precisará construir esse mapa (independentemente de centenas ou milhares de tabelas estarem envolvidas), porque eles geralmente verão imediatamente se a arquitetura e as necessidades futuras que você precisará suportar exigem muita leitura ou gravação. Em seguida, você escolherá um banco de dados apropriado, com base nessa disposição geral e, talvez, ainda mais com base no gosto e experiência pessoal, como pode predizer o trabalho com as respectivas ferramentas de desenvolvimento de software. MySQL é a escolha usual para implementações de leitura intensiva. Muitos desenvolvedores procuram bancos de dados como PostgreSQL para implementações confiáveis de gravação intensiva. Desenvolvemos nossa disposição em relação a essas ferramentas vitais por meio de pesquisa cuidadosa e com base na experiência da indústria geral de desenvolvimento de software. Despesas geralmente podem ser evitadas, porque implementações gratuitas de ferramentas muito boas estão disponíveis. O que procuramos é desempenho em ambientes de leitura ou gravação intensiva, confiabilidade, facilidade e minimização de administração e integração pronta com ferramentas de desenvolvimento de software em potencial.
Etapa 2. Escolha suas ferramentas de desenvolvimento de software
Existem dois padrões a serem considerados na escolha de ferramentas de desenvolvimento de software. Ferramentas supostamente "fáceis" raramente são de fato fáceis, quando um projeto inevitavelmente quebra o elenco dos padrões de desenvolvimento e funcionalidade a que as ferramentas "fáceis" são geralmente limitadas. Se você quiser fazer algo além das ferramentas "fáceis", como incorporar um parâmetro de idioma ou tradução em URLs gerados dinamicamente, pode ser muito mais difícil de realizar nas ferramentas "fáceis" que pode exigir habilidades de programação extremamente sofisticadas para tanto quanto enganar o padrão fácil para fazer coisas mais complexas. Devemos dominar nossas ferramentas para construir bons projetos. Isso não torna as ferramentas fáceis a melhor escolha ou as ferramentas mais sofisticadas uma proposta difícil. A armadilha do desenvolvimento "fácil" geralmente compreende limitações que se tornam muito caras de serem superadas na evolução inevitável dos projetos. Geralmente surge uma grande variedade dessas ferramentas, atendendo ostensivamente a essas necessidades. Mas o padrão de persistência das ferramentas revela um fato ostensivo de ter alcançado esse objetivo; e assim, geralmente descobrimos que as ferramentas mais sofisticadas e poderosas, seguindo bons padrões (ou disponibilidade de objetos e bibliotecas), não apenas aliviam obstruções praticamente inevitáveis para ferramentas fáceis, mas também tornam "chegar lá" um processo muito mais direto. Quando examinamos o escopo das ferramentas disponíveis, geralmente modelos menos abrangentes são apresentados em conceitos de desenvolvimento inicial e melhores conceitos são oferecidos por ferramentas que surgiram posteriormente (ou não teriam a chance de sobreviver em mercados que já foram conquistados). Se escolhermos uma ferramenta supostamente fácil, o que estamos procurando é um padrão de desenvolvimento que seja manejável e sem obstrução eventual. O paradoxo para o neófito, então, é a dificuldade de ver tão longe na estrada que podemos perceber obstruções de programação para um determinado conjunto de ferramentas. Algumas pessoas acreditam que as melhores ferramentas são as mais poderosas e as menos restritivas em termos de abordagem de projeto. Liberdade para desenvolver o que você deseja e precisa muitas vezes significa quebrar o modelo geral de ferramentas aparentemente simples, cujos desafios podem praticamente quebrar o cérebro do engenheiro de software mais experiente e sofisticado, porque ter sucesso em tal objeto significa tornar o "simples" modelo faça algo que pode não ter capacidade nativa de suporte. "Ruby", por exemplo, é realmente uma ferramenta mais fácil do que C ++ ou C # fundamentais? Não. Não realmente, especialmente se você tiver que quebrar o modelo simples de Ruby para entregar funcionalidades vitais. Como o Ruby, o GCC é gratuito para Linux e OSX. Ruby também vem no OSX - você só precisa descobri-lo em seu sistema. Das ferramentas supostamente mais fáceis, minha escolha pessoal é Ruby. Das ferramentas verdadeiramente sofisticadas, C ++ e C # reinarão supremos por muito tempo no futuro; e a verdade é que esses são os únicos veículos para o desenvolvimento sem obstrução. Portanto, sente-se ereto e prepare-se para um estudo sério, porque independentemente da estrada que você escolher, você terá que dominar não apenas suas ferramentas, mas os modelos potencialmente restritivos com os quais essas ferramentas podem eventualmente sobrecarregá-lo. Ruby é provavelmente muito mais limpo do que quase todos os seus pares "fáceis". C ++ é a ferramenta de excelência desimpedida; e, de fato, gurus experientes desenvolverão projetos incomparáveis provavelmente com muito menos dificuldade do que conseguiriam realizar os mesmos objetivos com uma ferramenta supostamente fácil. No final, os desenvolvedores que se desviam dessa observação pagam um preço: ou escolhem a ferramenta "fácil" mais propícia ou se preocupam menos com a liberdade de estorvos na ferramenta mais sofisticada. No último caso, você domina objetos Fast CGI, pega a bola e corre. Conceitos enormes são implementados frequentemente com pouco código. Sim, ferramentas simples fazem a mesma afirmação, mas abstraindo de nós a dificuldade ostensiva de tal forma que o desvio de seu padrão geralmente singular representa desafios de engenharia muito difíceis, além de desvantagens de desempenho que o C ++ resolve.
Etapa 3. No decorrer da resolução dessas questões, inevitavelmente temos que examinar os modelos ou padrões básicos de desenvolvimento de projetos da natureza que desejamos realizar
Isso significa pegar a melhor literatura para as ferramentas que queremos comparar e, pelo menos, dar ao nosso conceito alguma forma na qual ele possa assumir um determinado conjunto de ferramentas, em comparação com outros. Antes de escolher Ruby, por exemplo, você pode pegar livros vitais como "The Ruby Programming Language" e "Agile Web Development with Rails". Seu estudo inicial não deve apenas dominar suficientemente as ferramentas, mas também imaginar como você pode chegar lá - como fornecer a funcionalidade desejada com a ferramenta que você escolher. Esta é uma tarefa difícil para o iniciado. Se você for comparar um ambiente de desenvolvimento supostamente fácil com o melhor dos melhores, também terá que avaliar as melhores ferramentas C. Se você realmente for um engenheiro experiente, escolherá C por estar livre de limitações. C é realmente mais difícil? Não. A sintaxe é sintaxe. No final, você deve dominar a expressão da mesma funcionalidade; e, na verdade, a família de linguagens C é excelente. O difícil de se destacar desde o início em C ++ é colocar as mãos nos modelos que você pode precisar construir. Um excelente começo de praticamente 15 anos atrás foram os componentes FastCGI originais que estavam disponíveis no CPPBuilder da Borland - provavelmente ainda o melhor C ++ para Windows. Até mesmo iniciados em C podem ir longe com essas abordagens orientadas a objetos, porque o modelo geral de funcionalidade de sustentação está embutido nas próprias coisas com as quais você trabalha. Seu trabalho flui muito mais livremente do que no Ruby, por exemplo, sempre que você quebra ou excede o modelo Ruby em sua abordagem. Por outro lado, as técnicas de scaffolding Rails agilizam muito trabalho para o neófito, se e somente se o projeto se encaixar no molde geral de Ruby e Rails. Apresente provisões de segurança rudimentares, por exemplo, reconhecidas em todas as suas interfaces Ruby, e a próxima coisa que você sabe, você está reescrevendo mil linhas de código Ruby gerado automaticamente para cada tabela que seu aplicativo negocia. Isso é fácil? Bem, eu faço isso com um editor do Windows chamado NoteTab Pro, operando em projetos Ruby que residem em um sistema OSX; e macros sofisticadas fazem minhas revisões em talvez um segundo, personalizando mil linhas de código em quase o dobro disso. Ainda assim, isso se relaciona a uma funcionalidade básica relativamente simples, à qual um projeto está restrito. O fato é que, em C ++, podemos escrever nossos próprios objetos que lidam com essas tarefas de forma verdadeiramente universal - você nunca teria que replicar esse processo. Portanto, essas são as compensações. No final das contas, C orientado a objetos é o mais poderoso e eficiente. O que significa que também dá menos trabalho.
Etapa 4. Não importa sua escolha de ferramentas de programação, não há como evitar a dependência de um domínio razoável de HTML e CSS
Geralmente, os desenvolvedores experientes confiam no W3C.org para material vital. página da web
Vídeo - Ao usar este serviço, algumas informações podem ser compartilhadas com o YouTube
Pontas
- Uma parte vital de sua busca será colocar as mãos nos melhores recursos. Eu começaria com Ruby; e se você quiser se destacar, você terá que avaliar as linguagens C orientadas a objetos e os ambientes nos quais projetos bem escritos terão desempenho melhor do que todos os pares.
- Nada, portanto, pode substituir o estudo e a avaliação exaustivos.
Avisos
- Outro obstáculo para o domínio de ferramentas simples é a conduta pouco profissional em muitos fóruns. Há uma enorme diferença entre o know-how profissional e a habilidade pretendida que, com frequência, pode desviar você do caminho certo. As melhores fontes de informação são geralmente os colegas mais talentosos, não os pretensos mestres de ferramentas supostamente simples que simplesmente defendem o cumprimento do único padrão disponível para eles. O principal motivo pelo qual você enviará perguntas aos fóruns é que você precisará exceder (quebrar) o modelo compreendido pela abordagem supostamente simples. Quando você inevitavelmente se depara com essas necessidades, precisa do melhor conselho.
- Nunca pense então que um atalho aparente realmente acelera o trabalho. MUITO frequentemente, o inverso é verdadeiro.
