Limbaje noi la serviciu

Ați încercat să introduceți limbaje de programare acolo unde lucrați? Adică dacă lucrați întru-un shop unde se folosește exclusiv .net, java ori php.

Eu am introdus cu succes python și am eșuat cu ruby. Acum lucrez la a introduce go.

Eu mai bat campii de .net. Oricum main language va fi java. Personal cred ca cea mai buna idee este sa incerci proiecte micute si sa vezi cum te descurci. Vezi si pt ce s-ar preta limbajul mai bine. Este destul de usor sa faci un GUI in Windows cu C# de exemplu

Eu mai lucrez la un mic proiect in Go (la munca).

Eu sunt main C#, JavaScript, si am incercat sa modific niste scripturi in Python uneori cu succes alteori fara.

Nu cred ca e asa usor sa introduci limbaje noi in mediile enterprise sunt destul de conservatori, dar de ce nu tehnologia evolueaza, dar e nevoie de timp sa fie acceptate, de exemplu vechile proiecte sunt cu .net framework, noile cu .net core, ideea e cand ai scris un sistem sa zicem in 10 ani e greu sa migrezi, de obicei migrarea se face cand numai exista suport de la compania creatoare pentru tehnologia respectiva.

Edit: am uitat sa zic am folosit si Node.js pentru QA Automation.

2 Likes

introducerea de limbaje noi doar de dragul de a folosi ceva nou/ treandy este o greselea si va aduce multa durere mai tarziu

7 Likes

Well, nu cred ca este chiar o greseala pentru ca astfel nu ar mai exista progres. Totusi sunt de acord ca introducerea de limbaje noi trebuie facuta cu precautie si progresiv. Eu am cam reusit cu limbajul Go pe unde am fost.

2 Likes

Sunte de acord cu introducerea de limbaje noi atat timp cat usecase-ul este unul bun. dar asa cum am spus daca se introduc pentru ca e un limbaj “cool” sau “la moda” atunci este o problema.
Ca si exemplu acum cativa ani era la moda Ruby in special cu Rails. Acum nu se mai prea aude nimic de el. Daca atunci portai o parte a aplicatiei in Ruby acum o sa ai o problema la mentenanta.

1 Like

Da, am reusit sa introduc testarea automata cu TypeScript (WebDriverIO) la o corporatie cu toti QA-ii cu experienta pe Java/.Net. (aplicatia este scrisa in TS/JS si cu automatizarea terminata la fiecare story in definition of done, fiecare componenta a aplicatiei este in 3-3 iframe-uri si UI-ul e rerandat de backend)

Use case-ul a fost bun fiindca toata echipa a lucrat la automatizare in vreo 5 sprint-uri, adica cineva de pe frontend poate scrie foarte usor automatizare cu TypeScript. (plus m-a ajutat foarte mult faptul ca am putut apela la colegii cu experienta pentru a rezolva problemele complexe de logica, nu era nici un bottleneck cu setup-ul si sintaxa la java si toate cele, degeaba ma ajuta alt QA daca problema mea era cu logica, API-ul si flow-ul din aplicatie, plus ca a devenit mult mai usor de inteles cat de dificil poate fi automatizarea unui anumit feature la estimare)

1 Like

Corect, limbajele noi trebuie alese doar daca sunt mai bune/simple decat cele vechi pe domeniul respectiv. Exemplu: PHP a fost mai simplu de invatat decat Perl si astfel s-a impus. Insa iata mai jos un exemplu esuat de schimbare limbaj doar ca era “la moda”.

2 Likes

nu limbaj ci framework React. a fst un success primul proiect, maricel de altfel, iar acum folosim doar React la ce e mai mare

1 Like

Poate nu are sens, introducerea unei tehnologii noi vine cu costuri foarte mari care trebuiesc justificate. Daca vorbim de un produs matur sau cat de cat mare aproape niciodata nu se justifica rescriere produsului, poate pentru sisteme eterogene de servicii/microservicii in care poti beneficia de anumite plusuri aduse de un limbaj/tehnologie noua, sa zicem ca poate are sens, dar costul de training, de a tine oameni care stiu 2 sau mai multe limbaje+tot tech stack-ul lor e f mare.

Uite un alt punct de vedere: Vine concurenta si iti rescrie toata platforma intr-o tehnologie noua cu oameni care lucreaza mult mai rapid, cu componente reutilizabile peste tot si cu posibilitatea sa introduca aproape orice inovatie ce tine de schimbari de UI intr-un timp foarte scurt. Cu foarte mult suport disponibil pe internet gratuit.

Pe cand tu cu stack-ul deja existent ai ramas blocat, ai un produs matur, dar vine concurenta si te scoate de pe piata deoarece nu poti implementa de exemplu rerandarea UI-ului in timp real sau nu poti pune peste ce ai colaborare intre mai multe persoane. Chiar daca e posibil va trebuie sa apelezi la documentatie arhaica, la consultanti care lucreaza contra cost, la solutii foarte urate cu multe adaptoare, fatade in cod.

Este un punct valid de vedere, dar rescrierea unui produs este una dintre cele mai mari greseli posibile in software, o sa ai 2 echipe, una care rescrie si incearca sa ajunga la paritate de functionalitate si echipa care inca se ocupa de code-base-ul vechi si care nu sta pe loc si tot baga functionalitate in sistemul vechi. Este foarte scump ce zici tu acolo, de 2 ori am vazut scenariul asta si nu-l recomand nimanui daca nu are resursele necesare.

4 Likes

Depinde si daca produsul a evoluat din MVP sau a fost dezvoltat direct pentru productie si mentenanta. Daca a fost dintr-un MVP rescrierea unui produs este probabil extrem de importanta pentru mentenanta si dezvoltare in viitor.

Daca e un produs matur, atunci aducerea unei interfete noi la paritate cu interfata cea veche ar trebui sa ia foarte putin timp fiindca poate exista ceva documentatie, teste si experienta in spate.

Eu sunt curios câte produse mature ai rescris, câtă documentație ai găsit și câte teste erau la proiect.

1 Like

Din experienta iti spun ca nu merge asa. Daca traiam intr-o lume utopica da dar de obicei ai un monolit din care multa informatie este pierduta/ nedocumentata si orice schimbare este greoaie si lenta.