Nagu Saiku kodulehelt näha, siis kuu alguses lisandus meie väikese meeskonnaga Marti. Marti on andekas arendaja ja tema abiga suudame palju suuremaid projekte ette võtta. Sügiseks ongi plaanis juba mõnda aega arendatud projektid valmis saada. Anname nendest kindlasti blogi vahendusel teada.

Kõigele lisaks osalesin 14.-15. juunil Euroopa Sotsiaalfondi abiga Peep Vainu koolitusel “Võiduka meeskonna juhtimine” selleks, et osata luua motiveerivat tulemustele suunatud meeskonda. Kuigi koolitus on praeguseks läbi, suurem töö ja meeskonna arendamine alles algab. Projekt sai tuge EASi Teadmiste ja oskuste arendamise toetamise meetmest. Projekti abikõlblikkuse perioodi alguskuupäev oli 21.05.2010. a ja lõppkuupäev oli 13.05.2011. a.

Loe veel sarnasel teemal:

1. I. M. Wright’s “Hard Code” Mõni aeg tagasi andis Andres Sirel mulle Eric Brechneri raamatu...
2. GeekDinner September Eelmisest GeekDinnerist on terve suvi möödas ning võiks jälle kokku...
3. Mida TDD tähendab? TechEd 2008 sai külastatud ka Roy Osherove‘i ettekannet teemal “Understanding...

Mingil põhjusel arvatakse, et testid on samaväärsed write-only koodiga ning ei kanta erilist hoolt selle üle, et neid tulevikus hallata saaks. Küllaltki kurb on tõdeda pärast ümberstruktureerimist katkiseid teste, millest pole võimalik väga aru saada.

Pakun välja mõned võimalused testide paremaks struktureerimiseks.

Esimest varianti on võimalik kasutada küllaltki lihtsalt olemasolevate testide peal. Kuna testid koosnevad kolemast osast (Arrange, Act, Assert; Given, When, Then), siis võib testi ka selliselt tükkideks jagada. Cucumberi kasutajatele peaks see olema küllaltki tuttav: samalaadselt tuleb kirjeldada ära sammud. Selle pahupooleks võibki sammude haldamine olla, sest test on tükeldatud, kuid ülevaate saab palju kiiremini ning on korduvkasutatav.

[TestFixture]
public class SalesOrderTests
{
  [Test]
  public void Should_accept_regular_sales_order()
  {
    given_regular_sales_order();
    when_accepting_sales_order();
    expect_sales_order_state_to_be_accepted();
  }

  private void given_regular_sales_order()
  {
    Target = SalesOrderBuilder.Regular();
  }

  private void when_accepting_sales_order()
  {
    Target.Accept();
  }

  private void expect_sales_order_state_to_be_accepted()
  {
    Target.State.Current().Is(SalesOrderState.Accepted)
      .Should().Be.True();
  }

  private SalesOrder Target { get; set; }
}

Järgmine struktuur viib eelnevalt edasi, kuid nüüd on iga stsenaarium eraldi klassis. Sellest tulenevalt on testide klasside hulk küllaltki suur ning soovitatav on hoida hea projekti struktuur, et otsimine keeruliseks ei läheks (R#-i otsing pole enam nii kerge).

Sellist struktuuri on väga hea kasutada ärimudeli testimiseks, sest nii saab tihtipeale otse kasutusloost (use case) selle ümber kirjutada. Hiljem on ka võimalik tekitada ilus raport, mis on testitud ning see on ka loetav äripoolele.

[Specification]
public class When_accepting_new_sales_order :
  ScenarioFor<SalesOrder>
{
  public override void Given()
  {
    Target = SalesOrderBuilder.Regular();
  }

  public override void When()
  {
    Target.Accept();
  }

  [Then]
  public void It_should_have_accepted_state()
  {
    Target.State.Current().Is(SalesOrderState.Accepted)
      .Should().Be.True();
  }

  [Then]
  public void It_should_raise_accepted_sales_order_event()
  {
    DomainEvents.Published
      .Should().Contain<SalesOrderAcceptedEvent>();
  }
}

Viimane variant, mille tutvustamise praegu käsile võtan, on mõeldud sündmustele orienteeritud arhitektuuri puhul. Tulemuseks võiksime saada midagi sarnast alljärgnevaga. Selleks, et baasklassis argumenttüüpidest (generic) oleks paremini aru saada võime kasutada sisemisi klasse (nested type). Algseisu saame tekitada paari sündmuse loomisega, stsenaariumi käivitamiseks tuleb anda ette käsk ning kontrollimiseks vaadata juhtuva sündmuse andmeid.

[Specification]
public class When_accepting_new_sales_order :
  Scenario.For<SalesOrder>.When<AcceptSalesOrderCommand>
{
  public override IEnumerable<IDomainEvent> Given()
  {
    var identity = Guid.NewGuid();
    yield return new SalesOrderCreatedEvent(identity, "SO001", "ABC Company");
    yield return new ItemAddedToSalesOrderEvent(identity, "Mobile", 10.99m, 5);
  }

  public override AcceptSalesOrderCommand When()
  {
    return new AcceptSalesOrderCommand(Target.Id);
  }

  [Then]
  public void It_should_raise_accepted_sales_order_event()
  {
    DomainEvents.Published.Last()
      .Should().Be.TypeOf<SalesOrderAcceptedEvent>();
  }
}

Minu poolt praeguseks struktuurid otsas, kuid võite otsida ka Behavior Driven Development (BDD) stiilis raamistikke, kus lähenemisnurgad on sarnased või isegi väiksem kirjavaevaga. Kui teate mõnda mugavat struktureerimise viisi, siis oleksin vägagi huvitatud sellega tutvumisest.

Head testide struktureerimist!

Loe veel sarnasel teemal:

1. Iluvõtted koodile III Toidupoodides tihti võib leida väga huvitavaid teid. Mõned noorendavad, teised...
2. Iluvõtted koodile IV Ilusaks on võimalik ka saada igasuguste maskidega, näiteks näo- või...
3. Iluvõtted koodile II Loodetavasti on kõht nüüd brokkoli parajasti täis ja kood ilustatud...

Liideste abiga saame objektide omavahelist siduvust vähendada. Teavad täpselt nii palju kui vaja. Mida väiksemaks nendega läheme, seda rohkem anname teada kavatusest ning ei pea kartma NotSupportedExceptionit.

public interface IConsume<TMessage>
{
  void Consume(TMessage message);
}

public interface ICanMakeCustomerPreferred
{
  void MakePreferred(Cutomer customer);
}

Need liidesed on küllaltki väiksed, kuid leidub ka veel väiksemaid. Neid nimetatakse tähistajateks.

public interface IAggregateRoot {}

Tihti on vajadus ka liideste järgi, mis on mitme parameetriga (generic) ning nende lugemine osutub raskemaks. Õnneks saab teha C#-s sisemisi klasse (nested types) ja selle abiga maskeerida raskesti loetavat koodi.

public interface IMessageHandler<TMessage, TResponse>
{
  TResponse Handle(TMessage message);
}

public class RespondsTo<TMessage>
{
  public interface With<TResponse> :
    IMessageHandler<TMessage, TResponse>
  {}

  public interface WithListOf<TResponse> :
    IMessageHandler<TMessage, IList<TResponse>>
  {}
}

public class AcceptedSalesOrdersMessageHandler :
  RespondsTo<AcceptedSalesOrdersMessage>.WithListOf<SalesOrder>
{
  public IList<SalesOrder> Handle(AcceptedSalesOrdersMessage message)
  {
     //...
  }
}

Kui olete ise liideste osas kasutanud võtteid, mida jagada soovite, siis kommentaarid on oodatud.

Meeldivat maskide kandmist!

Loe veel sarnasel teemal:

1. Iluvõtted koodile I Ilusa koodi saamiseks ei ole vaja toita teda brokkoliga, osta...
2. Iluvõtted koodile III Toidupoodides tihti võib leida väga huvitavaid teid. Mõned noorendavad, teised...
3. Iluvõtted koodile II Loodetavasti on kõht nüüd brokkoli parajasti täis ja kood ilustatud...

public class Teabag
{
  //..
}

public class Trashbin<TTrash>
{
  public void Add(TTrash trash)
  {
    //..
  }
}

var trashbin = new Trashbin<Teabag>();
trashbin.Add(new Teabag());
trashbin.Add(new Teabag());
trashbin.Add(new Teabag());

Selle probleemi saab lahendada küllaltki lihtsalt kasutades params võtmesõna:

public class Trashbin<TTrash>
{
  public void Add(params TTrash[] trash)
  {
    //..
  }
}

var trashbin = new Trashbin<Teabag>();
trashbin.Add(
  new Teabag(),
  new Teabag(),
  new Teabag()
);

Alati ei pruugi seda vaja minna ärimudeli puhul, kuid küllaltki kasulik on seda kasutada registreerimistel, seadistustes:

ServiceLocator.Register(
  Requested.Service<ITrashbin>()
    .IsImplementedBy<Trashbin>(),
  Requested.Service<IShop>
    .IsConstructedBy(() => ShopFactory.Create())
);

Vahel tasub seda võtet kaaluda. Mida huvitavat olete ise selle küllaltki nurka jäetud võtmesõnaga korda saatnud?

Head teejoomist!

Loe veel sarnasel teemal:

1. Iluvõtted koodile IV Ilusaks on võimalik ka saada igasuguste maskidega, näiteks näo- või...
2. Iluvõtted koodile I Ilusa koodi saamiseks ei ole vaja toita teda brokkoliga, osta...
3. Iluvõtted koodile II Loodetavasti on kõht nüüd brokkoli parajasti täis ja kood ilustatud...

return this;

Võib kerkida küsimus, et kus neid kasutada, kui on klassides defineeritud ainult atribuudid (property) ja paar üksikut meetodit. Nii ei ole võimalik seda väga lihtsalt rakendada.

public class Product
{
  public StockKeepingUnit SKU { get; set; }
  public ProductName Name { get; set; }
  public Money Price { get; set; }
  public Party Vendor { get; set; }
}

var product = new Product
{
  SKU = new StockKeepingUnit(“PRO-2345”),
  ProductName = new ProductName(“Goldstein Elite Blue Pen”),
  Price = new Money(10m, Currency.EEK),
  Vendor = new Organization(“ABC Company”)
};

Defineerides paar meetodit võiksime selle klassi saada järgmiseks:

public class Product
{
  public StockKeepingUnit SKU { get; protected set; }
  public ProductName Name { get; protected set; }
  public Money Price { get; protected set; }
  public Party Vendor { get; protected set; }

  public Product Named(string name)
  {
    Name = new ProductName(name);
    return this;
  }

  public Product SerializedAs(string serial)
  {
    SKU = new StockKeepingUnit(serial);
    return this;
  }

  public Product Priced(decimal amount, Currency currency)
  {
    Price = new Money(amount, currency);
    return this;
  }

  public Product ProducedBy(string name)
  {
    Vendor = new Organization(name);
    return this;
  }
}

var product = new Product()
  .Named(“Goldstein Elite Blue Pen”)
  .SerializedAs(“PRO-2345”)
  .Priced(10m, Currency.EEK)
  .ProducedBy(“ABC Company”);

Ilmselt panite tähele, et uues koodis on rohkem koodi. Samas see tundub loetavam ja peamiselt tegeleme primitiivtüüpidega.

Esmapilgul võib tunduda, et Object-Relational Mappertite (ORM) osas võib tekkida probleeme, kuid NHibernate tingimused tunduvad täidetud olevat (protected setterid on olemas). Seevastu teisendamine objektist objektiks võib veidi probleemsem olla. Olemist (entity) transpordiobjektist (Data Transfer Object, DTO) ei tohiks probleemne olla, kuid vastupidine on juba keerulisem. Mulle tundub, et see ongi hea – see sunnib meid mõtlema veidi teisiti, muudatused olemis peaksid olema ärilise üksusena, mitte nagu tänapäeva tabelipõhised haldamised.

Liideste abiga on meil veel võimalik kitsendada valikuid ja sundida kindla jada läbima.

public IProductNamingExpression Named(string name)
{
  //...
  return this;
}

public interface IProductNamingExpression
{
  Product SerializedAs(string sku);
}

product.Named("Goldstein Elite Pen").SerializedAs("GEP-0001");

Kui leiate, et ei soovi enda ärimudelit nii keerukaks teha, siis on see vägagi sobilik Builder mustri jaoks, kus pika konstruktori argumentide asemele tuleb loetav jutt. See meetod sobib ka väga hästi seadistuste ja registreerimiste jaoks.

Ilusat koodi kirjutamist

Loe veel sarnasel teemal:

1. Iluvõtted koodile I Ilusa koodi saamiseks ei ole vaja toita teda brokkoliga, osta...
2. Iluvõtted koodile IV Ilusaks on võimalik ka saada igasuguste maskidega, näiteks näo- või...
3. Iluvõtted koodile III Toidupoodides tihti võib leida väga huvitavaid teid. Mõned noorendavad, teised...

Esimeseks võtteks, mida käsitlen, on laiendusmeetodite (Extension Methods) kasutamine. Nende abiga saame kergesti olemasolevatele klassidele lisada meetodeid juurde, eriti kui meil pole võimalik klassi ennast muuta.

Esimene näitena toon keeleliste struktuuride ilustamisest. Suhteliselt harva kasutan for tsüklit, mistõttu pole see konstruktsioon väga selgelt enam mu peas (ajan pidevalt segamini, kas on “,” või “;” osade vahel). Lisaks tuleb alati seda pikalt lugeda, et aru saada, mis seal tehakse. Palju selgemini väljendub laiendusmeetodite abiga tehtud funktsioon:

for (var index = 0; index < 5; index++)
{
  //...
}

// vs

5.Times(index =>
{
   //…
});

Realiseerimiseks läheb vaja mõnerealist koodi:

public static void Times(this int count, Action<int> action)
{
  if (count < 0)
    throw new ArgumentException("Count should be positive");
  for (var index = 0; index < count; index++)
    action(index);
}

Laiendusmeetodid on osutunud kasulikuks ka arvutuste sõnastamisel. Näiteks:

Time.AddDays(1);
new DateTime(Time.Year, Time.Month, DateTime.DaysInMonth(Time.Year, Time.Month))

Time.Tommorrow();
Time.EndOfMonth();

Viimased read on palju selgemini väljendatud ning ei vaja mõttetööd koodi lugemisel.

Abiks on olnud laiendusmeetodid ka teisendamistel. Eriti kui üle süsteemi kasutan ühte väärtust mõnel argumendil.

new Money(90.5m, Currency.EEK)

90.5m.AsMoney();

Vahel aitavad need lisada juurde ka konteksti:

5.Percent();

Laiendusmeetodid võivad arhitektuurilist piltiki veidi muuta – paljud kasutavad Active Record mustrit ning tüüpiliselt on see realiseeritud nii, et peame mõne raamistiku baasklassist pärinema. See on tihti ebameeldiv ja õnneks on see lahendatav:

public interface IEntity<TIdentity>
{
  TIdentity Id { get; }
}
public interface ISavable {}
public interface IDeletable {}
public interface IActiveRecord
  : IEntity<int>, ISavable, IDeletable {}

public static void Save(this ISavable entity)
{
  ServiceLocator.Resolve<IRepository>().Save(entity);
}

public static void Delete(this IDeletable entity)
{
  ServiceLocator.Resolve<IRepository>().Delete(entity);
}

Nende laiendusmeetodite abiga saame kenasti enda äriobjektid võõrastest raamistikest eemale hoida:

public class Person : IActiveRecord
{
  public int Id { get; set; }
  public string Name { get; set; }
}

var person = new Person();
person.Name = "Aabel";
person.Save();
person.Delete();

Kokkuvõtvalt võib öeda, et laiendusmeetodite abiga saab koodi loetavamaks muuta ning ärimudelit ja arhitektuuri parandada. Lisaks võite uurida laiendusmeetodeid Extentsion Method.NET-ist. Ja kui sul on rääkida oma lugu laiendusmeetoditest, siis ootame seda kommentaarides.

Head brokkoli söömist!

* foto: pontuse

Loe veel sarnasel teemal:

1. Iluvõtted koodile IV Ilusaks on võimalik ka saada igasuguste maskidega, näiteks näo- või...
2. Iluvõtted koodile II Loodetavasti on kõht nüüd brokkoli parajasti täis ja kood ilustatud...
3. Iluvõtted koodile III Toidupoodides tihti võib leida väga huvitavaid teid. Mõned noorendavad, teised...

Samas kui soovid midagi laenutada Saiku Kaizen raamatukogust – http://www.saiku.ee/kaizen/raamatukogu/ – või tahad Saiku arendusmeeskonda palgata oma veebirakendust või tarkvara meisterdama, siis helista 6 825 809 või kirjuta info@saiku.ee ja uuri täpsemalt.

Loe veel sarnasel teemal:

1. Kaizen raamatukogu on avatud Valisime välja hunniku põnevat tarkvaraarenduse alast kirjandust ning koondasime selle...
2. KoopiaKoopiaKoopia ei ole ilus Kui anekdooti rääkida esimest korda, siis arvatavasti on see naljakas,...
3. Kõike, mida sa omad, ei ole sul vaja Inimestele meeldib teha pigem seda, mida pole vaja. Seda illustreerib...

Meeldejäävaid ideed oli raamatus küllaga:

Oluline on meeskond, küll väärt ideed tulevad millalgi. Tihtipeale polnud asutajatel täpset arusaama, mida nad tegema hakkavad ning ajapikku leiti õige suund. Seega tasub hoolega valida kellega koos asutatakse. Fog Greek Software ja Excite alustasid ilma konkreetse toote plaanita, kuid enda saatuse üle nad viriseda ei saa.

Kes plaanib üksi startup-i tegema hakata peaks kõvasti järgi mõtlema. Üksi lahingusse ei minda. Paljudki investorid ei pruugi nii ettevõtmist tõsiselt võtta. Raamatustki selgus, et tüüpiliselt asutajaid on 2-4 inimest.

Paljud tooted arenevad välja kõrvaltegemistest ning populaarsuse tõusul vormistatakse see ettevõtteks. Luua iga enda idee jaoks eraldi ettevõte on kulukas ja võtab enamiku auru. See tundub olevat naha jagamine enne jahile minekut. Mõistlikum on teha midagi valmis ja vaadata, kas teistel on ka sellest kasu ning alles siis moodustada vajalik meeskond. Nii said alguse Craiglist ja Yahoo!

Selleks, edukas enda tootega olla, peab lahendama reaalse probleemi. See on ka üks põhjustest, miks kõrvaltegemisest väljaarenenud tooted edukad on. Inimesed ei viitsi vaevata ennast väga kasutute asjadega. Eranditeks on ilmselt MafiaWars ja Farmville Facebookis.

Enne teele asumist tuleks endal selgeks teha, et miski ei tule ise kätte ning tööd tuleb kõvasti rabada. 4 tundi päevas magada ja sedagi kontoris, pereprobleemid – kas need kõik on üldse väärt seda ja kas sellist elu üldse soovid elada? Tagasi vaadates tundus kõigile see lõbus aeg olevat, kuid selle keskmes olles see nii ei ole.

Tegevdirektor (CEO) on tore ametinimi, kuid alati ei pea see mõni asutajatest olema. Eelkõige kui asutajad on tehnilised inimesed. Vahel tasub selliseid inimesi ka palgata, sest nende töö on ilmselt tunduvalt viljakam. Huvitav, kas Eestis võiks selline asi juhtuda? See on siiski veidi ego kraapiv. Bloglinesis vahetati CEO välja investorite soovil. Six Apart võttis ise juurde endale CEO, kuna asutajad mõistsid, et nad ei suuda kõike ise teha.

Investoreid on igat sorti ning alati nad ei ole abistav käsi. ArsDigital läks vägagi kehvasti investoritega (see oli lausa koomiline) ning Six Apart suhtus vägagi ettevaatlikult neisse.

Väga meeldiv oli lugeda ka seda, kuidas Herman Milleri toole võib saada (lk 63), kuidas espresso masin võib ettevõtte päästa (lk 157) ja milline on Indiast saadav arendusteenus (lk 320).

Kui leidsid veel mõne põneva episoodi või tähelepaneku, siis jaga seda meiegagi. Lõbusat lugemist!

Loe veel sarnasel teemal:

1. Motivatsioon ja mõõdikud Üks tüüpilisi töövestluse küsimusi on: kas sa oled motiveeritud tööd...
2. Huvitavat vaatamist maailmast Hiljuti oli mul aega vaadata nädalas kogunenud huvitavamad ajaveebide kanded...
3. Maailmad on erinevad: Model-View-Controller Üks populaarsemaid kasutajaliides loomise mustreid veebirakenduste juures on Model-View-Controller ehk...

Meeldivat lugemist!

Loe veel sarnasel teemal:

1. Õppida, õppida… Sattusin ühel õhtupoolikul huvitavate videoseeriate otsa. Esimene neist oli jQuery’st...
2. Modernne tarkvara loomine V: Mitu kasutajakontot sul on? Väga lihtne küsimus teile: mitu kasutajakontot sul kokku on? Ma...
3. Tarkvara meistrite manifest Juba mõnda aega on käimas liikumine “Software Craftsmanship”, mille algatajaks...

Tagasi vaadates polnud see aasta üldse paha: avaldatud sai umbes 60 postitust, lugejaid kõigub 90-110 vahel ning avasime ka raamatukogu, et raamatud lihtsalt tolmu ei koguks. Siiski pean endale veidi tuhka pähe raputama, et pole jõudnud kirjutada midagi sel aastal, kuid võtan ennast järjekordselt käsile. Siinkohal võiksitegi anda soovitusi, mis teemadel soovite kirjatükke näha.

Meeldivat edaspidist lugemist!

Loe veel sarnasel teemal:

1. Otsuste langetamise kunst Süsteemide loomisel tuleb igal meeskonnas oleval inimesel viia läbi hulgalisi...
2. Pidev õppimine Tarkvara arenduses ellujäämiseks on vaja küllaltki palju juurde õppida pärast...
3. IT pole oluline Eelmise aasta sügisel TechEdil kuulates Miha Kralj ettekannet teemal “How...