archiwum tematu „software engineering” z maja 2004
Pair Programming - good intention gone bad
Pair Programming — jedna z podstawowych i jednocześnie najbardziej kontrowersyjnych praktyk stosowanych w XP. Mam wrażenie, że w przeważającej większości znanych mi przypadków to po prostu nie zadziała. Nie twierdzę, że to pomysł do niczego — Pair Programming może działać i może być wydajną techniką (może nie od razu 1+1=3, ale przynajmniej 1+1> 2). Jednak równocześnie istnieje mnóstwo powodów, dla których może się okazać absolutną klęską.
» czytaj całość (671 słów) | 2004.05.27 | 2 komentarze |
tagi » teorie i przemyślenia, xp
standard kodowania
O standardach pisania kodu programu powiedziano już bardzo wiele. Jest to jeden z najbardziej wyrazistych aspektów ludzkiego wymiaru programowania — styl kodu nie ma przecież żadnego znaczenia dla kompilatora i jego "jakość" to wyłącznie subiektywne odczucia programisty. A jednak sprawa od zawsze budzi wiele emocji — kod może być "elegancki" i "ładny" albo "brzydki" i wtedy taktowany jako produkt niskiej jakości (niezależnie od jakości skompilowanego programu). Nic dziwnego zatem, że powstają nawet oficjalne wytyczne na temat stylu kodowania, np. Suna dla Javy lub Microsoftu dla .NET-u oraz dziesiątki innych opracowań (prywatnych lub korporacyjnych), które zazwyczaj bazują na powyższych lub innych sławnych źródłach typu "C++ Coding Standard" Todda Hoffa.
» czytaj całość (1121 słów) | 2004.05.23 | 7 komentarzy |
tagi » sztuka programowania
niemodna optymalizacja
Tempo postępu technologicznego w informatyce jest (przynajmniej dla mnie) jednym z największych zaskoczeń ostatnich dziesięcioleci. Moc obliczeniowa komputerów wzrasta tak szybko, że nieraz jest to "poniżej ludzkiej godności", jak zwykł mawiać mój kolega. Znaczenie określenia "dobry sprzęt" zmienia się błyskawicznie i wyobrażam sobie, że ludzie chcący za tym nadążyć nie zajmują się niczym więcej. Niestety wraz ze sprzętem dewaluuje się pojęcie "dobrego" oprogramowania. Przyzwyczajeni do szybkich i tanich komputerów przestajemy zwracać uwagę na takie szczegóły jak optymalizacja kodu, wykorzystania pamięci czy szybkości obliczeń. Problemy z wydajnością oprogramowania nagminnie rozwiązuje się bezczelnie prostym stwierdzeniem — "poda się w specyfikacji większą ilość wymaganej pamięci, to kosztuje grosze". I niestety to jest prawda, co tylko umacnia trend ignorowania pojęcia optymalizacji. Jednak paradoksalnie rozczarowanie przychodzi w momencie kiedy zechce się napisać coś "naprawdę zgodnego z trendami", ponieważ "trendy" to dzisiaj urządzenia mobilne.
» czytaj całość (573 słowa) | 2004.05.21 | 7 komentarzy |
tagi » sztuka programowania
XP name considered harmful
Bez względu na to jak obiecujące byłyby koncepcje związane z Extreme Programming, nigdy nie będę w stanie wprowadzić takiego pojęcia oficjalnie w poczet technik stosowanych w firmie. Do powodów, które sobie wyobrażam, należą przede wszystkim takie:
» czytaj całość (324 słowa) | 2004.05.18 | 1 komentarz |
tagi » teorie i przemyślenia, xp
Blog Reader Add-In for Visual Studio .NET
Blog Reader Add-In for Visual Studio .NET — czytnik RSS zintegrowany z Visual Studio, czyli co zrobić, żeby lepiej udawać, że pracujesz ;-).
» czytaj całość (152 słowa) | 2004.05.13 | 2 komentarze |
IntelliSense
Najważniejsza, obok kolorowania składni, funkcjonalność edytora kodu — przewidywanie co chcesz napisać i podpowiadanie gotowych rozwiązań. Czy to się nazywa IntelliSense, code completion, code hinting czy jeszcze jakoś inaczej — bez znaczenia. Ważne, żeby było i żeby działało sprawnie, bo od tego zależy jakość, szybkość powstania, a nieraz w ogóle zaistnienie kodu.
» czytaj całość (715 słów) | 2004.05.13 | 1 komentarz |
tagi » sztuka programowania, soft, narzędzia
Agile Modeling
Kiedy pierwszy raz zetknąłem się z pojęciem Agile Modeling spotkałem różne mniej lub bardziej rozbudowane wprowadzenia czy też próby skrótowego przedstawienia tego pojęcia (choć niejako z definicji skrótowo przedstawić się go nie da), w tym również poniższą listę:
» czytaj całość (454 słowa) | 2004.05.09 | 0 komentarzy |
tagi » teorie i przemyślenia, xp
programista, a może projektant?
Teoria książkowa aka sformalizowany świat idealny przedstawia taki łańcuch rozbieżnych kompetencji — klient, analityk, projektant, programista, tester. W łańcuchu tym wymagania i uwagi klienta co do funkcjonalności systemu są pieczołowicie zbierane przez analityka i przekazywane projektantowi, który tworzy szczegółowy projekt tego co ma być wykonane. Następnie projekt ten trafia do programisty w celu jego urzeczywistnienia i na końcu do testera dla konfrontacji efektu z założeniami. Taki schemat zakłada separację ról, czyli jest praktycznie wzorowany na kaskadowym modelu cyklu życia projektu informatycznego. I jest równie absurdalny jak sam model kaskadowy.
» czytaj całość (540 słów) | 2004.05.06 | 0 komentarzy |
tagi » uczestnicy dramatu
engineering?
Pytanie o zasadność słowa engineering w wyrażeniu software engineering nie jest bynajmniej nowe ani dziwne. Jest wręcz uzasadnione, a uzasadnione pytania tego kalibru zawsze są kłopotliwe. Jeśli nie niebezpieczne...
» czytaj całość (629 słów) | 2004.05.04 | 0 komentarzy |
tagi » inżynieria?, teorie i przemyślenia