jak pracuję

Jak powstaje u mnie narzędzie

Najpierw opis na papierze: co ma robić, po czym poznam, że działa, i co się stanie, gdy się pomyli. Dopiero potem kod. Ta kolejność wygląda na formalność, dopóki nie zobaczysz, ile rzeczy odpada już przy pisaniu opisu, zanim kosztowały choć godzinę.

zasady

Cztery rzeczy, przy których się nie targuję

To nie są hasła na stronę. Każda z nich kosztowała mnie tygodnie poprawiania czegoś, co działało w połowie.

Albo działa, albo siedzę dalej

Nie ma u mnie stanu „prawie działa". Narzędzie, które sprawdza się w połowie przypadków, jest gorsze od żadnego, bo uczy człowieka ufać czemuś, co zawiedzie przy dwudziestym produkcie. Poprawiam tak długo, aż wynik jest powtarzalny.

Technologia dobrana do zadania, nie do mody

Nie zbuduję asystenta poczty, który stoi wyłącznie na instrukcjach dla modelu, bo wiem, że to się rozjedzie. Rzeczy, które muszą wyjść tak samo za każdym razem, robi zwykły kod. Model dostaje to, w czym jest dobry: szkic, propozycję, wariant do oceny.

Każdy zapis do żywego systemu ma hamulce

Podgląd przed zmianą, kopia stanu sprzed zmiany, wyraźna zgoda człowieka, a po zapisie odczyt z powrotem i porównanie. Dopóki nie ma dowodu zapisu, zadanie nie jest zrobione, tylko wysłane.

Szyję pod Ciebie, nie odsprzedaję swojego

Moje narzędzia powstały pod moje wąskie gardła. Twoje będą inne, bo masz inny towar, innego klienta i inne miejsce, w którym tracisz czas. Robota dla kogoś zaczyna się od poznania oczekiwań, nie od pokazania gotowca.

dane klientek

Imię klientki trafia do modelu. Jej adres już nie

Wolę napisać wprost, co model widzi, niż obiecywać, że nie widzi niczego. Pracuję na modelach codziennie, więc część danych przez nie przechodzi. Pilnuję, która część i na jakich warunkach.

Granicę wyznacza rodzaj danych, nie zadanie. W sklepie rozróżniam cztery:

Produkty i katalog. Opisy, skład, ceny, stany. Tu nie ma niczyich danych, więc model pracuje bez ograniczeń.
Sprawy wewnętrzne sklepu. Marże, sprzedaż, zamówienia u dostawcy. Model dostaje je wtedy, gdy zadanie ich wymaga.
Dane osób. Kto kupił, pod jaki adres, telefon, mail. Tu liczy zwykły kod na moim komputerze. Model dostaje skróty zamiast nazwisk albo wynik zbiorczy, bez ani jednego kontaktu.
Dostępy. Klucze do sklepu i hasła nie trafiają do modelu nigdy. Leżą zaszyfrowane, a narzędzie, w którym pracuje model, w ogóle ich nie ma. Pilnuje tego osobny test.

Poczta to jedyne miejsce, w którym model czyta tekst napisany przez klientkę, bo inaczej nie napisze szkicu odpowiedzi. Zanim wiadomość do niego trafi, kod zakrywa w niej adresy mailowe i numery telefonów. Adresata odpowiedzi wpisuje kod, nie model. Imię i nazwisko nadawczyni idą do modelu, tak samo jak wszystko, co klientka sama wpisała w treść. Zostawiłem to świadomie, po przejrzeniu prawdziwych wiadomości. To nadal są dane osobowe, więc przechodzą wyłącznie przez połączenie na warunkach firmowych.

Maskowanie łapie wzory, czyli adresy i numery. Imienia ani numeru z literówką nie złapie, dlatego nie piszę, że ryzyko znika. Piszę, że jest mniejsze, i wiem, co zostaje.

Tu leży różnica między czatem a połączeniem przez API. W oknie czatu o tym, co trafi do modelu, decyduje człowiek w chwili wklejania. Przy API decyduje kod napisany z góry i nie ma okna, do którego dałoby się wkleić całą bazę. Na warunkach firmowych dostawca nie trenuje modelu na tych danych i trzyma je najwyżej 30 dni, na serwerach w USA.

Szkic odpowiedzi czytam i wysyłam sam. Model nie ma narzędzi, którymi mógłby cokolwiek wysłać.

warsztat

Narzędzie, którym buduję narzędzia

Same programy to połowa rzeczy. Druga połowa to warsztat, w którym powstają: zapisane procedury, sprawdzenia uruchamiane automatycznie i reguły, których nie da się obejść przez nieuwagę. Ten warsztat budowałem równolegle z narzędziami i nadal go podnoszę, bo każdy jego stopień podnosi poziom tego, co z niego wychodzi.

Na czym to stoi:

Opis przed kodem. Każdy projekt ma napisaną specyfikację, zanim powstanie pierwsza linia. Sprawdzeń, które trzeba będzie zrobić, szukam wtedy, a nie po fakcie.
Sprawdzenia, których nie da się pominąć. Część kontroli odpala się sama przy zapisie pliku, bez mojej pamięci. Reguła zapisana jako prośba do siebie samego działa dopóty, dopóki się o niej pamięta.
Kontrola bezpieczeństwa z trzecim stanem. Wynik to nie tylko „czysto" albo „znalazłem". Jest jeszcze „kontrola się nie wykonała", a ten stan blokuje tak samo jak błąd. Poprzednia wersja potrafiła zwrócić „czysto", nie sprawdziwszy niczego, bo brakowało narzędzia.
Sprawdzanie własnych sprawdzeń. Przed skanem powstaje plik z celowo wstawionym błędem. Kontrola, która go nie znajdzie, jest uznana za zepsutą. To łapie przypadek, którego nie widać: narzędzie działa, ale skanuje pustkę.
Atak na własne wnioski. Zanim pokażę rekomendację, osobna procedura próbuje ją obalić. To, co przetrwa, dostaje się dalej z zapisem, czym było atakowane.

Rysunek pokazuje wyłącznie kolejność i miejsca, w których coś się zatrzymuje. Nie ma na nim ani jednej linii kodu, ani jednej nazwy narzędzia, ani jednej procedury.

34specyfikacje

Tyle projektów i większych zmian ma opis powstały przed kodem. Część z nich nigdy nie doczekała się kodu i to też jest wynik.

18automatycznych kontroli

Odpalają się przy zapisie albo przed oddaniem roboty. Nie zależą od tego, czy akurat pamiętam.

229plików testów

We wszystkich narzędziach razem. Zmiana, przez którą któryś przestaje przechodzić, nie wychodzi z warsztatu.