Nos comentários da primeira parte, alguns escreveram que a sinopse pode ser reduzida. Mas, neste caso, as transições lógicas seriam perdidas em algum lugar. Portanto, para aqueles que querem muito brevemente e apenas
concisa a própria essência, fiz uma
tabela resumida . Ela está no final do artigo. Também há uma votação com a pergunta "Qual é o sucesso desse formato?"
Parte 2. Investindo no seu produto
Fowler se considera um músico muito talentoso (acreditamos nisso). Devido à facilidade com que ele foi capaz de jogar, ele cresceu rapidamente no início de sua carreira e quase parou no final.
Ele deixou de ser exigente e deixou de investir em suas habilidades profissionais. E investir conscientemente em sua carreira (de várias maneiras) é uma das idéias principais de todo o livro.
Dica 11. Aprendendo a pescar
Não há como passar sem uma metáfora; caso contrário, o título deste capítulo não será claro.
Lao Tzu disse: “Dê ao homem um peixe, e ele ficará cheio o dia todo. Ensine-o a pescar, e ele ficará cheio a vida inteira. "
Pesque no desenvolvimento de software:
O processo de trabalhar com uma ferramenta, um determinado aspecto da tecnologia ou algumas informações do setor de negócios em que você trabalha.
A capacidade de testar uma parte específica do sistema de gerenciamento de código-fonte com a qual sua equipe trabalha ou de configurar o servidor de aplicativos.etc.
O conselho, do meu ponto de vista, é semelhante ao
conselho 8. Seja um especialista (versado em seu campo) e ao
conselho 7. Seja um generalista (resolvido em áreas relacionadas).
Nos comentários da primeira parte, alguns escreveram sobre a contradição dessas duas dicas entre si.
Para citar
um usuário
lxsmkv interpretando essa ideia de Fowler:
Não há contradição. Isso se refere ao que agora é chamado de Pessoas em Forma de T em Agile. Você possui uma área altamente desenvolvida, mas entende as áreas relacionadas ao ciclo de vida do software.
Dica 12. Entenda como uma empresa funciona.
Hum. A questão toda está no título, o resto é água. Dica: para entender como funciona o componente financeiro do negócio, do qual o desenvolvimento faz parte.
O autor do livro recomenda vivamente o estudo do livro de Steven Silbiger, MBA em 10 dias (Steven Silbiger, MBA em dez dias). Como não li este livro, não posso dizer nada sobre ele, mas as classificações e resenhas parecem boas.
Dica 13. Encontre um mentor
Estamos falando de uma pessoa mais experiente que, às vezes, solicita e orienta os movimentos para um estudo independente.
Dica 14. Torne-se um mentor
Se você quer realmente aprender alguma coisa, tente ensinar isso a outra pessoa. Não há melhor maneira de generalizar sua compreensão do problema do que se forçar a explicar momentos incompreensíveis para outra pessoa, para que ela entenda tudo.
Dica 15. Pratique, pratique e pratique novamente
Fowler recomenda reservar um tempo para exercícios de programação e lógica.
Essas tarefas estão em muitos sites. Por exemplo, nestes:
Dica 16. Abordagem para o trabalho
Às vezes, parece que o título das dicas tem pouco a ver com a idéia do capítulo.
É recomendável que você estude práticas de desenvolvimento de software. Outra área a explorar para obter a
dica 7. Seja um generalista.Dica 17. Nos ombros dos gigantes
Aprenda códigos e padrões alienígenas de qualidade.
Dica 18. Automatize tarefas
Se algo é repetido frequentemente, faz sentido automatizar. Ou de outra maneira: se algo é aconselhável automatizar, faz sentido fazê-lo.
Recomenda o aprendizado de Arquitetura Orientada a Modelo - Arquitetura Orientada a Modelo.
Pense nos pequenos problemas que seu grupo enfrenta todos os dias.
Liste-os no papel. Quais são essas coisinhas irritantes que fazem o grupo perder todos os dias alguns minutos com os quais ninguém pode ou não quer fazer nada?
Quais tarefas manuais do projeto atual podem ser automatizadas? Liste-os.Hora de esclarecer a própria sinopse. O objetivo do resumo é transmitir da maneira mais concisa possível os pensamentos do autor do livro. Portanto, mesmo as coisas óbvias, eu ainda saio. Por exemplo, padrões. Todo mundo entende que eles precisam saber. Mas deixo assim que Fowler escreve sobre isso, bem como seus pensamentos controversos.
Fowler não é um profeta e suas abordagens são sua visão subjetiva dessas questões e a solução para os problemas que o desenvolvedor enfrenta.
E agora a tabela de resumo prometida para a segunda parte do livro
