¿Cómo lograr que las personas valoren la abstracción y la flexibilidad en lugar de & # 8220; solo lograrlo & # 8221 ;?

Question

A veces tengo dificultades con otras personas que desean resolver un problema cuando desean omitir las interfaces oficiales y acceder directamente a los detalles de implementación subyacentes.

Argumentan que hacerlo les permitirá resolver el problema más rápidamente. Sostengo que hacerlo hará que nuestra arquitectura se acople más estrechamente y sea difícil de cambiar a medida que surjan nuevos requisitos.

Señalo todo el trabajo que se realizó en el diseño actual y la filosofía del diseño y el valor de la flexibilidad, el costo de tratar de mantener y cambiar el código frágil, el valor de la encapsulación y la ocultación de datos y las arquitecturas en capas y ser robusto para que pequeños cambios en la especificación conduzcan a pequeños cambios en el código. Y dicen "Pero esto sería más fácil".

¿Cómo manejas a estas personas?

Answer 1

Convencerlos de que tomar atajos es una economía falsa.

Explique que el esfuerzo inicial de codificación es menos del 30% del esfuerzo de desarrollo inicial y menos del 10% (en mi experiencia) del esfuerzo general del proyecto (incluido el mantenimiento).

Si no están convencidos y usted tiene la autoridad para hacerlo, dígales que lo hagan a su manera. Si no tiene la autoridad, no haga nada más. Eventualmente, su supervisor, si vale algo, lo reconocerá y usted estará en la posición de autoridad.

Answer 2

Haga que trabajen en algún código heredado que corrija los errores que contiene. Así es como la mayoría de las personas que conozco han aprendido estas lecciones realmente valiosas ... por las malas.

Answer 3

" Más fácil " cuando? Ahora, cuando todo no está en un estado de flujo? ¿O dentro de tres meses cuando los requisitos del cliente hayan cambiado y tengan una 'solución' que ya no sea una solución?

No me gustan mucho la estructura y las reglas por el bien de la estructura y las reglas, pero es bueno saber A) quién conduce el bote B) cuáles son las reglas y C) por qué elegimos hacerlo de esta manera .

En mi tienda no nos gusta tener que reescribir el código porque lo arruinamos y codificamos un montón de cosas o creamos alguna 'solución' frágil al problema. No suele ser más difícil seguir el enfoque más flexible una vez que la gente se da cuenta de que reducirá las frustraciones más adelante cuando las cosas se vuelvan al revés por un montón de cambios en los requisitos. Codificamos para 'largo recorrido', no para 'necesitarlo hoy', por lo general, por lo que el diseño se hace por una razón y el diseño se sigue por la misma razón .

Pasé una semana de mi vida (7 días seguidos) reescribiendo un módulo porque estaba en el modo 'hazlo rápido'. Siete días de tiempo agotador, días de 10-12 horas haciéndolo de la manera correcta, al final del juego, cuando podría haber estado viendo el Super Bowl. Eso apestaba. Aprendí una lección allí. Puede ser que tus 'amigos' también necesiten experimentar ese tipo de revelación.

¡Mucha suerte!

Answer 4

Realmente odio tomar la opinión disidente sobre esto, pero ...

Para citar a Van Halen (citando cliché), "hay un momento y un lugar para todo". Aunque ciertamente no abogo por escribir mal, nunca, a veces solo necesitas hacerlo, y encontrar ese medio feliz entre robusto / duradero y pirateado / documentado. (La parte documentada es particularmente importante, en dos frentes: uno, que indica claramente que todo lo que está haciendo se está haciendo simplemente en aras de hacerlo y está tomando ciertos atajos; y, dos, una idea aproximada en cuanto a cuál podría ser la forma más correcta de abordar el problema.

Como programadores, a menudo nos esforzamos por escribir el código perfecto (bueno, algunos de nosotros lo hacemos), y a veces perdemos de vista el panorama general; hay varias razones por las que podría estar bien (en un nivel) jugar rápido y suelto con el código, al tiempo que minimiza el impacto que tendrá en el futuro.

No utilice esto como justificación: la regla 80/20 se aplica aquí, por supuesto. La mayoría de las veces usted quiere aplastar cualquier atajo a lo largo de estas líneas; pero a veces ...

Answer 5

¡Muéstrales! Permítales hacer un pequeño módulo en "Pero esto sería más fácil". estilo mientras lo haces de la manera correcta. Luego pídales que realicen de 2 a 5 cambios en los requisitos (deben ser ellos los que realicen los cambios) y que tengan un concurso cronometrado para implementar los cambios. Puede tomar uno o dos días, pero lo conseguirán. Si no lo hace, tendrá la misma discusión sobre cada nuevo proyecto o tarea.

Answer 6

Podrías probar una analogía con ellos ...

Las reglas del ajedrez son bastante simples. Puedes enseñarle a un niño: "el caballo se mueve así", "el castillo se mueve así", etc.

Si eso es todo lo que sabes, puedes jugar un poco de ajedrez y probablemente pasar un buen rato, pero alguien con un conocimiento más profundo del juego va a limpiar el tablero contigo cada vez. Te golpearán tanto que ya ni siquiera será divertido, porque no tendrás idea de cómo lo están haciendo.

El mismo principio se aplica a la programación. Conocer la sintaxis del lenguaje y algunas estructuras de datos simples es suficiente para obtener un programa que funcione, pero no tendrá mucha suerte con una aplicación a gran escala que tenga que sobrevivir a múltiples ciclos de lanzamiento.

El ajedrez ha establecido aperturas, estrategias de ataque, etc. Tenemos patrones de diseño.

Answer 7

Lo mejor es probablemente promoverlos a la gerencia para que no puedan causar tanto daño.

Answer 8

El problema es que la mayoría de las personas ni siquiera conocen el diseño de software que no sean los conceptos más básicos y el desarrollo del estilo de arrastrar y soltar. Por cada desarrollador que investiga y se educa sobre los mejores nuevos conceptos y tecnologías, hay diez que se van a casa y no miran una PC. Tienes que enseñarles.

Answer 9

Diseñé un sistema grande y complicado hace unos cinco años. Pasé los siguientes cinco años inyectándome en cada proyecto que afectaba a "mi"; sistema para evitar que los bárbaros manchen mi arquitectura. Mientras aplicaba una presión constante e implacable, podía mantener la arquitectura bastante limpia, pero estaba luchando en una batalla perdida. He aquí por qué:

1) La mayoría de las personas son juzgadas sobre si hicieron el trabajo hoy . Nadie ha sido reprendido porque cortaron una esquina (o dos) hace tres años para sacar un proyecto a tiempo. Por otro lado, muchas personas han sido reprendidas por no hacer llegar los proyectos a tiempo.

2) Es posible que desee mantener el sistema ordenado porque tiene un sentido de propiedad sobre el código, o la aplicación, o los usuarios, etc. Muchas personas no tendrán un sentido de propiedad y, por lo tanto, están muy felices de hackear algo para que puedan terminar con eso. Puedes llevar un caballo al agua, pero no puedes hacer que se preocupe.

3) Si do convence a todos para que mantengan el código correctamente, nuevas personas se unirán y necesitarán que se les enseñe cómo hacer las cosas bien. Entonces, incluso si tienes éxito, puedes sentir que estás fallando porque siempre estás luchando la misma batalla contra nuevos oponentes.

4) En realidad puede estar equivocado. ¿Tendría sentido financiero para Microsoft gastar el doble de horas de programador para hacer que MS-Paint sea robusto y fácil de mantener? A veces, un sistema feo y pirateado es lo suficientemente bueno. La mayoría de los buenos programadores tienen problemas para entender esto, pero esto generalmente se debe a que son buenos programadores.

5) Juro que hay algunas personas que disfrutan perversamente de hackear cosas porque pueden hacerlo más rápido, o serán los únicos que lo entienden, o tienen una necesidad infantil de romper las reglas. No puede razonar con estas personas, y cuanto más tiempo pase discutiendo con ellas, más se acercará la fecha límite del proyecto, lo que lo obligará a piratear algo juntos de todos modos.

6) Hay una buena posibilidad de que comprenda el sistema mejor que ellos. Lo que parece un truco feo para ti podría parecer '' pisar ligeramente '' a una persona que no está tan familiarizada con el sistema. O el esfuerzo adicional para hacer que el código sea robusto protegerá al programador contra un problema que nunca ha tenido antes y, por lo tanto, no puede asimilar. No aprende a verificar los códigos de retorno hasta que algo sale mal porque no verificó un código de retorno. En ese punto deja de ser "trabajo extra". y comienza a ser "trabajo requerido".

Si tiene un equipo de desarrollo pequeño y ajustado, es posible. Pero cuanto más grande es la organización, menos probabilidades hay de que tenga éxito. Si logra que una tienda de TI de 250 personas valore hacer las cosas bien en lugar de hacer las cosas rápido, entonces sus poderes de persuasión son legendarios.

Answer 10

http://catb.org/jargon/html/L/LART.html SCNR, etc. pp;)

Answer 11

Dígales que lean (no es que nunca lo harán) la teoría de la encapsulación: http://www.edmundkirwan.com/