El documento describe los posibles efectos de la construcción casi gratuita utilizando robots avanzados. Esto podría conducir a una reducción dramática en los costos de construcción, pero también podría reducir la calidad del diseño. Sin costos de construcción, los diseñadores podrían implementar diseños no probados con el fin de ganar ventajas de mercado. La presión para usar diseños incompletos sería fuerte. Sin embargo, las simulaciones físicas y las pruebas automatizadas podrían ayudar a validar los diseños de manera más

1. Imagínese despertar MAÑANA y el aprendizaje que la indus-tria de la construcción ha hecho que el
gran avance del siglo. Millones de barato, muy
robots rápidos pueden fabricar materiales de la nada, tienen un gasto energético casi nulo,
y puede repararse. Y lo que es mejor: dado un modelo inequívoco
para un proyecto de construcción, los robots pueden construir sin la intervención humana,
todos a un costo insignificante.
Uno puede imaginar el impacto en la industria de la construcción, pero lo haría
pasar aguas arriba? ¿Cómo sería el comportamiento de los arquitectos y diseñadores de cambiar
si los costos de construcción fueron insignificantes? Hoy en día, los modelos físicos y el equipo
estén
construido y probado rigurosamente antes de invertir en la construcción. ¿Nos molesta
si la construcción era esencialmente libre? Si un diseño se derrumba, no es gran cosa, sólo
averiguar lo que salió mal y que nuestros robots mágicos construir otro.
Hay otras implicaciones. Con los modelos de diseños obsoletos, sin terminar
evolucionar de forma repetida la construcción y mejora en una aproximación de la
poner fin a meta. Un observador casual podría tener dificultad para distinguir un producto
inacabado
diseño de un producto terminado.
Nuestra capacidad para predecir los plazos se desvanecerá. Los costos de construcción son más
fácil de calcular los costos de diseño, sabemos el costo aproximado de install-ción de una viga, y
cómo muchas vigas que necesitamos. Como tareas predecibles encogerse hacia
cero, el tiempo de diseño menos predecible comienza a dominar. Los resultados se produce
más rápidamente, pero los plazos fiables escapar.
Por supuesto, las presiones de una economía competitiva se siguen aplicando. Con los costos de
cons-trucción eliminadas, una compañía que rápidamente se puede completar un diseño gana una
ventaja en el mercado. Conseguir rápido diseño hecho se convierte en la central de inserción de
las empresas de ingeniería. Inevitablemente, alguien no muy familiarizado con el diseño se ve
una versión no validados, consulte la ventaja en el mercado de la liberación temprana, y decir:
"Esto parece lo suficientemente bueno."
Algunos proyectos de vida o muerte será más diligente, pero en muchos casos, los consumi-dores
aprender a sufrir a través del diseño incompleto. Las empresas podrán enviar
nuestros robots mágicos para "parchar" los edificios rotos y vehículos que venden.
Todo esto apunta a una conclusión asombrosamente intuitivo: nuestra única premisa
era una dramática reducción en los costos de construcción, con el resultado de que la calidad tiene
peor.
No debe sorprendernos que la historia anterior se ha representado en software.
Si aceptamos que el código es el diseño de un proceso creativo en lugar de un mecánico
un crisisis el software explicado. Ahora tenemos una crisis de diseño: la demanda
por la calidad, diseños validados supera nuestra capacidad de crear. La presión
utilizar el diseño incompleto es fuerte.
Afortunadamente, este modelo también ofrece pistas sobre cómo podemos mejorar. Físico
simulaciones equiparar a las pruebas automatizadas, diseño de software no está completa hasta

2. que
se valida con una batería de pruebas brutal. Para realizar dichas pruebas más eficaces,
estamos encontrando maneras de frenar el enorme espacio de estados de sistemas grandes.
Mejorado
lenguajes y prácticas de diseño nos dan esperanza. Finalmente, hay un inevitable
hecho: grandes diseños son producidos por grandes diseñadores que se dedican a
la maestría de su oficio. Código no es diferente.

3. Código de Diseño
Cuestiones
NÚMERO ANiNFEASiBLE de años, yo trabajaba en un sistema donde Cobol
los funcionarios no se les permitió cambiar la sangría a menos que ya
tenía una razón para cambiar el código, porque una vez que alguien rompió algo por
dejar que un deslizamiento de línea en una de las columnas especiales en el principio de una línea.
Esta
aplica incluso si la distribución era engañosa, que a veces era, así que tenía que
para leer el código con mucho cuidado porque no podíamos confiar en ella. La política debe
haber costado una fortuna en la fricción programador.
Hay investigaciones que sugiere que todos gastan mucho más de nuestra programación
tiempo navegando y leyendo el código de búsqueda de aquello a que el cambio de
en realidad escribiendo, así que eso es lo que queremos optimizar. Aquí hay tres tales
optimizaciones:
Fácil de escanear
La gente es muy buena en concordancia con el modelo visual (un rasgo sobrante de la
momento en el que tuvo que reconocer leones en la sabana), así que puedo ayudarme a mí mismo
haciendo todo lo que no está directamente relacionada con el dominio, todo
"Complejidad accidental" que viene con la mayoría de los comerciales idiomas:
se desvanecen en el fondo mediante la estandarización de la misma. Si el código que se comporta
el
mismo se ve igual, entonces mi sistema perceptivo ayudará a escoger
las diferencias. Es por eso que también observan las convenciones acerca de cómo poner
las partes de una clase dentro de una unidad de compilación: constantes, campos, público
métodos, métodos privados.
Diseño expresivo
Todos hemos aprendido a tomar el tiempo para encontrar los nombres correctos para que nuestro
código
expresa con la mayor claridad posible lo que hace, en lugar de limitarse a enumerar la
pasos, ¿verdad? El diseño de código forma parte de esta expresividad, también. Un corte primero
es tener el equipo de acuerdo sobre un formateador automático para lo básico, y luego
Yo podría hacer ajustes a mano mientras estoy de codificación. A menos que haya activo
disensión, un equipo rápidamente se reunirán en un común "acabado a mano"
estilo. Un formateador no puede entender mis intenciones (que debería saber, que una vez
escribió uno), y lo que es más importante para mí que los saltos de línea y agrupaciones
reflejar la intención del código, no sólo la sintaxis del lenguaje. (Kevin
McGuire me liberó de mi esclavitud a formateadores automática de código.)
Formato compacto
Cuanto más lo puede obtener en una pantalla, cuanto más veo sin romper con-texto de
desplazamiento o cambio de archivos, lo que significa que puede mantener menos en mi estado
cabeza. Comentarios largos procedimientos y un montón de espacio en blanco tiene sentido para

4. Los nombres de ocho caracteres y las impresoras de línea, pero ahora vivo en un IDE que hace
coloreado de sintaxis y reticulación. Los píxeles son mi factor limitante, por lo que yo quiero
cada uno para contribuir a mi comprensión del código. Quiero que el diseño
que me ayude a entender el código, pero no más que eso.
Un amigo dijo una vez que nonprogrammer código es poesía. Me sale
esa sensación de realmente bueno de código que todo en el texto tiene un propósito,
y que está ahí para ayudarme a entender la idea. Desafortunadamente, la escritura de código
no tiene la misma imagen romántica como escribir poesía