Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
E o que acontece à sua estrutura clara se no meio, ou ainda mais perto do fim do projecto, o cliente mudar subitamente:
Este é um bom teste de quão pronto e resiliente o seu projecto está para mudar.
Este é o problema, e é por isso que estou neste fio.
Quero encontrar uma resposta sobre a forma de conceber (ou como enfiar o cliente em tal estrutura), para que tanto os seus desejos sejam satisfeitos como o projecto não seja quebrado.
SZY porque a moeda tem dois lados, com um pode mudar o projecto, com outro pode dizer "Não como parte deste projecto não pode fazer", a verdade está algures no meio.
O melhor é conceber o desenvolvimento de tal forma que a maioria dos desejos essenciais do cliente sejam realizáveis.
Actualmente, nenhum programador normal desenha fluxogramas. Tudo isto é um disparate teórico concebido para ser ensinado às crianças em idade escolar, mas não para trabalhar em projectos reais.
Tudo depende do que se põe no papel.
Não sou a favor da escrita, mas por vezes é preciso elaborar uma estrutura geral em papel. É conveniente e rápido, é como um esboço para um joalheiro, o quadro geral deve ser claro.
Talvez seja por isso que existem muitos programadores não-normais porque não desenham fluxogramas.
Hoje em dia, nenhum programador normal desenha fluxogramas. Tudo isto é um disparate teórico concebido para ensinar crianças em idade escolar, mas não para trabalhar em projectos reais.
Hoje em dia, nenhum programador normal desenha um diagrama de fluxo.
Acho que é por isso que existem muitos programadores anormais, porque eles não desenham fluxogramas.
Não lhe chamaria assim tão bruscamente "disparate teórico". O desenho de "quadrados com setas" no papel é largamente utilizado na programação, tomemos como exemplo UML - cheio de "setas com quadrados". :) Assim, também os diagramas de blocos nas fases iniciais podem ser úteis...
Já tentei conceber com a UML, é um disparate (IMHO).
Todos estes quadrados e flechas que consigo manter perfeitamente na minha cabeça, mas as abstracções não cabem na minha cabeça, por isso esboço-os.
HI Se cavar mais fundo, o cérebro humano é bem adequado para memorizar imagens, mapas, padrões de comportamento, mas não para construir abstracções, a abstracção é a coisa mais difícil que uma pessoa pode fazer.
Assim, a humanidade sempre tentou formalizar a abstracção em algo mais familiar.
O cérebro humano é bem adequado para recordar imagens, mapas, padrões de comportamento, mas não para construir abstracções; as abstracções são a tarefa mais difícil para um ser humano.
ZZZI É por isso que a humanidade se esforça sempre por formalizar a abstracção em algo mais familiar.
Concordo.
Tenho os meus próprios métodos de ligação do meu próprio cérebro nesta área, tenho até desenvolvimento de software (posso partilhar ocasionalmente), mas o desenvolvimento é muito lento (embora perceptível em retrospectiva).
--
De certa forma, toda e qualquer programação é trabalho de abstracção, mas há uma enorme variação no nível e habilidade do tratamento prático de conceitos abstractos.
Concordo.
Tenho os meus próprios métodos para afiar o meu próprio cérebro nesta área, tenho até desenvolvimentos de software (posso partilhá-los ocasionalmente), mas o desenvolvimento tem sido muito lento (embora perceptível em retrospectiva).
--
De certa forma, toda e qualquer programação é trabalho com abstracções, mas há uma grande diferença no nível e habilidade de utilização prática das abstracções.
Não estamos interessados na abstracção por causa da abstracção, pois não?
Penso que como não estamos evolutivamente melhor adaptados à abstracção ?! (discutível, pelo menos melhor do que os outros habitantes deste planeta), deveríamos tentar construir muletas.
Por exemplo, as pessoas inventaram uma técnica tal como o brainstorming.
Tenho frequentemente dificuldade em nomear uma entidade, dando-lhe um nome sucinto que seja ao mesmo tempo compreensível e extremamente curto. Quando isso é bem sucedido, a abstracção é facilmente assimilada.
Desculpe, não posso escrever muito agora (não é conveniente fazê-lo a partir de um telemóvel), não terei tempo para o fazer quando lá chegar. Não posso escrever muito agora (não é conveniente ao telefone). Não terei tempo.
Lamento não poder escrever muito agora (não é conveniente a partir do meu telemóvel), não vou ter tempo quando lá chegar. Melhor amanhã.