W sumie to, że się "zafiksowaliście na MD" przesłania Wam treść tego dokumentu.
Nie my się zafiksowaliśmy na MD, tylko ty się zafiksowałeś na nieużywaniu MD, stosując przy tym żenującą argumentacją. I to przesłania treść tego dokumentu, bo mało komu chce się robić jakieś konwersje do innych formatów.
Potarzam. Dokumentacja nie jest dla ciebie, tylko dla czytelników. To tobie zależy żeby dotrzeć do ludzi z jakaś treścią, a nie nam by ją poznać. Więc słuchaj rad, które ci dają, bo inaczej czytelników nie zdobędziesz.
A została ona dokładnie przemyślana, starannie sformułowana i starannie sformatowana.
Szczerze mówiąc tego nie widać.
Jakoś nie widzę, by ktoś z Was potraktował ten dokument jako wyzwanie i był zdolny do napisania swojej "Sztuki kodowania w C++".
Bo niestety, to żadne wyzwanie. Pomijając, ze merytorycznie nie widać tam 22 lat doświadczenia (prędzej 22 dni), to stylistycznie ten dokument przypomina wpis egzaltowanego licealisty, mieszającego emocje z faktami. Powiem krótko i dosadnie - nie potrafisz pisać takich tekstów i nie powinieneś się za to brać. Gdyby było widać, że się znasz na C++, to można byłoby Ci zasugerować inną formę dzielenia się wiedzą i doświadczeniem albo popracowania nad stylem. U ciebie nie ma ani jednego ani drugiego, nie ma punktu wyjścia by coś poprawiać, bo wszystko jest słabe.
Aby nie być gołosłownym, kilka przykładów:
`2. Analizuj problem
Niektórzy całe życie się głowią czy należy opracowywać rozwiązanie od ogółudo szczegółu czy odwrotnie. Rozwiązanie jest proste: jeśli nasz cel jest sformułowany wysokopoziomowo to jasne jest, że naszympunktem wyjścia powinno być wyjście z tego punktu i formułowanie kolejnychkroków koniecznych do dotarcia do celu (działającego urządzenia, ew.Programu)
[...]`
Analiza problemów w programowaniu jest zagadnieniem, na temat którego można napisać wiele grubych książek. Tymczasem powyżej zacytowałem mniej więcej 25% tego co masz do powiedzenia na ten temat. Napisałeś jedno zdanie, które jest tylko częściowo słuszne. Napisałeś "jeśli nasz cel jest sformułowany wysokopoziomowo to coś", czyli if { [...] } A gdzie jest tu else, ja się pytam? Gdzie jest w ogóle uzasadnienie twoich tez?
2.4Planowany czas projektu = optymistyczny czas x 2,7 - skąd ta wartość. Czemu nie 2.8 albo 3.14159?
Dalej jest nie lepiej, bo twoje rady to nagłówki, których nie chciało ci się rozwinąć. To co zrobiłeś przypomina bardziej szkic książki zrobiony w 10 minut na kolanie, którego autor zapomniał wypełnić treścią. A rady wpadają do następujących kategorii:
- Banały, o których wie każdy z minimalnym doświadczeniem: np.
Starannie projektuj i dokumentuj architekturę i algorytmy
- Tzw. 'rules of thumb` tyle, że wymyślone tylko przez ciebie, nie sprawdzone, nie poparte niczym,
- Ogólniki, mówiące co trzeba zrobić, co zresztą wie każdy rozsądnie myślący, ale bez wyjaśnienia jak: np:
2.3 Minimalizuj ryzyko projektu. Komentujesz to jednym zdaniem, pomijając fakt, że mogą być rozmaite ryzyka związane z projektem.
- Zwyczajne bzdury, np:
Używaj Qt: najlepszej biblioteki do programowania w C++, Nigdy nie używaj struct
Wszystko jest napisane z wąskiego punktu widzenia - związanego z zanikającym obszarem wykorzystania C++ w aplikacjach biznesowych.
Podsumowując: całość to mieszanka banałów związanych z językiem C++, inżynierią oprogramowania, pomieszanych z własnymi poglądami, napisana fatalnym językiem. Jedyną jej zaletą jest to, że jest krótka.
