No desenvolvimento de projetos de software, saber quando recorrer a uma biblioteca/framework e como optar por uma entre muitas, não é tão óbvio quanto parece. Neste artigo decidi sintetizar o processo. Tentarei abstrair-me da linguagem/runtime (PHP, Java, .NET, etc.) em causa, visto que os conceitos são transversais.
Em todas as profissões existe o interesse pela autosuperação. A profissão de programador não foge à regra. Esta reveste-se da particularidade de exigir lucidez de raciocínio, por um lado, e por outro, criatividade e inspiração.
Tentarei refletir sobre o assunto e sintetizar ideias resultantes da minha experiência e forma de estar na área. Afinal de contas, a instrospeção fomenta a melhoria. É por isso natural que alguns pontos sejam subjetivos e muitos não estejam isentos de exceções. Os objetivos passam por pensar, fazer pensar e promover a discussão.
Por Luís Soares para o PPLWARE.COM
O debugging de um programa baseia-se em alguns princípios e técnicas transversais à maioria das linguagens e ambientes de programação. Tentarei, neste artigo, sintetizar o que entendo por debugging, introduzindo o tema, colocando algumas luzes nos conceitos fundamentais e mostrando que há um mundo para além de alerts e prints.
Por Luís Soares para o Pplware
É importante analisar os projetos de software que correm mal. Nem sempre são resultado dos prazos impossíveis ou de maus gestores. Geralmente é um somatório de factores que entra numa espiral causa-efeito. Tentarei agora identificar alguns erros comuns dos programadores (também aqui me incluo). Tais erros não são exclusivos do programador júnior. De facto, alguns são cometidos mais frequentemente pelo programador sénior.
Por outro lado, não se pretende aqui falar em más práticas de programação mas sim de soft skills e de gestão pessoal.
Por Luís Soares para o Pplware
A gestão de projectos não é uma ciência exacta, muito menos a de projectos de software. Em engenharia de software, existe alguma incerteza nas metodologias, nas estimativas, nas representações, entre outros. Um programador não é um robô (tal como um designer).
Ao contrário do que se passa noutras engenharias, é muito fácil falhar, porque não existe uma “receita” de como fazer as coisas bem. Sendo uma pessoa por si só complexa, um conjunto de pessoas e as suas dinâmicas podem ser muito mais.
É necessário perceber o que costuma falhar quando os projectos derrapam no tempo e nos custos associados. É importante que um gestor “dê dois passos atrás” e tente perceber os padrões emergidos ao longo do tempo. Existem diversas técnicas que podem ser usadas para o efeito (ex: 5 whys, análise de casos de insucesso).
Aqui, tentarei sintetizar o que tenho observado ao longo da minha carreira.
Web apps ou apps nativas? Qual a melhor abordagem? Que argumentos favorecem cada uma? Haverá uma tendência? São complementares ou...
Últimas do Fórum
Loading ...
