language agnostic - ¿Cuál es la idea errónea más dañina de los principiantes sobre la programación?
language-agnostic (30)
Posible duplicado:
¿Cuál es la suposición de programación más larga que resultó ser incorrecta?
¿Cuál considera que es la idea errónea más dañina sobre la programación de personas que son nuevas en la programación que ha visto?
- Que su programa funcionará
- Si el obstáculo anterior se supera milagrosamente, su programa funcionará según lo esperado por el usuario final
- Si el obstáculo anterior nuevamente se supera milagrosamente, su programa resistirá el paso del tiempo, es decir, será fácil de mantener
- Si todos los obstáculos anteriores vuelven a superarse milagrosamente, su segundo sistema será tan bueno o mejor
"¡Voy a ganar muchísimo dinero jugando con las computadoras!"
Editar: Otro que me vuelve loco:
"El código del otro tipo no llama al mío correctamente, así que no es mi culpa que el sistema no funcione". - sin una investigación proactiva, diagnóstico, parche sugerido, nada. Como gerente o líder de equipo, esto realmente se mete debajo de la piel.
"El problema no está en mi programa, es un error en la biblioteca / OS / language".
"¡Funcionó en mi máquina! ¿Qué pasa con la tuya?"
"Todo es un patrón, solo tienes que encontrarlos".
"No necesito probar porque solo hice un cambio de una línea".
"El control de la fuente es una pérdida de tiempo para este proyecto".
¡Que "romperán" algo!
O bien, para definir a los "recién llegados" como aquellos que no lo hacen, "¡Será fácil cambiar! ¡Es un software!"
aclamaciones,
Despreciarlos de la idea de que "perfecto pero muy tarde" es mejor que "aceptable y puntual".
A nadie le importará si un informe semanal se ejecuta en 5 segundos en lugar de 8 si se retrasa dos meses.
El concepto erróneo más dañino es suponer que las personas en la industria del software saben lo que están haciendo. Los principiantes tienden a confiar en todo lo que está escrito en la documentación del producto, confían en los mensajes de error y las descripciones de las excepciones. Incluso confían en cosas publicadas en blogs.
El error más común es que puede escribir una aplicación iniciando su IDE / editor favorito y luego escribir el código inmediatamente.
Sí, creará una aplicación. Sí, probablemente también sea cr @ p cuando hayas terminado ...
Comienza a desarrollar software creando primero un diseño. Preferiblemente con lápiz y papel o con algunas herramientas útiles en su computadora. Escribir el código real es una pequeña parte de todo el proceso. (Si no, estás haciendo algo mal!)
El error más dañino es: has terminado cuando obtienes el código para que funcione.
El verdadero problema que he visto con los tiros de programación es "programar es magia", lo que significa no creer realmente que la computadora funcionará exactamente de manera lógica, y hará exactamente lo mismo cada vez, con la misma información.
Escriben algo que creen que debería hacer lo que quieren y luego, cuando no funciona, en lugar de tratar de abordar el problema lógicamente, comienzan a cambiar las cosas de forma semi-aleatoria, esperando, aparentemente, apaciguar a los dioses de la magia informática. por su tenacidad o disposición a humillarse sobre el altar de la fantasía. Sienten que la computadora es caprichosa y cambia las cosas de forma aleatoria, y lo mejor que pueden esperar es hacer que las cosas se aproximen a una vaga aproximación de trabajo, y esperar que las estrellas permanezcan alineadas durante largos períodos de tiempo.
Por supuesto, incluso para los programadores experimentados, puede sentirse de esa manera a veces, pero hay un conocimiento inherente de que lo que está sucediendo está sucediendo por una razón específica, y solo tiene que profundizar para llegar a esa razón.
Esa programación tiene que ver con la sintaxis. Resulta que se trata de resolver problemas.
Eso genial == utilizable.
Eso porque su programa compila y ejecuta lo que espera que haga.
Eso si su código no compila o funciona, es debido a un error en el compilador.
La peor idea errónea que he encontrado, y la más difícil de eliminar, es que la programación es escribir código y no leerlo.
Pensando que si no se ve horriblemente complicado, debe ser un código incorrecto o "malo".
Debo admitir que hace años en la escuela yo era culpable de pensar que mis programas no parecían lo suficientemente complicados. En estos días quiero llorar si algo no resulta tan simple como:
//start
if(something)
{
do_stuff();
}
//go home
:PAG
Que debe usar todas las características del idioma que está aprendiendo, herencia sobre todo.
Actualizado: ser obsesivo con el código en línea ensamblado en C
Que el programa debe ser correcto la primera vez.
Fracasar rápido, temprano y a menudo. Es la única forma de mejorar.
Que el usuario es un programador.
Que la parte difícil es tipear en el código. Cuanto más avanzas, más se convierte en la parte fácil.
Que si su programa funciona en su propia computadora, también funcionará en la computadora de todos los demás.
"¡Pero funciona en mi máquina!"
Que su código no necesita ser documentado. Son los únicos que lo mirarán alguna vez, ¿verdad?
Que su solución es la única y única forma de resolver el problema , y todos los demás son tontos e incorrectos.
Que tienes que tener patrones de diseño en tu código.
Reinventando las funciones / clases de la biblioteca estándar.
Después de pasar por un libro de idiomas / tutorial, la mayoría de los principiantes, que saben cómo manejar cadenas y números, inventarán sus propias funciones de fecha, sus propios ''algoritmos de compresión'', sus propias implementaciones de SORT.
Ah, y siempre pasan su primer día buscando clrscr(); .
Tal vez no sea el más dañino, pero por lo general no pueden estimar cuánto tiempo tardarán en realizarse, creen que se puede hacer mucho más rápido de lo que realmente debe (incluido yo).
En cuanto a las cosas dañinas, las buenas compañías suelen mantener a los principiantes lejos de donde pueden hacer mucho daño. Por lo general, se les anima a trabajar por alguien con más experiencia, para que puedan aprender mejor.
Temprano:
- Pero, ¿no es todo el mundo un x86?
- Tengo que pasar un tamaño con ese búfer?
- ¿Comprobación de errores? ¿Por qué?
- El STL es demasiado complicado. Prefiero implementar todo yo mismo.
- (Utilice std :: swap ()! Std :: swap ()! Comience allí, luego ramifíquese a más ...)
- Sin saber que no puede tratar los búferes binarios como cadenas sin cancelar primero el nulo. (Piense: leer (), recv (), etc.)
Mas tarde:
Pensando erróneamente que ...
- Que hay 8 bits en un byte.
Esa recolección de basura lo salvará de la administración de recursos.
Endianness? ¿Relleno? No puedo simplemente escribir (), enviar (), etc. toda la estructura?
- Hilos y bloqueos y condiciones de carrera oh mi.
- i18n? (2009, y todavía estamos aprendiendo que la tierra es redonda!)
- Podría haber escrito esto mejor. Hora de reescribir (Sugerencia: refactor .)
- Tiempo relacionado, pensando erróneamente que:
- Eso dentro de un año calendario, DST comienza antes de que termine.
- Que todas las zonas horarias son + o - horas completas.
- Que el desplazamiento máximo UTC es + o - 12 horas.
- Que hay 60 segundos en un minuto.
- Ese 1900 es un año bisiesto.
Pensando erróneamente que:
- 16 bits es suficiente para mantener un punto de código Unicode.
- Puedo ignorar las bibliotecas de FOSS que me harán el 90% del trabajo.
- Ese ensamblador C, C ++, Python, Lisp, C #, .NET, Java, VB6, Ruby, PHP, Bash es el lenguaje perfecto para cada tarea.
Tiene algo que ver con las computadoras.
Todo lo que hay que hacer es construir cosas nuevas y geniales todos los días. ¡El mantenimiento es parte de la programación!
concepto erróneo más dañino (versión financiera):
"Que se requiere una educación universitaria para saber o entender cómo escribir software".
- La programación es fácil: programar es muy divertido, pero nunca pienses que es fácil. Se necesita mucha experiencia, aprendizaje y fracaso para mejorar y ser humilde al respecto.
- Las herramientas lo hacen por mí, así que no necesito saber qué sucede debajo de las fundas: las herramientas facilitan mucho las cosas y te permiten hacer las cosas más rápido. Sin embargo, aún necesita saber y familiarizarse con lo que sucede debajo de las fundas, porque tarde o temprano tendrá que abrir el capó.
- Falta de curiosidad
- Se trata de las tecnologías más nuevas y más geniales: no necesariamente. Se trata de lo que es correcto para el cliente y el problema que está tratando de resolver.