Добре, я думаю, ми вибрали найдовший шлях. Я справді вражений тим, як зараз через надмірне використання boiler-plate коду надто ускладнюються фреймворки.
У мене є багато думок залежно від мови програмування, ось кілька зауважень:
C++
Сьогодні я бачив рекламу курсів з C++ на YouTube, і це було досить цікаво, вони вчать різними способами робити одне й те ж і дозволяють бути креативним. Одне з найскладніших завдань на програмістських співбесідах — це коли у вас немає відповіді на те, що питає інтерв'юер, тоді ви помиляєтеся… і йдете на наступну співбесіду, сподіваючись, що інша людина думає так само, як і ви.
Більшість інтерв'юерів були дуже здивовані, побачивши, який код використовується в продакшн середовищах.
Як приклад хочу показати вам цей фрагмент коду. Це частина тестування утиліти стиснення LZ4:
static void test_compress(FILE* outFp,FILE* inpFp,size_t messageMaxBytes,size_t ringBufferBytes)
{
LZ4_stream_t* const lz4Stream = LZ4_createStream();
const size_t cmpBufBytes = LZ4_COMPRESSBOUND(messageMaxBytes);
char* const cmpBuf = (char*) malloc(cmpBufBytes);
char* const inpBuf = (char*) malloc(ringBufferBytes);
int inpOffset = 0;
for ( ; ; )
{
char* const inpPtr = &inpBuf[inpOffset];
#if 0
// Read random length data to the ring buffer.
const int randomLength = (rand() % messageMaxBytes) + 1;
const int inpBytes = (int) read_bin(inpFp, inpPtr, randomLength);
if (0 == inpBytes) break;
#else
// Read line to the ring buffer.
int inpBytes = 0;
if (!fgets(inpPtr, (int) messageMaxBytes, inpFp))
break;
inpBytes = (int) strlen(inpPtr);
#endif
{
const int cmpBytes = LZ4_compress_fast_continue(
lz4Stream, inpPtr, cmpBuf, inpBytes, (int) cmpBufBytes, 1);
if (cmpBytes <= 0) break;
write_uint16(outFp, (uint16_t) cmpBytes);
write_bin(outFp, cmpBuf, cmpBytes);
// Add and wraparound the ringbuffer offset
inpOffset += inpBytes;
if ((size_t)inpOffset >= ringBufferBytes - messageMaxBytes) inpOffset = 0;
}
}
write_uint16(outFp, 0);
free(inpBuf);
free(cmpBuf);
LZ4_freeStream(lz4Stream);
}
Як ви бачите, ви створюєте вказівник за допомогою функції malloc, а потім звільняєте пам'ять через функцію "free" у C++.
Я не кажу, що це більш оптимізовано, ніж смарт-показники, я лише хочу сказати, що це не єдиний інструмент у вашому інструментарії.
PHP
Всі його ненавидять, але я думаю, що проблема всіх людей полягає в кількості псевдонімів для функцій. Але якщо подивитися з іншого боку, (окрім того, щоб вивчити всі) це досить хороша мова.
Загалом, набір серверів Apache є досить хорошим, він дозволяє мінімізувати розмір пакетів, що надсилаються у форматі стиснення gunzip, дозволяє шифрування каналу зв'язку за допомогою PGP (Pretty Good Privacy), серед інших переваг.
З іншого боку, Node.js — це своєрідний "доказ концепції", і дуже поганий… По-перше, в інтернеті існує модель OSI, яка дозволяє здійснювати комунікацію між системами, але ми не будемо брати все, тільки основну модель MVC (зараз існують інші моделі, але ми обираємо цю для зручності реалізації). Тепер, якщо ви прочитаєте код проекту Node.js, ви помітите, що інтерфейс з операційною системою написаний на C++, а інтерфейс для розробки — на JavaScript, тому якщо я не маю дуже гарної безпеки, легко здійснити відхилення (наприклад, SQL ін'єкцію).
Якщо система пакетів Node.js буде правильно виправлена, це може зменшити такі вразливості, але проблема в тому, що немає контролю над пакетами, які завантажують розробники.
C
Це найбільш складний випадок у цьому списку… Проблема з C# полягає в тому, що він дозволяє використовувати його в будь-якій системі, але політика підтримки бібліотек, зміни компонентів, зворотна сумісність тощо роблять цю мову дуже небезпечною.
Я знаю, що це не завжди залежить від розробника, але ваша система повинна бути працездатною протягом тривалого часу.
Компанії не витрачатимуть гроші на оновлення всієї системи, але проблема в тому, що Microsoft не переймається цим і буде продовжувати оновлювати свою систему.
Один з прикладів — комп'ютери, що використовують Windows ME, для яких необхідна версія 4.5 .NET (принаймні, я бачив деякі комп'ютери, які все ще працюють).
Але, як і з Java, якщо вам пощастить, продовжуйте.
Java
Ця мова в своїй основі є однією з моїх улюблених, велика колекція бібліотек для створення будь-чого (веб-сервери, JINI, Java Card, FX тощо). Цікаво, що коли ви читаєте підручники чи дивитеся на YouTube процес інсталяції, то вам обов'язково пропонують також встановити Spring framework.
Я знаю, що Spring framework створений для побудови мікросервісів, але хіба ми не можемо зробити це за допомогою Docker? Підхід, запропонований Spring, вимагає «жорсткого кодування» (very bad practice, mainly for unexpected behaviours in the compiler) сервера, і це потрібно робити щоразу, коли додаєте новий компонент.
Цей «додаток» для кожного компонента — це boiler-plate, який лише збільшує розмір фінальної програми, сповільнюючи її завантаження, а також робить код менш портативним для міграції чи оновлення.
SQL
Я буду трохи жорстким у цьому випадку… Як дуже важлива частина кожного проєкту, SQL мова була винайдена для того, щоб ви могли отримувати дані більш прозорим способом без інтерфейсів. Теорія множин в математиці — це модель, на основі якої працює механізм бази даних.
Виходячи з цієї тези, оптимальний спосіб отримати інформацію з таблиці — це використати SQL запит і базу даних, а розробник відповідальний за те, щоб правильно вбудувати це в модель на зразок «MVC», щоб отримати дані в нижчих шарах і потім відформатувати їх, роблячи більш «читабельними» для користувача.
Потім з’явились No-SQL бази даних (я використовую MongoDB), що частково було хорошим рішенням, бо іноді керівник просить додати нову колонку в вже велику таблицю з товарами, і тоді вам доводиться переробляти індексацію і оптимізацію, (і сподіваючись, що тільки ця таблиця була змінена, якщо ні — ви проведете наступні кілька днів, працюючи над усіма таблицями, що змінились…). Тому використання документів стало перевагою.
Швидко до кількох років тому почали з’являтися різні фреймворки, щоб «допомогти» вам з дизайном SQL запиту, але проблема в тому, що ви додаєте ще один шар складності до проєкту. Крім того, вони не повністю «оптимізовані», наприклад, SQLAlchemy (use the object relational mapper) робить розробку складнішою, оскільки потрібно створювати клас, а потім передавати його в об'єкт і таким чином маніпулювати даними.
Це занадто велика затримка, якщо вам потрібно тренувати модель штучного інтелекту (але якщо ви розробляєте сайт для електронної комерції, це ідеально для інкапсуляції та спільного використання даних, (наприклад, можна використовувати той самий батьківський клас Person для клієнта та працівника)).
Bash
Як завжди, дуже добре.
Matlab
Дуже добре, але має дуже малу нішу впливу, але ідеально підходить для моделювання та аналізу скінчених елементів.
Python
Має вражаючу історію, хорошу колекцію фреймворків (деякі дуже зручні, як pandas і Numpy, але деякі зловживаються, як Flask). Також дає можливість бути креативним, доповнюючи рішення для проблем, які ви хочете вирішити.
Javascript
Я не є Front-End розробником; я вважаю, що вам потрібно багато креативності і терпіння (щоб працювати з 80 різними Front-End фреймворками), але це не провина розробника.
Я використовую лише Bootstrap для розробки моїх особистих проєктів і деяких користувацьких інтерфейсів у своїй роботі. Тому поточна проблема з JavaScript — це неконтрольована система менеджера пакетів та взаємозалежність фреймворків.
Те саме відбувається й з дистрибутивами, насправді це частина того, як працює Linux, дозвольте пояснити.
Linux — це монолітне ядро з багатьма модулями навколо, які визначають дистрибутив.
Але різниця в тому, що існує стандарт, який регулює, яка бібліотека чи компонент можуть стати частиною системи пакетів (подібно до gem в мові Ruby).
Ruby
Дуже гарна мова, яка значно покращилась з часом, має дуже велику бібліотеку gem, також фреймворк "Ruby on Rails" покращився з часом і дозволяє використовувати SQL мову, що насправді є набагато практичнішим за Active Record (я припускаю, що вони вважали, що це легше за SQL, але тепер я бачу, що різниці мало, єдине, що "GROUP BY" та "ORDER BY" більш рідні в Active Record).
Висновок
Підсумовуючи, я думаю, що якщо ми повернемося до рідних мов програмування, ми зможемо отримати максимум користі з них (більшість із них вже покращені новими патернами, одним з прикладів можуть бути lambda функції), це зніме велику криву навчання та зробить розмір нашого проєкту меншим.
Успіхів у кодуванні!!
Перекладено з: “From Static Scripts to Dynamic Dreams: How Programming Has Evolved Since 2009”