c


 
 
  Por qu desperdiciar tu vida desarrollando software sino te
preocupas en hacerlo bien?
   Desconecta el piloto automtico y toma el control. Critica y
evala constantemente tu trabajo.

 
  
En vez de excusas, propn opciones. No digas que no
se puede hacer algo, explica mejor lo que s puedes hacer.
 
   Corrige malos diseos, decisiones equivocadas y el cdigo
mal escrito cuando lo veas.
 
 
 No puedes forzar que la gente cambie. En vez de eso,
muestra cmo podra ser el futuro y aydalos a participar en tu creacin.

!c  "No te obsesiones con los detalles porque hacen olvidarte de
lo que ocurre alrededor.
#

  $   
 Involucra a los usuarios para determinar
las necesidades de calidad reales del proyecto.
%     
 
  Haz de aprender un hbito
&  '


$ (

)No te dejes convencer por vendedores,
dogma o medios. Analiza la informacin en tus trminos y en basada en tu proyecto.
% $ 

'
. No tiene sentido tener buenas ideas
sino las transmitimos con eficacia.
 Cada pieza de conocimiento debe de tener una nica e inequvoca
representacin dentro de un sistema.
#'*
   Si es fcil de reutilizar, la gente lo har reutilizable. Crea un
entorno que apoye la reutilizacin.
+  '
 
 
 Los componentes de un diseo son
autnomos, independientes y tienen un nico propsito bien definido.
)(
  ' . Las decisiones no se deben grabar en una piedra, sino en la
arena de la playa. Cualquier decisin debe ser susceptible a cambio.
,
 . Haz distintas pruebas y tracea los resultados para ver
cmo se van compenetrando para llegar a nuestro objetivo.

  Crear prototipos es un experiencia para el aprendizaje. Su

valor no reside en el cdigo generado, sino en las lecciones que aprendes al crearlo.


 Disea y programa usando el mismo lenguaje usado por el
usuario.
# 
  Haz una estimacin antes de empezar. Podrs
adelantarte a los posibles problemas futuros.

   
 
- Usa la experiencia que vayas ganando para refinar las
escalas temporales de entrega del proyecto.
c  
 
    El texto plano nunca ser obsoleto. Ayuda a
aprovechar tu trabajo y simplifica la depuracin as como las pruebas.

.)/
 Usa la lnea de comandos (Shell) para
resultados seguros que no sean interferidos por las interfaces grficas.
   0
   El editor debe de ser una extensin de tu mano. Asegrate
que es configurable, ampliable (plugins) y programable.
 
 
- '  El control del cdigo fuente es una mquina del
tiempo, siempre puedes volver atrs.
& 
No importa de quin o de qu es la culpa, sigue siendo
un problema de todas formas y todava necesita ser reparado.
  .  /Respira profundamente y PIENSA en la causa del
error.
+ !
"Es raro encontrar un error en el Sistema Operativo o en el
compilador, o incluso en libreras de terceros. El error (bug) siempre es ms probable que
est en la aplicacin.
   Prueba tu hiptesis en el entorno actual que tengas, con datos
reales y condiciones lmites.
&      Gastas una gran parte del da peleando con
texto. Por qu no hacer que el ordenador haga el trabajo por ti?
+
 
- $ 
 
- Los generadores de cdigo aumentan la productividad
y evitan la duplicacin.
 
  '1'
El software no puede ser perfecto. Protege el
cdigo y a los usuarios de errores inevitables.

 2
 
 Recurre a los contratos para documentar y comprobar que el cdigo
hace realmente lo que tiene que hacer.
+ . Un error cuanto antes sea detectado mejor, har menos dao que aquel
que se detecte tarde, har que creemos que la aplicacin funciona.
' 
    Las afirmaciones validan tu hiptesis.
salas para proteger el cdigo de un mundo desconocido.


 

 El abuso del uso de excepciones
pueden convertir tu aplicacin en poco legible y sotenible. Usa las excepciones para casos
excepcionales.
&
$  Siempre que sea posible, la rutina o el objeto asignado a un
recurso debe de ser borrado cuando ya no sea necesario.
3  
   - Evita el acoplamiento debido al cdigo
tmido y aplica la Ley de Demeter.
 '    Implementa las opciones para una tecnologa usando opciones de
configuracin, no a travs de integracin ingeniera.



  
-  Programa para el caso general, y
coloca las especificaciones fuera del cdigo base compilado.
&  ' 


Aprovecha la concurrencia en
el flujo de trabajo del usuario.
 2
 Disea en trminos de servicios independientes, detrs de objetos
concurrentes bien definidos, interfaces consitentes.
  2


Permite la concurrencia, y disears interfaces ms
limpias.
 Gana flexibilidad a bajo coste diseando tu
aplicacin en trminos de modelos y vistas.
 
 ' Usa las pizarras para coordinar agentes
y hechos dispares, manteniendo la independencia y el aislamiento entre los participantes.



Confe slo en las cosas confiables. Ten cuidado con la
complejidad accidental, y no confundas una feliz coincidencia con un plan organizado.
#  
-    Ten una idea de la longitud de las cosas
antes de empezar a escribir cdigo.

   
 El anlisis matemtico no te lo dice todo. Prueba el tiempo
consumido por tu cdigo en su entorno final.
'
  '
  As como quitas las malas hierbas de un jardn
y lo reorganizas, reescribe, haz de nuevo y redisea el cdigo cuando sea necesario. Arregla
la raz del problema.
 2 Empieza a pensar en las pruebas antes de escribir una lnea de cdigo.
  '1)*     Prueba sin piedad. No hagas que los
usuarios encuentren los errores por ti.
   
- $  
 Los asistentes pueden generar
montones de cdigo. Asegrate de entender todo antes de incorporarlo a tu proyecto.
 $  0
Los requisitos rara vez estn en la superficie. Estn
enterrados bajo capas de supuestos, conceptos errneos y poltica.
,
     
    Esta es la mejor forma de
conocer cmo funciona el sistema que utilizarn realmente.
4

   *$ Invertir en abstraccin, no en la

implementacin. Las abstracciones pueden sobrevivir.
  (
Crea y mantn una nica fuente de todos los trminos y
vocabulario especfico de un proyecto.
  ' 

 
Cuando nos enfrentamos a un problema
imposible, identifica las limitaciones reales. Tienes que preguntarte Se tiene que hacer de
esta manera? Hay que hacerlo en todos?
+ 
  Has ido adquiriendo experiencia toda tu vida. No ignores las
dudas que te puedan surgir.
& 
 
 
$ 
 
  No caigas en la
espiral de las especificaciones, en algn momento tenemos que empezar a programar.
 
'No adoptes ciegamente cualquier tcnica sin
suponerla en el contexto de tus prcticas de desarrollo y capacidades.
4)  
 
  2Ten cuidado con las
exageraciones de los proveedores, el dogma de la industria, y el precio. Juzga las
herramientas en funcin a sus mritos.

 $ '

  No separes diseadores de
programadores ni los probadores (testers) de los modeladores de datos. Construye equipos
en funcin de tu manera de construir cdigo.
 
    Un Shell script o fichero por lotes se ejecutar las
mismas instrucciones, en el mismo orden, una y otra vez.
     ' *
Las pruebas que se
ejecutan cada vez que compilas son ms efectivas que los planes de pruebas tericos.
4
-  * )$ )( Queda
todo dicho.
  Introducir bugs a propsito en una copia
separada de la fuente para verificar que las pruebas detectan dicho error.
 
   
 
- Identifica y pon a prueba
los estados de los programas. Probar slo lneas de cdigo no es suficiente.
+
  Una vez que los probadores (humanos) encuentran un
error, esta debe de ser la ltima vez que se encuentra. A partir de ahora tienen que ser las
pruebas automticas las que comprueben los errores.
+    
- escribir documentos igual que escribes cdigo:
respeta el principio DRY (No Te Repitas, DontRepeatYourself), usa metadatos, MVC,
generacin automtica, as sucesivamente.

 
- 
 
- 
 
La documentacin
creada separadamente del cdigo acaba siendo poco precisa y actualizada.
'   
    Cuando comprendas las
expectativas de los usuarios, entonces es el momento de ofrecer un poco ms.
5  Los artesanos de la Edad Media se sentan orgullosos de firmar su
trabajo. Tu tambin deberas.









 


 
*elcome, Javalobby readers! You might be interested in the followup to this post.
Thanksforthegreatfeedback and suggestions.
|

| 
 
   





   
  


  





 

 
  ! 
   

 
  
 "


"
#"



 

 


|


 i


  |  

 

  
# 



  

  


$      









     


   
  
 
   
 
  
 %  


   
  
& 
 
"

|  #


   




"

|''   
  "



 |
 
() |
 
(
) 
*(+), 



 
 

  ++  


 %

$-- "



 &

 |
  

  ++ 



 

   
 
  
 
 



 
  
./

  
 

"

 



 | 
  
 0
$


1 #
$

  2   
3|0 
 

 

 

 
  
  


 


 

  3|

 &   
  4
  

 

$ 
 
)

 
$
 
  
  


  




 
 





   
   
 
 5

 
 
 

  4  
 
  
 
  3|


6
  
    7

 
  




  

     
 
   


 

| 
  




 |

$ 8 
8
 |
     

 &
 

 
 
 
  
 
 




   "

9$:


8
 











 |
 


%   
   
   + 

(

&+ 8  
  
  "




 
  
  

 "

 

 

4    "

  

    
 8
 



   
 

Note what  6 on the list: any of the Java 5 reference books or any of the tens (hundreds?)
of J2EE books. Its important to keep up with the language and the platform, but I think
thats better done through programming with the JDK and examples as reference. The
reference books can be helpful for getting up to speed for day to day work, but I don't think
they are essential for furthering your knowledge or your craft. Long after your J2EE

.4.x.niner book is collecting dust on the shelf, Effective Java will still be a reference you
consult regularly.