Блог инженера

History is written by its contributors

Как перестать волноваться о своем коде и стать x10 разработчиком

2025-11-10 время чтения 6 мин Career Ilya Brin

Вы пишете код, потом переписываете его три раза, потом рефакторите ещё раз, потом удаляете и начинаете заново. Знакомо? Перфекционизм в коде — это не добродетель. Это тормоз.

Разберём, как перестать волноваться о каждой строчке и начать создавать реальную ценность.

Проблема: паралич перфекциониста

Типичный день перфекциониста:

  • 2 часа на выбор названия переменной
  • 3 часа на спор о tabs vs spaces
  • 4 часа на рефакторинг кода, который никто не читает
  • 1 час на реальную работу

Результат: 10 строк кода, 0 ценности для бизнеса.

Что такое x10 разработчик

x10 разработчик - это не тот, кто пишет в 10 раз больше кода. Это тот, кто создаёт в 10 раз больше ценности.

Ценность ≠ Количество кода

Ценность = Решённые проблемы × Скорость × Качество

Принцип 1: Идеального кода не существует

Любой код можно улучшить. Всегда. Бесконечно.

Но есть deadline, бюджет и реальные пользователи, которые ждут фичу.

// Перфекционист
func CalculatePrice(items []Item, discount float64, tax float64, 
    shipping float64, coupon string, membership MembershipLevel,
    region Region, currency Currency) (Price, error) {
    // 500 строк идеального кода
}

// Прагматик
func CalculatePrice(cart Cart) float64 {
    return cart.Subtotal() - cart.Discount() + cart.Tax()
}

Начните с простого. Усложните, когда понадобится.

Принцип 2: Работающий код лучше идеального

// Это работает
if user != nil && user.IsActive && user.HasPermission("read") {
    return data, nil
}

// Это "красиво", но не работает
return data, user.Validate().
    CheckActive().
    VerifyPermission("read").
    Execute()

Сначала заставьте работать. Потом сделайте красиво. Потом сделайте быстро.

В таком порядке.

Принцип 3: Удаляйте код, не добавляйте

Лучший код - это код, которого нет.

// Было: 200 строк абстракций
type AbstractFactoryBuilder interface {
    CreateFactory() Factory
}

type Factory interface {
    CreateProduct() Product
}

// Стало: 5 строк
func NewProduct() *Product {
    return &Product{}
}

Каждая строка кода - это:

  • Потенциальный баг
  • Код для поддержки
  • Код для тестирования
  • Код для документирования

Меньше кода = меньше проблем.

Принцип 4: Копипаста лучше плохой абстракции

Да, вы правильно прочитали.

// Плохая абстракция
func ProcessEntity(entity interface{}, config Config, 
    validator Validator, transformer Transformer) error {
    // Универсальный код для всего
}

// Две простые функции
func ProcessUser(user User) error {
    // Конкретный код для пользователя
}

func ProcessOrder(order Order) error {
    // Конкретный код для заказа
}

Правило трёх: дублируйте один раз, дублируйте два раза, абстрагируйте на третий.

Принцип 5: Тесты важнее архитектуры

// Сложная архитектура без тестов
type Service struct {
    repo Repository
    cache Cache
    logger Logger
    metrics Metrics
}

// Простой код с тестами
func CreateUser(name string) error {
    return db.Insert("users", name)
}

func TestCreateUser(t *testing.T) {
    err := CreateUser("test")
    assert.NoError(t, err)
}

Тесты дают уверенность. Архитектура даёт сложность.

Принцип 6: Документация в коде, а не в комментариях

// Плохо
// Эта функция проверяет пользователя
func check(u *User) bool {
    return u.active && u.verified
}

// Хорошо
func IsUserAllowedToLogin(user *User) bool {
    return user.IsActive && user.IsVerified
}

Код должен читаться как книга. Комментарии в данном случае - признак плохого кода.

Принцип 7: Решайте проблему, а не пишите код

// Программист думает: "Напишу микросервис"
type UserService struct {
    grpcServer *grpc.Server
    kafka *kafka.Producer
    redis *redis.Client
}

// Бизнес думает: "Нужна кнопка регистрации"
func RegisterUser(email, password string) error {
    return db.Insert(email, password)
}

Спросите себя: какую проблему я решаю? Нужен ли для этого код?

Иногда ответ - нет.

Принцип 8: Доставляйте часто, итерируйте быстро

// Версия 1: MVP за неделю
func Search(query string) []Result {
    return db.Query("SELECT * FROM items WHERE name LIKE ?", query)
}

// Версия 2: через месяц, если нужно
func Search(query string) []Result {
    cached := cache.Get(query)
    if cached != nil {
        return cached
    }
    results := elasticSearch.Search(query)
    cache.Set(query, results)
    return results
}

Пользователи дадут фидбек. Метрики покажут узкие места. Не оптимизируйте заранее.

Принцип 9: Автоматизируйте рутину

// Ручная работа
// 1. Запустить тесты
// 2. Проверить линтер
// 3. Собрать билд
// 4. Задеплоить
// 5. Проверить логи

// Автоматизация
// git push
// CI/CD делает всё остальное

Время разработчика дороже времени машины. Автоматизируйте всё, что можно.

Принцип 10: Учитесь на чужих ошибках

// Не пишите свой
func MyCustomJSONParser(data string) (map[string]interface{}, error) {
    // 1000 строк багов
}

// Используйте готовое
import "encoding/json"

func Parse(data []byte) (map[string]interface{}, error) {
    var result map[string]interface{}
    err := json.Unmarshal(data, &result)
    return result, err
}

Библиотеки проверены миллионами пользователей. Ваш код - лишь вами.

Практика: чек-лист x10 разработчика

Перед каждым коммитом спросите себя:

  1. Решает ли это реальную проблему?
  2. Это самое простое решение?
  3. Можно ли удалить код вместо добавления?
  4. Есть ли тесты?
  5. Понятно ли это через 6 месяцев?
  6. А через неделю?
  7. Можно это задеплоить прямо сейчас?

Если хотя бы на один вопрос ответ “нет” - подумайте ещё раз.

Метрики x10 разработчика

Измеряйте не код, а результат:

// Плохие метрики
- Строк кода в день
- Количество коммитов
- Часов за компьютером

// Хорошие метрики
- Закрытые задачи
- Довольные пользователи
- Время от идеи до продакшена
- Количество багов в продакшене

Антипаттерны, которые нужно забыть

1. Преждевременная оптимизация

// Не нужно
func Sum(numbers []int) int {
    result := 0
    for i := 0; i < len(numbers); i += 8 {
        // Развёрнутый цикл для "скорости"
    }
    return result
}

// Нужно
func Sum(numbers []int) int {
    result := 0
    for _, n := range numbers {
        result += n
    }
    return result
}

2. Золотой молоток

// Не всё нужно решать микросервисами
// Не всё нужно решать паттернами
// Не всё нужно решать Kubernetes

// Иногда достаточно
func Handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!")
}

3. Архитектура ради архитектуры

// Не нужно
type AbstractSingletonFactoryBean interface {
    GetInstance() interface{}
}

// Нужно
var config = loadConfig()

Как перестать волноваться: практические шаги

Шаг 1: Установите таймер

# 25 минут на задачу
# Что успели - то успели
# Коммит и двигаемся дальше

Шаг 2: Ограничьте рефакторинг

// Правило: рефакторинг только если
// 1. Добавляете новую фичу в этот код
// 2. Фиксите баг в этом коде
// 3. Код читают больше 10 раз в день

// Не рефакторьте просто так

Шаг 3: Код-ревью за 15 минут

// Проверяйте
// 1. Работает ли код
// 2. Есть ли тесты
// 3. Понятна ли логика

// Не проверяйте
// 1. Стиль (линтер сделает)
// 2. Форматирование (gofmt сделает)
// 3. Философию жизни автора

Шаг 4: Автоматизируйте проверки

# .github/workflows/ci.yml
name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: go test ./...
      - run: go vet ./...
      - run: golangci-lint run

Шаг 5: Деплойте каждый день

# Маленькие изменения = маленькие риски
# Большие изменения = большие проблемы

git commit -m "feat: add button"
git push
# CI/CD задеплоит автоматически

Ментальные модели x10 разработчика

1. Принцип Парето (80/20)

20% кода создают 80% ценности. Найдите эти 20%.

2. Закон Паркинсона

Работа заполняет время, отведённое на неё. Ограничьте время - ограничите сложность.

3. YAGNI (You Aren’t Gonna Need It)

Не пишите код “на будущее”. Будущее не наступит, а код останется.

4. KISS (Keep It Simple, Stupid)

Простое решение всегда лучше сложного.

Что делать прямо сейчас

  1. Откройте свой проект
  2. Найдите самый сложный файл
  3. Удалите половину кода
  4. Запустите тесты
  5. Если работает - закоммитьте

Если не работает - значит, тестов не было. Напишите тесты.

Заключение

x10 разработчик - это не про код. Это про мышление.

Перестаньте волноваться о:

  • Идеальной архитектуре
  • Красивом коде
  • Мнении коллег
  • Технологических трендах

Начните думать о:

  • Решённых проблемах
  • Довольных пользователях
  • Скорости доставки
  • Реальной ценности

Код - это инструмент, а не цель.

Лучший код - это код, который решает проблему и не мешает жить.

Всё остальное - детали.

comments powered by Disqus