A z drugiej strony mówią, że jak klient jest nieogarnięty i zamówił coś, co mu nie działa to my mamy się głowić, co on namieszał. profesjonalizm where
Wersja do druku
A z drugiej strony mówią, że jak klient jest nieogarnięty i zamówił coś, co mu nie działa to my mamy się głowić, co on namieszał. profesjonalizm where
Przeciwnie. Twoim zdaniem jako profesjonalista jest dopasowanie się pod klienta i wykonanie tego co on potrzebuje. Co do ,,ramy śmiesznej pensji na etat" to juz się nie wypowiem, bo podejrzewam, że zarabiam więcej od Ciebie ;)
I niestety, ale ja już nie będe tłumaczył Ci dlaczego robi się tak a nie inaczej. Ja nie robię tego, że klient. Ja robie to dla siebie. Bo sprawia mi przyjemność pisanie kodu, który jest bardzo elastyczny i mogę bardzo łatwo rozbudować - takiego, który prezentuje sobą dużą wartość. To jest właśnie profesjonalizm. I na tym zakończmy, jak nabierzesz nieco doświadczenia to zrozumiesz ;)
Mi sprawia przyjemność pisanie kodu,a nie zgadywane czego chce klient kiedy on sam tego nie wie. Jak wie czego potrzebuje to problemu nie ma, nawet jeśli to kompletny kretynizm (patrz 90% stron internetowych różnych firm...) to przynajmniej są jasno określone wymagania
No ale to wcale nie jest tak że klient nie wie. Realia biznesowe zmieniają sie ekstremalnie szybko, a im bardziej potrafisz sie do tego dopasować - tym lepiej. I nadal nie rozumiem, czemu forsujesz rozwiązanie, które jest mniej elastyczne ( co Ci już pokazałem na przykładzie aliasów ) , a dokładnie tak samo proste w użyciu jak moje ( i wcale nie pisze się tego dłużej - u mnie gettery i settery to kwestia alt insert i dwa razy enter w IDE ;] )
@Edit
Strzelam że kolega @zakius ; miał po prostu przykre doświadczenia z klientami na rynku freelancerów. Też miałem i wiem jak to wygląda, ale tak postępując tylko utrudniasz sobie robotę, a co do samego rynku freelancerów się już nie wypowiem ponad tyle, że m.in dlatego zrezygnowałem z bycia freelancerem i w ogóle z pracy w Polsce.
Twoje rozwiązanie jest elastyczne jeśli albo w pierwotnej wersji oddałeś do api specjalną funkcję, której modyfikacja nie obniży zrozumiałości kodu, albo gdy porzucisz sensowne nazywanie metod i podstawową konwencję tworzenia tychże getterów w momencie zmiany wymagań. Pierwszy wypadek jest mało prawdopodobny, drugi nie jest poprawny z punktu widzenia czystości kodu, jeśli metoda nazywa się getNick() i klasa posiada pole nick to nie jest zbyt intuicyjne zwracanie przez nią zawartości pola alias. Nawet na miejscu klienta wolałbym przeprowadzić proste zamien wszystkie niż mieć burdel w kodzie zarówno swoim jak i zewnętrznym.
Załóżmy nawet, że gettery nie są takie złe, niech już będzie. Ale wracając do tego boola. Pewnie zaraz powiesz, że w każdej chwili może się okazać, że dana metoda ma zwracać zawartość pola tylko gdy inny warunek nie jest spełniony, w przeciwnym wypadku wasze prawdę albo coś w tym stylu. Jednak znów to nie jest typowy getter tylko metoda dodatkowa.
IDE... No cóż, tak długo, jak tym IDE nie jest visual studio to nawet nie mam ochoty mordować, chociaż w wypadku php nie znalazłem żadnego, które dałoby mi jakąkolwiek korzyść
Netbeans sprawdza się do javy, ale w php nie dawał mi nic ponad to, co mam w npp (bo nawiasy i klamry i tak zawsze sam robię, a reszty nie potrafił ogarnąć). Próbowałem wielu rzeczy, ale po prostu nie miałem siły zastanawiać się, co tu zrobić żeby mi to w końcu zaczęło pomagać zamiast przeszkadzać. Teraz mam więcej czasu to może spróbuję jeszcze raz.
Btw, eclipse ogarnia jak zamykam sam dodany przez niego nawias, ale klamry już nie i mi zostają 2 i muszę poprawiać... Niesamowite...
Ile to trzeba czasu poświęcić, żeby narzędzie zaczęło działać
PHPStorm to zdecydowanie lider.
O jakiej funkcji mówisz? Ja oddałem tylko getter getNick() ;)
Nieprawda. Dla mnie jest to wręcz bajecznie intuicyjne - Metoda getNick() ma zwrócić nick w kontekście biznesowym, słyszałeś kiedyś pojęcie logika biznesowa? Właśnie dlatego się tak nazywa, bo definiuje to, co nazywamy "biznesem", czyli działaniami na rzecz end-userów. W naszym wypadku, getNick() ma zwrócić nick używany w sytemie, a domyślnym nickiem jest alias o ile takowy istnieje :)
@EDIT
Rozwinę ten punkt jeszcze. A powiedz mi, czy jeśli wdg Ciebie nicki byłyby pobierane z jakiegoś zewnętrznego api, albo z jakiegoś cachea, albo nie wiem, z chuj wie jakiego źródła, to metoda nie powinna nazywać się getNick()? Jeśli myślisz że gettery sa tylko po to aby opakowywać pola, to jesteś w błędzie ^^
Powiedz to naszym wszystkim kontrahentom , którzy używają api przez jakiś SOAP.
Jak to powiedział mój szef gdy rozmawialiśmy o sposobach programowania : ,,nigdy nie wiesz co jutro będzie". Nigdy nie wiesz kiedy logikę z boola będziesz musiał zamienić na jakiś call zewnętrzny ;] i niestety to się sprawdza.
PHPStorm wspomniany jest genialny, mam tam absolutnie wszystko :) a jeszcze jest Netbeans i parę innych.
Dlatego polecam PHP storm.
phpstorm> aptana> netbeans
Sam spędziłem trochę czasu na konfiguracji, ale teraz na prawdę przyjemnie się kodzi.
Integracja z gitem, automatyczne wysyłanie na serwer i maaaasa innych przydatnych pierdół.
Czekam jeszcze na nową kartę graficzną i monitor, wtedy praca będzie jeszcze przyjemniejsza :)
Jasne, że metoda robiąca cokolwiek poza zwróc wartość pola się przydaje. Za to właśnie taka, która robi tylko to jest dość... No właśnie. Poza tym w tym przykładzie to by było getDisplayName(załóżmy) które zwraca alias jeśli istnieje, w przeciwnym wypadku nick. I tutaj wszystko się trzyma kupy. W każdym razie, udostępnianie do bezpośrednio do API metod wyłącznie zwracających wartość pola może prowadzić do takich dziwnych rzeczy. Co zrobisz, jeśli wewnątrz swojej części kodu potrzebujesz ZAWSZE nick, ale nie masz dostępu bezpośrednio do pola? Klepiesz nową metodę i po swojej stronie zmieniasz wywołania? To jest bez sensu i nieelastyczne. Z drugiej strony opakowywanie prostego gettera w dodatkową funkcję, która zwraca jedynie zwrot z tego gettera to już kompletny cyrk... I co z tym zrobić, żeby było czysto, działało i biedny klient nie musiał się pocić, bo jednak chce coś inaczej?
Nie wprowadzasz tego po to, abyś "dorabiał sobie roboty". Wprowadzasz to po to, bo w razie jeśli będziesz musiał to zmienić, nie musiał nadwyrężać się robotą ;) Design robi się aby uniknąć czegoś, a nie aby zaleczać :P
Na to samo wychodzi, to jest przykład gettera.
A jak myślisz, co jest bardziej prawdopodobne - że po zmianie będzie potrzebna nowa funkcjonalność czy stara? Ta stara może być użyta co najwyżej w paru miejscach . W tym celu mogę stworzyć ,,getOriginalNickname" i zmienić tam gdzie potrzebuje zmienić wykorzystanie logiki biznesowej ( co jest jedynym usprawiedliwieniem dla zmiany użytkowania interfejsu z zewnątrz, jakby się zastanowić, to ma to sens :) ).
Na prawdę dla Ciebie to takie trudne? XD dla mnie to jest z stoperem w ręku niecałe 10 sekund, a jeśli potem potrzebuję zmienić logikę zwracania nicku robię to bez bólu i refaktorowania całego projektu. Easy.Kod:<?php
interface IGotNick {
public function getNick();
}
class X implements IGotNick {
private $nick;
public function getNick(){
return $this->nick;
}
}
Aha, jeszcze jedna ważna sprawa - jeśli musisz zmieniać implementację korzystającą z interfejsu przy zmianie tegoż interfejsu, coś robisz źle. Dlaczego np mój klient miałby zmieniać swój interfejs pokazujący najnowszych użytkowników na swojej stronie np, tylko dlatego że ja wprowadziłem jakieś aliasy? :) To bez sensu.
Nie wiem, rób jak chcesz. Rozumiem Cię , bo sam tak myślałem parę lat temu, to wszystko przychodzi z czasem, zaczyna się rzeczy takie jak rozdzielanie odpowiedzialności , zależność od abstrakcji i hermetyzacja coraz lepiej rozumieć i doceniać ich zalety. I nie mówię tego by Cię jakoś obrazić czy coś, po prostu chciałem zwrócić uwagę na to, że sam przez to przechodziłem ;)
A no bo to ON wprowadził aliasy do specyfikacji gdy wszystko już było gotowe. Jasne, jeśli płaci za to, że getNick() mu zwraca liczbę postów to już inna sprawa. Ale jeśli niczego takiego nie wymaga to intuicyjne nazwy > 'intuicyjne' nazwy
Przestań zwalać winę na klienta. On wprowadził, bo chciał coś nowego do produktu, czemu się tego tak czepiasz? getNick() w kontekście biznesowym w momencie wprowadzenia aliasów zaczyna znaczyć coś innego i jako tako ma to zwracać. Mi za to płacą, więc to robię, a Ty jeśli masz zamiar robić wielkie burdy o to , że klient wprowadził coś nowego do projektu po paru latach ( bo realia biznesowe sie zmieniają ), to z każdej firmy po prostu wylecisz xD
@Edit
Wspomniane aliasy wprowadzono 4 lata po stworzeniu serwisu, uważasz że powinnem opierdalać pracodawcę za to, że chcą wprowadzać innowacyjność do swojego produktu? XD
@Edit2
Jeszcze jedna sprawa. Poczytaj o logice biznesowej. To naprawdę ważny koncept, bo nie programujemy dla zabawy, tylko dlatego aby wykonywać dane operacje które coś znaczą w Naszym świecie. ;)
Tylko ten klient musi się liczyć z tym, że będzie miał burdel. W tym wypadku ewentualne zastosowanie zmodyfikowanego getNick() zamiast pobrania wartości pola nick najwyżej wywoła trochę wstydu, ale może być znacznie gorzej.
Dlaczego? Jeśli getNick() zwraca aktualny nick używany w sytemie, to dlaczego wdg Ciebie jest to burdel? xD Dla mnie głupim by było zdobywać przez getNick() == "stasiu" kiedy tak naprawdę nick który chciałby zobaczyć user to ,,zbysiu" :) Nie każda implementacja jest ,,prosta" w tym sensie , że nick zwraca pole nick i trzeba się z tym niestety liczyć, po to mamy właśnie takie rzeczy jak SRP i SOLID ogółem, aby być elastyczni na to.