Dawno dawno temu w odległej galaktyce ... (tak to jest jak sie ciemne moce wpisuje jako backdoory). Dość dawno temu starałem sie ze znajomymi na bazie innego opracowania zastosować pewne zasady tworzenia programów. Obecnie chciałbym te zasady z Wami przedyskutować zmodyfikować i wdrożyć. Zapraszam do lektury i dyskusji.
Clarion for Windows
Development Standards
Revision 1.1PL 15.08.2005
By
Jim Morgan and Fred Schmitthammer
Wersja w języku polskim tłumaczona i weryfikowana przez
Olę Jańczak, Jacka Kosińskiego, Sławka Łopuszańskiego.
link do oryginału: http://www.clarionmag.com/col/98-04-c4devstandards.html?pFriendly=true
W odniesieniu do oryginału większośc propozycji zostało zmienionych, uwzględniono pomysły tak wielu ludzi z listy news.clarion.pik-net.pl, że trudno mi przypomnieć sobie, kto co proponował. Jednak wśród współautorów wymienić należy Piotra Rudnickiego, Mirka Sitarza oraz Grzegorza Siwca. Jeśli ktoś uważa, że powinien być wymieniony też na tej liscie to proszę o kontakt (kashiash@aip.pl).
Wprowadzenie
W dokumencie tym zajmujemy się zagadnieniami projektowania i programowania przy użyciu pakietu Clarion 4.x, i nowsze (obecnie 6.2). Dokument niniejszy bazuje na Zaleceniach Dla Programistów Interfejsu Windows – pozycji wydanej przez Microsoft Press. Wszelkich informacji nie zawartych w niniejszym dokumencie należy szukać w powyższej pozycji.
Standardy są ważne z wielu powodów. Dzięki korzystaniu ze wspólnego interfejsu użytkownika (UI) aplikacje stają się łatwiejsze do opanowania przez tegoż użytkownika. Spójne i proste projekty ekranów czynią pracę z nimi łatwiejszą i mniej stresującą. Pozwala to użytkownikowi na osiągnięcie lepszych rezultatów w korzystaniu z danego programu. Standardy programistyczne pozwalają grupie programistów na łatwiejszą współpracę w zespole. Używanie spójnego stylu kodowania zmniejsza ogólne koszty późniejszej konserwacji systemu, a także czyni łatwiejszym dokończenie czyjegoś programu bądź współużywanie bibliotek, które zostały stworzone przez innych.
Niektórzy twierdzą, iż standardy ograniczają kreatywność programistów i wymagają czasu w celu ich poznania i nauczenia się. Programiści mają jednak wiele możliwości wykazania się kreatywnością w ramach, narzuconych przez standardy. Standardów trzeba się nauczyć, to fakt, jednak zastosowanie standardowego podejścia do rozwiązywania problemów na ogół wielokrotnie rekompensuje czas, poświęcony na naukę. Ogólne korzyści, którymi są wydajność zespołu, wydajność użytkownika końcowego oraz niższe koszty konserwacji czynią stosowanie standardów niezbędnym w przypadku każdego projektu na tyle dużego, że konieczne jest zarządzanie nim.
To nie jest zamknięty dokument. Cały czas uczymy się lepszych metod. Zmiany technologiczne zachodzą ciągle. Standardy przemysłowe dotyczące UI zmieniają się również. Dokument niniejszy musi podlegać zmianom, by nadążać za bieżącymi potrzebami. Każda z osób posługujących się standardami może stworzyć propozycje zmiany, przedstawiając poniższe informacje osobie odpowiedzialnej:
Numer zmienianego standardu (lub propozycja nowego numeru).
Treść standardu
Argumentacja przemawiająca za przyjęciem nowego standardu
Argumentacja przemawiająca za odrzuceniem bieżącego standardu
Proponowane zmiany standardów zostaną rozprowadzone pośród członków komisji zajmującej się standaryzacją. Jeśli zmiany zostaną zaaprobowane, nowa wersja dokumentu zostanie udostępniona do pobrania. Obecna wersja powstała na bazie wersji sprzed 2ch lat i nowych doświadczeń, i jest w ciagłej modyfikacji wynikającej z braku czasu, postaramy sie zeby byla jak najbradziej aktualna - w koncu tylko w takiej postaci nadaje sie do wykorzystania.
Development Standards
Revision 1.1PL 15.08.2005
By
Jim Morgan and Fred Schmitthammer
Wersja w języku polskim tłumaczona i weryfikowana przez
Olę Jańczak, Jacka Kosińskiego, Sławka Łopuszańskiego.
link do oryginału: http://www.clarionmag.com/col/98-04-c4devstandards.html?pFriendly=true
W odniesieniu do oryginału większośc propozycji zostało zmienionych, uwzględniono pomysły tak wielu ludzi z listy news.clarion.pik-net.pl, że trudno mi przypomnieć sobie, kto co proponował. Jednak wśród współautorów wymienić należy Piotra Rudnickiego, Mirka Sitarza oraz Grzegorza Siwca. Jeśli ktoś uważa, że powinien być wymieniony też na tej liscie to proszę o kontakt (kashiash@aip.pl).
Wprowadzenie
W dokumencie tym zajmujemy się zagadnieniami projektowania i programowania przy użyciu pakietu Clarion 4.x, i nowsze (obecnie 6.2). Dokument niniejszy bazuje na Zaleceniach Dla Programistów Interfejsu Windows – pozycji wydanej przez Microsoft Press. Wszelkich informacji nie zawartych w niniejszym dokumencie należy szukać w powyższej pozycji.
Standardy są ważne z wielu powodów. Dzięki korzystaniu ze wspólnego interfejsu użytkownika (UI) aplikacje stają się łatwiejsze do opanowania przez tegoż użytkownika. Spójne i proste projekty ekranów czynią pracę z nimi łatwiejszą i mniej stresującą. Pozwala to użytkownikowi na osiągnięcie lepszych rezultatów w korzystaniu z danego programu. Standardy programistyczne pozwalają grupie programistów na łatwiejszą współpracę w zespole. Używanie spójnego stylu kodowania zmniejsza ogólne koszty późniejszej konserwacji systemu, a także czyni łatwiejszym dokończenie czyjegoś programu bądź współużywanie bibliotek, które zostały stworzone przez innych.
Niektórzy twierdzą, iż standardy ograniczają kreatywność programistów i wymagają czasu w celu ich poznania i nauczenia się. Programiści mają jednak wiele możliwości wykazania się kreatywnością w ramach, narzuconych przez standardy. Standardów trzeba się nauczyć, to fakt, jednak zastosowanie standardowego podejścia do rozwiązywania problemów na ogół wielokrotnie rekompensuje czas, poświęcony na naukę. Ogólne korzyści, którymi są wydajność zespołu, wydajność użytkownika końcowego oraz niższe koszty konserwacji czynią stosowanie standardów niezbędnym w przypadku każdego projektu na tyle dużego, że konieczne jest zarządzanie nim.
To nie jest zamknięty dokument. Cały czas uczymy się lepszych metod. Zmiany technologiczne zachodzą ciągle. Standardy przemysłowe dotyczące UI zmieniają się również. Dokument niniejszy musi podlegać zmianom, by nadążać za bieżącymi potrzebami. Każda z osób posługujących się standardami może stworzyć propozycje zmiany, przedstawiając poniższe informacje osobie odpowiedzialnej:
Numer zmienianego standardu (lub propozycja nowego numeru).
Treść standardu
Argumentacja przemawiająca za przyjęciem nowego standardu
Argumentacja przemawiająca za odrzuceniem bieżącego standardu
Proponowane zmiany standardów zostaną rozprowadzone pośród członków komisji zajmującej się standaryzacją. Jeśli zmiany zostaną zaaprobowane, nowa wersja dokumentu zostanie udostępniona do pobrania. Obecna wersja powstała na bazie wersji sprzed 2ch lat i nowych doświadczeń, i jest w ciagłej modyfikacji wynikającej z braku czasu, postaramy sie zeby byla jak najbradziej aktualna - w koncu tylko w takiej postaci nadaje sie do wykorzystania.
