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

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

Отслеживать
Kilian

Kilian

HDD-drive
Пользователь
Регистрация
29.03.2024
Сообщения
26
Реакции
2
Это больше похоже на вопрос, тем не менее...
Какие методики используете вы во время написания кода? Может у вас есть какие-нибудь категорические правила, которых вы придерживаетесь?
Как вы справляетесь с нагрузкой и как вы оптимизируете свой код? Как вы в конце концов планируете свой код?

только не раскрывай все секреты
 
Вы не оптимизируете все внутри кода.

Вы оптимизируете главным образом структуру каркаса, которая является основой всего тела.
Вы даете ему части, чтобы он мог ходить, говорить, делать что-то. Фокус
 
все сводится к знанию того, чего вы хотите достичь, я живу по принципу 5 P, правильное планирование предотвращает плохую производительность, выполняйте все задачи медленно и иметь хорошее представление о том, что вы хотите построить, например, если вы собираетесь сетевая связь, какой протокол вы будете использовать, как часто вы будете общаться? необходимо ли шифровать сетевой трафик? и при создании более крупного приложения убедитесь, что вы регулярно и часто тестируете свой код.

Мне потребовалось много времени, чтобы научиться этому, поскольку я писал партии, а затем обнаруживал, что половина не работает так, как задумано, потому что я никогда не проверял ее во время сборки, это было похоже на постройку автомобиля, который выглядит очень красиво, но у вас есть никогда не проверял, работают ли колеса, тормозят ли они и т. д.


Еще одна очень ценная вещь, которую я нашел, - это документировать/комментировать мой код по мере моего прогресса, когда я оглядываюсь назад и забываю, почему я принял такое решение или почему я разработал фрагмент кода, который будет работать определенным образом. это снова сэкономит много времени и усилий в долгосрочной перспективе.
 
Во первых удобную IDE.
Во вторых иметь четкий план и понимание того, что хотите получить в итоге.
Остальное уже зависит от вашего познания ЯП и практики.
 
Эгей великие кодыры, тема то интересная, родите конкритику а не вот эту импотентную чушню за все хорошее и против всего плохого.
 
Минимальные затраты в моем представлении - создание минимально рабочего задуманного продукта и улучшать его.

А не навыдумывать кучу всего, хреново спроектировав реализовывать и получать никому не нужный, неоптимизированный продукт.

Рефакторить после создания прототипа, а не в процессе.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Kilian сказал(а):
Может у вас есть какие-нибудь категорические правила, которых вы придерживаетесь?
8758a527541dc2251475335dd0570a29.jpg


Whisper сказал(а):
родите конкритику а не вот эту импотентную чушню за все хорошее и против всего плохого
Делай, чтобы было заебись, чтобы было хуево - не делай.

По сабжу: в целом, не нужно быть клин-код нацистом. В сфере малвари огроменная куча говнокода, которая вполне выполняла или все еще выполняет свою задачу. Заморачиваться какими-нибудь категорическими правилами необходимо, когда ты делаешь долго живущий проект, и/или в котором помимо тебя и твоей коленки участвуют другие люди. Я не против клин-кода, как такового, но нужно понимать, где и зачем его использовать. Например, если ты - тот несчастный, которому по какой-либо причине в 2024 году крайне необходимо писать на Цэ/Плюсах, то изволь сделать так, чтобы твой процесс не падал во всяческие сегфолты: используй принципы дефенсив программинг, проверяй все коды ошибок, что тебе возвращают все апишки, не проебывай память и хендлы и тд и тп. Чтобы все подобные вещи покрыть, нужно целую статью писать. Но и почти в любом языке есть неочевидные способы выстрелить себе по ногам, этого никак не избежать. Смысл в том, что между тем, чтобы выпустить в массы говнокод, и тем, чтобы задрочить себя полезными практиками и из-за этого ничего и никуда не выпустить, нужно всегда выбирать первое. Даже если тебя обосрут с ног до головы п#дара перфекционисты от мира качественного кода (вроде меня), то ты как минимум чему-то научишься на этом. А если ты ничего не выпустил, то ты и не можешь толком судить, сделал ты что-то хорошо или плохо. Самому о своей работе сложно судить объективно.
 
Rout сказал(а):
Минимальные затраты в моем представлении - создание минимально рабочего задуманного продукта и улучшать его.

А не навыдумывать кучу всего, хреново спроектировав реализовывать и получать никому не нужный, неоптимизированный продукт.

Рефакторить после создания прототипа, а не в процессе.
1 почти хороший совет.
Хороший звучит так - Сначала рабочий концепт доказавший свою жизнеспособность, потому чистый код с нуля. С нуля потому что концепт делается быстро, там все плохо с разделениме на отвественности, с контролем ио, а когда нет контроля ио и разделения на ответственности, нет и тестов нормальных, поддерживать(улучшать) что то в чем нет автотестов это дурной труд. Так что продумывается архитектура с нуля и код пишется с нуля, поптыки улучшать high coupling и low cohesion да еще и в рамках архитектуры концепта занятие дурное.
 
DildoFagins сказал(а):
Посмотреть вложение 85774


Делай, чтобы было заебись, чтобы было хуево - не делай.

По сабжу: в целом, не нужно быть клин-код нацистом. В сфере малвари огроменная куча говнокода, которая вполне выполняла или все еще выполняет свою задачу. Заморачиваться какими-нибудь категорическими правилами необходимо, когда ты делаешь долго живущий проект, и/или в котором помимо тебя и твоей коленки участвуют другие люди. Я не против клин-кода, как такового, но нужно понимать, где и зачем его использовать. Например, если ты - тот несчастный, которому по какой-либо причине в 2024 году крайне необходимо писать на Цэ/Плюсах, то изволь сделать так, чтобы твой процесс не падал во всяческие сегфолты: используй принципы дефенсив программинг, проверяй все коды ошибок, что тебе возвращают все апишки, не проебывай память и хендлы и тд и тп. Чтобы все подобные вещи покрыть, нужно целую статью писать. Но и почти в любом языке есть неочевидные способы выстрелить себе по ногам, этого никак не избежать. Смысл в том, что между тем, чтобы выпустить в массы говнокод, и тем, чтобы задрочить себя полезными практиками и из-за этого ничего и никуда не выпустить, нужно всегда выбирать первое. Даже если тебя обосрут с ног до головы п#дара перфекционисты от мира качественного кода (вроде меня), то ты как минимум чему-то научишься на этом. А если ты ничего не выпустил, то ты и не можешь толком судить, сделал ты что-то хорошо или плохо. Самому о своей работе сложно судить объективно.
Ты хотя бы дал минимум базис, как организовать структуру проекта, как делать првильно логи, как делать тесты - что именно нужно тестировать, как писать код которыей можно нормально тестировать, и не обязательно писать статью, дай хоть линков на хорошие чужие, а так же на инфу про очевидные ошибки программирования не привязанные к языку и архитектуре. Не факт что топикстартер новичок, вопрос актуален и для опытных.
 
1) Тесты - достаточно сильно бустят скорость разработки, достаточно единожды написать правильный тест для какой-либо части кода (пусть сперва и плохо написанного) - минимум возни с дебаггером, прочими вспомогательными тулзами.
Например:
Пример 1: пишем мы какую-либо мидлварь для шифрования/сжатия/какой-либо прочей модификации http-body, без тестов нам для проверки необходимо скомпилировать код, запустить, запустить postman, сформировать пейлоад, отправить запрос, проанализировать ответ и тд.
С тестами все проще: достаточно единожды написать тест, проверяющий необходимые параметры и запускать сколько угодно раз прямо из IDE. Большинство современных ЯП/фреймворков имеют отличное АПИ для тестирования.
Пример 2: к примеру пишем мы интерфейс для взаимодействия с планировщиком заданий Windows - без тестов, для проверки правильно ли отработал наш код необходимо собрать билд, запустить, проверить в планировщике все ли параметры заданы верно - долго, можно по невнимательности пропустить какой-либо параметр и он будет задан неверно.
С тестами: указали какой-либо параметр для задачи, тут же его проверили с помощью assert - нет необходимости запускать планировщик и проверять всё вручную - одним нажатием ЛКМ запускаем тест из IDE.
2) Не все случаи можно проверить с помощью тестов, поэтому логгируем каждое действие - тут думаю всё понятно
3) Обработка всевозможных вариантов ошибок - возвраты каких-либо апи, границы буферов и тд
Если соблюдать хотя бы эти три пункта, скорость разработки многократно вырастет, т.к время, затраченное на отладку > времени затраченного на написание самого кода.
Добавлю так же: при изучении каких-либо новых библиотек/интерфейсов/апи - полезно писать черновики. На примере того же планировщика: нам необходимо реализовать интерфейс для планировщика на Rust - как и что работает мы не знаем, поэтому писать сразу чистый и идиоматичный код на расте будет тяжело, гораздо проще набросать черновик на Си, вместо обработки ошибок используем assert/printf - с практикой новый материал проще усвоится, появится примерное представление как должен выглядеть конечный интерфейс, будет проще повторить этот же код на расте.
 
Сначала я распиши на листе бумаги, желательно схематично, структуру своего приложения, скрипта неважно. Дальше уже отталкивайся от этого, дописывай , изменяй.
 
У нормального кодера всегда есть "кодовая база". У самых опытных эта база настолько унифицирована, что новый проект пишется серией прожатий Ctrl-C + Ctrl-V
 
Пожалуйста, обратите внимание, что пользователь заблокирован
waahoo сказал(а):
У нормального кодера всегда есть "кодовая база". У самых опытных эта база настолько унифицирована, что новый проект пишется серией прожатий Ctrl-C + Ctrl-V
еще приходится открывать старые проекты и находить места откуда копировать
 
waahoo сказал(а):
У нормального кодера всегда есть "кодовая база". У самых опытных эта база настолько унифицирована, что новый проект пишется серией прожатий Ctrl-C + Ctrl-V
и так же думаю много такого лежит на гитах
 
Лохотронщик сказал(а):
еще приходится открывать старые проекты и находить места откуда копировать
Так у распиздяев или нубов. У профи каталогизированные готовые шаблоны типовых решений, из которых не придется выпиливать пол дня то что в новом проекте не нужно.

m00r сказал(а):
и так же думаю много такого лежит на гитах
Ага надо только потратить время на то что бы найти, потом разобратся в чужом коде, потом его потестить, потом поисправлять, потом выпилить ненужное и снова потестить и интегрировать в свой прокет.
 
Rout сказал(а):
Это уже DDD, а это не про код с минимальными затратами :D
Да ладно тебе, только так и надо. Типовые клиент-сервера, уи и прочее. Просто когда что то новое делаешь, начинаешь с типового шаблона который будешь копипастить. Потому что все равно будешь копипастить но это будет уже так - эээ когда то че такое я уже делал, пороюсь в архивах, ага нашел, так теперь выпилю вагон говна, подтащу зависимости и будет ок.
На практике это так.
Нужен мне клиент сервер, думаю лучшим решением будет на сырых сокетах, но это не факт. Делаю тестовый шаблон на сырых сокетах что бы его обкатать и убедится что он сгодится, вот в базе и появился типовой шаблон не проросший корнями в конкретный проект. Поскольку он тестился по всякому там удобные универсальные интерфейсы торчат наружу, бери да прикручивай.
 
admin


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