Mostrando postagens com marcador linux. Mostrar todas as postagens
Mostrando postagens com marcador linux. Mostrar todas as postagens
19 de agosto de 2017
13 de abril de 2015
11 de novembro de 2008
A Catedral e o Bazar
Nesses dias estava escutando o podcast do RailsBox e ouvi sobre o ensaio "A Catedral e o Bazar". O livro fala de algumas características que são premissas no desenvolvimento do Linux (do UNIX e de outros projetos open source) e como estas características contribuem para que o software tenha uma qualidade superior.
Vou listar os pontos destacados pelo Eric S. Raymond
1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador.
2. Os programadores bons sabem o que escrever. O grandes sabem o que re-escrever (e re-
usar)
3. "Planeje jogar algo fora; você irá, de qualquer maneira.'' (Fred Brooks, "The Mythical Man-Month'', Capítulo 11)
4. Se você tem a atitude certa, problemas interessantes irão encontrá-lo.
5. Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente.
6. Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz.
7. Liberece cedo. Libere freqüentemente. E ouça seus fregueses.
8. Dada uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém.
9. Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. Brooks, Capítulo 11: "Mostre-me seu código e esconda suas estruturas de dados, e eu poderei
continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não
necessitarei do seu código; ele será óbvio.''
10. Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso.
11. A melhor coisa depois de ter boas idéias é reconhecer boas idéias dos seus usuários.
12. Freqüentemente, as soluções mais impressionantes e inovadoras surgem ao se perceber que o seu conceito do problema estava errado.
13. "A perfeição (em projetar) é alcançada não quando não há mais nada a adicionar, mas quando não há nada para jogar fora.''
14. Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta verdadeiramente *boa* leva ela própria a usos que você nunca esperou.
15. Quando escrevendo um software gateway de qualquer tipo, faça tudo para perturbar o conjunto de dados o menos possível -- e *nunca* jogue fora informação a não ser que o destinatário force você a isto!
16. Quando sua linguagem não está perto de um Turing completo, açúcar sintático pode ser seu amigo.
17. Um sistema de segurança é tão seguro quanto é secreto.
18. Para resolver um problema interessante, comece achando um problema que é
interessante para você.
19. Contanto que o coordenador do desenvolvimento tenha uma mídia pelo menos tão boa
quanto a Internet, e saiba como liderar sem coerção, muitas cabeças são
inevitavelmente melhores que uma.
Para quem pensa em participar de algum projeto open source são 14 páginas obrigatórias!
O livro foi traduzido por Erik Kohler - ekohler at programmer.net
Baixe aqui
Vou listar os pontos destacados pelo Eric S. Raymond
1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador.
2. Os programadores bons sabem o que escrever. O grandes sabem o que re-escrever (e re-
usar)
3. "Planeje jogar algo fora; você irá, de qualquer maneira.'' (Fred Brooks, "The Mythical Man-Month'', Capítulo 11)
4. Se você tem a atitude certa, problemas interessantes irão encontrá-lo.
5. Quando você perde interesse em um programa, sua última obrigação a fazer com ele é entregá-lo a um sucessor competente.
6. Tratar seus usuários como co-desenvolvedores é seu caminho mais fácil para uma melhora do código e depuração eficaz.
7. Liberece cedo. Libere freqüentemente. E ouça seus fregueses.
8. Dada uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém.
9. Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. Brooks, Capítulo 11: "Mostre-me seu código e esconda suas estruturas de dados, e eu poderei
continuar mistificado. Mostre-me suas estruturas de dados, e eu provavelmente não
necessitarei do seu código; ele será óbvio.''
10. Se você tratar seus beta testers como seu recurso mais valioso, eles irão responder tornando-se seu mais valioso recurso.
11. A melhor coisa depois de ter boas idéias é reconhecer boas idéias dos seus usuários.
12. Freqüentemente, as soluções mais impressionantes e inovadoras surgem ao se perceber que o seu conceito do problema estava errado.
13. "A perfeição (em projetar) é alcançada não quando não há mais nada a adicionar, mas quando não há nada para jogar fora.''
14. Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta verdadeiramente *boa* leva ela própria a usos que você nunca esperou.
15. Quando escrevendo um software gateway de qualquer tipo, faça tudo para perturbar o conjunto de dados o menos possível -- e *nunca* jogue fora informação a não ser que o destinatário force você a isto!
16. Quando sua linguagem não está perto de um Turing completo, açúcar sintático pode ser seu amigo.
17. Um sistema de segurança é tão seguro quanto é secreto.
18. Para resolver um problema interessante, comece achando um problema que é
interessante para você.
19. Contanto que o coordenador do desenvolvimento tenha uma mídia pelo menos tão boa
quanto a Internet, e saiba como liderar sem coerção, muitas cabeças são
inevitavelmente melhores que uma.
Para quem pensa em participar de algum projeto open source são 14 páginas obrigatórias!
O livro foi traduzido por Erik Kohler - ekohler at programmer.net
Baixe aqui
Assinar:
Postagens (Atom)