krytyka IO

witam. chciałbym się dowiedzieć co najbardziej was wnerwia w IO. jakie są jej wady (jeśli są). bardzo proszę o wpisanie wszystkiego co wam przychodzi na myśl. Dla mnie to będą naprawdę ważne wskazówki i informacje. pozdrawiam

Mnie 'wnerwia', że wiele osób podchodzi do tego jak do ścisłej teorii matematycznej, a nie jak do narzędzia komunikacji. Moja zasada jest taka, że jeśli coś jest bardzo czytelne, ale nie koniecznie zapisane standardowo, to nie należy tego poprawiać. Denerwuje mnie, gdy ktoś to poprawi kosztem czytelności.

Z drugiej strony denerwują mnie ludzie, którzy byle jak podchodzą do projektowania. Myślą, że jak 'to' z 'tym' połączą to przecież dobrze oddadzą ideę. Od razu widać, kto kiedyś z nich musiał potem programować na podstawie tego, co wcześniej nakreślił.

dzięki za uwagi Szczawik. A czy spotkałeś się (lub ktokolwiek) z ludźmi którzy pomijają ten etap tworzenia projektów, uważając, że IO nie daje wymiernych korzyści? Jak to argumentują?

wyjaśnie czemu mnie to interesuje :) - jestem studentem na II roku informatyki stosowanej i wpakowałem się w referat o krytyce inżynierii oprogramowania, trafiłem tutaj szukając jakiś materiałów. Dlatego każda uwaga jest dla mnie cenna.

Zgadzam się ze Szczawikiem. Ogólne normy i schematy byc muszą, bo bez tego powstałby bajzel. Jednak prostota ponad wszystko. Przykład niesławnej instrukcji goto w pascalu:

Aby przerwać pętlę używa się procedury Break. Jednak ona powoduje przerwanie tylko tej petli w której jest wywołana:

for i := 1 to 10 do
 for j:= 1 to 10 do
  for k := 1 to 10 do
    if cos_tam then Break;

I tu break przerwie tylko pętlę for i.. a ja chcę przerwać wszystkie na raz

A teraz niezalecane goto

for i := 1 to 10 do
 for j:= 1 to 10 do
  for k := 1 to 10 do
    if cos_tam then goto BreakPoint;

 BreakPoint:

Witam

Trudno powiedzieć ,że Inzynieria Oprogramowania zawiera wady jako taka, gdyż jets to tylko dziedzina. Najwieksze niebezpieczeństwo widze w tym ,że staję się ona coraz bardziej "modna". Coraz częsciej pojawiają się wątki o tym ,że ktoś chce napisać program oparty na klasach, "bo przecież teraz pisze się programy obiektowe".Podobnie jest z wzorcami, widziałem ludzi ,ktorzy uważali ,ze im więcej w danym projekcie użyjesz wzorców projektowych , tym lepszym "specjalistą" jesteś.
Krążą po sieci programy-żarty , w ktorych "helllo world" wypisuje program mający kilkaset czy kilka tysiecy linijek implementujący wszystkie mozliwe wzorce projektowe.

pzdr

i := 1;
BreakPoint := False;
while not BreakPoint and i < 10 do
begin
 i := i + 1;
 j := 1;
 while not BreakPoint and j < 10 do
 begin
  j := j + 1;
  k := 1;
  while not BreakPoint and k < 10 do
  begin
    if cos_tam then BreakPoint := True;
  end;
end;

lub

procedure Petle;
var
   i, j, k: Integer;
begin
for i := 1 to 10 do
 for j:= 1 to 10 do
  for k := 1 to 10 do
    if cos_tam then Exit;
end;

Tak zadziała i na upartego goto nie będzie. Swego czasu gdzieś tutaj przerabiałem kod (chyba ŁF-a), tak by nie było goto, jako proof of concept. Nie wiem nawet, czy nie było czytelniejsze :P

Co nie zmienia faktu, że dla czytelności kodu nie waham się łamać zasad.

Tylko, że Exit opuszcza procedurę, a mi chodziło o przypadek kiedy trzeba przerwać pętlę, bez wychodzenia z procedury

Oleksy_Adam napisał(a)

Tylko, że Exit opuszcza procedurę, a mi chodziło o przypadek kiedy trzeba przerwać pętlę, bez wychodzenia z procedury

to wtedy właśnie wsadzasz te pętle w osobną procedurę albo robisz to na innych pętlach. BTW goto zawsze można pominąć, a w dobie projegramowania obiektowego to nie jest najpopularniejsza komenda

co do pomijania IO (czyli tworzenia przypadków użycia, diagramów klas, itd) to możecie mnie zjechać ale jeśli program, który pisze zawiera się na 3 formach, w sumie ma 6 przycisków (co nie znaczy, że nic nie robi, bo np. ostatnio taki pisałem i jego głównym zadaniem było wyeksportowanie z bazy danych w postaci dosyć złożonego raportu) to olewam IO

dzięki za pomoc. Znalazłem taki artykuł jeśli to by kogoś jeszcze zainteresowało:
http://en.wikipedia.org/wiki/Criticism_of_software_engineering

PawelW zwrócił uwagę na bardzo ważną rzecz - moda na tworzenie obiektów. Zbędnych, nieuzasadnionych obiektów - bo tak musi być. Chcesz być nowoczesny - twórz własne obiekty. Moim zdaniem - nie musisz, nie twórz! Szczególnie w małych aplikacjach.

IP -> nie wiem jak dla ciebie, ale dla mnie projektowanie małych aplikacji jest bez sensu ;) Dopuki możesz ogarnąć rozumem i pamięcią cały projekt bez żadnych diagramów i wykresów można z powodzeniem programować 'na żywioł'. Ja zwykle w takich wypadkach staram się rozwiązać problem za pomocą samych funkcji, a dopiero kiedy maja pełno zmiennych statycznych i zaczynam się zastanawiać nad wprowadzeniem paru zmiennych globalnych, naturalnie 'zmieniają się' one w obiekty ;)

Osobiście uważam, że korzystanie z inżynierii oprogramowania jest sprawą wyśrubowaną. Nie korzystał bym z IO gdybym tworzył coś nie dużego bo i po co - więcej stracił bym czasu na przechodzenie kolejnych faz (analizy, projektowanie, implementacji itp.) niż to wszystko by było warte. Ale jeżeli zabieram się za duży system sądzę, że warto z tego skorzystać. Nauka nie jest najnowsza i się sprawdza w takich sytuacjach, dlatego wole skorzystać z czegoś co jest sprawdzone niż samemu się gimnastykować aby popełnić jak najmniej błędów.