Tendencias del momento
#
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.
Estoy absolutamente de acuerdo, y creo que las herramientas LLM podrían ser un factor determinante para adoptar algunas de las prácticas de los mejores equipos/organizaciones en equipos más pequeños que quizás no hayan podido justificarlas antes.
1 oct, 06:01
No son solo 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 estarías loco por tener varios cientos de ingenieros sin un linter. Sin embargo, si solo tienes dos o cuatro, quizás nunca logres la energía de activación para eso, y tengas peleas mayormente improductivas sobre el estilo de codificación.
Pero añade a Claude Code y a) querrás ese linter
b) configurar ese linter ahora son cinco minutos de esfuerzo marginal frente a "Una persona desciende a una tarea clásica de tarpit para integrarlo con todos los IDEs/etc."
Para la parte de mi audiencia que no lo sabe: un linter es una herramienta automatizada que puede hacer cumplir estándares de convenciones de codificación que son más estrictos que los que un lenguaje podría permitir. Por ejemplo, puedes adoptar una regla interna que prohíba ciertas construcciones legales.
Como ejemplo, hay una expresión legal muy concisa en muchos idiomas llamada operador ternario.
Los operadores ternarios son notoriamente propensos a causar errores, y un equipo de ingeniería podría decidir que, aunque sean concisos, en base a un análisis de riesgo no son una característica aceptable para usar.
Como ejemplo de algo que puedes regular sensatamente a través de un linter y sobre lo que no quieres tener que discutir repetidamente con Claude Code: en Rails, something_id significa una clave foránea para la tabla something.
Claude olvida esto ocasionalmente, llamando ids a muchas otras cosas.
Puedes, si quieres, escribir una regla de linter que se ejecute cada vez que se modifique el código y avise a Claude y al resto del mundo: “Has nombrado una variable box_id, pero _ids solo deben usarse para referirse a claves de base de datos. Considera box_code u otro nombre.”
Una cosa buena sobre las reglas de linter es que pueden tener conocimiento específico del proyecto incorporado en ellas.
Un argumento repetido que un salaryman japonés se vio obligado a tener hace mucho tiempo, con (compañeros) hablantes no nativos que hacían una aplicación web universitaria: NO DEBES usar "subject."
¿Por qué no? Porque las universidades japonesas dividen las materias académicas en 教科 (kyouka; una materia como "matemáticas") y 科目 (kamoku; una materia como "álgebra lineal"), y dado que submateria es horrible de leer en código, se referían a estas por su romanización japonesa para que siempre fueran inequívocas.
30,66K
Parte superior
Clasificación
Favoritos