• XSS.stack #1 – первый литературный журнал от юзеров форума

Как писать код с минимальными затратами

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

Ну и поддерживаю слова про "не надо быть клин-код нацистом".
 
HateMe02 сказал(а):
Вижу очень много рекомендаций по шаблонам, но я считаю лично что шаблонным должен быть тот код, который "идеальный" под определенный N проектов, тому пример настроенная система логирования, архитектура с масштабируемыми воркерами, но шаблоны постоянно подвергаются изменениям если они совершенствуются, ведь из проекта в проект обычно всегда извлекается опыт, либо вы просто не прогрессируете от слова совсем застряв на своем конечном уровне, всегда есть что улучшить либо узнать новое.

Ну и поддерживаю слова про "не надо быть клин-код нацистом".
Шаблонные проекты не путать с паттернами проектирования. Если шаблонный проект совсем не подходит для новой задачи, надо просто сделать еще 1 шаблонный проект. Клин код нацизм вообще бесполезно включать на старте, все равно всего не предусмотришь, его включают когда уже есть рабочий прототип, когда уже ясны все ботлнеки и подводные камни.
Очень часто бывает нужно выяснить - а что если вот так.. и делать такой тест проще всего на базе шаблонного проекта а не вкорячивать его в рабочий а потом выпиливать.
И да у опытных так же набирается и база проделанных тестов, потому что нередко приходится возвращатся к старому тесту что в нем быстренько проверить новую идею.
Когда у меня возникает какая то идея то в поиск вбивается тег, дальше клик и открывается в студии набор релевантных тестов или шаблонов.
Так же изучая новую технологию, библиотеку, создаются тесты что бы пробовать все что учишь, когда уже будешь рабочий проект писать часто будешь захочдить в тесты и проверять какие то идеи и прояснять какие то моменты. Главное удобно каталогизировать все что делаешь, что бы быстро к этому вернутся в любое время и проверить что то еще.
Это еще и улучшит читаемость потому что будет много кода который был где то еще. А вот так что бы с нуля сразу чистый код хреначить это какой то год левел, хотя говорят тдд это позволяет сделать, но у меня слишком мало с ним опыта что бы что то про это утверждать, но скорее всего изза приципа тдд это действительно реально.
 
HateMe02 сказал(а):
Вижу очень много рекомендаций по шаблонам, но я считаю лично что шаблонным должен быть тот код, который "идеальный" под определенный N проектов, тому пример настроенная система логирования, архитектура с масштабируемыми воркерами, но шаблоны постоянно подвергаются изменениям если они совершенствуются, ведь из проекта в проект обычно всегда извлекается опыт, либо вы просто не прогрессируете от слова совсем застряв на своем конечном уровне, всегда есть что улучшить либо узнать новое.

Ну и поддерживаю слова про "не надо быть клин-код нацистом".
К слову про DDD, оно преподносит собой идеальную модульность, это не про код, а про то, что вне зависимости окружения их(модулей) использования, оно используется по назначению в конкретных бизнес целях, поэтому и переносится из проекта в проект без каких либо переработок, например тоже самое описанное логирование, задача логирования - писать логи в соответствии с каким-то тз, написался модуль, написался под него интерфейс, все готово, дальше оно используется в проекте где оно впервые потребовалось, дальше этот модуль можно переносить в любой другой проект без зависимостей от старой кодовой базы старого проекта
 
Rout сказал(а):
К слову про DDD, оно преподносит собой идеальную модульность, это не про код, а про то, что вне зависимости окружения их(модулей) использования, оно используется по назначению в конкретных бизнес целях, поэтому и переносится из проекта в проект без каких либо переработок, например тоже самое описанное логирование, задача логирования - писать логи в соответствии с каким-то тз, написался модуль, написался под него интерфейс, все готово, дальше оно используется в проекте где оно впервые потребовалось, дальше этот модуль можно переносить в любой другой проект без зависимостей от старой кодовой базы старого проекта
Что бы к этому прийти надо.
Написать большой проект где есть многопоточность, где есть отдельные процессы в которых выполняются отдельные задачи(мультипроцесс), где есть удаленные сервера. Написать это это все как привык не заморачиваясь чистым кодом =) В процессе охренеть от копания в логах сопоставляя тайминги тредов, охренеть с отладкой, охренеть с попыткой повторить баг, понять что нужно писать тесты. При попытке писать тесты понять что что бы написать тест для чего то, это что то должно быть спроектировано так что бы это в принципе могло быть оттестированно, а значит должен быть контроль ио и все должно быть связано интерфейсами. Потом охрень от того что объекты где не соблюли SRP тестировать как то ну очень трудно, потом охренеть от попытки тестировать метод на 300 строк с 15ю ифами. Начать дробить все на части, охренеть от того что это не так просто как может показаться.
Короче большинству надо сначала охренеть столкнувшись с реальным проектом что бы как то там рассуждать про клин код и про "минимальные затраты".
 
Whisper сказал(а):
Что бы к этому прийти надо.
Написать большой проект где есть многопоточность, где есть отдельные процессы в которых выполняются отдельные задачи(мультипроцесс), где есть удаленные сервера. Написать это это все как привык не заморачиваясь чистым кодом =) В процессе охренеть от копания в логах сопоставляя тайминги тредов, охренеть с отладкой, охренеть с попыткой повторить баг, понять что нужно писать тесты. При попытке писать тесты понять что что бы написать тест для чего то, это что то должно быть спроектировано так что бы это в принципе могло быть оттестированно, а значит должен быть контроль ио и все должно быть связано интерфейсами. Потом охрень от того что объекты где не соблюли SRP тестировать как то ну очень трудно, потом охренеть от попытки тестировать метод на 300 строк с 15ю ифами. Начать дробить все на части, охренеть от того что это не так просто как может показаться.
Короче большинству надо сначала охренеть столкнувшись с реальным проектом что бы как то там рассуждать про клин код и про "минимальные затраты".
Согласен, поэтому чтобы писать код с минимальными затратами, надо собрать максимальный практический опыт, тогда любой код станет минимальным :D
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх