É "contanto que funcione" a norma? [fechadas]

Veja minha pergunta mais recente: a programação como profissão está em uma corrida para o fundo?

Minha última loja não teve um processo. Agile significava essencialmente que eles não tinham um plano sobre como desenvolver ou gerenciar seus projetos. Significava "ei, aqui está uma tonelada de trabalho. Faça isso em duas semanas. Estamos em ritmo acelerado e ágil".

Eles lançaram coisas que sabiam que tinham problemas. Eles não se importaram como as coisas foram escritas. Não houve revisão de código - apesar de haver vários desenvolvedores. Eles lançaram um software que sabiam ser de buggy.

No meu trabalho anterior, as pessoas tinham a atitude desde que funcionasse, tudo bem. Quando pedi uma reescrita de algum código que eu havia escrito enquanto estávamos explorando a especificação, eles negaram. Eu queria reescrever o código porque o código foi repetido em vários lugares, não havia encapsulamento e as pessoas levaram muito tempo para fazer alterações.

Então, basicamente, minha impressão é a seguinte: a programação se resume ao seguinte:

1. Lendo um livro sobre as mais recentes ferramentas / tecnologias
2. Reunindo código com base nisso, evitando escrever qualquer código individual porque a empresa não deseja "manter o código personalizado"
3. Mostrando e passando para a próxima coisa, "desde que funcione".

Eu sempre disse a mim mesma que no próximo emprego vou comprar uma loja melhor. Isso nunca acontece. Se é isso, então eu me sinto preso. As tecnologias sempre mudam; se o único desenvolvimento profissional aqui é ler o mais recente livro de tecnologia da MS Press, o que você construiu em 10 anos, a não ser um conhecimento superficial de várias tecnologias? Estou preocupado com:

1. Melhor maneira de ter padrões profissionais
2. Como desenvolver conhecimento e experiência significativos nessa situação

Você indiretamente se deparou com o que eu acho que é o aspecto principal de ser um bom desenvolvedor : encontrar o equilíbrio entre " contanto que funcione " e código elegante e bem projetado.

Assim como na política, é muito mais fácil apostar sua posição em uma extremidade do espectro do que tomar uma posição diferenciada no meio. A maioria dos desenvolvedores que encontrei se enquadra em uma de duas categorias: codificação de hackers de cowboys e astronautas de arquitetura. Eu tento encontrar um equilíbrio entre os dois. Não é tão fácil quanto parece.

Para responder mais diretamente à sua pergunta, sim, acho que "contanto que funcione" geralmente é a norma. Mas olhe de outra maneira: você está em uma excelente posição para educar seus colegas e tentar introduzir algumas práticas melhores. Mas não vá ao extremo e lembre-se de por que estamos fazendo isso: para resolver os problemas de nossos clientes.

>> No meu trabalho anterior, as pessoas tiveram a atitude, desde que funcione, tudo bem.

Talvez eu seja uma minoria aqui, mas tenho a mesma atitude e acredito firmemente que, para reescrever algo, deve haver uma evidência clara de por que precisamos disso. E não quero dizer algo como "uf, não gosto de como foi codificado" - todo desenvolvedor tem suas preferências sobre o código. Deve haver alguns problemas com a parte que queremos reescrever:

• Problemas de desempenho
• Foram encontrados mais erros do que em qualquer outra parte do sistema
• Os desenvolvedores passam mais tempo trabalhando nessa parte
• etc.

O Agile não é responsável por nenhum ser humano que decida lançar o software de buggy; os seres humanos são.

Dito isto, você dá muita importância à qualidade, e isso é bom. Tenho certeza de que você é um perfeccionismo e se preocupa com seu próprio valor, se não se atualizar com as tecnologias mais recentes.

O problema é que o perfeccionismo leva à procrastinação e a procrastinação leva à mediocridade .

É por isso que os negócios colocam prioridade em itens como tempo de lançamento no mercado e usam o ágil para agregar valor rapidamente e em um ritmo previsível.

Como você não descreveu a estratégia de negócios da sua empresa, acho que você deve começar perguntando sobre isso aos seus gerentes.

Ao estar alinhado aos objetivos e planos deles (eles o contrataram para ajudá-los a alcançá-los), você estará em melhor posição para entender como poderia contribuir com eles, em vez de se concentrar em seus objetivos pessoais e pessoais.

Tenho certeza de que, ao tentar understando valor deles, você poderá compartilhar o seu, e isso será o começo de uma colaboração frutífera.

E se você descobrir que eles não sabem o que estão fazendo, sua única opção será desistir .

Tudo depende do que você está construindo. Se você estiver construindo um microsite que ficará online apenas por um mês e você terá nove dias para construí-lo: sim, contanto que funcione será suficiente.

Se você estiver escrevendo os algoritmos fly-by-wire para o sistema FA-18, é melhor construí-lo da maneira mais perfeita possível.

Assim como é o caso da maioria das respostas tecnológicas ... depende.

Depende da empresa. No entanto, muitas empresas têm concorrência séria e pressão de tempo. Essa é uma razão típica. Outra seria uma grande carga de trabalho, potencialmente sem pessoal suficiente. (Existem algumas boas razões para falta de pessoal, que não são necessariamente culpa da empresa.) Dito isto, algumas organizações não conseguiam sair de um saco de papel molhado.

Eu acho que a regra 80/20 se aplica aqui. Basicamente, você precisa aguentar os 80% ruins e trabalhar até os 20%. No entanto, perceba que mesmo eles terão que fazer trocas. Nos negócios, geralmente não importa se você está absolutamente certo. É importante que você o tenha agora.

se o único desenvolvimento profissional aqui é ler o mais recente livro de tecnologia da MS Press, o que você construiu em 10 anos, a não ser um conhecimento superficial de várias tecnologias?

Isso seria um pouco chato, mas pode ter havido algumas falhas espetaculares a serem observadas naquela década. Eu já vi muitos lugares onde me lembro de coisas bastante específicas que eu gostava de trabalhar lá ou que não gostava e, portanto, questionaria tê-lo novamente em meu novo local de trabalho. Às vezes, pode haver uma nova prática para tentar, se uma empresa tentar implementar o Scrum ou adotar uma abordagem de Desenvolvimento Orientado a Testes, essas podem ser oportunidades, mas não necessariamente o desenvolvimento profissional, pois não é uma sala de aula formal.

Conheço vários lugares onde o "contanto que funcione" é comum, juntamente com várias estratégias de codificação de cowboys. Em algumas empresas iniciantes, vi esse tipo de mentalidade que pode fazer sentido se a empresa for tão jovem que ainda está tentando expor a ideia do que realmente está tentando fazer. Em outras empresas em que trabalhei, houve mais processos e uma maturidade que pode ser bastante boa, embora não necessariamente fácil de encontrar. Alguns lugares tinham alguns processos que eu conseguia ver e seguir: "Eu gosto disso. Vou me lembrar disso para situações de trabalho posteriores" e outros para onde eu iria: "Eu realmente não gosto disso. Vou notar para tentar evitar isso no futuro. "

Eu trabalhei em uma loja como essa por um tempo, exatamente no ponto em que as alcançava. Havia aplicativos de dois ou três anos com bugs conhecidos que eles literalmente não conseguiam resolver. Pense em um loop longo de 4.000 linhas com um cálculo contínuo para larguras e alturas de layout. A correção de um pedaço de código para reparar um problema em uma instância resultaria em vinte problemas em outros lugares, porque os desenvolvedores anteriores haviam ajudado problemas semelhantes com bandas ajustando arbitrariamente os resultados dos cálculos com números mágicos. O código não pôde ser descrito como algo além de tóxico.

Finalmente, recebi um novo projeto que meu chefe me disse que poderia usar esse código existente para lidar com layouts. De alguma forma, convenci-o a me deixar "alterá-lo" para que ele me desse um tempo extra. Eu usei o tempo para escrever uma biblioteca bem projetada para ajudar no layout. Erros neste novo projeto levaram 10 segundos para ser resolvido. Eu pude identificar problemas antes mesmo de olhar o código para ver o que havia de errado.

Eu pensei que isso resultaria em um ponto de virada para o meu gerente, mas tudo o que consegui foi um tapinha nas costas e ele basicamente me disse que "o seu jeito também funciona, eu acho".

Desde então, comecei a trabalhar para outra loja e as coisas estão melhores aqui. O ponto é que você não pode mudar de idéia. Apenas vá trabalhar em outro lugar.

Ainda tenho esperança de que na economia exista um tipo de processo evolutivo que, mais cedo ou mais tarde, tire essas empresas do negócio. Mas talvez o alto ritmo do progresso tecnológico produz muitos nichos novos, de modo que mesmo os concorrentes fracos ainda consigam encontrar "comida" suficiente.

Se você deseja aumentar suas chances de trabalhar em um bom local, procure uma empresa que tenha um produto que eles vendem para muitos clientes, em vez de escrever algo novo a cada poucas semanas. Deveria haver mais interesse em ter uma boa base de códigos e poder adicionar novos recursos sem interromper o código existente o tempo todo.

Lembra-me do meu colega de faculdade. Ele estava participando de uma aula de design VLSI e, em sua primeira lição de casa, encontrou um componente da ordem de micrômetros de largura e uma milha de comprimento. As simulações passaram perfeitamente.

Sua resposta aos críticos foi: "Tudo o que sei é que minha merda funciona".

Uma norma bastante boa é o princípio de Pareto

Tenho experiência em um projeto com regra 80-20 e funcionou muito bem. Penso que as respostas a esta pergunta "Onde você desenha a linha do seu perfeccionismo" também podem ser úteis.

O termo "princípio de Pareto" também pode se referir à eficiência de Pareto. O princípio de Pareto (também conhecido como regra 80-20, lei dos poucos vitais e princípio da escassez de fatores) afirma que, para muitos eventos, aproximadamente 80% dos efeitos vêm de 20% das causas. O pensador de administração de empresas Joseph M. Juran sugeriu o princípio e o nomeou em homenagem ao economista italiano Vilfredo Pareto, que observou em 1906 que 80% das terras na Itália eram de propriedade de 20% da população; ele desenvolveu o princípio observando que 20% das vagens de ervilha em seu jardim continham 80% das ervilhas. É uma regra prática comum nos negócios; por exemplo, "80% de suas vendas vêm de 20% de seus clientes". Matematicamente, onde algo é compartilhado entre um conjunto suficientemente grande de participantes, deve haver um número k entre 50 e 100, de modo que "k% seja obtido por (100 - k)% dos participantes". O número k pode variar de 50 (no caso de distribuição igual, ou seja, 100% da população tem partes iguais) a quase 100 (quando um pequeno número de participantes responde por quase todo o recurso).Não há nada de especial no número 80% matematicamente, mas muitos sistemas reais têm k em algum lugar nessa região de desequilíbrio intermediário na distribuição. O princípio de Pareto está relacionado apenas tangencialmente à eficiência de Pareto, que também foi introduzida pelo mesmo economista. Pareto desenvolveu os dois conceitos no contexto da distribuição de renda e riqueza entre a população.

Link para fonte

Quando pedi uma reescrita de algum código que eu havia escrito enquanto estávamos explorando a especificação, eles negaram. Eu queria reescrever o código porque o código foi repetido em vários lugares, não havia encapsulamento e as pessoas levaram muito tempo para fazer alterações.

Sem ofensa, mas como gerente, li essa declaração em algum lugar ao longo das linhas de:

"Quando pedi o pagamento duas vezes para reescrever algum código que eu já havia escrito, minha empresa não quis pagar. Eu queria o dinheiro extra para limpar a bagunça que eu fiz quando o escrevi pela primeira vez, e meu colegas estavam com raiva de mim por tornar suas vidas difíceis ".

Se você está reclamando do seu próprio código, não precisa se apoiar muito.

ATUALIZAR

Entendo que esse ponto de vista é impopular. Mas também não acho que seja incongruente com as responsabilidades e atitudes de um desenvolvedor profissional.

Se você escrever um código limpo para começar (e há várias razões para fazer isso - independentemente se você acha que seu código vai ver o uso da produção ou não), então você terá esse problema com muito menos frequência.

Se você incluir código limpo e tempo de refatoração em suas estimativas, também terá a programação para manter a base de código organizada. Se, devido à pressão do cronograma, você não obtiver o tempo necessário - suas estimativas futuras deverão subir como resultado do tratamento da dívida técnica incorrida.

Em algum momento, suas estimativas futuras (ou incertezas em torno de suas estimativas) permitirão argumentar por uma reescrita (quando seu gerente estiver implorando para que você agilize o processo). Caso contrário, aceite que a empresa aceitou sua estimativa e prefere pagar o custo contínuo do que a substituição. Isso é puramente uma decisão comercial - não técnica.

Lembre-se de que o tempo para negociar agendas é antes de você escrever o código - não depois. Depois que o código é escrito (e "funciona"), clientes, gerentes e executivos não querem ver outra fatura de "manutenção" que se aproxime ou exceda o custo original. Se você se sente tão fortemente quanto pensa que a empresa deve, fique à vontade para reescrevê-la no seu próprio tempo - é isso que você está pedindo à empresa.

Do ponto de vista do seu gerente, programar a reescrita coloca sua bunda em risco. Quando você falha na entrega ou aumenta a produtividade tanto quanto você diz - então ele é quem fica segurando a sacola. Comparado ao inconveniente relativamente pequeno de ouvir você reclamar, adivinhe qual ele prefere.

Se esse é o tipo de trabalho que você pode conseguir, concentre-se em escrever um código melhor a cada vez, em vez de voltar e reescrever o código antigo. Ainda existe uma faixa de qualidade que você pode adotar no campo da colagem de pacotes de terceiros.

Se você tiver tempo e quiser melhorar o código de um componente existente que mantém, não poderá fazê-lo sem pedir permissão, desde que o que você faça funcione? Fatore o tempo em suas estimativas para o próximo projeto que usa o componente.

Para programação de nível inferior, se você não consegue obter satisfação com o trabalho, talvez seja a hora de analisar um projeto de código aberto.

q303, achei sua pergunta interessante e achei que você talvez achasse vale a pena ler esta pergunta sobre programadores sobre como convencer os gerentes a permitir que os desenvolvedores lidem com dívidas técnicas.

Eu acho que geralmente, sim, é a norma. Entenda que o software funcionando, mas menos do que o ideal, é muito melhor que o software que não está funcionando. Há também o argumento de que a definição de "trabalho" pode variar com base na percepção e nos vieses de cada indivíduo. Quando você implementa um novo sistema, sempre há alguém que diz que sentiu que o sistema antigo era melhor. E quando você fala com um desenvolvedor, é provável que ele ou ela relute em admitir ter trabalhado em software ruim.