Frontend | Вопросы собесов

🤔 Какие используешь подходы для написания приложения которую проще поддерживать, чем делать первоначальную разработку?

При разработке frontend-приложений, которые в будущем будет проще поддерживать и масштабировать, я придерживаюсь ряда ключевых подходов.

🟠

Разделение ответственности (Separation of Concerns)
Это значит, что код должен быть разделен по зонам ответственности. В frontend-разработке это проявляется в:
Чистом разделении логики, представления и данных (например, с помощью архитектуры MVC, MVVM или FLUX).
Использовании компонентов в React/Vue или шаблонов в Angular.
Разделении CSS, JS и HTML, либо использовании методологий, где стили хранятся рядом с компонентом (CSS Modules, Styled Components).
Вместо того, чтобы писать всю логику и разметку в одном файле:

function App() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

Я разделяю бизнес-логику и представление

// CounterLogic.js
export function useCounter() {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1);
  return { count, increment };
}

// Counter.js
import { useCounter } from "./CounterLogic";
function Counter() {
  const { count, increment } = useCounter();
  return <button onClick={increment}>Count: {count}</button>;
}

🟠

Компонентный подход и повторное использование кода
Frontend-приложения должны строиться из переиспользуемых и изолированных компонентов. Это уменьшает дублирование кода и делает его понятным.

// Button.js (переиспользуемый компонент)
function Button({ onClick, children }) {
  return <button onClick={onClick}>{children}</button>;
}

// Counter.js (использует Button)
function Counter() {
  const [count, setCount] = useState(0);
  return <Button onClick={() => setCount(count + 1)}>Count: {count}</Button>;
}

🟠

Чистый код и читаемость
Код должен быть понятным не только мне, но и другим разработчикам.
Понятные имена переменных и функций. Вместо x → userAge, вместо doSmth() → calculateTotalPrice().
Меньше вложенности. Вместо кучи if и else, лучше использовать early return.
Разбиение кода на модули. Один файл = одна зона ответственности.

function getDiscountedPrice(price, discount) {
  if (discount <= 0) return price;
  return price - price * (discount / 100);
}

🟠

Состояние приложения: локальное vs глобальное
В зависимости от сложности приложения нужно правильно управлять состоянием:
Локальное состояние – useState (React), ref (Vue) для простых данных внутри компонента.
Глобальное состояние – Redux, MobX, Zustand, Pinia, Context API – когда данные нужны многим компонентам.
Серверное состояние – React Query, SWR – когда данные приходят с API и их нужно кешировать.

🟠

Следование принципам SOLID и DRY
DRY (Don't Repeat Yourself) – не повторяем код, используем функции, хуки, компоненты.
SOLID – например, принцип единственной ответственности (Single Responsibility Principle) гласит, что каждый компонент или функция должны решать только одну задачу.

function sendEmailAndSaveToDB(user) {
  sendEmail(user.email);
  saveUserToDatabase(user);
}

Лучше разделить логику

function sendEmail(email) { /* отправка письма */ }
function saveUserToDatabase(user) { /* сохранение в БД */ }
function registerUser(user) {
  sendEmail(user.email);
  saveUserToDatabase(user);
}

🟠

Использование TypeScript
TypeScript помогает избежать ошибок и делать код предсказуемым.

type User = {
  id: number;
  name: string;
};

function getUserName(user: User): string {
  return user.name;
}

🟠

Документация и кодстайл
ESLint + Prettier → автоформатирование и проверка стиля.
JSDoc/TypeScript → документация функций и типов данных.
Storybook → для документирования UI-компонентов.

Ставь 👍 и забирай 📚 Базу знаний

Please open Telegram to view this post