Software engineering have made progress in 15 years!
Joel Spolsky is a good example of how you can safely manage your source
code base, and we do!
Of course you need to deprecate (remove) former code once in a while --
that's an easy deal.
FWIW, we do use run-time version control when dealing when AJAX request
because the FoxInCloud.js client file can be out of sync. with the
server (no longer a concern as the production server update routine now
includes the site components including HTML, CSS, JS, images, etc.)
Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/
Le 07/01/2016 10:41, Fernando D. Bozzo a écrit :
In my experience, this kind of programming is very dangerous:
#IFDEF PREVIOUS_VERSION
... && current code
#ELSE
... && copy of current code to be changed
#ENDIF
because to be successeful, it is needed that en every version developers
clean the code constantly.
One of our teams worked this way for years in VFP, and right now, 15 years
later, this application (a big one) is unmaintainable, because nobody ever
have made a cleanup of this code, so now you can found spaguetti code with
various levels of nested #IF, which is too costly and difficult to analyze
and modify.
Another problem for this #IF..#ENDIF technique is that requires
recompilation to be used, and the this causes real problems too because
when you use Source Code Control with the code with the binaries (SCX /
VCX) and their text representations, you normally only upload (checkin)
code when there is real code changed, and not when you only recompile.
For evaluating, it's better to use normal variables (even based on table
values) with normal IF..ENDIF, which always get evaluated in real time, and
do not require recompilation and a new EXE. This allows the activation or
deactivation of functionallity on real time.
2016-01-07 10:12 GMT+01:00 Thierry Nivelet <[email protected]>:
Does sound like a killer, but feasible... and useful on critical features
only!
Requires that developer no longer modifies code directly, but:
1 - creates a structure around code to be 'modified':
#IFDEF PREVIOUS_VERSION
... && current code
#ELSE
... && copy of current code to be changed
#ENDIF
2 - modifies 'copy of current code to be changed' only
3 - before starting next next version, replace all 'PREVIOUS_VERSION' by
'VERSION_MAJ_MIN_0' where 'MAJ' and 'MIN' are the current major and minor
version numbers.
Adding this in some .h file restores previous code:
#DEFINE PREVIOUS_VERSION
Adding this in some .h file restores previous previous code:
#DEFINE VERSION_MAJ_MIN_0
Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/
Le 07/01/2016 09:52, AndyHC a écrit :
On 07/01/2016 13:43, Thierry Nivelet wrote:
3- isolation: being able to compile with or without a given feature
without any side effect
sounds like a killer for anything but cosmetic changes
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
