You are currently browsing the category archive for the 'Qualidade' category.
Hoje a ler a revista MSDN online reparei num artigo que fala sobre implementar I/O assíncrono usando delegados para os callbacks. Imediatamente lembrei-me do projecto que fiz na Inosat, em que para conseguir rede, GPS ou GRPS no dispositivo móvel, usei um sistema parecido com este.
A maior diferença é que, em vez de declarar dois métodos para callback – um em caso de sucesso e outro em caso de falha – usei apenas um, retornando sempre um valor do tipo Result<T>. Por exemplo, se virem no artigo, o autor para o método:
1: public static string ReadAllText(string path);
define a seguinte assinatura:
1: public static void ReadAllTextAsync(string path, Action<string> success, Action<Exception> failure);
em que o primeiro método é chamado se o método correr como esperado, o segundo é invocado se houver algum problema pelo caminho. No meu caso, a definição seria algo como:
1: public static void ReadAllTextAsync(string path, Result<string> success);
em que a classe Result é:
1: public class Result<T>
2: {
3: private readonly T _value;
4: private readonly bool _valid;
5: private readonly string _error;
6:
7: private Result(T value)
8: {
9: _value = value;
10: _valid = true;
11: }
12:
13: private Result(string error) : this()
14: {
15: _error = error;
16: }
17:
18: private Result()
19: {
20: _valid = false;
21: }
22:
23: public static Result<T> Failed()
24: {
25: return new Result<T>();
26: }
27:
28: public static Result<T> Failed(string error)
29: {
30: return new Result<T>(error);
31: }
32:
33: public static Result<T> Success(T value)
34: {
35: return new Result<T>(value);
36: }
37:
38: public T Value
39: {
40: get { return _value; }
41: }
42:
43: public bool Valid
44: {
45: get { return _valid; }
46: }
47:
48: public string Error
49: {
50: get { return _error; }
51: }
52: }
Isto permite que o Result seja usado para notificar se o método teve sucesso ou não e, caso não tenha, que se possa passar o erro que se encontrou.
A diferença que encontro nas duas abordagens é que, no meu caso, quem trata do resultado tem de verificar se a operação teve sucesso chamando o result.Valid. No caso da implementação que está na revista, cada método sabe se o resultado teve sucesso ou não. Para os puristas que defendem a abolição do uso de If’s (já trabalhei com alguns 
), isto é puro ouro!
Quando me decidi a preparar um ‘build server’ para ter integração contínua no projecto, comecei a procurar na wikipedia pelos possíveis build servers existentes. Apesar de já ter trabalhado com o ‘Cruise Control’ na medialog, dado o pouco tempo (horas!) que tinha para preparar tudo, decidi-me pelo TeamCity da genial empresa JetBrains, também responsáveis pelo resharper.
No final, se tivesse de configurar os scripts nAnt para ter o servidor a compilar, testar e criar as releases dos vários componentes, teria perdido uns bons dias. Com o TeamCity, e inicialmente usando os ficheiros .sol do Visual Studio para criar os builds, foi tudo feito numa tarde*…
Altamente recomendado.
*Claro que assim que quis adicionar umas funcionalidades ‘especiais de corrida’, tive de fazer um build script de raiz. Mas mesmo assim…
Quando saí da faculdade (e até enquanto estava na faculdade) uma má percepção que tinha era que as entrevistas serviam para a empresa me fazer uma série de perguntas, de modo a saberem um pouco mais de mim, do que tinha feito e do que queria fazer e… pronto. Se tivesse conseguido “vender o peixe” eles haveriam de me ligar.
Hoje em dia alterei muito a minha perspectiva… a entrevista tem de servir tanto para eles saberem se eu sou a pessoa indicada para o lugar e para eu saber se eles são a empresa indicada para a minha próxima experiência.
Uma pergunta que geralmente fazem é: “Onde é que se vê daqui a 5 anos?”. Bem, no meu caso.. eu gosto de programar. Daqui a 5 anos… neste momento espero que daqui a 5 anos esteja a programar! E não, não é falta de ambição. Não, não sou uma pessoa que não gosta de subir na carreira. Mas gosto de programar. Claro que quero estar a gerir uma pequena equipa, tenho conhecimento que gostava de passar, tal como me foi passado. Mas a programar. Porquê? Porque, e pondo as tretas de lado, sou bom nisso. E se me derem a escolher entre um lugar como Developer ou Project Manager, podem ter a certeza que sei o que escolher.
E por falar nisso, como é que é feita a gestão dos projectos? Tenho de estar a preencher uma timesheet sempre que mexo numa classe? Por cada tarefa que faça, tenho de preencher um relatório a dizer o que estava a fazer das dez ao meio dia? Mas porquê? O project manager não sabe o que ando a fazer? Se sabe, então ele que faça o trabalho dele e me deixe a mim fazer o meu. Se não sabe, contratem outro. Um que não seja um gajo a tentar não ser programador.
E para os programadores, como é o processo de desenvolvimento? Há controlo de versões do código? Se não houver, desculpem, não é nada contra a empresa mas se não há gestão do código, não se podem chamar uma empresa de software. E é numa empresa dessas que eu quero trabalhar.
Se tiverem integração contínua então… Hmm, já começam a parecer uma empresa de jeito! É que, e de certeza que concordam, com integração contínua temos a certeza que o codigo que está guardado… bem, temos a certeza que compila! É que, e já aconteceu mais do que eu gostava de admitir, receber código que temos de manter ou alterar e o código não compila… É frustrante. E sim, a culpa até pode nem ser de ninguém, eu é que preciso de instalar a ferramenta X ou a dll Y para isto funcionar. Mas se eu preciso de um manual de instruções para poder começar a trabalhar, algo está mal.
Claro que já nem peço que a empresa tenha testes unitários implementados no build diário… mas se há ou se não se importam que eu começe… perfeito! Sim, eu sei que fazer testes faz com que o processo de desenvolvimento demore mais tempo mas acreditem em mim, quando lá para o final do projecto tiveremos com problemas no software, vão querer terem perdido algumas horas todas as semanas para não perder estes dias no final. Ah, e já disse que os testes também podem ser usados para inferir sobre a qualidade do código? E como vocês dizem muito, pouca informação é melhor que nenhuma. Sabem, alguns dos processes ágeis não vos retiram o controle sobre o projecto, mas permitem-nos a nós trabalhar melhor, com mais confiança acerca do que estamos a fazer.
Bem, se chegámos ate aqui, parece que vocês podem ser a empresa indicada para o lugar.
Claro que ainda teríamos de falar sobre a qualidade do local de trabalho mas vou assumir que a empresa já assinou a “Programmer’s Bill Of Rights” portanto podemos passar isso à frente.
Depois disto, parece-me que tudo possa correr bem… mas não esperem que eu pare de chatear por aceitar entrar na empresa. Ainda há coisas que vou poder querer que aconteçam.
Por exemplo, nas empresas por onde passei sempre houve programadores bons e outros menos bons. Sim, é verdade, nem todos eram geniais. E, a não ser que esteja a ser entrevistado para uma empresa excepcional, de certeza que nesta se passa o mesmo. É que a qualidade dos programadores segue mais ou menos a seguinte distribuição:
Há uns bestas e há uns bestiais. E no meio estão os outros. E, fazendo parte da equipa, tendo de manter, alterar e apagar o código de todos eles, quanto melhor for a equipa, melhor para mim e para a equipa.
Assim, já pensaram em dar um dia de 15 em 15 dias para que os programadores possam rever código em conjunto na sala de reuniões, discutindo o que está bem e o que está mal? Ah sim, e vocês, não estão convidados. É que sabem, estas reuniões não são para serem usadas para fazer as vossas reviews sobre os elementos da equipa. Queremos passar o conhecimento do programador bestial para os outros.
Mas estão convidados a trazerem os cafés a meio do dia para a malta aproveitar melhor o tempo, obrigado.
