Ideas and execution with passion, creativy and thought.
.Net Developer & Software Designer

Tech

notatki
  • 14-02-2012 11:39
    36 klasycznych błędów w procesie tworzenia oprogramowania
    Błędy ludzkie Błędy procesu Błędy produktu Błędy technologiczne
    1. Podważona motywacja
    2. Słabi ludzie
    3. Niekontrolowani problematyczni pracownicy
    4. Bohaterstwo
    5. Dodawanie ludzi do spóźnionego projektu
    6. Głośne, zatłoczone biura
    7. Tarcia pomiędzy twórcami a klientami
    8. Nierealistyczne oczekiwania
    9. Brak efektywnego sponsoringu projektów
    10. Brak zainteresowanych stron
    11. Brak zdania użytkownika
    12. Polityka ponad istotą sprawy
    13. Pobożne życzenia





    Źródło
    1. Zbyt optymistyczne planowanie czasu
    2. Niedostateczne zarządzanie ryzykiem
    3. Błędy wykonawców
    4. Niewystarczające planowanie
    5. Rezygnacja z planowania pod presją
    6. Strata czasu na rozmyty początek
    7. Niewystarczające aktywności początkowe
    8. Nieodpowiednie projektowanie
    9. Niewystarczające zapewnianie jakości
    10. Niewystarczająca kontrola zarządzania
    11. Przedwczesna lub zbyt częsta zbieżność
    12. Planowanie nadrobienia później
    13. Tworzenie kodu rodem z piekła

    1. Zbytnie precyzowanie wymagań
    2. Zbytnie dodawanie funkcjonalności
    3. Zbytni perfekcjonizm programistów
    4. Przepychanki w negocjacjach
    5. Programowanie sterowane badaniami
    1. Szybkie rozwiązywanie kłopotliwych spraw
    2. Przeszacowane oszczędności z tytułu użycia nowych narzędzi lub metod
    3. Zmiana narzędzi podczas trwania projektu
    4. Brak automatycznej kontroli wersji
  • 14-02-2012 11:36

    Właściwie to sukces w tworzeniu oprogramowania zależy nie tyle od niepopełniania kilku błędów, co od dążenia do robienia większości rzeczy prawidłowo.

    Jak głosi stare przysłowie programistów, pierwsze dziewięćdziesiąt procent zadania zajmuje dziewięćdziesiąt procent czasu, a ostatnie dziesięć procent zadania zajmuje kolejne dziewięćdziesiąt procent czasu.
  • 25-01-2012 21:55
    Najważnie zasady podczas korzystania z MVVM

    1. Unikanie kodu w code-behind – w większości przypadków to, co kiedyś było robione w code-behind, można przenieść do ViewModel, 
    2. Zdarzenia powinny zostać zastąpione komendami, np. zamiast podpinać zdarzenie Click, należy skorzystać z komendy; oczywiście istnieją przypadki, w których zdarzenia są jedynym rozwiązaniem, 
    3. ViewModel powinien implementować interfejs INotifyPropertyChanged, 
    4. Dane z widoku powinny być powiązane z właściwościami w ViewModel, 
    5. W testach sam ViewModel powinien wystarczyć; widok jest tak naprawdę wizualizacją przeznaczoną dla użytkownika; użytkownik, chcąc skorzystać z logiki dostarczonej przez aplikację, wprowadza tekst np. za pomocą TextBox – w testach jednostkowych ustawiamy właściwość w VM i powinniśmy uzyskać taki sam efekt, 
    6. należy rozróżnić Model od ViewModel; model nie może zawierać żadnej logiki, związanej z widokiem; innymi słowy, model to czysta logika biznesowa, z kolei ViewModel zawiera już informacje o stanie widoku.