Minun on aloitettava uuden kehyksen suunnittelu ja kehittäminen vuorovaikutuksessa avoimen lähdekoodin ECM: n kanssa. Tämä sisältää mukautetun tietomallin, joka auttaa verkkosivustojen kehittäjiä vuorovaikutuksessa tämän ECM: n kanssa, joten heidän ei tarvitse huolehtia solmujen manipuloinnin yksityiskohdista ja muista matalan tason yksityiskohdista. Se on vain joukko luokkia ja menetelmiä kehitettäväksi.
Minulla on epäilyksiä siitä, miten käsitellä projektin organisaatiota ja hallintaa: Onko olemassa joitain yleisiä sääntöjä, joita noudattaa, vinkkejä, parhaita käytäntöjä tai jotain, joka on pidettävä mielessä tällaisen projektin kehittämisessä?
Olen varma, että kehyksen, kirjaston ja sovelluksen kehityksessä on jonkin verran eroa.
Kommentit
- Haluammeko Oletetaan, että ECM tarkoittaa yrityksen sisällönhallintaa [järjestelmää]?
- Kyllä, minä ’ työskentelen Alfrescon kanssa
Vastaa
Tässä on ensin kaksi sääntöä kehysjätteen syntymän välttämiseksi:
- Olemassa olevan puuttuminen, joka kattaa 80% minun tarpeeni ja laajennettavissa vastaamaan viimeisiä 20%
- Lähellä varma, että käytän sitä uudestaan toisessa sovelluksessa
Kun olet läpäissyt ne, tarkista tämä:
- 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
Kommentit
- Lisäisin, että jos et voi ’ löytää kehystä, joka täyttää 80/20 -sääntösi joko työskentelet erittäin ainutlaatuisessa verkkotunnuksessa TAI et ’ ymmärrä verkkotunnustasi tarpeeksi hyvin.
Vastaa
1) Ominaisuudet tulisi lisätä kehykseen vain, kun ne on purettu työkoodista. Toisin sanoen, ennen kuin lisäät upean uuden idean upeaan uuteen kehykseen, varmista, että se todella tuo lisäarvoa ja vähentää toistoa toimivassa tosielämän sovelluksessa.
2) Dokumentaatio, dokumentaatio, dokumentaatio.
3) Dokumentaatio, dokumentaatio, dokumentaatio.
Vastaus
Kivulias kokemus ja paljon hukkaan menevää työtä johtaa tähän neuvoon: pura tai muokkaa kehys toimivista ohjelmistoista. Rakenna ohjelmisto pitäen mielessä, että luulet haluavasi purkaa kehyksen tulevaisuudessa, mutta älä rakenna sitä ensin.
Vastaa
Ehdotan kirjan kehyssuunnittelua . Se on pari vuotta vanha, mutta periaatteet pysyvät totta. Siinä on paljon malleja ja se selittää päätösten perustelut, jotka teet kehystä rakennettaessa.
Vastaa
1) Pidä kiinni hyvistä käytänteistä heti alusta alkaen ja varmista, että olet dokumentoinut hyvin erityisen käytännön, parhaat puitteet ovat sisäisesti yhdenmukaisia.
2) Varmista, että kaikki on hyvin dokumentoitua, hyvästä koodikommentit selittävät kaikki tärkeimmät toiminnot edellyttävät ja tuottavat, vaikka se tuntuisi sinulle erittäin yksinkertaiselta, saatat joutua jonkun käyttämään sitä 14. suorana tunnina ja he vain tarvitsevat yhtä asiaa heti.
3) Esittele itsellesi projektikohtainen esitys, jossa haluat kehyksen saavuttamisen, realistiset tavoitteet ja yleiset prioriteetit.
4) Jos se on ihmisten käytettävissä, varmista, että sinulla on jonkinlainen tukiprosessi / virheenseuranta. Virheitä tulee olemaan, se tapahtuu meille kaikille, mutta jos pystyt hallitsemaan niitä heti, se helpottaa elämääsi.
Kaiken kaikkiaan samanlainen lähestymistapa minkä tahansa sovelluksen rakentamiseen, mutta kehittäjät ovat jopa hämmentyneempiä kuin käyttäjät, ja parhaat kehykset ovat ne, jotka voimme noutaa, ymmärtää ja meidän ei tarvitse taistella.
Vastaa
Olen eri mieltä monista sanoista ja mielestäni enemmän on jätetty mainitsematta, joten aloitan tyhjästä.
Ketterät menetelmät
Ota kehityskehityksessäsi käyttöön ketterät menetelmät, jotta voit sopeutua muutoksiin, reagoida nopeasti esteisiin ja varmistaa toimivan, laadukkaan lopputuotteen. Ketterät menetelmät ovat niitä, jotka ”Ketterän manifestin” mukaan asettavat etusijalle:
Yksilöt ja vuorovaikutukset yli prosessit ja työkalut
Toimiva ohjelmisto over kattava dokumentaatio
Asiakasyhteistyö over sopimuksen neuvottelu
Muutokseen vastaaminen over suunnitelman mukaisesti
Se on totta. Sanoin, että toiminnallisuus on tärkeämpää kuin dokumentointi. Huomaa, että ”Ketterässä manifestissa” mainitaan, että oikeanpuoleiset prioriteetit ovat edelleen tärkeitä, aivan vähemmän kuin vasemmalla olevat.
Viestintä
Kehyksen luomisen on tiedettävä:
- Kuinka sitä käytetään: kohdesovellus
- mikä ongelma on tarkoitus ratkaista: kohdeongelma
- Kuka käyttää sitä: kohdeyleisö
Esimerkiksi, jos yritys aikoo kehittää lopullisen sovelluksen ASP .NET: n kanssa, olisi typerää sanoa ohjelmoijilleen ”tee tämä kehys” kertomatta heille yllä. Jos ohjelmoijat eivät tiedä kohdesovellusta, he eivät ehkä tee siitä verkkokeskeistä. Jos he eivät tiedä ongelmaa, he voivat luoda kehyksen eri tarkoitusta varten. Jos he eivät tiedä yleisöä, he voivat ohjelmoida kehyksen C ++: ssa. Mikä tahansa näistä olosuhteista tekisi tuloksena olevan kehyksen hyödyttömäksi.
Tyyli
Lienee tarpeetonta sanoa, että luot ohjelmointityylin / format ja pidä siitä kiinni.
E ”s
- Modulaarisuus : Käytä koodia uudelleen ohjelmallisesti, ei kirjaimellisesti.
- Tehokkuus : Koodisi on tarkoitettu uudelleenkäyttöön . Nopeuden haitat moninkertaistuvat.
- Ylläpidettävyys : Haluat pystyä muokkaamaan kehystä päivitä useita ohjelmia tarvitsematta muokata mainittuja ohjelmia.
- Käytettävyys : Voivatko sovellukset todella käyttää kehystäsi hyppäämättä vanteiden läpi?
- Käytännöllisyys : Älä keksi pyörää uudelleen, jos sinulla ei ole tehdä niin. Kehys voi riippua muista kehyksistä.
- Redundanssi : Ota poikkeukset / virheet kiinni. Joka puolella. Käsittele niitä. Joka puolella. Älä koskaan luota mihinkään muuhun kuin paikallisen koodin koodiin virheiden käsittelyyn, vaikka tiedätkin, että se toimii.
Kommentit
- Tervetuloa P.SE: lle! En ’ en ole samaa mieltä 6: n kanssa poikkeusten saamisesta puitteissasi. Olen ’ uskoo siihen, että kehyksen tulisi olla ehdoton karkea ja heittää poikkeuksia ja jättää se ohjelmoijan tehtäväksi kehyksen avulla kiinni heille tai (vielä parempi) suunnata koodinsa uudelleen poikkeuksen välttämiseksi – kannustamalla sopimusten noudattamista.
Vastaa
Olen varma, että kehyksen tai kirjaston ja sovelluksen kehityksessä on jonkin verran eroa.
Kehitysprosessit ovat olennaisesti samat. erot voivat johtua markkinointi- ja käyttöönottokysymyksistä, vaikka mielestäni suurimmat erot ovat yleensä projektin laajuudessa ja määritelmässä. Muista, että sovellus voi sisältää tai käyttää kehystä tai kirjastoa, kehys voi olla kirjastokokoelma.
Minulla on epäilyksiä siitä, miten käsitellä projektin organisaatiota ja hallintaa: Onko olemassa joitain yleisiä sääntöjä matala, vinkkejä, parhaita käytäntöjä tai jotain mielessä pidettävää tällaisen projektin kehittämisessä?
Projektin organisointi ja hallinta ovat jälleen samat kaikissa kehitysprojekteissa . Jälleen se tulee alas soveltamisalaan. Kehyksen kirjoittamisessa kannattaa kuitenkin olla hyvin selkeä näkemys siitä, mitä yrität saavuttaa, ja asettaa tiukat suunnittelusäännöt julkiselle käyttöliittymälle kehykseen, jotta varmistetaan API: n yhdenmukaisuus Jos annat jokaiselle kehittäjälle tehdä oman asiansa, päädyt monimutkaiseen sotkuun ja erittäin epäedulliseen API-suunnitteluun.
Olen ”toinen Ryan Hayes” suositus lukemaan kehyssuunnitteluohjeet vaikka itse kirjan tarkoituksena on kehittää .NET-pohjaisia kehyksiä, koska yleisiä neuvoja voidaan soveltaa riippumatta käytetyistä toteutustekniikoista, joita haluat käyttää.
Kokemukseni mukaan suosittelen pitämään kiinni klassinen YAGNI-periaate ottamalla ensin käyttöön yksinkertaisimmat julkiset rajapinnat ja laajentamalla sitä myöhemmin tarjoamaan paremman hallinnan ja syvyyden, mutta varo käyttämästä hyödyllisiä nimiä osoittaaksesi, miksi menetelmiä tai luokkia laajennetaan. En ole koskaan ollut fani lisätä ”Ex” tai muita vastaavia päätteitä menetelmien nimiin tai lisätä numeroita laajennettuihin käyttöliittymämäärityksiin. Erota toiminnallisuudesta, ja käyttöliittymän / menetelmän nimien tulisi olla selkeämpiä ja toivottavasti vähemmän hämmentyneitä ja hämmentäviä.