Thread by @mokevnin

Есть у меня список принципов, которых я придерживаюсь когда пишу код. Кратким списком они есть тут ru.hexlet.io/pages/principl… но без раскрытия, а у людей появляются вопросики. Пришла пора ответить за слова. Лайк, тред, инфлюенс =>

"Язык — это инструмент" банально, но факт. Не прикипайте к языкам, язык для души и работы это разные вещи. Я не люблю го, но буду использовать там где он силен, я люблю кложу, но не буду использовать почти нигде (:D) PHP сила, TypeScript могила

"Программирование — это не язык" tldr: вычислительное мышление. Задача => избавляемся от лишнего (Абстракция) => разбиваем на подзадачи (Декомпозиция) => Находим закономерности (pattern recognition) => строим алгоритм. ru.wikipedia.org/wiki/%D0%92%D1…

"Понимание принципов важнее знания инструментов". Можно много читать книги про рефакторинг функций (мартин ты кто такой?) и радоваться авторефакторингу в иде, но код от этого не станет лучше (а станет хуже!) если не опираться на фундаментальные принципы: чистота, абстракция и т.п

"Паттерны — это не принципы программирования" за шаблонами лежит гораздо большая идея, из которой этот шаблон следует. Если не понимать эту идею, то будет разработка в стиле: так, так куда применить абстрактную фабрику в проекте?

"Написание кода — не цель" Задача самурая устранять боль, наиболее эффективным с точки зрения стоимость/затраты способом. Задачи могут решаться удалением кода или административным решением. Думайте о том как уменьшить количество состояний, а не запрограммировать их все

"Удаление кода лучше его написания" Я бы сказал нет кода нет проблем. Никому не нужно бесконечное число фич. Режьте все ненужное, постоянно осматривайтесь "а нахрен оно тут лежит?". Чувствуйте бизнес, будьте бизнесом, будьте

"Читаемый код важнее быстрого". С хорошей абстракцией, вы всегда успеете оптимизировать ваш код, особенно если она не протекает. Прочитайте хорошую книжку (очень тонкую) optimization.guide

"Любое решение имеет плюсы" Даже если вас съели, у вас есть два выхода. Хороший программист рассматривает любое решение, даже то, которое ему не нравится. Мы тут не фильмы на нетфликсе выбираем.

"Уровень мышления определяет уровень решений" Очень похожая мысль на парадокс блаба nestor.minsk.by/sr/2003/07/307… но для картины мира в голове. Изучайте разные подходы, парадигмы, экосистемы. После js изучение python это трата времени (для мышления), а изучение java мощь

Нативная интеграция: ищу авторов курсов (в хекслет) и преподавателей (в колледж). Люди добры, не проходите мимо, напишите в личку даже если не уверены в своих силах. Мы покажем путь, прокачаем и вдохновим

"Изменяемое состояние — это необходимость и корень всех бед", а не преждевременная оптимизация. Если надо что-то менять, то приходит жопа в: историчности, порядке действий, канкаренси, сложности восприятия, сложности реализации отладке, восстановлении, скорости и дальше по списку

"Побочные эффекты требуют изоляции" пока тема побочных эффектов не понята, никакие паттерны и практики программирования не сделают код лучше. В основе всего и ключом к основному разделению лежат побочные эффекты. Функциональное ядро и императивная оболочка.

Реклама книги: СИКП для тех кому по проще labirint.ru/books/865701/

"Абстракция управляет сложностью" сложность прячется за абстракцией, но сама абстракция может стать сложностью. Как быть? Правильная работа с побочными эффектами, уровневое проектирование, грамотное разделение по областям знаний, не слишком много обобщений

"Однообразие лучше локальных оптимизаций" Это мега важный принцип. Моторная и ассоциативная памяти решают. Делайте одинаково, даже если местами кажется, что можно срезать. Например даже если состояния два, в базе все равно лучше строка: легко расширить, одинаковый код по проекту

"Тесты вселяют уверенность" Страх внесения изменения в проект заводит его в тупик. Юниты мешают изменениям. Интеграционные тесты решают. Не надо ничего мокать, стабы и нормальная инверсия всегда предпочтительнее. Работайте с базой по настоящему.

"Эксплуатация — это часть системы" Ответственность программистов довести фичу до прода, а не слить в main. Time To Market управляет проектами. Обязательно к прочтению: цель и проект феникс

Ну и уже классическое: guides.hexlet.io/ru/check-list-…

"Код — это не продукт" хорошо понимаешь когда начинаешь делать бизнес, а там логистика, саппорт, продажи, сопровождение, аналитика, бухгалтерия, финансы. Из 80 сотрудников Хекслета только 5 человек работает над кодом платформы

"Хороший код не рождает хороший продукт" Как правило, успешный продукт соткан из ниток и изоленты. Скорость изменений решает, а дальше можно продать бизнес и не париться) Программисты склонны переоценивать значимость архитектуры. Уверен что этот твит засияет ночью

Кстати внутри Хекслета охрененный код. Монолит на Ruby, которому 8 лет. Спокойно пилим фичи, подчищаем тех долг и обновляемся на новые версии всего. Весь внешний вид на бутстрапе, фронтенд только в виде виджетов (не считая ide), в остальном старый добрый запрос-ответ и шаблоны

Из недобавленного: не все знают, но программирование в основном состоит из написания кода для переходов между состояниями в рамках каких-то автоматов. Если вы научитесь их видеть в коде, ваш мир не будет прежним.