Zrozumieć programowanie ? 3 kluczowe zasady
Autor: Gynvael Coldwind
W niniejszym, artykule postaram się przedstawić trzy kluczowe punkty ze szkoły programowania, którą osobiście preferuje i o której piszę w swojej książce pt. "Zrozumieć Programowanie".
1. Kod jest najlepszą dokumentacją.
Programiści, jako użytkownicy danej funkcji, klasy, modułu, biblioteki czy API, często muszą sprawdzić jak dana funkcjonalność zachowa się w pewnym mniej lub bardziej specyficznym przypadku - wtedy zazwyczaj zwracamy się ku dokumentacji. Niestety, dokumentacja często jest wysokopoziomowa i pomija pewne istotne dla nas szczegóły, a w innych wypadkach jest nieaktualna, słabej jakości lub w ogóle nie istnieje.
W takich przypadkach warto sięgać do kodu źródłowego danej funkcji, i poszukać w nim odpowiedzi na nasze pytanie - dostępny kod źródłowy jest zazwyczaj znaczniej bogatszym źródłem informacji niż dokumentacja. Wymaga to oczywiście pewnej wprawy - w końcu kod innej osoby / grupy osób działający często w innej warstwie abstrakcji lub będący napisany w innym języku, będzie dla nas wyglądał dość egzotycznie - na szczęście szybko można do tego przywyknąć.
Co za tym idzie - warto pisać kod tak, aby był czytelny dla innych. Przykładowo, zamiast:
a ^= b ^= a ^= b;
lepiej jest napisać:
std::swap(a, b);
A co jeśli zabraknie nawet kodu źródłowego? W takim przypadku pozostaje inżynieria wsteczna (ang. reverse engineering), której podstawy warto znać, szczególnie, że czasami przydaje się również przy debugowaniu naszych własnych aplikacji.
2. Zaprzyjaźnij się z oficjalną dokumentacją.
Początkujący programiści często korzystają z wszelkiej maści tutoriali i kursów - są to bardzo dobre formy wprowadzające w programowanie. Niemniej jednak najwięcej i najbardziej szczegółowe informacje prawie zawsze zawiera oficjalna dokumentacja danego języka programowania (np. International Standard ISO/IEC 14882:2014(E) Programming Language C++), architektury (np. Intel® 64 and IA-32 Architectures Developer's Manual) czy protokołu (np. RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification). Niestety, dokumentacja tego typu jest zazwyczaj pisana bardzo formalnym językiem, przez co czytanie jej bardziej przypomina czytanie ustawy lub kodeksu aniżeli technicznej dokumentacji. Co za tym idzie - trzeba się do tego faktu przyzwyczaić. Oficjalna dokumentacja jest często kopalną ciekawostek i elementów pomijanych w innych materiałach, więc zdecydowanie warto się nią zainteresować.
3. Architektura komputera i systemu operacyjnego jest istotna.
Programując w językach wysokiego poziomu łatwo zapomnieć, że gdzieś poniżej znajduje się system operacyjny oraz fizyczny sprzęt, którzy rządzi się własnymi prawami i który bezpośrednio wpływa na wszystkie programowe warstwy abstrakcji znajdujące się powyżej. Warto więc, by nawet programiści języków wysokopoziomowych zainteresowali się zasadą działania schedulera systemowego, systemu plików, procesora, cache'u, pamięci RAM, timerów, dysków twardych, kart sieciowych, itp. Dodatkowa wiedza z tego zakresu pozwoli w przyszłości projektować lepszej jakości software, ponieważ programista będzie mógł wziąć pewne dodatkowe, niskopoziomowe, rzeczy pod uwagę i zoptymalizować odpowiednio oprogramowanie.
