Tag: software engineering

Entries for tag "software engineering", ordered from most recent. Entry count: 35.

Uwaga! Informacje na tej stronie mają ponad 5 lat. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 2 3 4 5 >

# 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:

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:

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;

Comments | #directx #philosophy #software engineering Share

# Architektura serwera MMO

Fri
30
Mar 2007

Czytając sobie różne materiały dochodzę do wniosku, że architekturę rozproszonego serwera gry MMO można podzielić na dwa rodzaje:

  1. Podział na węzły ze względu na pełnioną funkcję - na przykład osobny serwer nazw, osobny AI, osobny walki, osobny przedmiotów itd.
  2. Podział na węzły ze względu na symulowany obszar świata gry

W swoich na razie tylko teoretycznych rozważaniach skłaniałbym się obecnie ku opcji drugiej, bo wydaje mi się znacznie prostsza w implementacji i bardziej skalowalna.

Comments | #software engineering #networking Share

# Dobry pomysł firmy Psiloc

Tue
27
Mar 2007

Kod powinien być jak najbardziej ogólny i uniwersalny, przenośny i pozbawiony zależności. Tak uczy inżynieria oprogramowania. Wtedy nadaje się do ponownego użycia skracając czas pisania nowych produktów i stanowiąc nową cegiełkę do zasobów wiedzy programisty albo firmy. Tyle teoria. W praktyce, jak wiadomo, bywa różnie. Żadna klasa (oprócz tych najprostszych) nie możne się obejść bez odwołania do "warstw niższych" danej aplikacji, często łatwiej jest coś napisać od nowa niż przerabiać wcześniejszy kod, a pisanie wszystkiego jak najbardziej ogólnie i uniwersalnie to prosta droga do tego, żeby nigdy niczego nie skończyć.

W związku z tym ludzie radzą sobie w różny sposób. Na przykład pisząc większe moduły, które stosują w wielu swoich projektach. Ja już jakiś czas temu zorientowałem się, że często zamiast gotowej do wykorzystania klasy warto zachować kawałek kodu, który w razie potrzeby skopiuję do nowego programu dostosowując w nim co trzeba. Kody takie wraz z wszelką inną wiedzą trzymam w pliczkach tekstowych, których mam już ponad 700.

To, o czym chciałem tutaj napisać, to nowy pomysł, który usłyszałem na tegorocznej konferencji, na prezentacji firmy Psiloc. Można sobie mianowicie napisać oprogramowanie, które będzie automatycznie (nawet jakoś bardzo prosto) katalogowało nasz kod poszukując *specjalnych komentarzy*, a my będziemy zaznaczali tymi komentarzami szczególnie ciekawe fragmenty w swoim kodzie, jak na przykład wywołania potrzebne do sprawdzania numeru MAC karty sieciowej czy jakiś sprytny algorytm. Potem można będzie łatwo taki fragment odnaleźć. Zastanawiam się, czy to nie jest całkiem dobry pomysł...

Comments | #software engineering Share

Pages: > 1 2 3 4 5 >

[Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2021