Experiment: Durata de viata a becurilor (I)

Poate mi se pare mie, dar prea se ard becurile astea asa zis ecologice. Ar fi o problema daca ar fi doar ele, dar din pacate eu vad ca si alte tipuri de becuri se ard.

Cand spun ca prea se ard e clar ca asta se intampla cam des, cel putin in perceptia mea.

Ce incerc eu sa fac este sa loghez momentul cand schimb becurile, tipul becului si pe cat posibil momentul cand becul se arde.

Pe langa aceste lucuri de bun simt pentru realizarea experimentului este posibil sa mai adaug si alte elemente precum pretul si magazinul de achizitie. Daca acest lucru tinde sa devina mai mare decat e prevazut atunci e probabil sa realizez un proiect pe sourceforge, in care sa arunc ideile.

Orice sugestie e binevenita.

--------
Locatia instalatiei cu becuri: Bucatarie
Configuratia instalatiei:

• 4 becuri in linie dreapta de la E la V. 
• Identificator 0 primul bec ... Identificator 3 ultimul bec.

{Identificator + locatie} ar putea fi cheie primara daca sql-ul din mine nu-i destul de prafuit.

27 Decembrie 2012, schimbat Becul cu Id-ul 1 din Bucatarie. Tip bec: G9, Lampa Halogen, 35W (Facut Importat din China de Lohuis Romania)

Software development: Dealing with legacy code - The Zorro Approach

Like most of software developers today, I inherit code.

Of course, I also write new code and stuff but there are situations when legacy code must be fixed, updated, improved and so on. The bad part is that you rarely get to meet the original author of the modules you'll need to work at.

Well, in this situations, I think one should accept some facts about legacy code:

• it is usually considered good code
• it has been tested
• has brought and most likely still brings money to the company
• because of the above a rewriting decision is unlikely to happen with it

So what do you do when you need to add new functionality, fix some issues that didn't happen until now?

As a child I watched the Zorro series and all that the main character did after catching the bad guys was putting the "Z" from Zorro mark. This is what you should do with software that worked and now encountered unexpected cases. Only touch it where it is not working. Do not try to reorganize code that worked for many years, unless you covered all the cases.

Usually you will need to get familiar with that code. This probably takes months/years in order to reach a good level of understanding.


So here are my recommendations for such cases (I call this the Zorro approach):

• consult original authors or responsible people for guidance
• prefer local hacks to code refactoring/rewriting, unless rewriting is approved and easy to do
• keep documentation about what you did (you or someone else may need that later)
• always have tests (no matter what type: unit tests, validation tests, subsystem tests, etc) to check the code
• always run tests that worked with the previous version of code
• for each hack/patch always add a test with documentation about the problem
• tests imply that previous functionality shouldn't be affected; so don't affect previous functionality
• be proud ?!
• avoid this if possible :)