rewrite vs proiect nou

Nu-i vorba de asta.Clientul este un client strain, europa de vest, iar maintenerii erau la fel de la o firma din europa de vest.
Clientul  a dorit scaderea costurilor in contextul acelarasi venituri, ceea ce implica cresterea profitului, (sfatuit de o firma de audit tehnologic)  ne-a contractat pe noi sa facem , filiala de europa de est a unei corporatii  transatlantice.

Noi finalizam transferul tehnologic, dupa care comercialul va decide daca tot noi vom face mentenanta sau vom preda stefeta alte companii care va intretine noua aplicatie, in functie de cum se inteleg
astia la bani.Predarea stafetei inseamna predarea codului sursa, documentatiei tehnice aferente, probleme cunoscute dar care nu afecteaza business-logicul,  scripturile  de mentenanta si populare a bazelor de date, manual de utilizare pentru end-user.

Quote

Pentru o corporatie a fi bun inseamna  in primul rand a fi eftin si a rezolva problemele pentru care altii cer mai multi bani.Dar cauza principala  de alegere este pretul mic.
Pentru ca apoi un astfel de tanar se poate perfectiona la locul de munca prin proiecte mult mai mici si apoi i se da pe mana mentenanta unei portiuni a unei astfel de aplicatii.

Era in care programatorul era o comodiate rara incepe sa apuna, si asta am observat-o acum cand am vazut cum a patruns automatizarea taskurilor software.
Pentru un project manager nu conteaza daca esti bun, conteaza in primul rand sa fii eftin, si asta se aplica mai ales la noi in Romania, Bulgaria, Ucraina, Serbia, dar si in India, Africa de Sud, Singapore.

Deci ca sa-ti raspund la intrebare pe scurt: In toata lumea corporate asa se procedeaza si apoi se aplica legea junglei: cine se adapteaza supravietuieste, cine nu, trage pe dreapta,
cine cauta confort si zona de siguranta nu prea mai gaseste acest lucru in acest domeniu, in zona corporate.In alte zone poate, nu cunosc.

Edited by Iulius-Foyas, 18 August 2019 - 17:31.

Poate in corporatia unde lucrezi tu.
Nu toate corporatiile au aceeasi vizune.

Nici o corporatie in care sa merite sa lucrezi nu are o asemenea viziune. Se pare ca el nu cunoaste decat firme de sclaveti, in care nimeni nu invata nimic ci doar da la sapa.

Eu stiu ca pt o corporatie toata lumea este piesa de schimb, in afara de patron si actionari, probabil tu nu ai tangente cu lumea corporate.
Iar denumirea de "Resurse umane" imi da dreptate doarece o resursa nu este un om, o resursa este o comoditate care poate fii inlocuita cu alta comoditate.
Pam, pam.

Edited by Iulius-Foyas, 18 August 2019 - 21:46.

Schimba corporatia, extindeti orizontul.

Iulius-Foyas, on 14 august 2019 - 12:24, said:

Da, si e motivul pentru care, de exemplu, as prefera ca developerii sa scrie cod cat mai simplu, care sa nu foloseasca features avansate, greu de inteles sau atipice. De exemplu: OOP cat mai simplu, de inteles de catre developerul cu 2-4 ani experienta (dar nu e intotdeauna posibil). Recrearea de la zero nu cred ca e fezabila in multe cazuri, din motive destul de evidente (resurse) si poate veni cu alte probleme, noi (se stie). Uneori problemele nu sunt observate imediat.

Mai degeaba se creeaza un wrapper, APIuri etc si se scriu module noi. Totusi exista apicatii vechi scrise in COBOL sau M/MUMPS, care sunt rescrise complet in java sau chiar .NET. Dar sunt firme care se ocupa cu asa ceva.

Deci probabil ca de la caz la caz, dar mai degeaba nu, si daca da, trebuie asigurat un plan B, trebuie inteles ca poate esua proiectul, trebuie ales momentul migrarii. Sunt proiecte care functioneaza de 40-50 de ani. In limbajele folosite pt sisteme critice (de exemplu Ada), apar suficient de rar features noi, chiar daca e mai putin flexibil, expresiv, poate chiar mai batranicios.

Edited by aaaa4567, 19 August 2019 - 02:18.

MarianG, on 19 august 2019 - 01:00, said:

chestia asta suna in genul  "fii omul nou, tu poti schimba universul, yeah right".

TS030, on 18 august 2019 - 16:14, said:

In toata lumea se practica. Nu in toata, dar in multe locuri.

Spre exemplu, peste tot exista presiunea pietei pentru produse ieftine. Programatorii de COBOL /etc sunt scumpi si greu de gasit si se prospecteaza ca nu se va rezolva problema. La produse si servicii altadata cu pretentii, de nisa, si tot vei vedea asa ceva. de exemplu, companii fintech noi. Daca tu nu faci scaderea costurilor, o va face concurenta. Aceeasi driving force ca si la Boeing, aceeasi asumare de riscuri calculata etc etc. Nu toti oamenii sunt conservatori, tinerii sunt mari consumatori de tehnologie, si risti sa devii outdated:

https://bigthink.com...airs/ibm-ageism

Edited by aaaa4567, 19 August 2019 - 02:38.

Aha, deci muncesc pe bani de semințe si scot produse ieftine, dar proaste.

In cazul de fata, la proiectul de fata te asigur ca  nimeni nu munceste  pe bani de seminte iar produsele scoase sunt la fel de bune sau chiar mai bune decat cel intial, altfel clientul nu facea transferul tehnologic.De altfel s-au remediat buguri de business logic gasite in proiectul intial, iar logica convoluta din proiectul intial (care il face sa fie greu mentenanbil si aia
care sa faca mentenanta sa ceara bani seriosi) a fost inlocuita cu o logica mai clara, mult mai simpla si mult mai eficienta calibrata  corect pe tehnologiile  java enterprise.

aaaa4567, on 19 august 2019 - 02:29, said:

Asa este, marii jucatori de pe piata software au aceasta practica pe care o aplica des.

Edited by Iulius-Foyas, 19 August 2019 - 03:23.

Vorbesti mult fara sa spui nimic concret. Iar viziunea ta se rezuma la corporatia de sclaveti care-si baga fatis picioarele in programatori si-n legislatie. Nu e deloc greu sa gasesti un mediu de lucru nu neaparat ideal dar net superior a ceea ce descrii...

Ce inseamna "transfer tehnologic"? Reimplementarea unei aplicatii intr-un alt limbaj? De ce i-ai spune "transfer tehnologic", caci nu transferi nici o tehnologie?
A reimplementa o aplicatie complexa doar pentru ca programatorii-s mai ieftini mi se pare o aberatie crunta. Nimeni nu face asta doar de dragul de-a lucra in Java. Deci, despre ce situatii vorbim?

Referitor la al doilea subiect, cu ce te-ajuta daca dai afara tocmai oamenii familiarizati cu produsul pe care vrei sa-l reimplementezi?

Eu nu înțeleg de ce îi dai zor cu "transfer tehnologic".


De ce nu îl numești ceea ce este: rewrite.

Îl faci să sune mai popos de cât este, când ceea ce este de fapt e repararea deciziilor trecute.

Poate nu stie?

Pentru tehnologiile vechi se găsesc greu programatori să le întrețină. Apoi se adaugă cunoștințele despre proiect/software - de obicei echipa inițială nu mai e și în timp zone din proiect se transformă în black-boxes. În cazul fericit mai găsești specificații dar probabil neactualizate. Probabil nici taskurile în Bugzilla/Jira/whatever nu le mai găsești pe toate că s-a migrat de la A la B la C, idem și cu source control-ul.
De procesul de build nu mai zic - cel puțin pe .NET fug developerii de linia de comandă și de scripturi ca naiba. Preferă să înjure că-i rigid decât să investească timp să-l înțeleagă și să-l flexibilizeze.

Dacă ar fi să se rescrie de la 0, ca să fie 'industry standard' ar trebui refăcute specificațiile apoi implementarea - mult timp, mulți bani (și un project owner capabil nu wanna-be). Practic se reduce la "vezi în cod și fă la fel pe tehnologia nouă". Așa am făcut parte de web la un proiect desktop de 10 ani, asa s-a migrat un proiect maaare și vechi de pe VB6 pe VB.NET.

Ca paranteză, mi se pare extraordinar să ai un epic de refactoring pe proiect și să poți trage din el taskuri în fiecare sprint. Fără să se sperie biznisu' sau managerii din firma de outsourcing. E doar o chestie realistă și transparentă pentru toată lumea (și satisfăcătoare pentru developeri).

Btw - https://blog.almaer....er-of-the-json/

Btw2: Când asiguri și suport tehnic, nu vrei să-ți pierzi oamenii cu knowledge tehnic de pe proiect.

Edited by shiva, 20 August 2019 - 09:44.

OriginalCopy, on 19 august 2019 - 19:23, said:

Pt ca este transfer tehnologic.
Vezi tu este o diferenta de la cer la pamant intre a stii limbajul java si a cunoaste si stapani  tehnologiile java enterprise care sunt implementate prin limbajul java insa dpdv al  subiectelor pe care
le trateaza sunt agnostice limbajului java.
Daca cineva stie limbajul java asta nu-l face angajabil nicidecum. Ceea ce se cauta pe piata java sunt cunoasterea si stapanirea tehnologiilor enterprise, respectiv  a celor doua framewokuri concurentiale: EJB framework si spring framework.
EJB este mandatory pentru proiectele vechi pe java enterprise(mai mult acolo se regaseste acest framework)  dar si cele noi, insa spring framework sunt pentru proiectele noi

Ce se intampla la un transfer tehnologic pentru un sector al aplicatiei: pai se studiaza care subtehnologie java enterprise este cea mai potrivita pt implementarea business-logicului pt acel sector.
Apoi se modifica parametrii tehnologici ai subtehnologiei enterprise folosindu-ne de catre disciplina OOAD,  astfel incat aceasta sa deserveasca business-logicul din acel sector.
Apoi se foloseste OOP-ul pentru a implementa in java modelul OOAD al subtehnologiei enterprise calibrata insa pt business-logicul din sectorul respectiv.

Asa rezulta transferul tehnologic.Java enterprise nu este java iar cine lucreaza cu java enterprise este inginer de software (si nu programator obisnuit).
Daca in cazul C++, cunostii limbajul si totul le faci in acel limbaj folosind API-uri si este suficient, ei bine in java lucrurile sunt cu totul diferite. De aceea multi care cred ca stiu java iti iau tzeapa pt
ca java nu este java enterprise.Si efectiv nimeni nu da doi bani daca cineva stie java.Banul este un tehnologiile enterprise bazate pe java si nu pe limbaj in sine.

Quote

Pt ca nu este rewrite.Rewrite-ul este de fapt rescrierea unui program dintr-un limbaj fie in acel limbaj fie in limbaj diferit,pastrand insa acelasi mod de abordare, acelasi greseli si acelasi buguri

Transferul tehnologic inseamna transferul business-logicului dintr-un limbaj intr-un sistem software de tehnologii, pastrand acelasi business-logic insa cu posibilitati de extindere facila a acestuia,
fixarea bugurilor, fixarea greselilor privind modul de abordarea in rezolvarea diferite subetape, schimbare de arhitectura software.
In esenta prin transfer tehnologic se porteaza business logicul insa modul de implementare este substantial diferit.

Si apoi chiar daca ai face un rewrite, in momentul in care ai ales sa-l faci ti-ai asumat raspundarea pt vechile buguri ca fiind ale tale si nu le-ai remediat si raspunzi pt efectele acelor buguri pt care nu te le-ai facut originar , insa ai preluat raspunderea.

Quote

Mercedes construieste masini.
Bmw construieste masini.
Care de la care repara deciziile trecute ?  Intelegi cum pui problema ? Bine.

Sa recapitulam:

• pt rewrite: ordinary programmer
  
• pt transfer tehnologic: senior software enterprise engineer.

Cele doua joburi sunt absolut diferite.
Iti las aici si o discutie ca sa ai ceva asupra caruia sa reflectezi: https://www.quora.co...kes-them-better
La revedere.

Quote

Adica ?

Edited by Iulius-Foyas, 20 August 2019 - 18:30.

Quote

Va permite disciplina sa pastrati greselile si bug-urile ?

Noi facem transferuri tehnlogice si nu "re-writer"-uri. De aceea codul nostru deontologic nu ne permite sa pastram greseli sau buguri.
Altii insa prin re-writeruri fac chiar asta.Rewrite si nimic mai mult.

Dar un rewrite in sens tehnic inseamna strict portarea codului as it is in alt limbaj si nimic mai mult si asta pt ca un rewrite nu implic deloc refactorizare nici la nivel de business-logic
dar nici la nivel de implementare software.

Edited by Iulius-Foyas, 20 August 2019 - 19:49.

N-are nicio noimă ce zici.


Când faci un rewrite, nu îl faci de dragul de a tasta cod, ci pentru a elimina neajunsuri.

Adică fix definiția ta a acestui "transfer tehnologic". Folosești termeni doar pentru a îi impresiona pe cei slabi de înger.