PplWare Mobile

Os erros mais comuns do programador

                                    
                                

Este artigo tem mais de um ano


Autor: Marisa Pinto


  1. joaquim sousa says:

    Muito bom tópico, arrisco-me a dizer que este foi sem dúvida o melhor artigo dos últimos tempos aqui no pplware. Muito bem.
    Quando a pessoa pensa que faz um código em x tempo isso nunca é realista há sempre muitos factores em jogo. Pseudocódigos acho que é sempre um bom começo para assentar ideias, de um certo modo que é “o pontapé de saída” para o que queremos fazer.

    • lmx says:

      mas isso do desenhar a app, ou que seja, leva tempo…ás vezes mais tempo que fazer o código…e os gestores tendem a se defender a eles…é uma treta…

      No entanto se “saltares a gatilhar” sem conseguires ter uma visão do que queres…podes ficar meio enrascado(ou enrascado na totalidade) , se o projecto for grande…

      • Luís Soares says:

        obrigado!
        sim.. após os fluxogramas pode-se saltar para o pseudocódigo. Ou então usá-lo como alternativa.

        O que não defendo é quando o pessoal se lança logo a bater código que nem leões, sem qualquer desenho prévio do conceito via uma dessas técnicas. É uma ilusão pensar que se está a ganhar tempo ao fazê-lo…

  2. joaquim sousa says:

    Programação é uma arte que deve ser cultivada logo desde muito cedo, talvez por volta do 2ºano de escolaridade. Porque de certa forma obriga a sistematizar o pensamento, a estruturar as bases para a resolução de problemas complexos que sem essa organização sairiam um fiasco.

    Por isso é que eu acho que cá em Portugal devia-se incutir nas crianças e nos jovens o gosto pela programação alicerçando sempre como é obvio em aspectos práticos e motivantes adequados à sua idade. Porque de outro modo estaríamos a criar não um gosto mas sim um pesadelo que no final do dia leva a muitas pessoas detestarem a programação. É por isso que nas nossas Universidades se vê parvalhões de alguns professores que não têm sentido de pedagogia nenhuma que ao invés de cativarem os seus alunos para a programação só os afastam. E porquê?

    Porque limitam-se a descarregar a matéria ao invés de paralelamente darem enfoque à algoritmia.

    Sim para mim a questão da algoritmia é o grande problema da programação, não são as regrinhas lá do C ou do Java.

    • joaquim sousa says:

      Quando eu falo em algoritmia falo dos pseudocódigos…

      • ze.ccjs says:

        Concordou em tudo menos numa coisa: criança não! No 8° ano ou por aí, tudo bem. Antes, as criança têm de usufruir disso mesmo: serem criança! Abraço.

    • Luís Soares says:

      Olá Joaquim.
      Grandes verdades. Acho que nos EUA já estão a ter essa mentalidade, de considerar a programação uma competência que todos deviam ter desde cedo. E há cada vez mais recursos na web que tentam “democratizar” a programação. Tal como a ciência no geral, a programação não pode nem deve ser de uma elite.

      • Carlos says:

        Agora não me lembro o nome do país, mas sei que era um nórdico, que vai começar a dar noções programação nos primeiros anos de escolaridade. E muito útil nem só para quem um dia seguir a área, mas também para desenvolver o pensamento logico desde muito cedo.

        • lmx says:

          Os nórdicos são “uns leões nisso”…

          Os míudos na escola ja desenham e mexem em microcontroladores…estão envolvidos num acompanhamento brutal desde cedo na ciencia…é impressionante..

          Os putos participam em torneios de ciencia..é impressionante…

          Cá em Portugal…o ATL é mesmo, piscina, futebol, basket…e farturas 🙂

          Depois admiram-se que os Nórdicos sejam extremamente evoluidos…

          Eles também teem um tempo da treta, e isso ajuda por um lado ao desenvolvimento intelectual…mas nós abusamos no desporto, e afins 🙂

          • Mr.Antunes says:

            Eu acho que devia ser mesmo desde de bebés, em vez de música púnhamos-los a ouvirem código máquina, assim quando chegassem aos 10 anos já sabiam programar em binário…

            O que foi da raça humana até agora pois pelos vistos nunca tivemos boas metodologias de resolução de problemas.

            Se abrissem os olhos…

          • Luís Soares says:

            tem de haver um balanço… há coisas nas escolas que podiam muito bem ser substituídas. desporto não é uma delas pois mantém a mente sã..
            os miúdos aprendem apenas a descorar para passar, em vez de se estimular a criatividade e o raciocínio.

        • Sigsegv says:

          Os franceses já fazem isso desde os anos 80. Programação em logo. Sei do que falo apanhei isso em 85 na primeira classe.

  3. int3 says:

    Eu tenho alguns maus hábitos :/
    Tenho que melhorar.

    • lmx says:

      não há ninguém perfeito,

      Como nos gerimos como um todo e a maior parte deve ser seguida… as coisas que pensamos serem boas podem ser consideradas más.. 😉

      lá está temos todos maus habitos, mas aquilo que hoje é um mau habito, amanhã também pode ser uma mais valia. lol 🙂

      • int3 says:

        pois pode. 😀
        Eu não consigo estimar o tempo que demoro a desenvolver uma certa aplicação porque há sempre algo que mete-me a martelar em algo durante uma noite e acaba por ser algo simples.
        E eu culpo sempre o utilizador. x)

        • Carlos says:

          Eu tenho o mesmo problema, as vezes uma coisa tao simples faz me perder até dias, coisa que eu não tinha previsto e que me faz sair logo fora dos planos. As vezes é tao simples que ate tenho “vergonha” de dizer ao cliente e invento outro problema.

  4. Steve says:

    muito bom artigo. Parabéns

  5. tomesoares says:

    A base de qualquer pessoa ou equipe de trabalho, parte sempre da “humildade intelectual” individual.
    O conteúdo deste post não se aplica só a programadores mas de forma longitudinal a todos aqueles que trabalham em equipa.
    +1

  6. Mark says:

    Eu sempre tentei utilizar estas e outras metodologias de forma a melhorar o projecto, ou seja fazer mais e melhor com muito menos esforço.

    O maior problema é tentar convencer os pseudo-gestores que “perder” 1 ou 2 horas a planear e analisar o projecto vai acelerar todo o processo. Para muitos desenhos é para designers e mesmo assim só pode a versão ficar a cores.

    Por muito triste que seja o “Developer” que utilize todas estas más praticas vai ser muito mais respeitado pelo chefe pois consegue mostrar qualquer coisinha em menos de nada.

  7. Rui C says:

    Eu tenho um gravíssimo … é não saber programar. :/

  8. KWu says:

    Eu passei com distinção em todas as práticas descritas.

    Ou sou muito bom ou muito aldrabão…

  9. JJ says:

    Concordo com alguns pontos/explicações e discordo com outros.

    Qualquer das formas, existem coisas que também tenho de melhorar…
    Mas como o artigo destaca, todos os programadores uma vez ou outra, falham em algum aspecto mencionado no artigo. E quem diz programador, diz outra área informática, porque alguns dos pontos também se aplicam.

  10. Courela says:

    A minha principal “batalha” tem sido mesmo com os prazos. É sempre tudo para ontem e depois esperam que o software tenha qualidade. Muitas vezes o developer nem tem voto na matéria, os prazos são definidos pelos gestores, ou pior, pelo cliente.

  11. Jorge says:

    Nao vi ai o PEBKAC em lado nenhum….

    • Luís Soares says:

      o que defendo é que não existem PEBKACs (mesmo que existam, é uma questão de me reger por esse princípio).
      se o utilizador não consegue fazer, das duas uma:
      ou não faz parte do público-alvo, ou a equipa não resolveu bem o problema.

  12. Jorge says:

    Só e só :))))

  13. Alexandre says:

    O artigo está muito bom, parabéns. No entanto acho que alguns tópicos são um pouco utópicos.

    A constante refactorização do código é problemática porque o seu valor não é reconhecido pela organização. O projecto está sempre atrasado e é difícil explicar a um gestor a razão de re-inventar a roda.

    O plano de projecto deve passar pelo programador, mas geralmente o GP é que decide tudo. É errado, mas o programador raramente tem o poder da decisão. Pode aconselhar, mas como é tudo para ontem pouca ou nenhuma diferença faz.

    A questão da delegação da culpa também é tricky. Se foi um colega meu que fez determinado módulo da aplicação e esse módulo tem um bug é com ele que vou falar. Não o faço para me descartar do problema mas porque acho que é cortesia profissional. Foi ele que fez o módulo, foi ele que desenhou a sua lógica, considero que seria um pouco desrespeituoso corrigir o problema sem lhe dirigir uma palavra. Se ele já não estiver alocado ao projecto ou se a tarefa me for alocada então aí sim vou ver o que se passa.

    Revejo-me nalgum dos defeitos: falta de pair programming, deslumbramento por angular e alienação do negócio 🙂

    • Luís Soares says:

      Olá Alexandre,

      Obrigado 🙂

      Quanto ao ponto da refatorização, não se deve fazer por fazer. Eu referia-me mais aos momentos em que algo tem de ser feito. Por exemplo, quando há um funcionalidade nova. Claro que não há regra sem exceção. O que quero dizer é que se deve refatorizar se há valor acrescentado, mas sempre fundamentado.

      “A questão da delegação da culpa também é tricky.”
      Talvez eu me tenha explicado mal. Não disse que a pessoa tenha de resolver. É apenas uma questão de atitude: em vez de ter uma atitude “não é comigo”, mais vale ter uma atitude “será resolvido” e depois sim, fala-se com a pessoa. O importante é desencadear a resolução do problema.

  14. MM says:

    Um programador não tem de ser designer, nem deve, tal como um designer não tem que ser programador.
    Cada um tem de saber o seu lado, um programador fazer mockups não me parece boa prática – fazer um esboço para ajudar o designer tudo bem, mas ser 2 e 1 acho que só é perda de tempo porque está a dispersar-se em duas frentes distintas.

    • Luís Soares says:

      se for um programador de um driver de software ou exclusivamente de backend, concordo. Agora, se estamos a falar de frontend, só pode ser positivo que o programador saiba um pouco de UX. afinal de contas, é para os utilizadores que ele trabalha. Não disse que tenha de ser especialista: daí só ter falado em mockups rápidos em papel e não em ferramentas profissionais de prototipagem.
      Fazer apenas uma coisa e recusar-se a saber de outras que lhe estão diretamente ligadas dá origem ao pensamento “linha de montagem” que vigora em muitas organizações.
      Por outro lado, UX não é trabalho do designer gráfico. É trabalho do designer de interação, que pode ou não ser ele. São coisas diferentes.

      • MM says:

        Sim, concordo. Daí ter dito que fazer um programador saber mockups rápidos ajuda até que a linguagem entre o designer e o programador seja mais facilmente entendida por ambos.
        Sim, um programador de frontend trabalha para o utilizador directamente, para geralmente quem tem a obrigação de saber como é que os UX se devem construir em termos de passar a mensagem e de serem funcionais (de ser claro, dos botões existirem ou estarem no local certo, etc.,), faz parte do estudo do designer.
        Mas pronto, também há os erros básicos dos designers quando constroem um mockup, p.ex., meter o design à frente da funcionalidade é um erro comum (e é o que mais se vê por aí).

      • MM says:

        De qualquer maneira, este assunto de relações entre designer, programador, ambiente de interacção, funcionalidades, UX e UI correctos e funcionais ou não, já é coisa para um artigo diferente 🙂

      • João Dias says:

        E aí entro eu, que sou UX Designer de profissão 🙂

        A User Experience não é competência apenas do designer (friso o apenas), é de todos num projecto. A preocupação com a experiência tem que estar em todos os vectores de uma organização. É isso que dá a qualidade final que toda a gente inveja, mas nem toda a gente consegue.

        Porque é por isso que é tão difícil implementar UX Design nas organizações. Porque nem toda a gente – dos gestores aos programadores e designers inclusos – se quer preocupar com o resultado final. Ou descuram a importância, ou tentam mostrar que estão preocupados com isso, mas as práticas não mudam.

        O valor do design numa organização que desenvolve software é algo que é cada vez mais importante. Às vezes as melhores soluções podem vir das mentes menos ligadas a um projecto, é importante meter todos no mesmo barco.

        Quanto à parte de desenvolvimento, eu tanto desenvolvo o UI de uma app, como ajudo na sua implementação. Essa ideia de que ou é preto ou é branco, não é de todo correcta. Não se pode ser designer e não conhecer um produto ou ajudar na sua implementação.

        Claro que não vou fazer o trabalho de um programador quando este está em frente ao Xcode ou ao Android Studio, mas é importante acompanhar a nível visual e de performance como o projecto está a ser desenvolvido.

        • Luís Soares says:

          Olá João,

          Concordo a 100% com a tua resposta. Sendo programador e “UX designer em part-time” luto diariamente com essas questões, especialmente:
          – o cargo de alguém não ser preto no branco
          – o UX não ser uma funcinalidade ou algo que se possa adiconar depois; tem de estar omnipresente
          – o valor do perfecionismo.

  15. Roberto Brandini says:

    Muito bom o seu post, concordo com todos os pontos.

  16. Eskiso says:

    “Isso? Isso é num instante…”
    5 horas depois: “Pá..isto tá complicado”

  17. Pedro says:

    Discordo no Pair programming.

    Existem tantos estudos a dizer que é eficiente como tantos outros a dizer que é uma perca de tempo.

    Sim ganhas mais segurança e certezas no código, mas tirando em questões de aprendizagem não faz muito sentido.
    Pagar a 2 pessoas para fazer o trabalho de 1? Não diria que é muito lucrativo.

    Num mundo perfeito talvez fosse engraçado.

    Mas com boas práticas, testes, testes, mais testes e algum code review consegues atingir os mesmos resultados.

  18. Bond says:

    Muito bom. É destes artigos que fazem o verdadeiro Pplware. É pena serem cada vez menos…

  19. Excelente conteúdo, é sempre benéfico reconhecer ou relembrar alguns dos factores que complicam o que por si só já é complicado.
    Gostaria de contribuir com dois erros que muitos programadores cometem (eu inclusive) e que não estão directamente ligados ao conteúdo do artigo mas que, na minha opinião, têm bastante importância para o assunto.
    Que são: o trabalhar pela noite dentro e a falta de exercício.
    Trabalhar pela noite dentro pode parecer mais produtivo, porque há menos distracções e não há hora definida para acabar o dia de trabalho, mas o cérebro não funciona da mesma maneira, o cansaço aumenta e gera fadiga mental.
    Fazer exercício é óbvio e do conhecimento geral “corpo são mente sã”. Mas em muitos casos este factor é sempre deixado para amanhã.

  20. F. Rios says:

    Muito Bom, ri-me bastante, então aquela expressão das marteladas, é “de génio”, pura realidade. =)

  21. Kitamura says:

    Excelente artigo, continuem assim. Ultimamente o PPLWare parece mais um site de notícias sobre smartphones que outra coisa, mas é bom saber que ainda fazem artigos assim =).

  22. Ana Rito says:

    O artigo está muito bom! Gostei muito de ler.

  23. Gonçalo says:

    O pior erro do programador é aceitar, em muitos casos, trabalhar por pouco dinheiro 🙂

  24. Ricardo Moura says:

    “Pode ter diferentes responsabilidades: sys. admin., tester, designer de interfaces, etc.”
    Fez-me lembrar uma empresa que perdeu o foco naquilo que sabia fazer bem, para se meter no mundo do software, lembrou-se que podia “fazer umas coisas” e até tentar vendê-las. Criou um departamento com duas pessoas, uma para gerir todo o projecto (waterfall) e outra para programar. O Jira foi substituído pelo Google Docs (a parte equivalente do Excel), o Eclipse pelo Notepad++, o SVN pelo Google Drive e o TDT por.. nada, não havia testes.
    Concluindo, Em empresas a sério, trabalha-se a sério (até existem technical writers, para escreverem a documentação do software, e esta hein?)
    Conclusão 2, Amigos se estão a ver no filme descrito anteriormente, provavelmente trabalham num vão de escada, talvez esteja na hora de alcançar novos horizontes e deixar o mercado dar conta dos tais vãos de escada.

    Beijinhos e Abraços!

    • Luís Soares says:

      Olá Ricardo,
      Obrigado pelo comentário. Respeito a sua opinião. Eis o que me leva a crer:

      0. Não deve ter lido a palavra “pode”
      1. É anti-agile
      2. Não deve considerar que há diferentes metodologias para diferentes ambientes. Não há uma super metodologia infalível.
      3. Talvez até ache que jira = gestão e gestão só com jira
      4. Considera que uma pessoa só pode fazer uma coisa, como numa linha de montagem. Ver filme Modern Times
      5. Só vê uma forma de fazer as coisas – by the book. Um consultor tem de se saber adaptar.
      6. Encaixa as pessoas em caixinhas é só podem fazer/saber o que diz no título dessa caixinha.

    • bin says:

      Ricardo, alguns de nós querem ser engenheiros e não apenas gurus de uma linguagem ou framework. E mais digo que as empresas a sério são os engenheiros que as fazem.

  25. José Simões says:

    Só uma sugestão

    Digitalizem e guardem esses desenhos juntamente o código.

    Mais: espero que os teóricos da gestão de projectos (pessoas em relação às quais eu tenho alguma desconfiança 😉 ) comecem a pensar como gerir essa parte.

    Isto é, avançar na direcção de metodologias em que os programas de gestão de versões de código também incluam documentos diversos, como os contratos com os clientes, comunicações entre os diversos intervenientes, os tais desenhos, etc.

    Tenho feito isso colocando sempre a data (e a hora!) em todos os papeis e mantendo isso arquivado em separadores, primeiro em gavetas, depois dentro de caixas plásticas herméticas que arrumo em prateleiras. Até já mantive mimi-cassetes audio analógicas nesses arquivos com a gravação de reuniões. Fiz isso porque tenho muito má memória e para me proteger, mas penso que reuniões que são gravadas em audio são muito mais produtivas (combine-se um sinal quando alguém quiser parar a gravação, mas que seja óbvio que o off-record não tem valor).

    Mas a gestão disso tudo em analógico é pouco prática, trabalhosa e ocupa espaço.

    Claro que se teria de definir um certo número de formatos e codificações livres de problemas com patentes (ascii-7-bits, unicode-utf-8-boom, png, jpg, mp3, odf ?) mas o pontos é que esse documentos deveriam ser geridos, juntamente com as versões do software, através de software adequado. e incluídos nos backups.

    Já é comum manter arquivos dos emails, mas não deforma integrada nos projectos. Também aí se poderia avançar, se bem que seja menos prioritário.

  26. Miguel Pinto says:

    Excelente artigo! Os vários tópicos descritos são o dia a dia dos programadores :). O importante é ter a humildade de reconhecer os erros e perceber o contexto onde estamos inseridos de forma a contribuirmos de forma positiva para o projecto. Sempre em busca da solução e não de quem originou o problema, visto que muitas vezes vêm de vários factores.

  27. Joao Maria Sesifredo Pimentel says:

    Muito interessante, gostei bastante .

  28. Redin says:

    A @Codacy dá uma ajuda.

  29. Hugo says:

    Excelente artigo.

    Muito interessante mesmo e aplicável em qualquer altura.

  30. José says:

    Excelente artigo, embora há certas afirmações que não concorde. Por exemplo, o programador deve conhecer todo o código – de momento trabalho numa solução que tem 500 e tal projectos e é impossível haver alguém que o conheça de ponta a ponta. Um grande problema, que pelo menos vi nas empresas portuguesas por onde passei, é que a maioria dos gestores de projecto só chegou a esse lugar por não saber/querer programar, e muitos fazem o papel de comercial. Não estão a par das tecnologias e metodologias. Ouvem falar de uma metodologia que está na moda e querem aplicá-la sem mais nem menos (quando na minha opinião as metodologias devem-se adaptar ao projecto e não ao contrário). A pressão sobre os programadores para cumprir prazos surreais também é sempre enorme. Qualquer tipo de documentação é sempre uma perda de tempo. Não existem equipas de teste. O cliente não faz testes de aceitação. Entre muitos outros problemas.

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.