Alegerea unei tehnologii care supraviețuiește autorului ei

Alegerea tehnologică pentru o aplicație de business este o decizie de mentenanță deghizată în decizie tehnică. Codul va fi scris o dată și întreținut un deceniu.

Criteriile care prezic cu adevărat costul

Puteți angaja pentru ea? Căutați pe piața locală și pe cea remote. Dacă o tehnologie întoarce o mână de candidați, orice schimbare viitoare depinde de găsirea unuia dintre ei.

Este plictisitoare? Plictisitoare înseamnă bine înțeleasă, larg răspândită, temeinic documentată, cu moduri de eșec cunoscute. Plictisitoare este un compliment.

Cine o întreține? O fundație sau o companie mare cu politică de suport este cu totul altceva decât un entuziast. Verificați istoricul versiunilor și dacă patch-urile de securitate apar prompt.

Care este fereastra de suport? Orice framework are o dată de sfârșit de viață pe versiune. Acea dată este momentul în care actualizarea devine obligatorie și ar trebui să fie în plan înainte de a începe.

Cât de mare este arborele de dependențe? Fiecare pachet este ceva de actualizat și ceva ce ar putea aduce o vulnerabilitate. Mai puține dependențe, mai bine alese, îmbătrânesc mult mai frumos.

Capcana alegerii interesante

Framework-urile noi sunt cu adevărat plăcute și adesea superioare tehnic. Sunt și locul unde o tehnologie ajunge să fie abandonată. Un instrument cu o comunitate mică și un singur întreținător poate fi excelent azi și neîntreținut peste trei ani, moment în care aplicația funcțională devine o rescriere.

Pentru software intern de business, alegeți opțiunea cu cea mai mare comunitate care satisface cerința. Păstrați noutatea pentru lucrurile pe care vă permiteți să le aruncați.

Alegeri implicite rezonabile

• Un limbaj mainstream cu versiuni de suport pe termen lung
• Un framework aflat în uz comercial larg, nu doar în discuție largă
• O bază de date relațională, dacă nu aveți un motiv anume pentru altceva
• O punere în producție pe care un inginer competent o poate înțelege doar din documentație
• Cât mai puține piese în mișcare, atâtea câte cere efectiv problema

Scrieți decizia

O pagină: ce s-a ales, ce s-a respins și de ce. Când peste patru ani cineva întreabă de ce sistemul este construit așa, acea pagină previne o rescriere scumpă argumentată din necunoaștere.

Luăm aceste decizii deliberat în proiectele de dezvoltare software.