10 lipca 2009

Co to znaczy "dobrze napisać artykuł"?

Zainteresowałem się ostatnio na poważnie (z racji książki którą piszę) problematyką sprawnego władania językiem... polskim, z naciskiem na język pisany. Kupiłem opasłe tomisko traktujące o tymże języku i rozpocząłem mozolne (książka jest niezwykle gruba) studia. A tymczasem dostaję komentarz czytelnika do mojego ostatniego artykułu - że jest nieczytelny (choć merytorycznie dobry), z racji braku podziału na akapity.

Postanowiłem więc przeprowadzić eksperyment i przeredagowałem tekst co nieco. Tekst podzieliłem na akapity, które przy okazji przekonstruowałem tak, by nadać im w miarę możliwości charakter analityczny.

Akapit analityczny (powtarzam z pamięci za książką o której przed chwilą wspomniałem) to taki akapit, który zaczyna się od natychmiastowego - w pierwszym zdaniu - przedstawienia treści akapitu. Dalsze zdania stanowią rozwinięcie i wyjaśnienie stwierdzenia otwierającego akapit. Chodzi o to, aby dało się czytając tylko pierwsze zdania każdego akapitu wyłapać sens i tematykę tekstu. Naturalnie nie zawsze i nie każdy akapit powinien być właśnie taki - urozmaicenie formy też jest wskazane.

Zobaczmy co z tego wyszło i czy jest lepiej. Oto artykuł "Co to znaczy "dobrze wykonać projekt"?" w wersji 2.0:

Co to właściwie znaczy „dobrze wykonać projekt”? Zamyśliłem się co nieco nad tym inspirowany konferencją, na której ostatnio zdarzyło mi się gościć, a właściwie tym co tam usłyszałem. Widziałem na konferencji świetną prezentację o programowaniu sterowanym testami – brawa dla prelegenta; na innej prelekcji z kolei słyszałem uszczypliwe żarty ze strony publiki wykpiwającej praktyki wykonywania poprawek (tzn. bug-fixów) bezpośrednio na systemie produkcyjnym. Ktoś tam jeszcze mówił o ciągłej integracji (na tej prelekcji nie byłem), ktoś inny w jeszcze inny sposób promował techniki i sposoby tworzenia „dobrego” oprogramowania.

Odnoszę wrażenie, że wszyscy jako aksjomat przyjmują, że aplikacja powinna być zrobiona przede wszystkim „dobrze”; możliwie kompleksowo przetestowana, możliwie jak najprzyzwoiciej wdrożona.

Ja tymczasem mam wrażenie, że w rzeczywistości rzadko chodzi o osiągnięcie właśnie tych celów. Właściwie wymienione powyżej to raczej środki do pewnego celu a nie same cele, tylko czy rzeczywiście zastanawiamy się nad tym, co jest prawdziwym celem?

Oczywiście wszyscy mamy potrzebę odczuwania zadowolenia z wykonywanej przez siebie pracy – a satysfakcję mamy przeważnie z pracy wykonanej dobrze – tyle tylko, że może nie do końca potrafimy sobie zdefiniować, co to „dobrze” oznacza.

Dobrze – w pewnej konkretnej sytuacji – może przecież oznaczać przede wszystkim szybko. Może firma która zleca nam wykonanie jakiegoś rozwiązania ma w planach zakup albo wykonanie poważnego systemu w przyszłości a póki co chcą tylko czegoś taniego i wykonanego szybko, po to by móc dodać do swej oferty możliwie szybko nowy produkt; po to by pomóc sobie samemu zdefiniować wymagania funkcjonalne dla aplikacji docelowej? A może są jeszcze jakieś inne powody? A może nie powinniśmy się zastanawiać dlaczego? Może po prostu powinniśmy słuchać i starać się odpowiadać na rzeczywiste zapotrzebowania, zgłaszane przez tego, który za implementację nowego rozwiązania zapłaci?

To co staram się powiedzieć można de facto wyrazić w jednym zdaniu – dopasowujmy sposób pracy (sposób wykonywania i wdrażania rozwiązań) do faktycznych celów i istniejących założeń, nie do aksjomatów narzuconych nam nie wiadomo jak, kiedy i przez kogo.

Pamiętajmy jednak aby nie popadać ze skrajności w skrajność. Gdybyśmy rzeczywiście zechcieli kiedyś pokusić się o dostarczenie rozwiązania-prowizorki, nie zapominajmy, że prowizorki często są najtrwalsze. A jeśli już zdecydujemy się na wypuszczenie naprędce upichconego gniota, to liczmy się z tym, że ktoś kiedyś – nie rozumiejąc okoliczności – zapyta… „kto tą aplikację (…) wykonał”? No ale sztuka kreowania wizerunku i zabezpieczania się przed potencjalnymi atakami to już inny temat.

8 komentarzy:

Al Makoth pisze...

Postaraj się rzeczywiście robić akapity, a nie enter co zdanie.

Mariusz Lipiński pisze...

Istotą akapitu jest podział tekstu w taki sposób aby dało się go łatwiej przeczytać. Nic innego. Zerknij sobie jak pisane są artykuły w gazetach - często akapit zawiera jedno czy dwa zdania. Liczba zdań czy słów w akapicie nie jest żadnym kryterium.

Anonimowy pisze...

lepiej się czyta ten pocięty prostokąt, niż tamten zbity kwadrat (w zależności od rozdzielczości wygląda u was inaczej). A te całe "akapit, który zaczyna się od natychmiastowego - w pierwszym zdaniu - przedstawienia treści akapitu. Dalsze zdania stanowią rozwinięcie i wyjaśnienie stwierdzenia otwierającego akapit." to sprawa drugorzędna...

Janek pisze...

Tanio, szybko, dobrze - możesz wybrać tylko dwa.

Mariusz Lipiński pisze...

Dwa to by było nadto dobrze :) Często nie można mieć (tzn. nie ma) nawet jednego :)

Revontuli pisze...

Skoro jesteśmy przy języku, chciałabym zwrócić Twoją uwagę na to, że nie zostawia się na końcu linii jednoliterowych spójników i przyimków. Czyli słów typu: i, a, w, z, o, u.

Zauważyłam też w opublikowanych przez Ciebie rozdziałach podręcznika kilka przypadków błędnej pisowni końcówki "by" z osobowymi formami czasowników. Zawsze piszemy je łącznie.

No i często zapominasz o przecinkach. Na przykład w zdaniach zawierających spójnik "aby".

Pozdrawiam ;)

Mariusz Lipiński pisze...

Co do spójników i przyimków na końcu linii - polegam na łamaniu automatycznym; tzn. w linii jest tyle ile się zmieści. Zapewne dałoby się to kontrolować, ale chyba byłoby to nadto trudu jak na bloga.

Reszta uwag niewątpliwie słuszna. THX.

Revontuli pisze...

No, tak, jasne. Ale w podręczniku można by już zadbać o wstawienie niełamliwych spacji tam, gdzie trzeba.