Temas en tendencia
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Absolutamente de acuerdo, y creo que las herramientas de LLM podrían ser una función forzada para adoptar algunas de las prácticas de los mejores equipos/organizaciones en equipos más pequeños que podrían no haber podido justificarlas antes.

1 oct, 06:01
No se trata solo de pruebas unitarias: hay muchas otras prácticas de ingeniería de software de primer nivel que aceleran la productividad con agentes de codificación
Pruebas automatizadas, documentación completa, buenos hábitos de control de versiones, una cultura de revisión de código, despliegue rápido en entornos de staging...
Creo que sería una locura tener varios cientos de ingenieros sin un linter. Sin embargo, si solo tienes dos o cuatro, tal vez nunca logres energía de activación para eso, y tengas peleas en su mayoría improductivas sobre el estilo de codificación.
Pero agregue el código Claude y a) quiere ese linter
b) configurar ese linter ahora es de cinco minutos de elevación marginal versus "Una persona desciende a una tarea clásica de tarpit de integrarlo con todos los IDE / etc."
Para la parte de mi audiencia que no lo sabe: un linter es una herramienta automatizada que puede hacer cumplir los estándares de la convención de codificación que son más estrictos que los que podría permitir un lenguaje. Por ejemplo, puede adoptar una regla de la casa que indique que no se permiten construcciones legales particulares
Como ejemplo, hay una expresión legal muy concisa en muchos idiomas llamada operador ternario.
Es notoriamente probable que los operadores ternarios causen errores, y un equipo de ingeniería podría decidir que, aunque concisos, sobre una base ajustada al riesgo, no son una característica aceptable para usar.
Como ejemplo de una cosa que puede regular sensatamente a través de linter que no desea tener que tener discusiones repetidas con Claude Code sobre: en Rails, something_id significa una clave externa para la tabla algo.
Claude olvida esto de vez en cuando, llamando a muchas otras cosas ids.
Puede, si lo desea, escribir una regla linter que se ejecutará cada vez que se modifique el código y marque a Claude y al resto del mundo: "Nombró una variable box_id, pero _ids solo se deben usar para referirse a claves de base de datos. Considere box_code o algún otro nombre".
Lo bueno de las reglas de linter es que pueden tener conocimientos específicos del proyecto incorporados arbitrariamente.
Un argumento repetido que un asalariado japonés se vio obligado a tener hace mucho tiempo, con (compañeros) hablantes no nativos haciendo una aplicación web universitaria: NO DEBES usar "sujeto".
¿Por qué no? Debido a que las universidades japonesas dividen las materias académicas en asignaturas (kyouka; una asignatura como "matemáticas") y una asignatura (kamoku; un tema como "álgebra lineal"), y dado que el subsujeto es espantoso de leer en código, el japonés romanizado se refería a ellos como siempre inequívocos.
30.66K
Populares
Ranking
Favoritas