Arquivo da categoria: Software Engineering

The Customer Problem

ProblemProblem, What Problem? Why is it happening? To propose a solution the problem is the key component. Often entrepreneurs, software engineers, designers forget to trace back this valuable asset to guide the development of the design. The problem study is the “missing part” and is what this article is about. As it is a continuous format, come back in other moments for a fresh look.

From math point of view…

The verbal statement of the problem must be understood. [2](Polya 1957).

I found this excellent reference about “how to solve a problem” from George Polya. Polya was Emeritus professor of Stanford and construct studies in mathematics such number theory and mathematical analysis. In these series of work on “how to solve a problem” he developed a framework or guide with four steps which is very interesting for us here.

  1. Understand the problem.
  2. Devising a Plan.
  3. Carrying out the plan.
  4. Looking back.

Poly bring four steps which includes the thoughts regarding the solution (or design). But I will state only the initial part of which is understanding the problem.

drawit-diagram3

Polya proposes that the process of understanding the problem generates questions related to: What is unknown? What is the data and conditions? Is the condition sufficient to understand unknown? Those questions are a good start point to dive into customer problems with a thoughtful approach. I will continue here…

In contrast of math the Startup Management think problem as a pure customer landscape, have a look what I compile.

From the entrepreneurship or VC point of view…

For Blank and Dorf(2012) is their Startup Owner’s Manual[1] mention the problem study as part of the customer segments of their startup framework. For the authors the problems are latent problems, passive problems, active problems and vision problems(or a problem with home-grown solution).

drawit-diagram1

The point of view here is related to the knowledge about the problem which gravitates  in unknown, know and the solution. the difference between passive and active is that passive problems the customer aren’t motivated to take action on it, different from active which the customer are searching for a solution but not found it yet.

Lets discuss software engineering in the next change here…

References:

[1] Startup Owner’s Manual 

[2] Polya, 1957. “How to Solve lt.” Princeton University (1957). But you can find the new version here: Polya, George. How to Solve It: A New Aspect of Mathematical Method: A New Aspect of Mathematical Method. Princeton university press, 2014.

Código Fonte: Os acordos

Cconvenções sobre códigos fonte são importantes e bem-vindas quando existem mais de uma pessoa construindo software. As vantagens são várias, mas a principal é a possibilidade de um desenvolvedor poder analisar o código de outro o mais rápido possível.

Independente qual abordagem de engenharia de software o time está usando, o código fonte será modificado e interpretado por pessoas o tempo todo. O nível mais físico (ou baixo) de abstração em um projeto de software é o código fonte e, este código, deve ser cuidado e preservado utilizando melhores práticas, convenções e acordos.

Este artigo apresenta tanto o ponto de vista acadêmico como profissional utilizando referências de trabalhos de pesquisa e sugestões de experiências profissionais. As informações aqui publicadas são de interesse para desenvolvedores, arquitetos de software e gerentes de desenvolvimento de software.

Nos seguintes tópicos serão apresentados elementos relacionados com os acordos sobre códigos fonte.

Utilizar Code Standards

Uma das formas mais conhecidas de acordos são os padrões de código ou do inglês code standards. Os padrões de código tem como objetivo criar um conjunto de sugestões, regras e acordos para que o time de desenvolvimento seja homogêneo na construção do código fonte. Independente da linguagem estes acordos descrevem, por exemplo, como nomear os arquivos, nomear variáveis e formatar o código.

Existem diversos modelos [4][5][6] para code standards disponíveis na internet. O ideal é que o time leia várias opniões e compile um documento customizado para as necessidades do time composto. A formula é sempre diferente para cada grupo de trabalho. Então idealmente faça um workshop e defina junto com o time quais padrões serão utilizados e onde serão publicados.

Utilize Nomes Significativos

Quando utilizamos nomes significativos para variáveis, nomes de arquivos, nomes de classes e pacotes criamos ligações mentais entre os componentes do software e do sistema tornando o entendimento melhor. Nomes são substantivos para identificar coisas, estas coisas podem ser objetos, processos, ou estados em um software. Quando cria-se um software estes nomes devem ser claros e significativos para quem o interpreta depois. A equipe de desenvolvimento deve acordar um conjunto de regras para nomear os componentes, classes, variáveis, arquivos de um programa.

Vou comentar um exemplo inusitado da missão Apollo 8 da década de 50. O que você pensa quando depara-se com um programa chamada “P01” ? Você pensaria o “primeiro programa” a ser executado? humm…. “Primeiro programa” pode significar o programa de inicialização? Faz sentido… certo? Sim! Portando vou executa-lo antes dos demais! :) Certo? hehehe! Certo! Foi o que aconteceu! O astronauta Jim Lovell selecionou P01 e executou em pleno espaço e apagou todo os dados de navegação da Apollo! [7]

Este exemplo da Apollo mostra como um nome de programa pode causar um problema e tanto. O software P01 foi desenhado para limpar os dados em ambiente de desenvolvimento e não deveria ser executado em pleno voo. Estava no Manual! :) Entretanto  o usuário( um militar inteligente e treinado ) fez algo que o desenvolvedor documentou para não fazer. O problema é que Jim foi induzido pelo programador ao erro.

Como consertar esse tipo de coisa? Que tal CLR ou DNT como nomes para o programa? Não chamaria mais a atenção que P01? Imagino que sim! Uma possível conversão para isso é Utilizar nomes mais claros e objetivos! E não esconder idéias e lógicas especificas atrás de variáveis como “list”, “l”, “hash”, “stmt”, “i”, “result”…

Concluimos que linguagens modernas(Java, Go, …) não precisam de mnemonicos e que suportam nomes longos e significativos. Um acordo para o seu time seria utilizar nomes mais precisos e explícitos como listaOrdenadaClientes ou programaApagaDadosNavegacao :)

Remover Código Antigo ou Código Comentado

Quando um desenvolvedor altera um código para correção ou inclusão de uma nova funcionalidade ou até um refactoring é comum aparecer trechos de códigos antigos que não estão sendo executados ou até estão comentados. A razão para existência de códigos antigos não utilizados é a natureza dos requisitos de software que sempre mudam, exigindo assim, a melhoria contínua do software. Uma outra razão é a construção de códigos de “teste” e debug dentro do código principal.

É obrigação de cada desenvolvedor fazer a limpeza do código fonte removendo códigos que não estão sendo executados ou estão comentados. Qualquer linha de código incrementa o tempo de análise do desenvolvedor e pode gerar uma interpretação errada do estado atual do código.

Remover código antigo? Isto mesmo? Sim! Isto mesmo! :) Parece ser um pouco radical apagar um código feito por um desenvolvedor no passado. Entretanto, a quantidade de código gerada em um projeto pode influenciar na sua complexidade. Então, é dever do desenvolvedor criar uma solução com o mínimo de informação possível.

Nos anos 80 acreditava-se que códigos não utilizados (ou comentados) eram ativos e que não deveriam ser apagados [2]. Porém, como comentado anteriormente, a quantidade de informação influencia na qualidade da solução e isto foi proposto por Suh (1990) [3].

Deixe os acordos vivos, visíveis e disponíveis

É importante visitar os acordos de construção de software uma vez ao ano ou quando a equipe sofre uma mudança significativa, como inclusão de novas pessoas no time de desenvolvimento. Geralmente utilizo um brown-bag session que é uma reunião rápida (max 20 min) para apresentar este tipo de assunto.  A rotação entre as pessoas que apresentam os acordos é importante; assim, o responsável pode melhorar a apresentação e até acordos.

Sugiro a publicação dos acordos em uma página wiki interna como Confluence (da Atlasian). Desta forma, todos podem visualizar e sugerir mudanças no longo prazo. Dependendo da sua empresa ou equipe é necessário um documento formal. Para isto, o Confluence tem plugins para exportar em “.PDF” ou “.DOC”. Caso não tenha esta ferramenta o Word é excelente :).

A utilização de acordos é vital para times de desenvolvimento de software e fazem as pessoas crescerem em conhecimento sobre a linguagem de programação utilizada e cenários comuns do dia-a-dia do desenvolvedor de software. O resultado esperado com a utilização dos acordos é o aumento da familiarização com o código fonte e a redução na melhoria e correção de problemas (bugs).

Ultima alteração: 19 Outubro 2015.

Me diga o que achou pelo twitter @RafaelGorski. Caso tenha algum template para compartilhar, terei o prazer de publica-lo.

Referências:

[1] Schneidewind, Norman F. “The state of software maintenance.” Software Engineering, IEEE Transactions on 3 (1987): 303-310.

[2] Belady, Laszlo A. “Special Feature Evolved Software for the 80’s.” Computer12.2 (1979): 79-82.

[3] Suh, Nam P. The principles of design. Vol. 990. New York: Oxford University Press, 1990.

[4] DOOM 3 code style convension from ID Software.

[5] Oracle Java Code Convension.

[6] Java programming Style Guide,  Central Washington University\

[7] Digital Apollo