Βάζω εδώ αυτό το θέμα ελλείψει καλύτερου topic και μια και βασικά δεν αφορά μόνο το VS.NET αλλά και γενικότερα θέματα οργάνωσης.

Ας υποθέσουμε λοιπον, για χάρη του παραδέιγματος, οτι μια ομάδα προγραμματιστών δουλεύει μια εφαρμογή. Ας υποθέσουμε οτι αποτελείται από 3 προγραμματιστές.

Υπαρχουν στην εφαρμογή τα εξής:
Presentation tier (winforms, asp.net, οτιδήποτε)
Business logic layer (COM+)
Data Access Layer (COM+)

Τα βάζω σε com+ γιατί πρώτον αντιπροσωπεύει τα προβλήματα που αντιμετώπισα και εγώ εδώ και αρκετό καιρό και δεύτερον γιατί εκεί τα πράγματα γίνονται πραγματικά δύσκολα όσον αφορά στο teamworking.

Ας πούμε λοιπόν οτι κάθε προγραμματιστής έχει την ευθύνη ενός layer. Ας υποθέσουμε ακόμα οτι υπάρχει άριστη επικοινωνία μεταξύ τους σχετικά με τα signatures ωστε να μην υπάρχει πρόβλημα συνεργασίας και να μην "σπανε" τα builds.

Εδώ αρχίζουν τα προβλήματα:
Πως κάνει ο καθένας τη δουλειά του;

Στη δική μου περίπτωση κάναμε το εξής: Στήναμε ο καθείς τοπικά τα com+ μας, ολα μαζι, στο δικό μας μηχανάκι (και το UI). Δουλεύαμε το δικό του com+ o καθένας. Τα references ήταν σε ένα κοινό network drive και από εκεί τα βουτάγαμε (με copy local true ή false).

Ετσι ο καθείς μπορούσε να δουλέψει ενώ οι άλλοι αλλαζανε τα φώτα στο δικό τους layer.

Οταν αλλαζε ένα signature, ας πούμε το data access layer, ο υπαίτιος ειδοποιούσε τους υπόλοιπους και όταν ήταν έτοιμοι ανέβαζε νέο dll στο network drive. Οι υπόλοιποι θα έπρεπε:

- Να κλεισουν τα δικά τους ή να βρουν κανα μακρο για να φρεσκάρουν τα references
- Να απεγκαταστήσουν τα com+
- Να σηκώσουν την εφαρμογή με το ανανεωμένο ref και να φτιάξουν και τις δικές τους  κλήσεις
- Να εγκαταστήσουν τα com+
- Να συνεχίσουν.

Ωραία μέχρι εδώ. Και ασφαλές, και δεν σου σπάνε τα νευρα τα references αφού παραμένουν σταθερά απο όπου και να το ανοίξεις, και και και....

Και ξαφνικά ερχομαι εγώ και παίρνω ΟΛΑ τα components τοπικά για να κάνω κάποιες διορθώσεις.

Αρχίζουν τα πρόβλήματα:
Που και που δεν μπορώ να αντιγράψω στο δικτυακο επειδή κάποιο VS κλειδώνει και πρέπει να το κλείσω.
Τα references δεν γίνονται refresh και πρέπει να τα βγάζω και να τα ξαναβάζω σε κάθε ένα project κάθε φορά που αλλάζω signature σε ένα άλλο.

Λεω και εγώ εντάξει, και αλλάζω τα references σε τοπικά (το ένα κοιτάει στο bin folder του άλλου). Παλι αν αλλάξω signature καπου, τζιφος. Refresh references δεν υπαρχει (χρησιμοποιώ macro που δεν δουλεύει σε αυτή την περίπτωση), το καλό είναι οτι μπορώ να κάνω update το δικτυακό drive μια και κανείς δεν κοιτάει πιά εκέι. Αλλα μου σπάει τα νεύρα να πρέπει να έχω 200 VS ανοιχτά.

"Α, λεω, εξυπνος ειμαι, θα τα βάλω όλα μαζί σε ΕΝΑ solution". Αμ δε. Για κάνε debug com+ έχοντας τα πάντα σε ένα solution. Τα references παίζουν και γίνονται refresh (project references), debug ομως τσου. Και μην ακουσω το γνωστο "κανε attach σε όλα τα dllhost που είναι ανοιχτά", θα κόψω τις φλέβες μου!

Εν κατακλειδι και επειδή απλά σκέφτομαι τον πόνο μου δυνατά:
ΠΩΣ μπορεί να επιτευχθεί σωστό teamworking με το visual studio, com+ or not? Αλλάζεις references που υποτιθεται οτι ειναι ΓΙΑ ΣΕΝΑ εχοντας το solution σου έξω από το sourcesafe, έρχεται ο άλλος, κάνει get latest, παίρνει τα δικά σου references που μπορεί να μην του δουλεύουν. Τα βάζεις σε δικτυακό, έχεις προβλήματα locking. Εχεις ενα project για κάθε component, εχεις προβλήματα. Εχεις ένα solution για όλα, έχεις προβλήματα. ΠΩΣ πλεον πρέπει να δουλεύει μια ομάδα;

Ναι, δοκίμασα και το visual build pro (τουλάχιστον) πριν προλάβει κανείς να ρωτήσει. Αλλα δεν θέλω (και δεν μπορώ) να έχω διαθέσιμες τέτοιες λύσεις ακόμα.

Ελπίζω να μην σας μπερδεψα πολύ. Απλά θα ήθελα να μου πείτε τις δικές σας εμπειρίες από teamworking με vs.net. Πως ειναι το σωστό approach ΣΤΗΝ ΠΡΑΞΗ; Τα papers της Microsoft, λυπάμαι που το λέω, αλλα πιό πολύ σε μπερδεύουν παρά σε διαφωτίζουν....

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Non com+ version που χρησιμοποιώ εγώ: Τα references είναι όλα μεταξύ projects, εκτός κάποιες εξωτερικές dlls που κατεβαίνουν από το source safe σε προσυμφωνημένη κοινή για όλους τοποθεσία στο δίσκο.

Τα projects μας μπορούν να χωριστούν ουσιαστικά σε δύο ανεξάρτητα solutions, το τι solution θα χρησιμοποιεί ο καθένας είναι δικό του καπέλο, απλά υπάρχει και ένα συνολικό solution για να υπάρχει ενημέρωση για νέα projects που πρέπει να μπουν μέσα.

Κολλήματα και κλειδώματα περιστασιακά υπάρχουν αλλά σε ανεκτό επίπεδο. Τα συχνότερα πρόβληματα είναι στο να θέλουν δύο developers το ίδιο αρχείο την ίδια στιγμή, και ιδιαίτερα σε update web references για projects που παίζουν για web services.

Η επιχείριση πάντως αποφεύγει να απομονώσει τους developers σε συγκεκριμένα layers από φόβο μήπως την κάνει κάποιος developer και μείνει όλος ο layer αμανάτι...

---

Χρήστος Γεωργακόπουλος

Διάβαζα τα παραπονά σου και πρέπει να πώ ότι δεν είναι μακριά από την καθημερινή πραγματικότητα.

Μερικά κόλπα που χρησιμοποιούσα:

Το μοίρασμα της εφαρμογής σε tiers είναι κάτι που είναι αναπόφευκτο σε μεγάλα έργα. Ναι, στο να δώσεις σε ένα developer/μία ομάδα ένα tιer και να δουλεύει αυτό. Μπορεί να ασχοληθεί περισσότερο με το συγκεκριμένο κομάτι και να κάνει καλύτερες βελτιστοποιήσεις.

Ναι, στην χρησιμοποίηση του COM+. Όχι, στην εισαγωγή στο COM+ components που είναι στο δίκτυο. Έχω την εντύπωση ότι πρέπει να σου βγάζει και ένα warning όταν το κάνεις αυτό, αλλά το δέχεται - είναι κάτι DO NOT DO! Πιστεύω, ότι ο κάθε developer πρέπει να τα τρέχει στα local component services, και να έχει τον απόλυτο έλεγχο των components - το studio μπορεί να τα κάνει refresh στα component serices αυτόματα. Τα πακέτα των applications μέσα στο Component Services να τρέχουν με το δικό του λογαριασμό. ΜΟΝΟ TOTE μπορεί να κάνει debugging μέσα στα component services. Σε περίπτωση που δουλεύαμε 2 μαζί, τα components ήταν σε ένα μηχάνημα και ο δεύτερος έμπαινε με Remote Desktop και τον ίδιο λογαριασμό - πάντα σε Windows Server 2000 - συνήθως με τον Local Administrator. Όσοι δούλευαν με τα Components μας χρησιμοποιούσαν stubs.

Όταν ετοιμαζόταν το component services application, γινόταν export το stub στους άλλους. Αυτοί το φόρτωναν τοπικά και έτσι κάνανε τοπικό reference και είχαν πάντα το πιο καινούργιο διαθέσιμο από την αντίστοιχη ομάδα. Αλλαγή του stub χρειάζεται, όταν αλλάξει το signature του component. Αλλά και πάλι η αλλαγή δεν ήταν και τόσο ζόρι, αφού από το Add/Remove στο Control Panel, έβγαζες το παλιό και έκανες εγκατάσταση το καινούργιο. Κλείσιμο του Studio είναι απαραίτητο για να δει την αλλαγή. Δεν είχες το πρόβλημα να προσέχεις να είναι κάτω το component για να το βγάλεις και να βάλεις το καινούργιο, και αν ξέχναγες να το κατεβάσεις, να πρέπει να κάνεις rebοot για να δεις την αλλαγή!

Τα components πρέπει να είναι το καθένα στο δικό του project. Το χρησιμοποιούσα κατά κόρον για .ASP εφαρμογές. Έτρεχα το component (dll), χτύπαγα την σελίδα από το browser και όταν γινόταν instance από το .ASP τότε ο έλεγχος ερχότανε στο studio. Από κει και πέρα ξεκίναγε το step & debug και ο IIS έκανε timeout.

Αυτό που παίζει ρόλο πολύ είναι όλα τα μηχανήματα να έχουν το ίδιο λειτουργικό - όλοι Windows 2000 Server Std. Οχι ανάπτυξη ενός layer σε XP και export σε packages για να φορτωθούν σε Windows 2000. Μου είχαν στείλει ένα package από Αγγλία exported από XP και δεν έπαιξε ποτέ σε Windows 2000 Server. Αναγκάστηκα τότε να κάνω register όλα τα DLL ένα προς ένα και να τους περάσω τα constraction strings με το χέρι, copy & paste... Τι δημιουργική ώρα που είχα περάσει να το κάνω αυτό για 120 dlls!

Ακόμη σε N-tier εφαρμογές που είναι σε πάνω από ένα server, πρέπει να είναι όλα το ίδιο λειτουργικό! Μην πω ότι και ο SQL σου ή όποια μηχανή RDBMS χρησιμοποιείς. Αλλιώς DTC "καπούτ"! Την είχα πατήσει με 2000 Server και NT4 Server και ενώ δούλευε όλη η εφαρμογή τέλεια όταν έφτανε η ώρα να γίνει η χρέωση στον πελάτη - τι πιο ιδανικό να έχεις distibuted transaction από τον application server στον database server - έσκαγε!

Εχε υπόψη σου ότι μέσα στο Support ΚΒ της Microsoft βγαίνουν κάποια Bulletins που μιλάνε για COM+ Refresh packages. Δεν τα δίνουν ελέυθερα, πρέπει να τα ζητήσεις.

Βέβαια μετά από το Windows XP SP2 και Windows Server 2003 SP1 τα component services έχουν αλλάξει πολύ. Η ασφάλεια έχει δυσκολέψει την κατάσταση, και δεν παίζει σχεδόν τίποτα από απομακρυσμένο μηχάνημα - ούτε το DTC, ούτε το COM+ γενικότερα και σίγουρα ούτε το Debugging. Δεν έχω τόσο "πρόσφατα ψυχολογικά τραύματα" για να σου πω...

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Λοιπόν,

συμφωνώ απόλυτα με τον gcapnias. Εν κατακλείδι:

- ΟΧΙ components στο com+ από δικτυακά drives. Εκτός να ψάχνεις για προβλήματα
- ΝΑΙ στο διαχωρισμό σε layers. Μπορεί να γίνετε το project management κάπως πιο σύνθετο αλλά τα κέρδη ισοσκελίζουν τις όποιες δυσκολίες.
- ΝΑΙ το κάθε component σε δικό του project. ΑΥΣΤΗΡΑ! Ετσι για να κάνω αλλαγές ανοίγω ένα και μόνο ένα project το οποίο περιέχει τον κώδικα από ένα και μόνο ένα component, ελαχιστοποιώντας τις πιθανές (και απίθανες ) παρενέργειες σε άλλα components.
- ΝΑΙ στο να υπάρχει ένα solution, και μάλιστα να είναι και στο source safe, το οποίο θα περιέχει όλα τα components κάθε layer. Αλλιώς μας περιμένει ο κίνδυνος να "ξεχαστεί" κάποιο component σε μελλοντικά builds, οπότε τρεχάτε να προφτάσουμε...
- ΝΑΙ στο να έχει κάθε developer το δικό του solution εκτός source safe. Δε χρειάζετε να φορτώνουν όλοι όλα! Δουλεύω με αυτά που χρειάζομαι ανά περίπτωση.
- ΝΑΙ στο να είναι ΟΛΑ τα references σε projects και όχι σε assemblies. Επίσης ΟΛΟΙ οι developers πρέπει να έχουν ΤΗ ΙΔΙΑ δομή directories από το root του working folder του source safe και κάτω.

Τώρα, αν κατάλαβα καλά από ότι γράφεις, το ότι έχεις το δικό σου solution εκτός source safe και να αλλάζεις τα references, δεν σε προστατεύει από το get lates version των άλλων λόγω του ότι τα references τηρούνται στο proj αρχείο, το οποίο ΕΙΝΑΙ στο source safe, οπότε με get latest θα το πάρουν και οι άλλοι.

Κατ'αρχήν να ευχαριστήσω όλους για τις διαφωτιστικές απαντήσεις που δόθηκαν. Ειναι πολύ χρήσιμο να γνωρίζεις τον τροπο με τον οποίο δουλεύουν οι συνάδελφοί σου σε παρόμοιες καταστάσεις.

Επειδή το πρώτο μου post ήταν λίγο "νευρικό", σκέφτομαι να συγκεκριμενοποιήσω λίγο τον τρόπο με τον οποίο εργάζομαι αυτή τη στιγμή για να δούμε αν λέμε τα ίδια πράγματα:

Στο sourcesafe λοιπόν υπάρχουν:
Ο κώδικας των components (καθε ένα στο δικό του project)
ΔΕΝ υπάρχουν compiled dlls
ΔΕΝ υπάρχουν solutions

Στο δικτυακό drive υπάρχουν:
Τα compiled dlls των components (το κάθε ξεχωριστό version σε δικό του subdir) - δεν αλλάζουμε version σε κάθε build, μόνο όταν αλλάξουν signatures - ουσιαστικά χρησιμοποιούμε 3-number versions εκ των οποίων αλλάζουμε συνήθως το μεσαίο. Παρακάμπτουμε την αλλαγή του τελευταίου αριθμού όταν μεταβληθεί το internal functionality για ευκολία.

Στα PC μας υπάρχουν:
Το project του tier στο οποίο δουλεύει ο καθένας μας.
Reference στο δικτυακό drive για τα υπόλοιπα components.
Τα υπόλοιπα components έχουν "κατέβει" τοπικά (ίδιες versions με αυτές που κάνουμε reference) και έχουν στηθεί στο τοπικό μηχανάκι. Το στήσιμο γίνεται από το τοπικό μηχανάκι στο τοπικό μηχανάκι και όχι από com+.
Δεν υπάρχει συμφωνία στα local directories που χρησιμοποιεί ο καθένας μας αλλά μόνο στο που κανουμε reference (στο δικτυακό drive). Ετσι οποιος και να κατεβάσει από sourcesafe έχει τα ίδια references.
Ολα τα references που αφορούν σε com+ είναι file references.
Δεν δουλεύουμε με stubs μια και κάνουμε debug ο καθενας στο μηχάνημά του.
Ολα τα μηχανάκια έχουν ίδιο λειτουργικό.

Θα ήθελα, στη μέχρι τώρα περιγραφή, να μου υποδείξετε, ο καθένας με την προσωπική του εμπειρία, που θα μπορούσα να βελτιώσω την κατάσταση, ή, τι πιθανόν να γίνεται λανθασμένα.

Αυτό μέχρι τώρα.
Ανέλαβα λοιπον πρόσφατα κάτι το οποίο απαιτούσε να δουλεψω προσωπικά σε πολλά tiers ταυτόχρονα. Ετσι, πήρα όλα τα com+ στο μηχανάκι μου (από το sourcesafe το source, compile & στήσιμο τοπικά), κράτησα τα references στο δικτυακό και επιχείρησα να δουλεψω.
Αυτό που έκανα για να επιταχύνω την κατάσταση κάθε φορά που έκανα build ήταν ένα batch το οποίο ξέστηνε/ξανάστηνε στο com+ τα πράγματα, έκανε register GAC με force install και αντέγραφε τα καινούρια components στο δικτυακό drive ωστε να παίζουν τα references και πάλι. Κατόπιν, σε όποιο project εργαζόμουν, χρησιμοποιούσα ένα macro για να κάνω refresh τα references (το οποίο δουλεύει πολύ καλά και δεν χρειαζόταν να κλείνω και να ξανανοίγω το studio).

[Απόπειρα 1]
Δυστυχώς όμως δεν μπορούσα να κάνω σωστά debug. Symbols δεν φορτώνονταν, γιατί όποτε έκανα attach to process (dllhost) κάποιο component και παταγα "play", προφανώς δεν συμφωνούσαν τα symbols που παράγονταν εκείνη την ώρα με αυτά που έκανα reference από το δικτυακό drive. (Δεν θυμάμαι, μπορεί και να μην αντέγραφα τα tlb αρχεία εκεί!!!). Ερώτηση λοιπον: Θεωρητικά, αν αντιγράφονται σωστά τα tlb αρχεία, έστω και αν παράγονται καινούρια την ώρα που πατάς το αναθεματισμένο "play", δεν πρέπει να φορτωθούν τα symbols από το δικτυακό drive? Αν η απάντηση είναι ναι, τότε είμαι κοντά στην αιτία του προβλήματός μου.

[Απόπειρα 2]
Ειπα λοιπον να αλλάξω τροπάρι και φτύνω τα references στο δικτυακό drive. Project references λοιπον με ενιαίο solution για τα πάντα. Configuration manager, ενα configuration για τα components, ένα για το application (winforms) που τα χρησιμοποιεί, ένα για τα nUnit tests (πρωτόγονα). Χτιζω, τρέχω το batch (χωρίς να κάνει πλέον copy στο δικτυακό), προσπαθώ να κάνω debug. Οκ μέχρι εδώ. Αλλα!!!! Κατι πάντα κλειδώνει κάτι άλλο και δεν μπορούν να γραφτούν όλα στο δίσκο όταν χτίζω....

[Απόπειρα 3]
Ξεχωριστά λοιπόν solutions με file references μεταξύ των components. Εδώ το απόλυτο χάος! Πότε symbols δεν φορτώνονται, πότε dlls δεν μπορούν να γραφτούν....όλα τοπικά, δεν υπάρχει δικτυακό drive

και ερωτώ:

Ποιά η πιό ασφαλής μέθοδος; Εγώ βλέπω οτι η μέθοδος των references σε δικτυακό drive (προσοχή, μόνο references, όχι στήσιμο των components από εκεί!) είναι πιό ασφαλής. Τι κάνετε εσείς; Η τεχνογνωσία σας σε αυτό είναι πολύτιμη.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap wrote:

Αυτό που έκανα για να επιταχύνω την κατάσταση κάθε φορά που έκανα build ήταν ένα batch το οποίο ξέστηνε/ξανάστηνε στο com+ τα πράγματα, έκανε register GAC με force install και αντέγραφε τα καινούρια components στο δικτυακό drive ωστε να παίζουν τα references και πάλι. Κατόπιν, σε όποιο project εργαζόμουν, χρησιμοποιούσα ένα macro για να κάνω refresh τα references (το οποίο δουλεύει πολύ καλά και δεν χρειαζόταν να κλείνω και να ξανανοίγω το studio).

Όταν αρχίζεις το test και debug, προυποθέτει ότι οι υπόλοιποι σταματάνε. Έχει παγώσει η παραγωγή και ότι άλλο.

Αν υποθέσω ότι μέσα στο project του κάθε component κάνεις reference το sign key και εξάγει από μονο του το COM interface και το .tlb, κάνεις local install, αλλά κάνεις reference το remote .tlb, που δεν έχει στον ίδιο κατάλογο το τελευταίο .pdb και μετά δεν μπορεί να φορτώσει τα debug σύμβολα και δεν κάνει αυτόματα attach στο proccess! Και όταν το κάνεις attach στο process με το χέρι, πάλι δεν φορτώνει σύμβολα... Λογικό δεν είναι; Αν δεν κάνεις reference το τοπικό .tlb που είναι στο ίδιο directory με το .dll και .pdb, που μόλις έχουν γίνει compile, πως θα δουλέψει το debugging;

Σε ποιο σημείο έχει ακριβώς πρόβλημα, όλα τα components να έχει referenced σαν projects, και να έχεις ένα solution, και όλα αυτά είναι τοπικά, για να κάνεις debug;

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Εχεις δίκιο σε αυτό που λες Γιώργο.

Από την άλλη μεριά, όταν κανω project references και έχω τα παντα σε ένα solution, θα πρέπει μετά όταν τα πάρουν οι άλλοι να βαζοβγάζουν references για να τα δούν. Αυτό λύνεται αν συμφωνήσουμε σε κοινό local storage path?

---

Σωτήρης Φιλιππίδης

DotSee Web Services

(Λαμπάκι ανάβει) Να συμπληρώσω και κάτι άλλο που θυμήθηκα τώρα μετά από κουβέντα με τους συναδέλφους:

Ειχαμε αποκλείσει παλιότερα τα project references. Ο λόγος; Οταν έχεις ένα solution με project references και θέλεις να κάνεις debug ναι μεν γίνεται, αλλά για ένα κάθε φορά από τα components σου. Αν θέλεις να κάνεις trace την κλήση μεταξύ πολλών layers, πρέπει να έχεις πολλά instances του VS ανοιχτά, κάθε φορά attached στο process που σε ενδιαφέρει το συγκεκριμένο component με το additional overhead οτι πρέπει να το βάλεις σαν startup project (αν θυμάμαι καλά).

Αρα, υπό αυτή την έννοια, είναι βολικότερα τα file references με διαφορετικά instances του VS ανοιχτά για κάθε component. Ας πουμε οτι θέλεις να παρακολουθήσεις μια κλήση από UI->business1->business2->business3->DAL ... και να δεις που πραγματικά έχεις πρόβλημα. Καηκες αν παίξεις με ενιαίο solution (και τωρα που το θυμάμαι και εγώ είχα καεί έτσι).

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Είναι αλήθεια αυτό που λες ότι δεν μπορείς να κάνεις cross layer και cross component debugging. Αλλά μήπως το UI->business1->business2->business3->DAL είναι ισοδύναμο του "ψάχνω βελόνα στα άχυρα"; Δεν είναι και το δυνατότερο σενάριο για debugging.

Έχεις Unit Testing, για ναν δεις το κάνουν πραγματικά τα components σου, μπορείς να ενεργοποιήσεις tracing μέσα από Framework για να δεις τι ανταλλάσουν μεταξύ τους, μπορείς να φτιάξεις perfomance counters για να έχεις μια runtime εικόνα της εφαρμογής τι κάνει, τόσα πράγματα για να μπορέσεις να απομονώσεις το σφάλμα και να το διορθώσεις.

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Παμε σε πιό θεωρητικό επίπεδο τώρα, αλλα ας το ακολουθήσουμε για λίγο: Εστω οτι έχω όλα αυτά τα εργαλεία. Σε ιδανικές συνθήκες ναι, unit testing, tracing κλπ αποτελούν αποδεκτές λύσεις. Ομως, εχεις και καταστάσεις οπου ξαφνικά ψωνίζεις 3-4 layers από το πουθενά, που ίσως και να μην τα έχεις φτιάξει εσύ, και θέλεις να δεις που παει η αναθεματισμένη η κλήση που γίνεται από το UI και δεν γράφει στη database αυτά που θα ήθελες να γράφει, υποψιαζόμενος π.χ. οτι κάπου "πνίγεται" κάποιο exception ή οτι κάτι δεν γίνεται σύμφωνα με τα αναμενόμενα requirements...αρα; Τι κάνεις; Φτιάχνεις εκείνη την ώρα τα unit tests σου; Η φτιάχνεις ολόκληρη την υποδομή που μέχρι τώρα μπορεί να μην υπάρχει για 1002 λόγους;

Θελεις μια γρήγορη (στο μέτρο του δυνατού) λύση.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Σοβαρά, αυτά που λες είναι υπαρκτές καταστάσεις και βασίζονται σε πραγματικά πρόσωπα! Παραπάνω από μία φορές ο καθένας μας, έχει έρθει σε τέτοια θέση και ξέρει τον πόνο.

Δεν μπορώ να σου δώσω μια υποθετική απάντηση, σε αυτό το υποθετικό ερώτημα. Πιστεύω ότι κάνεις ότι κάνουν όλοι: Επικαλείσαι τους Αγίους για να μπορέσεις να βρεις μια λύση ή την επιφοίτηση του Αγίου Πνεύματος να σε φωτίσει που είναι το σφάλμα!

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias