Mai întâi aici sunt cele 2 reguli ale mele pentru a evita sindromul cadru al deșeurilor:

• Absența unuia existent, care acoperă 80% din nevoile mele și extensibil pentru a se potrivi cu ultimele 20%
• Aproape certitudine că o voi folosi din nou, într-o altă aplicație

După ce le-ați trecut, verificați acest lucru:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Comentarii

• Aș adăuga că, dacă nu puteți ‘ găsi un cadru care îndeplinește regula dvs. 80/20, fie că lucrați într-un domeniu extrem de unic SAU ‘ nu vă înțelegeți domeniul suficient de bine.

1) Caracteristicile trebuie adăugate într-un Framework numai atunci când sunt extrase din codul de lucru. Cu alte cuvinte, înainte de a adăuga noua idee interesantă la noul dvs. cadru, asigurați-vă că aceasta adaugă valoare și reduce repetarea într-o aplicație de lucru reală.

2) Documentare, documentare, documentare.

3) Documentare, documentare, documentare.

Experiență dureroasă și mult efort irosit conduceți la acest sfat: extrageți sau refactorizați un cadru din software-ul de lucru. Creați acel software ținând cont de faptul că credeți că veți dori să extrageți un cadru în viitor, dar nu „construiți mai întâi cadrul.

1) Respectați convențiile bune chiar de la început, asigurați-vă că ați documentat o convenție foarte specifică, cele mai bune cadre sunt cele care sunt consistente la nivel intern.

2) Asigurați-vă că totul este foarte documentat, de la bun comentarii de cod până la explicarea a ceea ce necesită și produc cele mai importante funcții, chiar dacă vi se pare foarte simplu, s-ar putea să îl folosiți pe cineva în a 14-a oră consecutivă și doar au nevoie de acel lucru chiar atunci.

3) Stabiliți un rezumat al proiectului pentru dvs., cu ceea ce doriți să realizeze cadrul, obiective realiste și priorități generale.

4) Dacă va fi disponibil pentru utilizare, asigurați-vă că aveți o formă de urmărire a procesului de asistență / erori. Vor exista bug-uri, ni se întâmplă tuturor, dar dacă le poți gestiona de pe off, îți va ușura viața.

Una peste alta, o abordare similară cu construirea oricărei aplicații, dar dezvoltatorii sunt chiar mai agitați decât utilizatorii, iar cele mai bune cadre sunt cele pe care le putem prelua, înțelege și nu trebuie să ne luptăm.

Nu sunt de acord cu multe dintre cele spuse și consider că mai multe nu au fost menționate, așa că voi începe de la zero.

Metodologii Agile

Adoptați metodologii agile în timpul dezvoltării cadrului, astfel încât să vă puteți adapta la schimbare, să reacționați rapid la blocaje și să vă asigurați un produs final funcțional și de calitate. Metodologiile Agile sunt acelea care, conform „Manifestului Agile”, prioritizează:

Persoane și interacțiuni peste procese și instrumente
Software de lucru over documentație cuprinzătoare
Colaborarea clienților over negocierea contractului
Răspunsul la schimbarea over în urma unui plan

Așa este. Am spus că funcționalitatea este mai importantă decât documentarea. Rețineți că „Manifestul agil” menționează că prioritățile din partea dreaptă sunt încă importante, cu atât mai puțin decât cele din stânga.

Comunicare

Oricine realizează cadrul trebuie să știe:

1. Cum va fi utilizat: aplicație țintă
2. Ce problemă intenționează să rezolve: problema țintă
3. Cine îl va folosi: public țintă

De exemplu, dacă o companie intenționează să dezvolte o aplicație finală cu ASP .NET ar fi o prostie să spună programatorilor săi „să facă acest cadru” fără să le spună cele de mai sus. Dacă programatorii nu știau aplicația țintă, s-ar putea să nu o facă orientată pe web. Dacă nu știau problema, ar putea crea un cadru pentru un scop diferit. Dacă nu ar cunoaște publicul, ar putea programa cadrul în C ++. Oricare dintre aceste circumstanțe ar face inutil cadrul rezultat.

Stil

Inutil să spun, stabiliți un stil de programare / format și rămâneți cu el.

E „s

1. Modularitate : Reutilizați codul programatic, nu literal.
2. Eficiență : Codul dvs. este destinat reutilizării . Eventualele deficiențe pentru viteză se înmulțesc.
3. Mentenabilitate : doriți să puteți edita cadrul în actualizați mai multe programe, fără a fi nevoie să modificați programele menționate.
4. Utilizare : Aplicațiile pot folosi efectiv cadrul dvs. fără a sări prin cercuri?
5. Practicitate : Nu reinventați roata dacă nu aveți pentru a face acest lucru. Cadrul dvs. poate depinde de alte cadre.
6. Redundanță : Prindeți excepții / erori. Pretutindeni. Manipulați-le. Pretutindeni. Nu aveți niciodată încredere în niciun cod, dar în domeniul local pentru a gestiona erorile, chiar dacă știți că da.

Comentarii

• Bine ați venit la P.SE! Nu ‘ nu sunt de acord cu w / # 6 pentru a prinde excepții în cadrul dvs. Eu ‘ sunt un mare credincios în faptul că cadrul ar trebui să fie un tâmpit absolut și să arunce excepții și să lase la latitudinea programatorului care folosește cadrul să le prindă sau (mai bine) să reorienteze codul lor, astfel încât pentru a evita excepția – încurajarea conformității convenției.

Sunt „sigur că există o diferență între dezvoltarea unui cadru sau bibliotecă și a unei aplicații.

Procesele de dezvoltare sunt în esență aceleași. diferențele se pot reduce la problemele de marketing și implementare, deși consider că cele mai mari diferențe sunt de obicei în ceea ce privește sfera și definiția proiectului. Amintiți-vă că o aplicație poate include sau utiliza un cadru sau o bibliotecă, un cadru poate fi o colecție de biblioteci.

Am unele îndoieli cu privire la modul de gestionare a organizării și gestionării proiectului respectiv: Există câteva reguli generale de fo low, sfaturi, cele mai bune practici sau ceva de reținut pentru dezvoltarea acestui tip de proiect?

Organizarea și gestionarea proiectului sunt din nou aceleași pentru orice proiect de dezvoltare . Din nou, se reduce la scop. Cu toate acestea, atunci când vine vorba de scrierea unui cadru, merită să aveți o viziune foarte clară despre ceea ce încercați să realizați și să plasați reguli stricte de proiectare pe interfața publică a cadrului pentru a asigura coerența în ceea ce privește API-ul prezentare. Dacă permiteți fiecărui dezvoltator să-și facă propriile lucruri, veți ajunge la o mizerie complicată și un design API foarte elegant.

Îl voi alătura pe Ryan Hayes „ recomandare pentru a citi Liniile directoare de proiectare cadru chiar dacă cartea în sine are ca scop dezvoltarea cadrelor bazate pe .NET, deoarece sfaturile generale sunt aplicabile indiferent de tehnologiile specifice de implementare pe care ați alege să le utilizați.

Din experiență, aș sfătui să rămâneți la principiul clasic YAGNI prin implementarea mai întâi a celor mai simpliste interfețe publice și apoi extinderea pentru a oferi un control și o adâncime mai mari ulterior, dar aveți grijă să folosiți nume utile pentru a arăta de ce metodele sau clasele sunt extinse. Nu am fost niciodată un fan al adăugării „Ex” sau a altor sufixe similare la numele metodelor sau la adăugarea de numere la definițiile extinse ale interfeței. Diferențați funcționalitatea, iar numele interfeței / metodei dvs. ar trebui să devină mai clare și, sperăm, mai puțin ofuscate și confuze.