Disseminando conhecimento e inovação em desenvolvimento de software corporativo
Como programadores, a nossa primeira prioridade é criar código que funciona. Infelizmente, código que simplesmente “funciona” não é suficiente. Código que tem valor real e é duradouro, tem de ser “limpo”. Em “Clean Code: A Handbook of Agile Software Craftsmanship”, Robert C.
Mitch Harper, cofundador do BigCommerce.com, afirmou em um recente artigo que a educação universitária talvez não seja o melhor caminho para se tornar um engenheiro de software. Segundo Harper, as universidades muitas vezes não preparam seus estudantes para a o dia-a-dia e os desafios de trabalhar como um engenheiro de software.
Recentemente John Sonmez publicou um artigo polêmico afirmando que Engenharia de Software não pode ser encarada como as engenharias tradicionais.
Por definição, um manifesto é uma declaração pública de princípios e intenções que descreve as motivações, razões e demandas de um grupo. Um dos manifestos mais populares existentes é o Manifesto Ágil. Contudo, o número de manifestos tem crescido de forma epidêmica desde então.
São muitas as razões que podem ser citadas para o fracasso de projetos de software. Alguns projetos falham devido a requisitos ruins, outros devido ao custo e um cronograma super estimado e alguns simplesmente devido à um mau gerenciamento.
Big Ball of Mud, é um código bagunçado que é mal estruturado, desleixado e muitas vezes amarrado com fita adesiva. Com o passar dos anos tentamos introduzir vários guidelines tais como SOLID, GRASP e KISS, alta coesão e baixo acoplamento. Entretanto, a situação parece continuar e ainda vemos que a "Grande Bola de Lama" parece ser o jeito mais popular de fazer o design de um software.
Alixx Skevington postou um Manifesto do Pronto como o começo de uma discussão, falando sobre os compromissos que os membros do time tem sobre os outros em relação à qualidade do seu trabalho e claramente expressando suas obrigações para entregar valor de negócio através do código.
Uma recente discussão se iniciou no grupo Agile Alliance do LinkedIn com a questão feita por Reeju Srivastava: "Deveríamos ter um reconhecimento individual em um time Scrum?"
Kent Beck, autor de “Extreme Programming Explained” e “Test Driven Development: By Example” sugere que um projeto de software, assim como golf, pode ser um jogo longo ou curto. JUnit é um exemplo de projeto longo, muitos usuários, rentabilidade estável (a $0 é triste para qualquer envolvido), onde o objetivo principal é proporcionar funcionalidades além das necessidades dos usuários.
