ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 131
Abonament PDF

Over-Engineering: Cost, Cauze, Soluții

Ioan Șut
Engineering Manager @ CodeCrafters by BT



MANAGEMENT


Termenul "over-engineering" este utilizat frecvent pentru a desemna procesul de a complica inutil un sistem sau un produs. Acest lucru se poate întâmpla din mai multe motive, inclusiv din incapacitatea de a înțelege corect o problemă, dorința de a-i impresiona pe ceilalți cu complexitatea răspunsului nostru sau credința că este calea "corectă" de acțiune. În acest articol, vom analiza atât cauzele acestui fenomen, cât și modalități de a-l evita pe cât posibil în munca noastră zilnică.

În sectorul software, putem defini procesul de over-engineering drept procesul de a crea software care este mai complex, mai bogat funcțional sau mai robust decât este necesar. A crea aplicații versatile sau cu multe funcționalități poate părea o idee bună, dar a face acest lucru poate fi problematic, deoarece poate duce la cheltuieli suplimentare, mai puțină productivitate și multe alte probleme. Mai departe, vom analiza cauzele și modurile de prevenire a efectelor acestui proces.

Care sunt cauzele practicilor de over-engineering?

Sunt multe motive care duc la over-engineering, dar mă voi referi la cele cu care m-am confruntat în carierea mea de programator și arhitect software.

Specificații neclare sau schimbate frecvente

Specificațiile pot fi neclare și se pot schimba în timp. Poate fi foarte greu să determini câtă complexitate sau câte funcționalități sunt necesare într-un proiect software, dacă specificațiile se schimbă frecvent în procesul de dezvoltare. Prin urmare, programatorii pot fi presați să adere la practici over-engineer pentru a face proiectul cât mai flexibil cu putință.

Lipsa de aplecare spre simplitate

Sunt cazuri în care nu suntem obișnuiți să lucrăm simplu. Pentru a economisi timp și bani, dar și pentru a menține și modifica aplicația ușor, trebuie să ne reîntoarcem la fundamente, la lucrurile de bază, la lucrurile simple. În ciuda acestei realități, dacă programatorii nu fac din simplitate o prioritate, ei ar putea să introducă funcționalități suplimentare și să facă sistemul mai complex decât este necesar.

Motivații nealiniate

Uneori, motivațiile diferite ale celor ce fac implementarea pot duce la over-engineering. Programatorii ar putea fi motivați să adauge mai multe funcționalități sau mai multă complexitate în produs dacă salariul lor depinde de volumul de cod pe care îl scriu. În mod similar, un furnizor software ar putea promova practici over-engineer pentru a obține contracte în care sunt prevăzute compensații, recompense pentru producerea de software ce are funcționalități adiționale.

Probleme de comunicare

Comunicarea deficitară poate duce și ea la over-engineering. Poate fi o provocare să detectăm și să reducem complexitatea dacă programatorii nu înțeleg specificațiile sau obiectivele proiectului sau dacă nu comunică suficient cu alți membri ai echipei.

Lipsa experienței

Lipsa experienței sau incapacitatea noastră de a înțelege o problemă pot contribui ocazional la over-engineering. Programatorii riscă să creeze programe ultra-complicate sau supra-dimensionate ca funcționalități dacă nu înțeleg problema pe care încearcă să o rezolve sau dacă nu sunt familiari cu bunele practici de rezolvare a acesteia.

Cum putem evita acest lucru?

În primul rând, trebuie să acceptăm faptul că suntem atrași de over-engineering, pur și simplu deoarece mintea noastră caută mereu să facă lucruri noi și interesante. Din proprie experiență, se pot aplica următoarele măsuri pentru a evita aceste practici:

Definirea specificațiilor cu claritate

Definirea clară a specificațiilor software este primul pas preventiv. Trebuie să acoperim toate capabilitățile necesare, aspectele de performanță, precum și alte restricții și limitări ce se aplică. Având specificații clare, ne putem asigura că doar funcționalitățile necesare sunt incluse în produs, respectând un nivel proporțional de complexitate.

Folosirea metodologiilor Agile

Metodologiile Agile presupun scrierea de cod și teste în iterații incrementale. Datorită concentrării pe dezvoltarea și testarea funcționalităților cruciale, va fi mai simplu să detectăm și să înlăturăm complexitatea inutilă. Mai mult, modificând sistemul gradual, în loc de a restructura complet tot sistemul, este mai simplu să abordăm modificările care apar în specificații.

Evitarea optimizările premature

Tentația de a optimiza codul și algoritmii prea devreme în procesul de dezvoltare reprezintă încă un factor ce duce la over-engineering. Deși trebuie luate în considerare performanța și scalabilitatea, este mult mai eficient, din punctul de vedere al costurilor, să ne concentrăm pe funcționarea corectă a funcțiilor de bază, în faza inițială. Ulterior, se pot face optimizări în funcție de necesități. Optimizările premature pot duce la un cod inutil de complex ce poate fi o pierdere de timp și resurse.

Simplificarea

Principiul "KISS" (Keep It Simple, Stupid) este o strategie menționată de foarte mulți specialiști ca fiind eficientă în evitarea practicilor de over-engineering. În loc să introducem funcționalități suplimentare sau complexitate, trebuie să avem în vedere crearea celei mai simple, directe soluții ce satisface specificațiile. Vom economisi timp și bani păstrând lucrurile simple, ceea ce ne va permite să avem un soft ușor de modificat și menținut.

Testare și adaptare

Pentru a minimiza practicile de over-engineering, este esențial să testăm aplicațiile software cât mai frecvent și să facem modificările necesare reieșite în urma rulării testelor. Putem identifica zonele unde s-a făcut over-engineering și să facem îmbunătățiri, creând prototipuri și testându-le în cadrul unor scenarii reale. Aplicațiile software vor fi eficiente atât din punct de vedere tehnic, cât și economic, dacă testam și adaptam codul devreme și frecvent.

Concluzii

Practicile de over-engineering sunt o problemă din care rezultă consecințe precum costuri mărite, productivitate redusă și nu numai. Evitând aceste practici în dezvoltarea software, putem crea software mai eficient, mai economic, ce satisface standardele de performanță solicitate.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects