Zarządzanie złożonością - czyli jak budować, żeby nie żałować. Będzie to o strukturze aplikacji, narzędziach, metodologiach w zastosowaniu, czyli w sumie wszystkiego po trochu co trzeba wziąć pod uwagę rozpoczynając projekt.
Marek Gajda - Pi razy drzwi
Prezentacja z Uszanowanka Programowanka #9 - uszanowanko.pl
Każdy programista przynajmniej raz w życiu usłyszy magiczne słowa “Mam taki projekt… Ile to zajmie?”. Jak radzić sobie z odpowiedzią, kiedy nie mamy jeszcze wszystkich szczegółów, a jedynie ogólny zarys tego, co trzeba wykonać? Jak wróżyć z fusów skoro najczęściej pijemy kawę z ekspresu? Podzielę się swoimi doświadczeniami z szacowania projektów.
Zarządzanie złożonością - czyli jak budować, żeby nie żałować. Będzie to o strukturze aplikacji, narzędziach, metodologiach w zastosowaniu, czyli w sumie wszystkiego po trochu co trzeba wziąć pod uwagę rozpoczynając projekt.
Marek Gajda - Pi razy drzwi
Prezentacja z Uszanowanka Programowanka #9 - uszanowanko.pl
Każdy programista przynajmniej raz w życiu usłyszy magiczne słowa “Mam taki projekt… Ile to zajmie?”. Jak radzić sobie z odpowiedzią, kiedy nie mamy jeszcze wszystkich szczegółów, a jedynie ogólny zarys tego, co trzeba wykonać? Jak wróżyć z fusów skoro najczęściej pijemy kawę z ekspresu? Podzielę się swoimi doświadczeniami z szacowania projektów.
Łukasz Łuczak
Language: Polish
Klienci lubią zmieniać zdanie, jeśli klient mówi, że dana aplikacja nie będzie równolegle użytkowana przez wielu użytkowników to na pewno będzie. To można przewidzieć ale co w przypadku gdy część z tych użytkowników będzie potrzebowała korzystać z niej offline, synchronizując dane z częścią centralną kiedy powrócą online? A co w przypadku kiedy nagle klient postanawia aplikacje zamówioną do użytku wewnętrznego sprzedawać? Rok developmentu projektu w PHP'ie z wykorzystaniem frameworka Zend Framework 2 oraz biblioteki Doctrine 2 a klient wywraca całkowicie architekturę do góry nogami a do tego neguje słuszność wyboru technologii. Można powiedzieć, że się nie da a można spróbować podjąć wyzwanie.
Chciałbym przedstawić zakres zmian jakie musieliśmy wprowadzić w projekcie, a także przedstawić cały proces modyfikacji aplikacji od rozwiązania gdy jest całkowicie online, przez rozwiązanie wspierające offline, a dalej przez możliwość sprzedaży produktu klientom by wreszcie zrobić z tego rozwiązanie boksowe dystrybuowane na Raspberry Pi.
Wśród poruszonych tematów będą: optymalizacja aplikacji napisanych z wykorzystaniem ZF2, Doctrine 2, audyt logi i synchronizacja danych, live update danych, zabezpieczanie aplikacji PHP'owej, rozdzielanie aplikacji niepodzielnej. przygotowywanie paczki dystrybucyjnej a także przygotowanie całego stosu by działał poprawnie na Raspberry Pi.
Girls in It - Front-end & Back-end. Jak zacząćmonterail
“Girls in IT” to cykl spotkań dla kobiet, które mają na celu pokazać od kuchni jak wygląda praca w firmie technologicznej i pomóc im podjąć właściwą decyzję na temat kariery zawodowej.
W pierwszej części, przeznaczonej dla przyszłych Front-end Developerek, opowiemy na czym polega tworzenie strony internetowej i podzielimy się listą niezbędnych źródeł dla początkujących.
Druga część zawiera praktyczne informacje dotyczące Backend development'u. Przedstawimy specyfikę pracy na tym stanowisku, dobre praktyki, a także cenne wskazówki od naszych ekspertek.
https://www.youtube.com/watch?v=ww36brBuxU8
4Developers 2015: Jak przekonać managera, że czas na refaktoring jest potrzeb...PROIDEA
Sebastian Łaciak
Language: Polish
Jest tysiące powodów dla których nasze projekty mogłyby być lepsze a świat dzięki temu piękniejszy. Niestety często na drodze stoi manager i brak czasu na pielęgnowanie kodu. Podczas sesji postaram się przekonać Was, że nie stoimy na pozycji przegranej oraz podam wiele argumentów, których będziecie mogli użyć po powrocie do biura. Poruszony zostanie również temat roadmapy.
4Developers 2018: Sagi na frontendzie - czyli jak ułatwić sobie pracę ze skom...PROIDEA
Asynchroniczność przestała być dodatkiem, a stała się mechanizmem bez którego nie wyobrażamy sobie budowy aplikacji. Możemy do tego podejść na różne sposoby.
Możemy albo utknąć w "callback hellu" albo poszukać czegoś co umożliwi nam pisanie czytelnego, łatwego w utrzymaniu a zarazem prostego kodu, który dodatkowo bez najmniejszych przeszkód możemy testować.
Jak zredukować efekty uboczne związane z pobieraniem, przetwarzaniem danych, dostępem do cache’a na rzecz prostej integracji z popularnymi frontendowymi bibliotekami takimi jak redux? Jak modelować skomplikowane transakcje biznesowe wymagające synchronizacji wielu kroków?
Podczas mojej prezentacji opowiem na bazie doświadczeń w projektach komercyjnych jak sagi oraz generatory wykorzystane w bibliotece redux-saga mogą poprawić czytelność Twojego kodu, ułatwić jego testowanie, oraz oszczędzić Twój cenny czas.
O tym jak realizowane są projekty w branży internetowej, dlaczego przypomina to czasem jazdę bez trzymanki w ekstremalnych warunkach i jak sobie z tym radzić. Prezentacja wygłoszona podczas konferencji NetVision'13
Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
Refactoring - Jak pozostać przy zdrowych zmysłach, redukując długMax Małecki
Pracowałem przy wielu projektach, które to miały specyfikę totalnie zadłużonych. W prezentacji podzielę się 14 latami moich doświadczeń i zmagań z długiem technicznym w projektach small & medium business. Odpowiem jak my sami się godzimy na wprowadzenie długu technicznego do projektu. Opowiem jak go trzymać w ryzach i monitorować. Dam przykłady narzędzi do monitorowania miejsc w kodzie, które są potencjalnymi nosicielami długu technicznego. Podam gotowy przepis jak wprowadzić do work-flow walkę z długiem technicznym.
Agenda warsztatów przygotowanych dla ProductTank:
1. Metoda OKR: podstawowe elementy i opis działania w organizacji
2. Określanie celu i kluczowych miar - ćwiczenie i omówienie wyników
3. OKRy i Rozwój produktu - praca warsztatowa nad możliwymi powiązaniami backlogu i celów biznesowych
Tomasz Bienias
Tomasz jest znawcą metodyki OKR. Prowadzi szkolenia i pomaga firmom wdrażać podejście. Już w 2015 roku jako członek kierownictwa segmentu internetowego Agory wprowadzał ją w zespołach biznesowych skupiających ponad 200 osób. Przez 15 lat kariery zawodowej odpowiadał za produkty internetowe, design i UX, project management, a po transformacji za pracę zespołów produktowych oraz technologię.
Stworzył stronę Okry.pl, która jest darmowym kompendium wiedzy o metodyce. Od 2004 roku pisze bloga "Tebe Gada" o User Experience, rozwoju produktów cyfrowych i zarządzaniu. Pasjonują go nowoczesne organizacje i systemy, w których autonomiczne zespoły zaangażowanych ludzi współpracują ze sobą dążąc do wspólnego celu.
Jerzy Stawicki
Jerzy jest konsultantem, trenerem i coachem w dziedzinie zarządzania oraz zarządzania projektami, programami i portfelem projektów. Prowadzi warsztaty i szkolenia oraz uczestniczy w projektach zmian organizacyjnych i transformacji firm i zespołów w duchu Agile i Management 3.0.
Posiada 25-letnie doświadczenie w zarządzaniu i zarządzaniu projektami, jako menedżer zespołów konsultantów, kierownik projektów wdrożeniowych systemu SAP i projektów doradczych, członek komitetów sterujących oraz audytor i asesor projektów.
Pasją Jerzego jest doskonalenie pracy organizacji, zespołów oraz kierowników projektów, tak by korzyści biznesowe powstawały dzięki samo-organizacji i upełnomocnieniu zespołów oraz strategicznej roli menedżerów. Jest promotorem nowoczesnych metod i technik zarządzania i samoorganizacji.
Przez kilkanaście lat pracy zawodowej wielokrotnie padłem ofiarą mitów i przejściowych trendów przemysłu IT. Bałem się wysłać CV na widok ściany wymagań. Wprowadzałem Scruma "na siłę", przepisywałem systemy od zera, budowałem wymyślną architekturę. Umknęło mi wiele ważnych rzeczy, na które dziś pragnę zwrócić Waszą uwagę. Opowiem jak możecie ruszyć swoją karierę "z kopyta" poprzez skupienie się na 20% rzeczy, które dadzą 80% rezultatów. Pokażę, jakie praktyki realnie pozwoliły mi osiągać duże sukcesy u klientów z całego świata.
Ślepe zaułki designu, czyli jak przestałem się bać i pokochałem preprodukcję.Artur Ganszyniec
Droga od idei do gotowej gry rzadko bywa usłana różami, nie wszystkim pomysłom i nie wszystkim projektom udaje się przetrwać do wydania. Jednym ze sposobów na zmniejszenie ryzyka jest dobre przygotowanie się do właściwej produkcji. Podczas prelekcji przyjrzymy się dokładniej preprodukcji i sposobom, dzięki którym można odpowiedzieć sobie na trzy ważne pytania: Czy nasz świetny pomysł rzeczywiście jest materiałem na świetną grę? Czy jest to projekt dla naszego zespołu? Jak duża będzie to produkcja? Życiowe przykłady z udanych i nieudanych projektów gwarantowane.
Code Camp NYC 2017 - How to deal with everything... | Chris Ozog - Codesushi Krzysztof (Chris) Ozog
Being rookie especially in PHP world means constantly dealing with legacy software that’s in maintenance mode and won't be rewritten. And you have to deal with awful codebase with files spanning over couple thousand lines.
I'm here to help, been there, done that and want to share with you with some tricks... how to get to know even oldest of systems.
21st-century problem… The cost of IT department!
In this lightning talk, I want to outline the problem of today's times - the cost of IT department.
Every company, every product, every department need them, but what is the real cost of their work. Step by step I will show it to the audience and stimulate discussion about these issues and possible ways to solve it.
Let's meet, talk and find optimization possibilities!
More Related Content
Similar to Jak uchronić Twój piękny kod przed destrukcyjnym wpływem klienta | Codesushi
Łukasz Łuczak
Language: Polish
Klienci lubią zmieniać zdanie, jeśli klient mówi, że dana aplikacja nie będzie równolegle użytkowana przez wielu użytkowników to na pewno będzie. To można przewidzieć ale co w przypadku gdy część z tych użytkowników będzie potrzebowała korzystać z niej offline, synchronizując dane z częścią centralną kiedy powrócą online? A co w przypadku kiedy nagle klient postanawia aplikacje zamówioną do użytku wewnętrznego sprzedawać? Rok developmentu projektu w PHP'ie z wykorzystaniem frameworka Zend Framework 2 oraz biblioteki Doctrine 2 a klient wywraca całkowicie architekturę do góry nogami a do tego neguje słuszność wyboru technologii. Można powiedzieć, że się nie da a można spróbować podjąć wyzwanie.
Chciałbym przedstawić zakres zmian jakie musieliśmy wprowadzić w projekcie, a także przedstawić cały proces modyfikacji aplikacji od rozwiązania gdy jest całkowicie online, przez rozwiązanie wspierające offline, a dalej przez możliwość sprzedaży produktu klientom by wreszcie zrobić z tego rozwiązanie boksowe dystrybuowane na Raspberry Pi.
Wśród poruszonych tematów będą: optymalizacja aplikacji napisanych z wykorzystaniem ZF2, Doctrine 2, audyt logi i synchronizacja danych, live update danych, zabezpieczanie aplikacji PHP'owej, rozdzielanie aplikacji niepodzielnej. przygotowywanie paczki dystrybucyjnej a także przygotowanie całego stosu by działał poprawnie na Raspberry Pi.
Girls in It - Front-end & Back-end. Jak zacząćmonterail
“Girls in IT” to cykl spotkań dla kobiet, które mają na celu pokazać od kuchni jak wygląda praca w firmie technologicznej i pomóc im podjąć właściwą decyzję na temat kariery zawodowej.
W pierwszej części, przeznaczonej dla przyszłych Front-end Developerek, opowiemy na czym polega tworzenie strony internetowej i podzielimy się listą niezbędnych źródeł dla początkujących.
Druga część zawiera praktyczne informacje dotyczące Backend development'u. Przedstawimy specyfikę pracy na tym stanowisku, dobre praktyki, a także cenne wskazówki od naszych ekspertek.
https://www.youtube.com/watch?v=ww36brBuxU8
4Developers 2015: Jak przekonać managera, że czas na refaktoring jest potrzeb...PROIDEA
Sebastian Łaciak
Language: Polish
Jest tysiące powodów dla których nasze projekty mogłyby być lepsze a świat dzięki temu piękniejszy. Niestety często na drodze stoi manager i brak czasu na pielęgnowanie kodu. Podczas sesji postaram się przekonać Was, że nie stoimy na pozycji przegranej oraz podam wiele argumentów, których będziecie mogli użyć po powrocie do biura. Poruszony zostanie również temat roadmapy.
4Developers 2018: Sagi na frontendzie - czyli jak ułatwić sobie pracę ze skom...PROIDEA
Asynchroniczność przestała być dodatkiem, a stała się mechanizmem bez którego nie wyobrażamy sobie budowy aplikacji. Możemy do tego podejść na różne sposoby.
Możemy albo utknąć w "callback hellu" albo poszukać czegoś co umożliwi nam pisanie czytelnego, łatwego w utrzymaniu a zarazem prostego kodu, który dodatkowo bez najmniejszych przeszkód możemy testować.
Jak zredukować efekty uboczne związane z pobieraniem, przetwarzaniem danych, dostępem do cache’a na rzecz prostej integracji z popularnymi frontendowymi bibliotekami takimi jak redux? Jak modelować skomplikowane transakcje biznesowe wymagające synchronizacji wielu kroków?
Podczas mojej prezentacji opowiem na bazie doświadczeń w projektach komercyjnych jak sagi oraz generatory wykorzystane w bibliotece redux-saga mogą poprawić czytelność Twojego kodu, ułatwić jego testowanie, oraz oszczędzić Twój cenny czas.
O tym jak realizowane są projekty w branży internetowej, dlaczego przypomina to czasem jazdę bez trzymanki w ekstremalnych warunkach i jak sobie z tym radzić. Prezentacja wygłoszona podczas konferencji NetVision'13
Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
Refactoring - Jak pozostać przy zdrowych zmysłach, redukując długMax Małecki
Pracowałem przy wielu projektach, które to miały specyfikę totalnie zadłużonych. W prezentacji podzielę się 14 latami moich doświadczeń i zmagań z długiem technicznym w projektach small & medium business. Odpowiem jak my sami się godzimy na wprowadzenie długu technicznego do projektu. Opowiem jak go trzymać w ryzach i monitorować. Dam przykłady narzędzi do monitorowania miejsc w kodzie, które są potencjalnymi nosicielami długu technicznego. Podam gotowy przepis jak wprowadzić do work-flow walkę z długiem technicznym.
Agenda warsztatów przygotowanych dla ProductTank:
1. Metoda OKR: podstawowe elementy i opis działania w organizacji
2. Określanie celu i kluczowych miar - ćwiczenie i omówienie wyników
3. OKRy i Rozwój produktu - praca warsztatowa nad możliwymi powiązaniami backlogu i celów biznesowych
Tomasz Bienias
Tomasz jest znawcą metodyki OKR. Prowadzi szkolenia i pomaga firmom wdrażać podejście. Już w 2015 roku jako członek kierownictwa segmentu internetowego Agory wprowadzał ją w zespołach biznesowych skupiających ponad 200 osób. Przez 15 lat kariery zawodowej odpowiadał za produkty internetowe, design i UX, project management, a po transformacji za pracę zespołów produktowych oraz technologię.
Stworzył stronę Okry.pl, która jest darmowym kompendium wiedzy o metodyce. Od 2004 roku pisze bloga "Tebe Gada" o User Experience, rozwoju produktów cyfrowych i zarządzaniu. Pasjonują go nowoczesne organizacje i systemy, w których autonomiczne zespoły zaangażowanych ludzi współpracują ze sobą dążąc do wspólnego celu.
Jerzy Stawicki
Jerzy jest konsultantem, trenerem i coachem w dziedzinie zarządzania oraz zarządzania projektami, programami i portfelem projektów. Prowadzi warsztaty i szkolenia oraz uczestniczy w projektach zmian organizacyjnych i transformacji firm i zespołów w duchu Agile i Management 3.0.
Posiada 25-letnie doświadczenie w zarządzaniu i zarządzaniu projektami, jako menedżer zespołów konsultantów, kierownik projektów wdrożeniowych systemu SAP i projektów doradczych, członek komitetów sterujących oraz audytor i asesor projektów.
Pasją Jerzego jest doskonalenie pracy organizacji, zespołów oraz kierowników projektów, tak by korzyści biznesowe powstawały dzięki samo-organizacji i upełnomocnieniu zespołów oraz strategicznej roli menedżerów. Jest promotorem nowoczesnych metod i technik zarządzania i samoorganizacji.
Przez kilkanaście lat pracy zawodowej wielokrotnie padłem ofiarą mitów i przejściowych trendów przemysłu IT. Bałem się wysłać CV na widok ściany wymagań. Wprowadzałem Scruma "na siłę", przepisywałem systemy od zera, budowałem wymyślną architekturę. Umknęło mi wiele ważnych rzeczy, na które dziś pragnę zwrócić Waszą uwagę. Opowiem jak możecie ruszyć swoją karierę "z kopyta" poprzez skupienie się na 20% rzeczy, które dadzą 80% rezultatów. Pokażę, jakie praktyki realnie pozwoliły mi osiągać duże sukcesy u klientów z całego świata.
Ślepe zaułki designu, czyli jak przestałem się bać i pokochałem preprodukcję.Artur Ganszyniec
Droga od idei do gotowej gry rzadko bywa usłana różami, nie wszystkim pomysłom i nie wszystkim projektom udaje się przetrwać do wydania. Jednym ze sposobów na zmniejszenie ryzyka jest dobre przygotowanie się do właściwej produkcji. Podczas prelekcji przyjrzymy się dokładniej preprodukcji i sposobom, dzięki którym można odpowiedzieć sobie na trzy ważne pytania: Czy nasz świetny pomysł rzeczywiście jest materiałem na świetną grę? Czy jest to projekt dla naszego zespołu? Jak duża będzie to produkcja? Życiowe przykłady z udanych i nieudanych projektów gwarantowane.
Code Camp NYC 2017 - How to deal with everything... | Chris Ozog - Codesushi Krzysztof (Chris) Ozog
Being rookie especially in PHP world means constantly dealing with legacy software that’s in maintenance mode and won't be rewritten. And you have to deal with awful codebase with files spanning over couple thousand lines.
I'm here to help, been there, done that and want to share with you with some tricks... how to get to know even oldest of systems.
21st-century problem… The cost of IT department!
In this lightning talk, I want to outline the problem of today's times - the cost of IT department.
Every company, every product, every department need them, but what is the real cost of their work. Step by step I will show it to the audience and stimulate discussion about these issues and possible ways to solve it.
Let's meet, talk and find optimization possibilities!
1. The presenter will discuss the history and modern state of PHP, using Symfony as an example. PHP originated in 1995 but had poor code quality until frameworks like Symfony emerged.
2. PHP 5.3 in 2009 introduced important features like namespaces and anonymous functions that allowed new frameworks like Symfony 2 to implement best practices. Symfony focuses on concepts like dependency injection, decoupling, and clean code.
3. PHP and Symfony have matured significantly. PHP 7 and Symfony's influence have made PHP a viable choice for web development, despite its reputation in earlier eras of "spaghetti code". The presenter argues it is worth
This document discusses parallel development approaches for web apps. A standard approach involves implementing endpoints sequentially after defining user stories. A parallel approach involves frontend and backend determining endpoints together upfront. They then use tools like Apiary, Symfony, or Json-server to create mock APIs so frontend and backend can work simultaneously. This allows attacking on multiple fronts and creates less blocking, enabling developers to build a minimum viable product faster. The document provides examples of when different tools are useful and concludes with a case study where using parallel development delivered a new product in 3 months versus 12 months previously.
How to create a WordPress not understanding WordPress, so more on the headles...Krzysztof (Chris) Ozog
This document discusses the headless approach to WordPress development. It begins with introductions and then outlines the agenda which includes: defining the headless approach, advantages like using any frontend technology, disadvantages like losing some WordPress capabilities, and a step-by-step process including installing WordPress configured for headless and building a PHP frontend app. The document promotes the headless approach as allowing WordPress to act as just a content management system with any technology used on the frontend, communicating via API.
1. Asynchronous PHP is possible using options like PThreads or forks to allow non-blocking operations.
2. Asynchronous PHP can be useful for applications that spend a lot of time waiting, like websockets.
3. ReactPHP is a popular option for asynchronous PHP that uses a reactor pattern similar to Twisted or Node.js and includes Ratchet for websockets support.
The automation of the process of caring for the quality of the code in PHP an...Krzysztof (Chris) Ozog
This document discusses tools for automating code quality checks in PHP and JavaScript. It begins with an overview of the history of code quality, from unstructured "spaghetti code" to standardized practices. It then covers generally accepted practices like DRY principles. The document outlines PHP standards like PSR-0/4 and tools like PHP CodeSniffer and PHP Mess Detector. Similar JavaScript standards and tools are covered, including JSLint, JsHint, and ESLint. It emphasizes integrating these tools with editors and continuous integration systems to automatically enforce code quality standards.
How to protect your code against a destructive influence of client | Codesush...Krzysztof (Chris) Ozog
The document discusses how to protect code from a destructive client influence. It recommends (1) correctly communicating with the client and planning for refactoring time, (2) introducing rules like SOLID for code creation, and (3) performing code reviews by outsiders and using PHP tools like Mess Detector and Code Sniffer. The goal is to maintain responsibility for the code quality and prevent a good start from leading to a bad finish due to changes.
This document discusses daemons and how to create them in PHP and Symfony. It begins with some background about the speaker and defines what a daemon is. It then outlines that daemons are useful for processes that run more frequently than every minute, like websockets or socket protocols. Typically daemons are created by forking processes or using OS tools like upstart scripts. The document demonstrates creating a simple looping daemon in PHP and discusses its issues, and then shows how to properly create daemons using forking or upstart scripts. It also introduces a Symfony bundle that provides an interface for creating daemonized console commands. In the end it notes some things to consider for long-running daemon
This document summarizes and compares several online development environments: Nitrous, Codio, Koding, and Cloud9. It finds that Nitrous is the best fit overall as it allows users to create and share cloud virtual machines while also using local tools through the Atom text editor plugin, and provides templates for common languages and frameworks. While the others have advantages like configuration sharing for Koding or being designed for teaching for Codio, they lack the ability to use local tools like Nitrous or share built machines like Koding.
Speed up your zombies! - Bootstrap dev environment in 5 minutes!
Jak uchronić Twój piękny kod przed destrukcyjnym wpływem klienta | Codesushi
1. Jak uchronić Twój piękny kod
przed destrukcyjnym wpływem klienta
Chris Ozog - Codesushi CTO
2. Agenda:
● Coś o mnie...
● Żaden kod nie jest pisany z myślą o tym, że będzie zły
● Czy leci z nami pilot? Ty tworzysz kod czy Twój klient?
● I co dalej? Czyli trochę o odpowiedniej komunikacji i
jasnym przekazie!
● Droga miękka - odpowiedni mindset
● Droga twarda - narzędzia które nam w tym pomogą
● Nie od razu Rzym zbudowano! Czas na refactoring to czas
na wagę złota
● Podsumowanie
3. Coś o mnie...
● Od ponad dekady twórca aplikacji
webowych
● Uzależniony od czystego kodu
● Lider techniczny w Codesushi
● CodeReviewer z zamiłowania
● Filozof i Developer w jednym…
co gorsze, jest to udokumentowane dwoma dyplomami
4. Żaden kod nie jest pisany
z myślą o tym, że będzie zły
● Miłe złego początki
● Zmiany
● Zmiany do zmian
● Zmiany do zmian, do zmian
5. Ty tworzysz kod czy Twój klient?
● To nie klient pisze kod, tylko Ty!
● W pewnym momencie popełniamy
pierwszy grzech - zaniedbanie
● I potem jest już tylko gorzej...
6. I co dalej? Czyli trochę o odpowiedniej
komunikacji i jasnym przekazie!
● Rozpacz i obwinianie!
● Ale czy można inaczej?
● Dwie drogi miękka i twarda?!
7. Droga miękka - gdy klient
ciągle zmienia zdanie…
● Programista niezłomny i PM wyklęty
○ Nie tędy droga
● Złoty środek
○ Rozmowy trójstronne : klient - PM - dev team
○ Planowanie powinno uwzględniać refactoring
● Droga na pół twardo
○ SOLID code
○ Code review - najlepiej zrobione przez człowieka spoza projektu
8. Droga twarda - czyli narzędzia,
które nam w tym pomogą
● PHP Code sniffer
● PHP Mess detector
9. Podsumowanie:
● Zły kod to zwykle nasze dzieło
● Aby solidnie zabezpieczyć się przed złym kodem należy:
○ Komunikować się odpowiednio z klientem
○ Przewidzieć czas na refactoring
○ Wprowadzić jasne zasady tworzenia oprogramowania np.
SOLID
○ Code Review robione przez osobę spoza projektu
○ Wdrożenie narzędzi PHP Mess detector i PHP Code Sniffer
10. Dziękuję za uwagę :)
e-mail: hello@codesushi.co
www: codesushi.coKrzysztof Ożóg
Codesushi CTO