Ответ
-
Разделение ответственностей (SoC)
Каждый модуль/компонент должен решать одну задачу. Например, UI-логика отдельно от бизнес-логики. -
Dependency Injection (DI)
Внедрение зависимостей через параметры или контекст, а не жесткие импорты.
// Плохо
class AuthService {
private api = new ApiService(); // Жесткая зависимость
}
// Хорошо
class AuthService {
constructor(private api: ApiService) {} // DI
}-
Использование интерфейсов/абстракций
Зависимости от абстракций, а не конкретных реализаций. -
Принцип единой ответственности (SRP)
Функция/класс должен иметь одну причину для изменения. -
Чистые функции
Функции без сайд-эффектов, зависящие только от входных параметров. -
Тестируемость
Код должен легко покрываться unit-тестами (изоляция зависимостей). -
Слоистая архитектура
Разделение на presentation, domain, data слои (например, по аналогии с Clean Architecture).
Ответ 18+ 🔞
Да ты посмотри, какой цирк с конями развели в коде! Будто в помойке ковыряются, а не программируют. Слушай сюда, я тебе сейчас на пальцах объясню, как не быть мудаком в разработке.
1. Разделение ответственностей (SoC)
Это ж элементарно, Ватсон! Нельзя, чтобы один модуль был как та швабра — и пол помыл, и посуду вытер, и в жопу тебе заехал. Каждый кусок кода должен делать что-то одно, блядь. Интерфейсы — отдельно, логика — отдельно, работа с данными — отдельно. А то получится каша, в которой даже черт ногу сломит.
2. Dependency Injection (DI)
Вот это, сука, вообще основа основ! Не надо тупо создавать зависимости внутри класса, как последний распиздяй. Это как пришить себе руки к жопе — потом не оторвешь. Передавай зависимости извне, будь человеком!
// Пиздец как делать НЕ надо
class AuthService {
private api = new ApiService(); // Жёсткая привязка, тебе же пиздец потом будет!
}
// А вот так — красиво, как у людей
class AuthService {
constructor(private api: ApiService) {} // Всё пришло извне, жизнь удалась
}3. Использование интерфейсов/абстракций
Работай с абстракциями, а не с конкретными реализациями, ёпта! Это как с женщинами: не надо привязываться к одной, ищи общие черты. Потом легче будет поменять, когда текущая начнёт мозги ебать.
4. Принцип единой ответственности (SRP)
Если твой класс или функция меняются по пяти разным причинам — ты уже проебался. Одна штука — одна задача. Не надо делать из функции универсального солдата, который и воевать умеет, и борщ варить.
5. Чистые функции
Функция должна быть как монашка: взяла что-то на вход, отдала результат, и никого не трогала по пути. Никаких внезапных изменений глобальных переменных, никаких запросов налево. Иначе потом будешь искать баг, как иголку в говне.
6. Тестируемость
Если код нельзя нормально покрыть тестами — это не код, а говно в файле. Изолируй зависимости, делай моки, не прячь логику в дебрях фреймворка. Иначе тестировщики тебе такого наговорят, что мама не горюй.
7. Слоистая архитектура
Представь, что код — это многослойный торт. Presentation (показ), domain (логика), data (данные) — всё отдельно. Нельзя, чтобы крем из одного слоя перетекал в другой, а потом ещё и коржи перемешались. Это же ебаный беспорядок!
Вот так, коротко и без соплей. А то некоторые пишут код, будто обезьяна с гранатой — страшно смотреть.