coding-style - códigos - como detectar codigo malicioso en mi web

¿Cómo justificar a tus colegas que producen un código malicioso? (16)

¿Ha considerado agregar quizás fxcop a las compilaciones automáticas para imponer el estilo de codificación? Aparte de eso, podrías intentar sugerir TDD que otorgaría poder a quien escribe la prueba para que las interfaces para cada clase estén estructuradas de una manera particular.

Fuera de mi cabeza, eso es todo lo que puedo pensar.

Me resulta algo difícil seguir trabajando en mi trabajo actual.

La base de código se ha vuelto un poco salvaje últimamente (pero definitivamente no es lo peor que he visto), y estoy teniendo dificultades para tratar con algunas partes del código. Podría ser estúpido, pero lo más probable es que me desmotive mucho para empezar a trabajar en algo que es difícil razonar.

Mi jefe ya está al tanto de mis pensamientos. Expresé lo que se siente al trabajar así. Me pidió que diera ejemplos de lo que estaba mal. Cuando señalé dos o tres pequeños problemas, dijo "sí, está bien", pero esa refactorización le cuesta mucho dinero, y tenemos que sacar el producto (no es la primera vez que escucho esto).

Tengo que admitir que los ejemplos no fueron los más convincentes, pero el problema es realmente difícil de explicar. Se compone de un montón de pequeñas "malas decisiones" a lo largo de la base de código. (También vemos que este problema es absolutamente subjetivo). Por ejemplo, nombrar mal, tratar con nulos, repetitivo, no hacer código reutilizable (o lo contrario) y así sucesivamente. Puede ser agotador volver a pensar en el código de otra persona para justificar que lo hubiera hecho de otra manera.

¿Tienes ideas sobre cómo lidiar con esto? ¡Estoy harto de tener que piratear una base de código rápida y sucia todo el tiempo!

Creo que una vez que estás en el medio de las malas hierbas, realmente no tienes una buena posibilidad de hacer las cosas bien, solo tienes que hacerlas. Yo diría que a la mayoría de los desarrolladores no les gustan los bomberos y quieren la base de código ideal, pero en mi opinión, esto requiere que pases el tiempo planeando el sistema.

Recomiendo tratar de trabajar con su gerente para garantizar que las áreas que cree que faltan ahora no faltan en el próximo proyecto. Tal vez sea ponerlo a usted a la cabeza, tener más revisiones de código con sus compañeros, tal vez sea una capacitación adicional para todo el equipo.

De cualquier manera, creo que esto es algo por lo que la mayoría de nosotros pasamos. Estoy de acuerdo con que la otra persona advierta un poco de precaución al respecto. Sé que el código que escribí ayer parecía genial en ese momento y, al mirar atrás, probablemente encuentre otras 10 maneras de hacerlo y que se vea más limpio.

Descubrirás que es un lugar común. Lo que puedes hacer es aceptar que las cosas se hacen de forma diferente por diferentes personas. Al corregir errores o agregar funciones, obtendrá una breve ventana en una subsección de la aplicación que puede mejorar. Cuando trabajas en el código, puedes hacerlo mejor, y no necesitan saber que estás mejorando el código gradualmente.

Sé muy cuidadoso sin embargo. A veces el código está escrito de una manera que parece ''pirateada'', pero resuelve un error que no es fácil de discernir. Especialmente si se trata de un código anterior que ha sido probado.

En otra nota, quejarse solo hará que te vean como un quejoso. Piense qué resultado desea, y qué acciones probablemente producirán ese resultado. Siempre escuchará la respuesta "No" cuando pregunte: "¿Puedo hacer X días de trabajo sin ningún resultado notorio?"

El 99% de las veces nunca puedes elegir a las personas con las que trabajas. No todas las relaciones funcionan, ya sea que trabajen o no.

Sería mejor si su proyecto se dividiera lo suficiente como para que cada desarrollador pueda contribuir a una especificación de lo que el otro necesita, de modo que los programadores no se pisen los dedos del pie.

Hacer que la gente cambie su estilo de codificación es difícil. Se necesita un cable técnico de hierro fundido para estas cosas y ayudará cuando lo menciones. Los tipos de gestión no pueden hacer esto, el liderazgo necesita proporcionar detalles técnicos.

Las cosas en la vida no son perfectas y si comienzas a criticarte, las plumas se agitarán y las relaciones se agotarán.

El mejor método es elegir tus batallas cuidadosamente. Si algo es lo suficientemente pequeño ignóralo y vive con él. Si es grande y vale la pena (es decir, la administración ve que el ROI lo respalda) apúntelo.

Esto es apto para su situación ...

Dios, concédeme la serenidad para aceptar las cosas. No puedo cambiar el coraje para cambiar las cosas que puedo y la sabiduría para saber la diferencia.

Lo único que tiene una oportunidad de convencer a la gerencia es demostrar que las cosas que usted cita como problemas percibidos se convierten en problemas reales .

Para tratar de aprovechar esto, trate de mantener el tono de "quejoso" al mínimo, es decir, enfóquese en cómo esto afecta el resultado final en lugar de cómo lo hace sentir. Señale las posibles consecuencias de las malas decisiones que ve que se toman. Si esas consecuencias se cumplen, y cuestan más de lo que un arreglo inicial tendría, recuerde suavemente a la gerencia que ha previsto la dificultad y brinde una sugerencia útil sobre cómo evitar futuros costos similares con un pequeño esfuerzo inicial.

El problema es que, en muchas organizaciones, los problemas nunca causarán un problema suficiente para que la administración lo cuide, o si lo hacen, no verán la conexión entre su percepción del problema y el problema real tal como ocurre. En estos casos, terminas viendo como una persona técnica innecesariamente perspicaz, que no es una reputación que deseas tener.

Entonces mi consejo es, elige tus batallas. Si hay algo muy atroz que otros están a punto de dejar escapar, entonces puedes hablar y quizás ser vindicado más tarde. Para los pequeños detalles que simplemente te critican, me temo que no hay mucho que puedas hacer sino aguantarlo.

Me parece que no tienes tanto problema con el código como tus compañeros de trabajo . Probablemente le resulte muy difícil forzar los cambios que desea ver. Su mejor opción sería comenzar a actualizar su currículum y mantener los ojos abiertos para otras oportunidades

Podrías dejarlo y esperar encontrar algo mejor.

O bien , podrías aguantarlo e intentar mejorar el código que puedes controlar, cuando puedes controlarlo. No importa qué tan bien intencionados sean los desarrolladores, si hay más de un desarrollador, la base del código será "fea" según los estándares de un desarrollador competente. Trabaja con los otros desarrolladores para mejorar sus habilidades y refactorizar el código a medida que realizas mejoras.

Recientemente me enfrenté a un problema muy similar y un amigo me dio algunos consejos que me ayudaron mucho. Él dijo: "mantente fuera de eso".

Lo que quería decir es que debe comunicar los problemas porque son problemas reales y costosos con consecuencias en términos de tiempo y dinero. Pero cuando te comunicas, habla solo de las consecuencias para la organización. No menciones las consecuencias para ti, porque entonces suena como un lloriqueo y será ignorado.

Por ejemplo:

No mantenerse fuera de esto:

"Los otros desarrolladores usan estos identificadores oscuros y engañosos y luego tengo que pasar horas repasando el código tratando de descubrir lo que significan. Me está llevando mucho tiempo".

Mantenerse fuera de esto:

"Sería muy útil y rentable hacer algunas refactorizaciones de nombres de clases y variables y también establecer algunos estándares de codificación en torno a los identificadores. El beneficio inmediato será una base de código más fácil de entender para todos, lo que redundará en una mejor productividad. La recompensa del término será que más adelante podremos modificar el código y arreglar las cosas más rápido. Si se descubre un error crítico justo antes de una publicación, una base de código comprensible será realmente importante ".

Espero que eso ayude.

Si tiene una buena relación con su gerente, es posible que pueda usar esto para trabajar en una función de Desarrollador "Senior" o "Lead". Podría proponer que sería mejor si una persona en el equipo toma el liderazgo técnico de la base de código. Sería su trabajo revisar el código de los demás y pedirles que realicen mejoras cuando lo considere necesario. Si vas por esta ruta, solo asegúrate de tomarla lentamente. Si pide mucho rápidamente, podría terminar molestando a todos los demás desarrolladores.

Tal vez podría configurar reuniones mensuales y en esas reuniones podría demostrar buenos y malos códigos. Obviamente, no quiere señalar con el dedo, por lo que querrá utilizar ejemplos de código genérico que se basen en las cosas que vio en su proyecto. De esta manera, puedes reunir de manera constructiva el apoyo de otros en tu estilo. Es posible que desee compilar estos después de las reuniones para que las personas puedan consultarlos fácilmente.

Creo que es muy fácil señalar problemas y quejarse, pero ser mentores y ayudarlos a cambiar requiere un esfuerzo. No es una tarea fácil, pero si tiene problemas para sentirse motivado con su trabajo, quizás le genere una buena motivación. Puede aprender algunas cosas a lo largo del camino.

Una cosa que trato de hacer y puede ser de ayuda. Si una parte del código es incorrecta, y la idea que propone corregir es la mejor, pero se da una excusa de "no hay tiempo", ¿por qué no la reescribe? ¿Decir en tu propio tiempo? Si decides quedarte un tiempo en ese trabajo, solo te ayudará. Y solo usted aprenderá y se convertirá en un mejor programador.

Tenga en cuenta que es una buena idea e incluso diría que es necesario, hacer una revisión completa del código de ese cambio antes del check-in y debe intentar programar el check-in para que sea antes de un ciclo de prueba de regresión completo para un lanzamiento . De esta forma, su refactorización quedará completamente probada. En un período de aproximadamente 6 meses, comenzará a mostrar un impacto beneficioso y luego podrá solicitar una asignación de tiempo para esto, con pruebas que lo respalden.

1) Haga que el problema sea más visible y obtenga la aceptación de la administración

Mantenga un diario muy detallado del tiempo dedicado a varias tareas de codificación durante el período de aproximadamente un mes. Al final del mes, analice y resuma los contenidos para su jefe, es decir, tiempo perdido y, por lo tanto, dinero desperdiciado, para ilustrar que es necesario cambiar de alguna forma.

2) Piense en una forma rentable de seguir adelante

Por ejemplo; En lugar de refacturar toda la base de códigos, separar las interfaces de las implementaciones y aplicar estándares más estrictos, incluidas pruebas unitarias, convenciones de nomenclatura, etc. en una capa de interfaz. Por lo tanto, cada programador puede confiar en el uso de un código que no haya escrito. Si bien esto está barriendo la basura debajo de la alfombra hasta cierto punto, es una buena forma de prepararse para una refactorización a mayor escala.

Desde el punto de vista de la gestión, es importante que el flujo de trabajo no se interrumpa y que los resultados positivos sean visibles, por lo que debe planificarse en consecuencia.

3) Acuerde mejoras de términos más largos con sus compañeros de trabajo

Siéntese y acuerde estándares de codificación razonables para el código futuro con los otros programadores.

Muéstreles su propio código olvidado disfrazado como suyo para la crítica.

Tome una vieja parte de su código que han olvidado
Finge que lo escribiste
Pídales que descubran algo con eso
Asegúrese de que señalen qué tan malo es el código por el motivo que sea
Agregue sus propios artículos. Haga una lluvia de ideas sobre lo que debe hacerse, ya que es su culpa.
Hágales saber que no sabía cómo provocarlo para ofenderlos, pero es su código.

Si recuerdan que lo escribieron, podrían entenderse ...

A veces, tus compañeros programadores hacen las cosas de manera muy diferente a ti , y las cosas que podrías sentir que están muy equivocadas en realidad podrían tener aspectos positivos. Todos tenemos nuestras escuelas de donde venimos. Creo que me he encontrado con programadores que se quejan de cosas que no entiendo con la misma frecuencia que yo mismo he sentido que algo tiene que quejarse.

Asegúrate de que puedas deducir de qué te quejas en una desventaja concreta . Si no es por ninguna otra razón para que pueda motivar a la gerencia media acerca de las mejoras que debe realizar. Las cosas que son difíciles de deducir en hechos mensurables generalmente provienen de la diferencia en el gusto / estilo más que en la calidad (hay boooks para leer sobre este tema). ¡La respuesta publicada por smacl tiene buenos y concretos consejos!

Si puede deducir su preocupación en una desventaja real, entonces realmente no estoy de acuerdo cuando la gente dice que uno tiene que "aceptar" situaciones como esta. He estado expuesto a este problema más de una vez, y déjame decirte, la refacturación no es la solución al problema. Refactorizar solo corrige los síntomas .

Aceptar una situación como esta es lo mismo que decir " las líneas de productos de mala calidad y el mantenimiento costoso y frustrante es algo con lo que mi compañía puede vivir " . Por supuesto, esto rara vez es el caso. Sin embargo, la administración (es decir, los que tienen la opción de ir / no seguir qué proyectos priorizar) a menudo no es técnicamente consciente de cuáles son los problemas o por qué el desarrollo es costoso. No deberían tener que ser para ese asunto.

Es por eso que necesita una organización de desarrollo con clientes potenciales, arquitectos jefes, una buena estructura organizativa y un modelo por niveles, etc. Profesionales de software experimentados que han visto a dónde conduce el camino si ignoran ciertos aspectos del desarrollo. Se trata de cambiar la "cultura" de su (s) equipo (s).

O te quedas con tu compañía y tratas de cambiar la forma de hacer las cosas desde la raíz , o encuentras otro lugar para trabajar y te aseguras de averiguar durante la entrevista cómo funcionan exactamente en el desarrollo diario.

Buena suerte

Para principiantes:

Aplicar el uso de herramientas de análisis de código estático. Cada idioma tiene algunas herramientas bien conocidas.
Muestre algunos ejemplos de códigos refactorizados antes y después y explique por qué cree que es mejor. Trata de no poner a ninguna persona en el lugar.
Revisiones de código por desarrolladores experimentados.
tenga en cuenta que no se puede ayudar a algunos desarrolladores sin importar cuánto intente ...
Si alguien critica su código, sea cortés y de mente abierta, puede aprender algo.
Complejidad ciclomática / cantidad de conjuntos de cambios / errores. Es más probable que el código complejo se rompa, causando más errores que causan más cambios, ¡que cuestan más dinero!