Entries for tag "software engineering", ordered from most recent. Entry count: 37.
# Filozofia #1
Sat
21
Jul 2007
Kiedy człowiek ma dużo wolnego czasu, to za dużo myśli i przychodzą mu do głowy różne dziwne rzeczy. Dlatego to jest pierwsza cyklu notek filozoficznych. Wszystkich zdegustowanych czytelników mojego bloga przepraszam i obiecuję, że kiedyś mi to przejdzie :)
Myślałem sobie mianowicie o tym, jak wiele czasu potrzeba, by stworzyć cokolwiek - czy to będzie napisanie książki, zrobienie swetra na drutach czy napisanie jakiegokolwiek, małego nawet programu albo gry. Wielokrotnie więcej, niż wydawałoby się komuś niewtajemniczonemu albo początkującemu programiście. A czas mija nieubłaganie. Dlatego trzeba jak najstaranniej dobierać sobie zadania do wykonania - zarówno duże projekty, jak i te drobne sposoby na ich zrealizowanie.
Inna związana z tym sprawa to paradoks, że niejednokrotnie boimy się i nie możemy się zabrać za zrobienie czegoś, co w końcu zajmuje nam nie więcej niż 15 minut (np. zadana w szkole praca domowa), a innym razem angażujemy się w coś małego, co niespodziewanie zabiera wiele dni. Dlaczego tak jest? Moim zdaniem dlatego, że tym, czego podświadomie się boimy jest wysiłek, a to, co liczy się naprawdę to czas - dwie różne rzeczy.
Jeszcze inna kwestia to motywacja, która może wielokrotnie przyspieszyć robienie czegokolwiek. To jednak nie jest lekarstwo na wszystko - bo dlaczego firmy informatyczne nie zatrudnią po kilku młodych genialnych amatorów z motywacją zamiast armii tak niewydajnych w porównaniu z nimi programistów? O tym pisze Frederick Brooks w książce "Mityczny osobomiesiąc".
Comments | #philosophy #software engineering Share
# Projektowanie API
Thu
28
Jun 2007
Projektowanie interfejsu biblioteki jest równie ważne, jak projektowanie interfejsu użytkownika programu. O tym drugim napisano całkiem sporo. Sam mam jedną książkę właśnie na ten temat. Co z tym pierwszym? Czy ktoś widział jakikolwiek tekst poświęcony projektowaniu dobrego API? Ja znam tylko jeden mały artykuł - Designing Qt-Style C++ APIs napisany "przy okazji" przez autorów biblioteki Qt.
Comments | #software engineering Share
# Nowa teoria filozoficzna
Sun
24
Jun 2007
Wymyśliłem wczoraj nową teorię filozoficzną :) Przypomniał mi się temat forum Jeśli nie kodzić... to co? i uświadomiłem sobie, że ludzi programujących można podzielić na 3 grupy zależnie od tego, kim byliby, gdyby nie było komputerów:
Może gdyby ludzie to rozumieli i każdy znał swoje miejsce na tym schemacie, skończyłyby się spory na temat tego, czym tak naprawdę jest informatyka i programowanie? :)
Comments | #philosophy #software engineering Share
# Dobra biblioteka, zła biblioteka
Sat
02
Jun 2007
Chcę teraz napisać moduł do obsługi daty i czasu. Poszukując czegoś, na czym mógłbym się wzorować szczególnie dokładnie przejrzałem dokumentację i kod dwóch bibliotek - Boost.Date_Time oraz wxWidgets wxDateTime. Was też zachęcam do poświęcenia kilku chwil na próbę zrozumienia, jak te biblioteki wyglądają i ich porównania. Można tu naprawdę klarownie zobaczyć, jak powinien wyglądać, a przede wszystkim jak NIE powinien wyglądać interfejs dobrej biblioteki. Jedni głoszą, że "Mądrość i piękno bardzo rzadko idą w parze" (ten cytat jest mottem całego dzieła Meyersa "Effective C++"), inni znają takie pojęcie jak elegancja...
Comments | #libraries #software engineering Share
# Konwencja nazywania identyfikatorów
Mon
14
May 2007
Istnieje kilka różnych sposobów nadawania nazw funkcjom, zmiennym, poleceniom, znacznikom i wszelkim identyfikatorom. Można je podzielić na:
MyLittleFunction
- styl Microsoft
myLittleFunction
- styl Java
my_little_function
- styl C/C++
my-little-function
- styl XML
mlttlfnctn
- styl Unix
Który z nich jest najlepszy, tego nie można jednoznacznie powiedzieć. Zamiast tego spróbuj pomyśleć, który jest najgorszy ;)
Comments | #philosophy #software engineering Share
# Accidental Complexity, Essential Complexity
Thu
03
May 2007
Accidental Complexity i Essential Complexity to pojęcia, których użył Fred Brooks w swojej książce "Mityczny osobomiesiąc" oraz artykule "No Silver Bullet". Pisząc w skrócie, złożoność każdego programu jest sumą Accidental Complexity - nadmiernej złożoności, której da się uniknąć oraz Essential Complexity - złożoności która musi być, bo, jak mówią, jeśli program ma robić 30 rzeczy, to te 30 rzeczy trzeba zaprogramować.
Pomyślałem sobie dzisiaj, że tych dwóch pojęć, oprócz udowadniania dlaczego Srebrna Kula nie istnieje i nie może istnieć, możnaby też użyć do mierzenia jakości interfejsu API bibliotek (a może też podobnie interfejsu użytkownika programów?). Polegałoby to na tym, aby:
Comments | #philosophy #software engineering Share
# Singletony precz!
Tue
01
May 2007
W ramach porządków w kodzie pozbyłem się dzisiaj wszystkich singletonów zamieniając je na zwykłe, globalne zmienne wskaźnikowe. Tak, wiem co sobie teraz pomyślą wszyscy obrońcy programowania obiektowego... Ja nie mam nic do OOP ani nawet do wzorców projektowych, ale jednak krócej niż res::ResManager::GetInstance().Cośtam
jest napisać res::g_ResManager->Cośtam
. Poza tym to działa szybciej, bo mówcie co chcecie, ale sprawdzać czy obiekt już istnieje tysiące razy na klatkę to nie jest zerowy narzut czasu.
Przede wszystkim jednak mam teraz kontrolę nad tym, kiedy obiekt powstaje i kiedy jest niszczony, bo... robię to sam. Mogę więc powiedzieć dokładnie, czy w pewnej chwili to czy tamto jest utworzone, w jakiej kolejności jest alokowane i zwalniane oraz zagwarantować, że w danym momencie dany obiekt na pewno istnieje. Słowem - mam w pełni formalnie zdefiniowany czas życia obiektów. To rozwiązało problem, który miałem podczas finalizacji różnych modułów, a z którym nie sposób było inaczej sobie poradzić. Co za ulga! A już zaczynałem wierzyć, że singletony są OK...
Comments | #c++ #philosophy #software engineering Share
# Dobra dokumentacja na wagę złota
Fri
13
Apr 2007
Dokumentacja... Najbardziej znienawidzona część każdego programu. Prawie nikt nie lubi jej pisać, ale wszyscy wiedzą, że jest niezbędna. Dokumentacja jest tym, co najlepiej odróżnia prawdziwy, dopracowany program od eksperymentu/prototypu.
Dla odbiorcy danego programu (czy - przede wszystkim - biblioteki) dobra dokumentacja to nieoceniona pomoc. Zaawansowani tym się właśnie różnią od początkujących, że nie boją się do niej zaglądać, bo wiedzą, że znajdą tam systematyczny i szczegółowy opis każdej funkcji, jej działania i parametrów. Tylko czy na pewno kompletny?
MSDN zawsze pozostaje dla mnie pod tym względem wzorem. Ale już dokumentacji w DirectX SDK można co nieco zarzucić, szczególnie jej części poświęconej D3DX. Oprócz braku rozdziałów opisujących ogólnie sposób używania poszczególnych interfejsów doskwierają liczne drobiazgi. Na przykład:
D3DXVec3Normalize
albo D3DXMatrixInverse
można podać ten sam wektor/macierz jako wejście co jako wyjście? (Tu akurat wiem że można, bo podpatrzyłem w źródłach DirectX-a kiedy miałem do nich dostęp.)
D3DXCreateEffect
w razie błędu zawsze zwraca ppCompilationErrors
a nigdy nie zwraca ppEffect
?
D3DXCreateEffectCompiler
parametru pDefines
używa się tak (autentyczny problem z wczoraj, rozwiązanie znalazłem z pomocą Google na jakimś forum):
D3DXMACRO Macros[MACRO_COUNT+1]; for (int i = 0; i < MACRO_COUNT; i++) { Macros[i].Name = // ... Macros[i].Definition = // ... } Macros[MACRO_COUNT].Name = NULL; Macros[MACRO_COUNT].Definition = NULL;