Ao se trabalhar com o TFS, existem algumas limitações que devem ser levadas em consideração na hora de criar team projects ou work items. É importante conhecer isso para não ter problemas na hora de decidir como estruturar seus projetos (Nenhuma limitação listada é impeditiva para se trabalhar com o TFS, é só se preparar e evitar as situações que elas possam ocorrer ou serem necessárias). Obs. Esta lista foi retirada do livro Professional Team Foundation Server 2010 (Wrox Programmer to Programmer) . []’s Renomear um Team Project Após a criação de um team project (repositório de código-fonte, atividades do projeto, etc.) não é possível renomeá-lo. Uma vez escolhido o nome, será este para sempre, então tome cuidado ao escolher. Caso contrário, se realmente você quiser “renomear”, terá que criar um novo team project e migrar todo o conteúdo do anterior… Mover work items entre Team Projects e Team Project Collections Não é possível mover work items entre team projects diferentes, visto q
Já vi sistemas desenvolvidos em linguagens orientadas a objetos em que todos os métodos das classes eram estáticos. Uma vez perguntei para uma pessoa o motivo dela estar programando dessa maneira. Ela não soube me responder. Bom, por que não devemos colocar static em todos os métodos? Para mim, a melhor resposta é comparar o uso de métodos static com o uso de baionetas. Antes do uso da pólvora, as guerras eram travadas geralmente em combate corpo-à-corpo, com o uso de objetos cortantes como espadas ou machados. No final do século XVIII, na França, começaram a ser produzidas as primeiras baionetas. Baioneta é uma arma branca de curto alcance que pode ser presa na ponta de um fuzil. Dessa maneira, em situações especiais como combate próximo (trincheiras) ou simplesmente falta de munição, os soldados possam utilizar suas armas de fogo como lanças. Mas é claro que atualmente, na maioria das situações, é preferível utilizar fuzis com o objetivo que eles foram criados: disparar pro