Pozwól, że zadam ci całkowicie poważne pytanie przeciwne: jaka według ciebie jest różnica między „danymi” a „kodem”?
Kiedy słyszę słowo „dane”, myślę „stan”. Dane są z definicji rzeczą, którą sama aplikacja jest przeznaczona do zarządzania, a zatem tą samą rzeczą, o której aplikacja nie może wiedzieć w czasie kompilacji. Nie można na stałe zakodować danych, ponieważ zaraz po ich zakodowaniu staje się to zachowanie - nie dane.
Rodzaj danych różni się w zależności od aplikacji; komercyjny system fakturowania może przechowywać informacje o klientach i zamówieniach w bazie danych SQL, a program do grafiki wektorowej może przechowywać dane geometryczne i metadane w pliku binarnym. W obu tych przypadkach i pomiędzy nimi istnieje wyraźny i niezłomny podział między kodem a danymi. Dane należą do użytkownika , a nie do programisty, więc nigdy nie mogą być zakodowane na stałe.
Chodzi o to, aby mówić o najdokładniejszym technicznie opisie dostępnym dla mojego obecnego słownictwa: informacje dotyczące zachowania programu, które nie są zapisane w podstawowym języku programowania używanym do opracowania większości aplikacji.
Nawet ta definicja, która jest znacznie mniej niejednoznaczna niż samo słowo „dane”, ma kilka problemów. Na przykład, co jeśli znaczna część programu jest napisana w różnych językach? Osobiście pracowałem nad kilkoma projektami, które mają około 50% C # i 50% JavaScript. Czy kod JavaScript to „dane”? Większość ludzi powiedziałaby „nie”. A co z HTMLem, czy to „dane”? Większość ludzi nadal powiedziałaby „nie”.
Co z CSS? Czy to dane lub kod? Jeśli uważamy, że kod jest czymś, co kontroluje zachowanie programu, CSS tak naprawdę nie jest kodem, ponieważ tylko (głównie) wpływa na wygląd, a nie zachowanie. Ale tak naprawdę to nie są dane; użytkownik nie jest właścicielem, nawet aplikacja nie jest jej właścicielem. Jest to odpowiednik kodu dla projektanta interfejsu użytkownika. Jest podobny do kodu , ale nie do końca.
Mogę nazwać CSS rodzajem konfiguracji, ale bardziej praktyczną definicją jest to, że jest to po prostu kod w języku specyficznym dla domeny . To właśnie reprezentują Twój XML, YAML i inne „sformatowane pliki”. Powodem dla którego używamy języka specyficznego dla domeny jest to, że ogólnie mówiąc, jest on jednocześnie bardziej zwięzły i bardziej wyrazisty w swojej konkretnej domenie niż kodowanie tych samych informacji w języku programowania ogólnego przeznaczenia, takim jak C lub C # lub Java.
Czy rozpoznajesz następujący format?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Jestem pewien, że większość ludzi; to JSON . A oto ciekawa rzecz w JSON: w JavaScript jest to wyraźnie kod, aw każdym innym języku, to wyraźnie sformatowane dane. Prawie każdy główny język programowania ma co najmniej jedną bibliotekę do „parsowania” JSON.
Jeśli użyjemy tej samej składni w funkcji w pliku JavaScript, nie może to być nic innego niż kod. A jednak, jeśli weźmiemy ten JSON, wepchniemy go do .jsonpliku i przeanalizujemy w aplikacji Java, nagle będzie to „dane”. Czy to naprawdę ma sens?
Twierdzę, że „dane”, „konfiguracja” lub „kod” są nieodłączne od tego, co jest opisywane, a nie jak to jest opisywane.
Jeśli twój program potrzebuje słownika o wartości 1 miliona słów, aby np. Wygenerować losowe hasło, czy chcesz go zakodować w następujący sposób:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
A może po prostu wepchniesz wszystkie te słowa do pliku tekstowego rozdzielanego liniami i powiesz programowi, aby z niego czytał? Tak naprawdę nie ma znaczenia, czy lista słów nigdy się nie zmienia, nie jest to kwestia tego, czy kodujesz na stałe, czy na miękko (które wielu słusznie uważa za anty-wzór, gdy jest niewłaściwie stosowane), to po prostu kwestia jaki format jest najbardziej wydajny i sprawia, że najłatwiej jest opisać „rzeczy”, bez względu na „rzeczy”. Nie ma znaczenia, czy nazywasz to kodem, czy danymi; są to informacje wymagane przez program do uruchomienia, a format pliku płaskiego jest najwygodniejszym sposobem zarządzania nim i zarządzania nim.
Zakładając, że przestrzegasz odpowiednich praktyk, wszystkie te rzeczy i tak podlegają kontroli źródła, więc równie dobrze możesz nazwać to kodem, po prostu kod w innym i być może bardzo minimalistycznym formacie. Możesz też nazwać go konfiguracją, ale jedyną rzeczą, która naprawdę odróżnia kod od konfiguracji, jest to, czy udokumentujesz go i powiesz użytkownikom, jak go zmienić. Być może mógłbyś wymyślić jakiś fałszywy argument o interpretacji konfiguracji podczas uruchamiania lub w czasie wykonywania, a nie w czasie kompilacji, ale wtedy zacząłbyś opisywać kilka dynamicznie pisanych języków i prawie na pewno wszystko z wbudowanym silnikiem skryptowym (np. większość gier). Kod i konfiguracja to wszystko, co postanowisz nazwać je niczym, niczym więcej, niczym innym.
Teraz nie jest zagrożeniem dla uzewnętrzniania informacje, które są rzeczywiście bezpieczne modyfikować (patrz odnośnik „miękkiego kodowania” powyżej). Jeśli uzewnętrznisz tablicę samogłoskową w pliku konfiguracyjnym i udokumentujesz ją jako plik konfiguracyjny dla użytkowników końcowych, dajesz im niemal niezawodny sposób na natychmiastowe zerwanie aplikacji, na przykład poprzez umieszczenie „q” jako samogłoski. Ale to nie jest podstawowy problem z „separacją kodu i danych”, to po prostu zły sens projektowy.
Mówię młodszym deweloperom, że powinni zawsze uzewnętrzniać ustawienia, których zmiany oczekują w zależności od środowiska. Obejmuje to między innymi parametry połączenia, nazwy użytkowników, klucze API, ścieżki do katalogów i tak dalej. Oni mogą być takie same na polu dev i produkcji, ale chyba nie, a administratorzy będą decydować, jak chcą go szukać w produkcji, a nie deweloperów. Potrzebny jest więc sposób zastosowania jednej grupy ustawień na niektórych komputerach i innych ustawień na innych komputerach - ergo, zewnętrznych plików konfiguracyjnych (lub ustawień w bazie danych itp.)
Podkreślam jednak, że po prostu umieszczenie niektórych „danych” w „pliku” nie jest tym samym, co przekazanie go na zewnątrz jako konfiguracji. Umieszczenie słownika słów w pliku tekstowym nie oznacza, że chcesz, aby użytkownicy (lub dział IT) go zmienili, to tylko sposób na ułatwienie programistom zrozumienia, co się dzieje, do diabła, i, w razie potrzeby, ułatwienie sporadyczne zmiany. Podobnie, umieszczenie tych samych informacji w tabeli bazy danych niekoniecznie liczy się jako eksternalizacja zachowania, jeśli tabela jest tylko do odczytu i / lub DBA są instruowane, aby nigdy jej nie przekręcać. Konfiguracja oznacza, że dane są zmienne, ale w rzeczywistości jest to określane przez proces i obowiązki, a nie przez wybór formatu.
Podsumowując:
„Kod” nie jest terminem ściśle zdefiniowanym. Jeśli rozszerzysz swoją definicję o języki specyficzne dla domeny i wszystko inne, co wpływa na zachowanie, wiele z tych pozornych tarć po prostu zniknie i wszystko to będzie miało sens. Możesz mieć nieskompilowany „kod” DSL w pliku płaskim.
„Dane” oznaczają informacje, które są własnością użytkownika (użytkowników) lub przynajmniej osoby innej niż programiści i nie są ogólnie dostępne w czasie projektowania. Nie można go zakodować na stałe, nawet jeśli chcesz to zrobić. Z możliwym wyjątkiem kodu samodmodyfikującego , oddzielenie kodu od danych jest kwestią definicji, a nie osobistych preferencji.
„Miękkie kodowanie” może być okropną praktyką w przypadku nadmiernego zastosowania, ale nie każdy przypadek eksternalizacji koniecznie stanowi miękkie kodowanie, a wiele przypadków przechowywania informacji w „płaskich plikach” niekoniecznie jest prawdziwą próbą eksternalizacji.
Konfiguracja to specjalny rodzaj miękkiego kodowania, który jest konieczny ze względu na wiedzę, że aplikacja może wymagać działania w różnych środowiskach. Wdrożenie osobnego pliku konfiguracyjnego wraz z aplikacją jest znacznie mniej pracochłonne (i znacznie mniej niebezpieczne) niż wdrożenie innej wersji kodu w każdym środowisku. Tak więc niektóre rodzaje miękkiego kodowania są faktycznie przydatne.