Wiem, że brzmi to może jak banał, ale to nie jest jakaś wytyczna ustalona raz na początku projektu. Zrozumienie tego zajęło mi 4 lata. Nie możesz się umówić, że od teraz, od tego projektu, od tej funkcji będziesz pisał kod wysokiej jakości.

Możesz umówić się, że będziesz pisał kod o jakości najlepszej na jaką Cię w tym momencie stać.

Jednak w międzyczasie nauczysz się czegoś nowego. Wysokiej jakości kodu to taki, którego jakość rośnie ciągle. Nie tylko wraz z dodawaniem nowych linii. Również trafiając na kod z przed roku warto pochylić się nad nim.

Czy masz zespół, który stosuje zasadę skautów?

Chciałbyś być członkiem takiego zespołu?

Jak zawsze – staraj się myśleć, żeby nie popaść w przesadę.

Wyobraź sobie dwa typy osobowości, dwa ekstrema.
Z jednej strony masz “komandosa”, człowieka do zadań specjalnych, który jest w stanie pracować nad trudnym problemem godzinami i dążyć do celu długo po tym jak inni się poddali.

Komandos vs. komandos na warcie

To oczywiście są dwa punkty między którymi rozciąga się kontinuum zawierające mieszanki tych dwóch składników we wszystkich możliwych proporcjach. Jeśli 0 to komandos, a 1 wartownik to 0.75 to ktoś u kogo znacznie przeważają właściwości wartownika.

Idąc dalej trzymając się bitewnej analogii spójrz na swój projekt. Na pewno znajdziesz tam mnóstwo zadań dla wartowników. Z pewnością pojawiają się przeszkody o rozwiązywaniu których aż marzą komandosi.

Śmiem twierdzić, że każdy z tych typów osobowości naturalnie ulokuje się na pozycji, która jest dla niego naturalna. Ludzie nawet nieświadomie zarządzają swoimi zadaniami, a środowisko wytworzone przez członków zespołu przesuwa odpowiednie zadania do odpowiednich ludzi.

Upewnij się tylko, że nie zaburzasz tej samoorganizacji. Czasem pojawiają się pomysły, że ludzie za bardzo się specjalizują i może wymusić rotację, aby wszyscy w efekcie zajęli się każdym rodzajem zadania. Zastanów się czy warto. Z pewnością nie chcesz aby irytować swoich komandosów i wartowników.

Wpisz koniecznie w komentarzu jaką mieszanką jesteś.

Po przygodnie z promocją bloga za pomocą Wave’a wracam do głównej tematyki. Z uwagi na to, że jest sobota – znalazłem trochę czasu na obszerniejszy tekst. Mam nadzieję, ze Wam też uda się znaleźć czas na jego przeczytanie. Mam nadzieję też na ciekawą dyskusję.

No, może nie wszystko, ale to co Ty jako programista, albo Twój zespół programistów robi ręcznie.

Piszę tu w kontekście programowania w php – niestety czasem musimy nadganiać innych. Mam wrażenie, że php jest traktowany jako język “przejściowy” – jednak można przy jego pomocy robić rzeczy naprawdę dobre i przydatne. Ale to temat na inny wpis.

Postaram się podać kilka obszarów, w których automatyzacja może stać się Twoim przyjacielem.

Struktura bazy danych

Odpowiedz sobie na dwa pytania: czy nad moim projektem pracuje tylko jedne osoba? czy mam ustaloną i zaprojektowaną strukturę bazy danych przed rozpoczęciem projektu, której nie zmienię, choćby klient chciał zapłacić mi milion dolarów za dodanie systemu komentarzy?

Jeśli odpowiedź na nie brzmi ‘nie’ – zastanów się nad automatyzacją aktualizacji struktury bazy danych. I nie chodzi mi o problem migracji, który próbowałem ugryźć, a który okazuje się być dość skomplikowany. Napisałem nawet MySchemaShell i radził on sobie z migracją, dopóki nie zaczęły się zmieniać indeksy- straciłem do niego serce.

Okazuje się, że skomplikowana migracja nie jest potrzebna (pod warunkiem, że masz też dane “startowe” o czym poniżej). Okazało się, że wystarczy napisać prosty skrypt, który zrobi drop’a wszystkich tabel w bazie, a potem utworzy je na nowo. Przy czystej bazie danych MySchemaShell radzi sobie świetnie.

Zawartość bazy danych

Ten element łączy się z poprzednim. Bardzo żadko zdarza się, żeby aplikacja internetowa, którą piszesz obywała sie bez jakichkolwiek danych w bazie. Często bywa tak, że do staru aplikacja potrzebuje danych w bazie. Choćby reguł dla ACLi, czy innych rzeczy (zależą one często od rozwiązań, jakie stosujesz). Wypełnianie tych rzeczy jest strasznie upierdliwe. Robisz svn update, wchodzisz na strone – “Missing database”. Dodasz tą bazę – “Brak uprawnień ACL”, dodajesz uprawnienia – jakieśtam drzewo się nie generuje, bo w bazie nie ma głównego elementu (root) itd. W gorszym dniu zanim zabierzesz się do pracy masz już ochotę na godzinę sam-na-sam z workiem treningowym – tak Cię rozszadza. Szkoda na to czasu. Lepiej napisać najprosztszy mechanizm, który jedną komendą wypełni Ci bazę danymi startowymi. Jeśli taki masz – możesz się nie przejmować migracją bazy danych. Możesz jej strzelić DROPa i stworzyć na nowo i odpalić wypełnianie danych.

Tutaj obojętne jest w jaki sposób to rozwiążesz. Mogą to być zwykłe pliki sql, jeśli na prawdę nie masz czasu. Ja osobicie wolę rozwiązania niezaleźne od engine’u bazy danych. Dlatego dla struktury używam MySchemaShell (zmodyfikowany cake’owy SchemaShell). A dla danych startowych też skryptu Shell’owego który zwyczajnie wykonuje save na odpowiednich modelach, niedługo postaram się go wrzucić na tego bloga. Jeśli jesteś zainteresowany praktycznym przykładem przeczytaj o tym w jaki sposób automatyzuję instalację w aktualnym projekcie.

Testy czarnej skrzynki

Czyli testy od strony interfejsu. Bardzo prosto jest je wykonać z odpowiednim narzędziem. My używamy Selenium. Często jest tak, że “trzeba by przeklikać” system i sprawdzić, czy się nie sypie. To jest praca dla odpowiednio wytresowoanej małpki, więc szkoda na to Twoich programistów. Małpki są pod ochroną, a tresowanie nie jest takie proste jak zainstalowanie selenium – wybór jest więc prosty. Selenium za Ciebie przeklika całą aplikację. Trochę to trwa, więc nie ma co tych testów odpalać przed każdym commitem. Ale raz na iterację (zaraz się dowiesz kiedy dokładnie) warto odpalić wszystkie.

Unit testy

Gdy pierwszy raz się z nimi zetknąłem zrezygnowałem, bo testy kontrolerów i widoków były etdy koszmarem. Nie wiem, czy dalej są. Ale stosując zasadę, że “wszystko jest sztuką możliwego” doszliśmy do konkluzji, że wystarczą nam testy tylko w modelach. I nawet nie potrzebujemy 100% pokrycia kodu w tychże. Stosujemy unit testy w dla skomplikowanych reguł walidacyjnych i ogólnie wszędzie tam, gdzie dana funkcja jest skomplikowana. Na przykład, gdy chcemy powiązać element A z B (habtm), gdzie w powiązaniu istnieją daty. Daty danego powiązania nie mogą się zazębiać + jeszcze kilka skomplikowanych reguł biznesowych.

Oczywiście takie metody można napisać i bez unit testów (i TDD), ale w momencie kiedy nam się to uda – jedynym dowódem, że robią to co mają robić jest nasze przeświadczenie, że rozpatrzyliśmy wszystkie warunki. Poza tym, gdzy warunki się zmienią i tą walidację trzeba będzie zmienić – strach będzie tknąć się tej metody. Unit testy, które powstają przy okazji TDD nas przed tym chronią.

Jakie są efekty?

Oprócz braku negatywnych zjawisk, które opisałem przy okazji każdego zagadnienia – w prezencie dostajesz przyjemność. Przyjemność ta utrzymuje się dłużej w czasie, gdy projekt się rozrasta i staje bardziej skomplikowany. Chętniej zasiadasz do pracy, a to oznacza, że wydajniej pracujesz. Nie będę się rozpisywał – nie mam zamiaru reklamować mojego podejścia. Jeśli, któreś z tych elementów Cię irytuje – spróbuj zastosować.

Z własnego doświadczenia wiem, że zawsze warto mieć te mechanizmy w projekcie, który jest większy od “strony wizytówki” i ma trwać dłużej niż 3 tygodnie. Oczywiście jest to dodatkowy kod, który muszisz pielęgnować. Wymagania dot. tych skryptów mogą się zmienić. Ale koszty tych działań w porównaniu do zysków w naszym przypadku są pomijalne.

Zyskujesz przy okazji jeden bonus. Jeśli sotsujesz iteracje, to po każdej powinno się odbyć demonstracja jej efektów. Aby się odbyła potrzebujesz systemu, który działa. Wrzucasz go na serwer, odpalasz instalację, odpalasz unit testy, a na koniec testy interfejsu. Jeśli team jest zdyscyplinowany (a w stosując te rozwiązania czuje, że są dobre, więc je stosuje nadal) – usadawiasz się wygodnie w fotelu i patrzysz jak kolejne testy przechodzą. Potem cieszysz się, że masz demo, które działa.

Co dalej?

Jeśli masz te działające mechanizmy, możesz się zastanowić nad systemem (przepraszam za wyrażenie) Build’owania aplikacji. Właściwie masz już taki system, ale na przykład phing daje Ci dodatkowe możliwości (odpowiedz sobie tylko na pytanie, czy ich potrzebujesz).

Następnym krokiem jest system ciągłej integracji. To jest następny obszerny temat, którego tutaj nie opiszę, ale zachecam do zapoznania się z ideą – warto wiedzieć, co jest pod ręką.

Przede wszystkim – iteracje (trzytygodniowe).
Właśnie zakończyliśmy pierwszą. Odbyła się prezentacja iteracji, na której niestety nie było klienta. Był za to szef w roli klienta wewnętrznego- to on bywał na spotkaniach z klientami, więc był najlepszym substytutem na jaki nas było stać.

Ze scrum używamy dziennika zaległości produktowych (product backlog), który ciągle się rozrasta. Na razie sukcesem jest to, że przed końcem pierwszej iteracji w dzienniku mieliśmy wystarczająco elementów, żeby zacząć następną.

Tak wygląda wykres burndown dla zakończonej właśnie iteracji:

Staramy się stosować stopniowe zbieranie wymagań i stopniowy rozwój architektury z tym, że to drugie przetestowaliśmy już wcześniej w mniejszych pod-projektach. Pomijając fakt, że jest to zwyczajnie przyjemne podejście – gdybyśmy chcieli zebrać wszystkie wymagania, to trwałoby to do końca października. Gdyby jeszcze do tego projektować wszystko “z góry” – następny miesiąc by minął do startu projektu.

Po pierwszej retrospekcji doszliśmy do wniosku, że zbyt mało energii zostało włożone w etap planowania iteracji. Tym razem bardziej się na tym skupiliśmy. Jednak efekty, jeśli będą widoczne, to dopiero podczas kolejnej iteracji.

Udało nam się też wykonać krok w kierunku ciągłej integracji (CI):
- używamy MySchemaShell do migracji struktury bazy danych
- własnego narzędzia dla startowych danych testowych (też programik Shell) + do generowania obiektów ACL
- Selenium dla prostych (na razie) testów interfejsu, dla zabezpieczenia się przed sytuacją, gdy jest dwie godziny do prezentacji iteracji, nie ma odważnego do przeklikania systemu w celu znalezienia wpadek. No i te wpadki znajduje klient. Te testy trochę trwają, ale na pewno mniej niż ręczne “śmiganie po stronie”.

Co do testów jednostkowych – na razie jest plan, aby umieszczać je w krytycznych miejscach. Co w praktyce oznacza testowanie reguł biznesowych umieszczonych w warstwie modelu.

Jeśli pojawi się więcej ciekawostek – na pewno nie omieszkam napisać.

Tzn. zawsze wiedziałem, że kompilacja się odbywa podczas wykonywania kodu, więc mnie nie zajmowała. Klawisz F9 z Delphi czy BorlandBuildera zastąpiony został przez klawisz F5 w przeglądarce ;)

Jeśli chodzi o budowanie (Crtl+F9 zdaje się ;)) to wiedziałem, że zawarta jest w tym procesie. Reszta mnie nie interesowała, więc osunąłem się w słodkie objęcia ignorancji.

Czytając książki sugerujące stosowanie systemów ciągłej integracji (CI) i konsolidacji myślałem sobie, że spoko, fajnie by było, ale jednak w PHP nie ma czegoś takiego jak integracja i konsolidacja.

Nie mogłem bardziej się mylić ;) Dopiero przy trzeciej książce, w której wspomniana jest CI mnie olśniło:
Budowanie aplikacji to cały proces, który zmienia czysty kod z repozytorium w działającą aplikację!

A zatem obejmuje stworzenie bazy danych o odpowiedniej strukturze(*), ustawienie odpowiednich uprawnień do katalogów, które tego wymagają, wypełnienie bazy danymi startowymi i wszystkie inne czynności wymagane do poprawnego używania aplikacji.

Niezwykle ważne jest, aby móc cały ten proces zautomatyzować. Jedna z rzeczy jakich nauczyłem się podczas mojego, dwuletniego już, stażu w zawodzie to:
Jeśli jest do wykonania skończony ciąg operacji oraz
informacja o tych operacjach zapisana jest w pamięci ludzkiej
to
istnieje skończona, stosunkowo mała, liczba powtórzeń ciągu tych operacji, że
przynajmniej jedna z operacji nie zostanie wykonana.

Nazywę tą regułę “Zasadą zapominania”. Dlatego warto zautomatyzować ten proces przy pomocy chociażby narzędzia Phing (jest to php’owy odpowiednik Ant’a).

Możliwe, że niedługo napisze Wam co i jak z tym Phing.

* Nigdy nie wiedziałem dlaczego przechowywanie struktury bazy w repozytorium jest moją obsesją. Widać podświadomie czułem, że kiedyś będę używał Project Build System(s).

W tym artykule chciałbym zwrócić uwagę na ukryte problemy, których możesz nie być świadom pisząc projekt z myślą o tym, żeby po akceptacji zlecić go zewnętrznej firmie budującej systemy informatyczne.

Przede wszystkim specyfika wsparć unijnych wymaga, aby taki system został w (niemal) 100% wyspecyfikowany. To jest wymóg szkodliwy, zakładający że

• klient dokładnie wie czego mu potrzeba
• potafi doskonale wyartykuować swoje myśli
• analityk w lot złapie o co klientowi chodzi i…
• … idealnie zamodeluje te wymagania

Takie rzeczy możliwe są co najwyżej w przyszłowiowej “erze” (czyt. w reklamie i marketingu). Każdy kto miał styk z wytwarzaniem oprogramowania w stylu wodospadowym (dokładnie takim jaki wymusza UE) wie, że to bardzo rzadko jest możliwe.

Wykorzystując analogię budowlaną, gdyby projektem był dom, to musiałbyś najpierw móc opisać słowami jaki dom potrzebujesz. Nie zamówiłbyś u architekta szkicu (prototypowanie!) bo masz nadzieję, że szkic upchniesz w całym projekcie i zapłaci Ci za niego unia. Wszystko co możesz to powiedzieć co chcesz móc robić w tym domu:
spać, kąpać się, zjeść obiad, zaparkować samochód, oglądnąć telewizję, urządzić przyjęcie.
Czy z czymś takim poszedłbyś do firmy budowlanej, żeby oszacowali koszty zbudowania takiego domu?
Niech masz wstępnego projektu, bo zapłaci za to Unia. Nie masz żadnego szkicu i chcesz do planu dodać jakieś szacowanie, bo Unia wymaga, żeby na samym początku podać kwoty.

Z powyższej listy, można wywnioskować, że potrzebna Ci kuchnia (chcesz jeść), salon (tv + przyjęcie), garaż, sypialnia, łazienka. Doświadczony wykonawca domyśli się, że potrzebujesz też toalety mimo iż na liście “zrobić siku” zapomniałeś umieścić. Ale nie domyśli się, że salon powinien mieć przynajmniej 200m bo przyjęcia chcesz dla 100 osób organizować. Nie wie ile tych sypialni. Czy w ogóle chcesz ogród? Może ogrzewanie? Nie wspomniałeś nic o oknach, ani drzwiach.

Przejdźmy dalej. Kolejną wadą projektów wspieranych przez Unię jest to, że Unia za to płaci. Tym razem będzie analogia zakupowa. Wyobraź sobie, że idziesz do sklepu na zakupy i:

1. bierzesz 500zł własnej ciężko zarobionej krwawicy
2. ktoś daje Ci 500zł i to co wydasz to Twoje, czego nie wydasz – musisz oddać

Zagadka: Które zakupy zaowocują zakupem naprawdę potrzebnych rzeczy?
Dokładnie tak samo jest z “systemem informatycznym”. Gdy Ty za niego płacisz – jesteś zainteresowany funkcjonalnościami, które naprawdę zwiększą Twoją wydajność. Gdy płaci Unia – upychasz tam ile się da bo “a nuż się przyda”. Najważniejszym problemem w tym wypadku jest to, że takie upychanie kilkuktornie komplikuje projekt. A to z kolei

• zwiększa koszt całego projektu (tym się nie przejmujemy, bo unia płaci),
• implikuje jeszcze mniej dokładne niż “wróżenie z fusów” szacowanie (ryzykujemy obsówę projekty – Unia może nie zapłacić, ale nie przejmujemy się, bo w umowie załączymy kary umowne i wykonawca zapłaci)
• skutkuje skomplikowanym do wdrożenia systemem, pełnym niepotrzebnych funkcji, który muszą opanować Twoi pracownicy (robi się nieprzyjemnie, bo za to Unia nie zwraca, płacisz tylko Ty)

Dlatego warto się zastanowić, czy zwyczajnie warto. Czy na prawdę chcesz mieć Wielką Kobyłę za 150 tysięcy złotych, pełną niepotrzebnych funkcji, która była robiona w pośpiechu i przez to nikt nie chce nawet zaglądnąć do jej kodu, żeby cokolwiek zmodernizować? Czy chcesz czekać na Wielką Kobyłę za 150 tysięcy półtorej roku i kiedy dostaniesz ją do testów (sic!) wiesz, że otoczenie biznesowe i konkurencja zmieniły się na tyle, że przydało by się mieć juz coś lepszego?

Alternatywą jest system mniejszy. Zawierający 10% funkcjonalności Wielkiej Kobyły. Ale są to te rzeczy, które zwiększają Twoją wydajność (a co za tym idzie konkurencyjność) na przykład trzykrotnie. Może zapłacisz za nie więcej niż 10% ceny Wielkiej Kobyły i z własnej korzyści, ale spójrz na stosunek cena/korzyści. A co jeśli dodam do tego taki bajer:
Po dwóch miesiącach Twoi pracownicy uzywają systemu. Oni stają się specjalistami w zakresie jego obsługi i mogą współpracować przy jego rozwoju. Na pewno będą miec świetne pomysły, aby nieco ulepszyć działanie programu znów poważnie zwiększając swoją wygodę (wydajność!) pracy.
Przypomnij sobie ile razy używając Standardowego Programu (MsExcell, Outlook, Firefox etc.) miałeś poczucie “Kurcze, gdyby zmienić tutaj to i to, to bym się mniej naklikał przy tych codziennych … (raportach, analizach, wstaw cokolwiek)”.

To są rzeczy, których nie przewidzisz projektując Wielką Kobyłę.

Dlatego zamiast liczyć złotówki (150tys.) których nie musiałeś wydawać, policz korzyści których nie udało Ci się osiągnąć. Wiem, że to boli bardziej i nie jest takie proste. Nie mam pojęcia czy Twoja księgowa to potrafi ;).

Możesz też spróbować odpowiedziec na pytanie: Czy na przyjęciu/konferencji/piwku z ludźmi z branży wolisz:
a\ Opowiedzieć o tym jak to ostatnio wdrożyliście Customer Relationship Management Entenrprise Edition (nazwa kodowa Wielka Kobyła) za 150 tysięcy złotych, podciągnąć spodnie, odchrząknąć, a potem obwąchać pobliską latarnię i zaznaczyć swoje terytorium*
b\ Pochwalić się jak udało Wam się zwiększyć wydajność jednego z działów trzykrotnie za mniej niż miesięczną pensję dla tego działu. Polecić ekipę, z którą naprawdę dobrze się Wam pracowało. Następnie wrócić tego wieczoru do domu z długonogą menadżerką (ew. wspaniale umięśnionym, przystojnym menadżerem) spragnioną szczegółów na temat tego projektu.

Na zakończenie: pamiętaj, że ekonomia to coś więcej niż rachunkowość. Więc przestań liczyć tylko dutki na koncie.

(*)wiem, odpowiedzi są tendencyjne, ale to nie jest nielegalne ;)

Jednak okazuje się, że cake w nowym wydaniu wychodzi nam na przeciw razem z klasą Schema, oraz z narzędziem konsolowym ./cake schema … po krótce opowiem o co chodzi.

Zabawę z tym narzędziem najlepiej zacząć mając już jakiś zalążek aplikacji (tabele + modele). Jeśli sprawiamy ten podstawowy warunek możemy wpisać w konsoli ./cake schema generate … ot tak, dla jaj.

Następnie możemy się w katalogu app/config/sql/ namierzyć plik schema.php. To właśnie artefakt wygenerowany przez nas przed sekundą. Można w celach samorozwojowych zajrzeć do środka…

Jednak ciekawe rzeczy dzieją się, kiedy ponownie wywołamy to samo polecenie: otóż cake rezolutnie zauważy, że plik schema.php już istnieje i zapyta nas co dalej. Polecam wybór opcji [S]napshot i ponowny rzut oka do wspomnianego wyżej katalogu. Co widzimy? Dokładnie! Nowy plik o nazwie schema_2.php :D Zachęcam do zapoznania się z helpem (./cake schema help).

Wystarczy, że teraz przekonam zespół, aby w sytuacji, gdy nastąpiły zmiany w bazie, przed commitem wywołali to polecenie. Jest jeden problem, którego ewentualnie można się spodziewać – sporadycznych konfliktów. To znaczy sytuacji, w której dwóch programistów:

1. ściąga repozytorium, 
2. dokonuje (nawet różnych) zmian w bazie, 
3. zatwierdza dane: 
1. schema generate, 
2. svn add schema_X.php, 
3. svn commit

Problem w tym, że w takiej sytuacji w punkcie 3.3 jeden z nich dostanie informację

Nie mogę dodać schema_X.php do repozytorium, gdyż takowy  już w repozytorium istnieje.
Z poważaniem Twój
SVN

Nie jest to jakaś wielka tragedia, jak przy każdym konflikcie trzeba będzie go rozwiązać (w tym wypadku przy spotkaniu tych dwóch programistów). Jednak myślę, że takie sytuacje można by zlikwidować wywołując tą sekwencję w jednym ciągu (nie np. commit po dwóch godzinach od schema generate), może nawet napisać prosty skrypt, który załatwi to za nas (taki svncommitwithcakeschemagenerate.sh ;))

Ciągle mam problem ze złym podejściem do produktu jakim jest oprogramowanie. Dlatego będę pisał o tym pewnie za każdym razem, gdy da mi się we znaki. Jak zwykle zpróbuję opisać to na przykładzie.

Załóżmy, że pytasz mnie ile czasu pracy jednego programisty zajmnie gdyby miał zaprogramować:

- Prosty blog
 Ja odpowiem, że dwa miesiące.
- Galerię zdjęć
Ja również odpowiem, że dwa miesiące.

Jeśli uważasz, że to wystarczające szacowania i gdybyś chciał dostać system, który ma funkcjonalności kryjące się pod hasłem “Prosty blog” i “Galeria zdjęć”, oszacujesz już sobie sam, że to razem 4 miesiące…

Otóż jesteś w błędzie. Ten nowy system zajmie więcej czasu.

Jeśli uważasz, że przypisując czterech programistów do tego projektu czas jego wykonania skróci się czterokrotnie – również się pomyliłeś. Zapomniałeś o tym, że nie zawsze można podzielić projekt na kilka niezależnych elementów, które można implementować współbierznie. Nawet gdyby się dało – ktoś musi odwalić tą robotę, odpowiednio zaprojektować i koordynować współbierzną implementację.

Dlatego jeśli jesteś menadżerem, kierownikiem projektu, sponsorem lub klientem – oddasz przysługę wielu ludziom, jeśli przestaniesz traktować tworzenie oprogramowania jak skręcanie długopisów.
Nam zaoszczędzisz nerwów i wrzodów na żałądku, a sobie – rozczarowań.

Czym jest motywacja, a czym odpowiedzialność społeczna?

Motywowanie pracowników- w czym się przejawia?

Dlaczego zatem etyka czasem się nam gubi?

Związek społeczeństwa z przedsiębiorstwem.

Jak promować etykę?

1. “Propagowanie dobrych wzorów, “budujących” przykładów. Powszechnie znane jest postępowanie znanego
   menadżera, który w najgorszym dla Chryslera roku, jako szef koncernu zredukował wysokość swojej pensji do jednego dolara rocznie” – moim zdaniem najlepsza i najtańsza. Ci którzy mają szczęście doświadczać potrzeby etycznego postępowania muszą dawać (i niejako „siłą rzeczy” dają) dobry przykład.
2. “Stanowcze potępianie nieetycznych zachowań. ” Co oznacza zdefiniowanie kodeksu etycznego i definitywne jego przestrzeganie.
3. “Powołanie sądownictwa polubownego”, które jest świetnym sposobem na budowanie więzi społecznych. Do tego społecznie akceptowana instytucja arbitra będzie idealna do realizowania punktu poprzedniego.
4. “Treningi wrażliwości etycznej. ” dla tych, którzy nie mieli szczęścia tej wrażliwości się wyuczyć¹¹.
   Miałaby ona polegać na przedstawianiu pozytywnych przykładów etycznego postępowania, które odniosły pożądany skutek. Dietl i Gasparski proponują również nawyk stawiania się po drugiej stronie. Można to nazwać nauką „menadżerskiej empatii”.

Czym tak w ogóle jest etyka?

Powyższy tekst to praca zaliczeniowa na przedmiot “Etyka w biznesie”, napisana w połowie 2008 roku. Bardzo ciekawie i inspirująco wykładany przez dra Leopolda Zgodę. Jego wykłady otworzyły mi oczy na to, czego do tej pory nie widziałem (choć może gdzieś pod skórą czułem). Postanowiłem się tym tekstem podzielić (tym bardziej, że został on dobrze przez doktora oceniony :))

Od jakiegoś czasu używamy Subversion i pewnie jest o niebo lepiej niż by było bez tego narzędzia, ale dalej jest cholernie ciężko. Szczególnie wtedy, gdy Ciągle wprowadzane są poprawki w bazie. Bywa tak, że mam trzy wersje do synchronizacji: developerską, do testów wewnętrznych i do testów klienta.

Druga zazwyczaj generuje typową ilość znalezionych bugów, a potem sporą ilość ‘feature requests’ (przegląda ją między innymi manager projektu, który ma dobre pomysły jak usprawnić pracę w systemie; sęk w tym, że poważnie utrudniają one pracę nad systemem).
Trzecia z kolei generuje szum pt. ‘na stronie X, link Z jest w nie takim foncie jak potrzeba’ i inne problemy ;)

*Razem tworzą żyzne środowisko, z którego co jakiś czas wylęgają się pomysły wymagające zmiany struktury bazy danych.

**Wszystkie trzy wersje są update’owane w różnych momentach, do różnych wersji repozytorium.

Z * i ** wynika, że powinno się zdarzać (i zdarza, a jak!), że na każdej wersji systemu jest inna wersja bazy danych.

Jeszcze nie koniec.

W teamie mam pewną ilość programistów, którzy nie rozwinęli jeszcze umiejętności polegającej na pisaniu kodu w taki sposób, aby był on jak najbardziej elastyczny (dzięki wszystkim bogom za CakePHP, bo przy przenoszeniu systemu na serwer klienta przepisywalibyśmy wszystkie linki… aż mnie ciarki przeszły). Jednocześnie nie mogę ich za to zdyscyplinować – przecież nie dostali żadnych wytycznych jak pisać kod (kto próbował coś takiego napisać, ten wie…)

No i to w sumie wystarczy, żeby przy końcówce projektu mieć poczucie braku kontroli.

Jednak jest pewne światełko w tunelu (nikt nie wyłączył z powodu kryzysu;)), o którym napiszę w następnym poście…
Niektóre wskazówki znajdziesz wponiższych postach:

• Zarządzanie wersjami struktury bazy danych 
• ImageBehavior – pliki w bazie, a jednak na dysku