Zasady technicznej organizacji projektów programistycznych

Zasady technicznej organizacjiprojektów programistycznych

Jarosław Rzeszótko // [email protected]

Tutoria GmbH

Styczeń 2015

Jarosław Rzeszótko // [email protected] Tutoria GmbHZasady technicznej organizacji projektów programistycznych

Programowanie jest łatwe

O ile jedynym wymaganiem jest ”to ma działać”, to dzięki dostępności:

wygodnych języków programowania wysokiego poziomu

zintegrowanych środowisk programistycznych

wielkiej ilości gotowych bibliotek programistycznych

błyskawicznej i łatwej do otrzymania zewnętrznej pomocy (StackOverflow itp.)

programowanie jest naprawdę łatwe!


Programowanie jest trudne

Problemy pojawiają się wraz z:

Ewolucją modelu biznesowego i wymagań

Postępującą w czasie rozbudową projektu i akumulacją kodu

Wzrostem popularności projektu i co za tym idzie liczby użytkowników

Rozrostem zespołu programistycznego

Rozrostem infrastruktury(liczby serwerów, liczby krajów w jakiej działa projekt, itp.)

Nieuchronną w perspektywie paru lat rotacją członków zespołu


Programowanie jest trudne

W wyniku działnia tych czynników, prawie każdy projekt programistyczny napotykapewne podstawowe problemy:

Pogmatwanie fundamentalnej logiki biznesowej

Stale rosnący czas potrzebny na wykonywanie bieżących zmian

Stale rosnący czas potrzebny na wdrożenia nowo zatrudnianychprogramistów/programistek

Rosnącą liczbę błędów

Częste awarie

Wolne i niestabilne działanie aplikacji pod obciążeniem


Czym jest techniczna organizacja projektu?

Przez techniczną organizację projektu rozumiem działanie mające na celu optymalizacjejego jakości od strony inżynieryjnej, to jest sumy poniższych jego cech:

Poprawności i zgodności z wymaganiami

Niezawodności

Wydajności

Przejrzystości dla osób dotychczas niezwiązanych z projektem

Łącznego długoterminowego kosztu


Czym jest techniczna organizacja projektu?

Techniczna organizacja projektu odbywa się w obliczu ograniczonych zasobówczasowych, finansowych oraz ludzkich

Wobec tego nie chcemy ściśle rzecz biorąc jedynie podnosić jakości inżynieryjnejw jakikolwiek sposób

Chcemy dokonywać jej ciągłej ”metaoptymalizacji”, to jest:

Identyfikować czynniki, które mają na nią w danej chwili największy pozytywny lubnegatywny wpływ

Znajdować konkretne sposoby na optymalizację tych czynników

Wdrażać te sposoby poczynając od tych które dają największe ogólne zyski w stosunkudo wysiłku ich wdrożenia

Ta prezentacja jest próbą identyfikacji kilku takich właśnie ważnych czynników,które wydają się być wspólne dla wielu projektów


Przywiązuj wagę do czytelnego układu katalogów

Układ katalogów jest najbardziej podstawową metodą komunikacji podziału całegosystemu na niezależne moduły

Chaotyczny układ katalogów praktycznie uniemożliwia zrozumieniewysokopoziomowej architektury systemu, a w zasadzie często oznacza jej brak

Dobre drzewo katalogów nie jest ani zbyt głębokie (zbyt wiele poziomówzagnieżdżenia), ani zbyt szerokie (zbyt wiele plików w jednym katalogu)


Mądrze zarządzaj zależnościami

Automatyzuj zarządzanie zależnościami

Pieczołowicie dokumentuj zależności

Gdzie są używane

Jeśli ustawiona jest konkretna wersja, dlaczego?

Linkuj powiązane zgłoszenia na GitHub, pull requesty, itp.

Unikaj jak ognia modyfikowania zewnętrznych zależności przez monkey patching lubprzez włączenie zależności w główne repozytorium

Zamiast tego zgłaszaj błędy i pull requesty w orginalnym projekcie



Słaby Gemfile:

gem 'rails', '3.0.18'gem 'capistrano'gem 'eventmachine', '1.0.0.beta.3'gem 'will_paginate', '3.0.pre2'gem 'daemons', '1.1.4'gem 'gabba', :path => './vendor/gems/gabba'gem 'browser', :path => './vendor/gems/browser'gem 'calendar_date_select',

:git => 'git://github.com/paneq/calendar_date_select',:branch => 'rails3test'

...



Dobry Gemfile:

# Geocodinggem 'geocoder'

# PDF documents generation (for receipts, for example)gem 'prawn'gem 'prawn-table'

# Excel documents generation (statistical reports, etc.)gem 'spreadsheet'

# Trigger Google Analytics events from server side# Switch back to upstream after 0.0.5 is releasedgem 'staccato', git: 'git://github.com/tpitale/staccato'

# DelayedJobgem 'delayed_job'# Revert to upstream after 4.0.3 release:# https://github.com/collectiveidea/delayed_job_active_record/issues/99gem 'delayed_job_active_record',

github: 'collectiveidea/delayed_job_active_record'


Minimalizuj infrastrukturę

Więcej klocków - bardziej profesjonalna architektura? Nie!

Działa wolno, potrzebny nowy klocek? Rzadko! Co zmierzyłeś?

Każdy nowy komponent infrastruktury: baza danych, serwer proxy, cache, ... towiększe prawdopodobieństwo awarii.

To także konieczność zorganizowania i utrzymywania:

Monitorowania i narzędzi pomiarowych

Backupu

Failover-u


Maksymalizuj wykorzystanie istniejącej infrastruktury

Tymczasem, niektóre popularne komponenty infrastruktury oferują bogate, rzadkowykorzystywane możliwości

Na przykład, w zakresie funkcji PostgreSQL oferuje:

Silnik wyszukiwania pełno tekstowego (tsearch)

Bazę płaskich dokumentów o wydajności porównywalnej do MongoDB (hstore)

Indeksowane zapytania na dokumentach JSON (typ jsonb)

Indeksowane zapytania geograficzne (moduły cube, earthdistance, PostGIS)

Funkcje kryptograficzne (moduł pgcrypto)

...

Wszystko to w ramach jednego procesu, wspólnego monitorowania, backup-u ifailover-u, z tymi samymi metodami wykonywania pomiarów i tak dalej


Nie twórz własnej infrastruktury

Jeżeli uważasz, że w ramach komercyjnego projektu świetnym pomysłem będzierozwinięcie własnej:

bazy danych

serwera www

systemu kryptograficznego

...

to prawdopodobnie jesteś w bardzo dużym błędzie

Jak to się kończy?http://www.anton-pirker.at/the-big-rewrite-war-story/


http://www.anton-pirker.at/the-big-rewrite-war-story/


Udane projekty w tej przestrzeni są wynikiem:

Wieloletniej pracy dziesiątków, często setek ludzi

Biegłej znajomości teorii podlegającej danemu zastosowaniu

Tysięcy popełnionych i naprawionych błędów



Jeśli naprawdę jesteś przekonana/przekonany, że masz świetny pomysł, to:

Wydziel osobne repozytorium

Zaprogramuj swój pomysł

Dokładnie udokumentuj przynajmniej cały zewnętrzny interfejs tego programu

Udostępnij projekt jako Open Source

Przekonaj trzy niepodległe Ci osoby do jego używania

Przekonaj się, że nikt nie chcę tego używać

Usuń to repozytorium i ogarnij się


Znaj wartość pisemnej dokumentacji

O skomplikowanych procesach i systemach po prostu nie da się z dobrym skutkiemwyłącznie rozmawiać

Ważne systemy, komponenty, procedury i standardy które nie zostały pisemniewyspecyfikowane, nie są też raczej wysokiej jakości

Praca domowa:

Znajdź trzy ważne, często używane metody w swoim projekcie

Napisz do każdej z nich dokumentacje np. na wzór dokumentacji API Rails

Czy nie nasuwa Ci się wiele pomysłów na usprawnienia?


Znaj wartość pisemnej dokumentacji

Patrz też:

Matematyka, fizyka i inżynieria

Leslie Lamport, “Thinking for programmers”https://www.youtube.com/watch?v=4nhFqf_46ZQ


https://www.youtube.com/watch?v=4nhFqf_46ZQ

Identyfikuj i dokumentuj “fundamenty” projektu

Jedynym z podstawowych warunków udanej pracy zespołowej jest obecnośćdokumentacji najważniejszych:

Serwerów i systemów

Komponentów programistycznych

Procedur (korzystania z kontroli wersji, code review, zgłasznia propozycji zmian)

Standardów (dla wszystkich używanych technologii)

Jest to jedyny sposób upewnienia się, że cały zespół posiada:

Wspólne, pełne zrozumienie najbardziej podstawowych aspektów całego projektu

Jednolite, systematyczne i efektywne podejście do pracy

http://c2.com/cgi/wiki?ConceptualIntegrity


http://c2.com/cgi/wiki?ConceptualIntegrity

Pisz czytelną dokumentację

Stosuj zdania

Wszyscy wielcy pisarze je stosowali...



Unikaj “ściany tekstu”

Długie paragrafy ciągłego tekstu będą po prostu ignorowane

Pisz krótkie, zrozumiałe zdania...

... ale nie stosuj skrótów innych niż najbardziej powszechnie znane

Kiedy usunięcie któregokolwiek ze słów z któregokolwiek ze zdań wypacza jego senslub czyni je niegramatycznym, osiągnąłeś cel

Patrz też:

Strunk & White, “The elements of style”



Myśl o swoim docelowym odbiorcy

Decelowy odbiorca Twojej dokumentacji posiada oczywiście mniej informacji na temato którym piszesz, niż Ty

Pisanie dokumentacji która nie jest odbierana jako wyrwana z kontekstu wymagaświadomego wysiłku

Nie pisz w pośpiechu i staraj się tłumaczyć “od początku” ...

... zwłaszcza jeśli zgłaszasz błąd w zewnętrznym projekcie

Ilustruj każde ogólne sformułowanie przynajmniej jednym konkretnym przykładem



Nadaj tekstowi klarowną strukturę wizualną

Dokumenty techniczne częściej są przeglądane niż czytane od początku do końca

Naprzemienne czytanie kodu i zwięzłego tekstu o wyraźnej strukturze, jest znaczniełatwiejsze niż czytanie kodu na przemian z jednostajną, “powieściowej” prozą

Stwórz wyraźną hierarchię: nagłówki, podnagłówki, sekcje, paragrafy, przykłady

Używaj list wypunktowanych do wyliczeń, tabel i wykresów do prezentowania danychZnaj możliwości swoich narzędzi:

W wiki, trackerach itp. stosuj podświetlanie składni, zwijane bloki kodu itp.

W kodzie korzystaj z możliwości RDoc

Niech to jakoś wygląda!

Patrz też:

“Grid Systems in Graphic Design”, Josef Müller-Brockmann“Elementarz stylu w typografii”, Robert Bringhurst“Detal w typografii”, Jost Hochuli


Klarownie organizuj dokumentację

Podstawowe dokumenty zorganizuj w Wiki, w formie drzewa, na przykład:Standardy programistyczne

Ogólne zasadyKod w RubyModele RailsKontrollery RailsWidoki RailsSQLHTML/CSS...

ProcesyKontrola wersjiAktualizowanie serwerów...

PrzewodnikiKorzystanie z GitPisanie wydajnego koduZgłaszanie zmian do istniejących GemówTworzenie Gemów...


Klarownie organizuj dokumentację

Dokumentacja mocno powiązana z kodem źródłowym powinna być częściąrepozytorium

Dotyczy to dokumentacji m. in.:

Układu katalogów

API dla najważniejszych obszarów logiki biznesowej

API dla najczęściej używanych komponentów ogólnego przeznaczenia

...

https://github.com/voloko/sdoc


https://github.com/voloko/sdoc

Twórz standardy dla wszystkich używanych języków

W dłuższym horyzoncie czasowym brak standaryzacji dla jakiejkolwiek technologiiprędzej czy później powoduje poważne problemy.

Podstawę może stanowić któryś z istniejących standardów:

https://github.com/narkoz/guides


https://github.com/narkoz/guides

Standaryzuj użycie kontroli wersji

Wrzucanie zmian w Git-a to nie jest jeszcze kontrola wersji

Sensowna kontrola wersji to:

Logicznie oddzielne zmiany w oddzielnych commitach

Dokładne, czytelne opisy commitów dokumentujące kontekst dla dokonanych zmian

Używanie właściwych branchów dla właściwych zmian


Edukuj (siebie i innych) w zakresie pracy zespołowej

Aby zespół programistyczny mógł tworzyć wysokiej jakości, spójne projekty, wszyscyprogramiści muszą posiadać dwie podstawowe umiejętności:

Umiejętność przygotowania swojego kodu do użytku i rozbudowy przez inne osoby

Umiejętność analizy istniejącego kodu pod kątem jak najlepszego dopasowaniazamierzonych zmian do zamysłów oryginalnego autora tego kodu


Edukuj (siebie i innych) w zakresie pracy zespołowej

Bierz udział (i zachęcaj do brania udziału) w projektach Open Source

Udane wprowadzenie zmiany w którymś z dojrzałych, uznanych projektówOpen Source wymaga od programisty:

Konkretnego pomysłu i jasnego jego zakomunikowania

Lektury wskazówek dotyczących wprowadzania zmian (“Contributing guidelines”)

Sensownego podziału wprowadzanej zmiany na commity i dobrego ichudokumentowania

Dostosowania swojego kodu do stylu projektu

Nabyte w ten sposób umiejętności są bezcenne również w komercyjnym projekcie

Udane zmiany na uznanych projektach Open Source stanowią wobec tego lepsząreklamę programisty niż najpiękniejsze z CV


Ważne decyzje podejmuj metodycznie

Niejednokrotnie błędnie podjęta decyzja projektowa skutkuje miesiącami czy wręczlatami zmarnowanego i zbędnego wysiłku implementacyjnego

Rozpoznanie kiedy mamy do podjęcia decyzje o tak dużych potencjalnychkonsekwencjach jest sztuką w samą sobie

Niestety często decyzje te, nawet jeśli zostały rozpoznane jako ważne, sąpodejmowane na zasadzie:

“widzimisię”

“lubie bo znam” / ”nie lubie bo nie znam”

“lubie bo fajna składnia”

“kolega używał”

Jest to jedno z podstawowych źródeł problemów projektów programistycznych



Następujące, przykładowe decyzje mają najczęściej daleko idące konsewkencje:Wybór technologii programistycznych

Języka programowaniaBazy danychBibliotek...

Wybór infrastrukturyLiczby serwerówRodzaju serwerówRozmieszczenia usług pomiędzy serwerami...

Projekt wysokopoziomowej organizacji koduUkładu katalogów, konwencji nazewniczych i używanych wzorców projektowychDokładnego kształtu najbardziej ogólnych i najczęściej używanych modułów...



Wszystkie ważne decyzje projektowe tego typu muszą być ugruntowane w:

Jasno i precyzyjnie sformułowanych wymaganiach

Wymagania które nie są od początku dokładnie znane, należy zastąpić wspólniedokonanymi oszacowaniami i przedziałami

Szacowanie to nie to samo co zgadywanie i myślenie życzeniowe

Wiedzy teoretycznej z zakresu informatyki, m. in.:

Algortymów

Architektury komputerów

Systemów operacyjnych

Systemów rozproszonych

Baz danych

...



Wszystkie ważne decyzje projektowe muszą być ugruntowane w:

Praktycznym doświadczeniu w stosowaniu szerokiego wachlarza technologii

Prototypujcie!

Udanych istniejących wdrożeniach danego pomysłu czy technologii

Np. w projektach Open Source

Eksperymentach (metoda naukowa)

Hipoteza

Eksperyment

Pomiar

Statystyka!



W procesie podejmowania decyzji powinny:

Brać udział conajmniej dwie osoby

Zostać udokumentowane i upublicznione:

Znane wymagania oraz oszacowania nieznanych czynników

Rozważone alternatywy, ich za i przeciw

Wykonane eksperymenty, prototypy i testy



Argumentacja stojąca za ostateczną decyzją również powinna być jasno opisana,upubliczniona i znana wszystkim członkom zespołu

Zespół musi być świadomy, że decyzja została podjęta racjonalnie, a nieargumentem przez autorytet

Dokumentacja pozwala porównać późniejszy rzeczywisty obrót spraw z projektem istale usprawniać proces podejmowania decyzji



Przykłady ilustrujące racjonalny proces projektowy w działaniu:

Propozycja dodania funkcji generowania bezpiecznych tokenów do ActiveRecord:https://github.com/rails/rails/issues/16879


https://github.com/rails/rails/issues/16879


Metodologia podejmowania decyzji i zgłaszania zmian, na którą zgodził sie zespół,powinna sama w sobie również zostać udokumentowana

Przykłady:https://wiki.postgresql.org/wiki/Submitting_a_Patchhttps://wiki.postgresql.org/wiki/Reviewing_a_Patch


https://wiki.postgresql.org/wiki/Submitting_a_Patch

https://wiki.postgresql.org/wiki/Reviewing_a_Patch

Mierz i rządź

Ucz się dokonywać pomiarów i porównywać różne podejścia i implementacje

John Carmack o równoległych implementacjach:https://web.archive.org/web/20140719065227/http://www.altdev.co/2011/11/22/parallel-implementations/


https://web.archive.org/web/20140719065227/http://www.altdev.co/2011/11/22/parallel-implementations/

https://web.archive.org/web/20140719065227/http://www.altdev.co/2011/11/22/parallel-implementations/

Czerp inspiracje z udanych projektów

https://github.com/torvalds/linux/tree/master/Documentation/development-process

https://github.com/torvalds/linux/blob/master/Documentation/ManagementStyle

https://github.com/torvalds/subsurface/blob/master/README(Sekcja “Contributing”)

https://wiki.postgresql.org/wiki/Development_information

http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html

http://contribute.jquery.org/






https://github.com/torvalds/subsurface/blob/master/README

https://wiki.postgresql.org/wiki/Development_information

http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html

http://contribute.jquery.org/

Praca

Zapraszamy do pracy z nami

Szukamy jednego programisty z min. 2 latami doświadczenia w Rails

Rails 4.2, Ruby 2.2, RSpec 3, PostgreSQL

55-65 złotych brutto za godzinę pracy (średnio 9 000 - 11 000 złotych miesięcznie)

mailto:[email protected]


mailto:[email protected]

Zasady technicznej organizacji projektów programistycznych

Engineering

Transcript of Zasady technicznej organizacji projektów programistycznych