LINUX.ORG.RU

Код как лапша.


0

2

Я работаю в большой компании над старым и большим проектом.

Код - миллионы строк. Почти весь код который я вижу - макароны ;)

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

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

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

Решения выбираются в основном по кретирию максимальной понятности разработчикам, но так как большинство разработчиков не знакомы (мало знакомы) с bash, системными вызовами unix, основами многопоточного программирования (методами синхронизации), то...

Некоторые «системные» вещи которые десятилетиями делаются в unix проверенным способом велосипедятся не лучшим образом.

И это не все проблемы кода на самом деле.

Но это все ерунда по сравнению со стремлением разработчиков делать все одной большой функцией. Т.е например скрипт на 6-20 сотен строк с большущей вероятностью будет одной большой функцией. Либо будет содержать парочку, но с такими именами что от них можно только запутаться. Единственное что побуждает вынести часть кода в отдельную функцию - это то, что код будет вызываться откуда-то еще, да и то не всегда.

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

Неужели все проекты со временем становятся такими?

★★★★

Ответ на: комментарий от OxiD

Начнём с начала. Как это ни странно, машины выполняют машинный код. Для них «синтаксическими конструкциями языка» не существуют. Исключение только лисп-машины, но это было давно и неправда.

vahtu
()
Ответ на: комментарий от vahtu

Ты так уверенно расписывал переключение контекстов в x86, но при этом не отвечаешь на конкретный вопрос, связанный именно с контекстами. То есть там толкько один кэш связан конкретно с контекстом задач и MMU.

Artificial_Thought ★★★★
()
Ответ на: комментарий от vahtu

Давай начнем с начала топика, а не сотворения мира, ок?

Ты говорил что гото это плохо _всегда_ без исключений.

При чем тут работа процессора?

OxiD ★★★★
() автор топика
Ответ на: комментарий от OxiD

Программы пишутся для людей, и поэтому читаемость кода никакого отношения к работе процессора не имеет, за исключением случаев когда код пишет машина, например bison.

OxiD ★★★★
() автор топика
Ответ на: комментарий от Artificial_Thought

На самом деле кэшей два. Для данных и программы. С данными всё понятно - процессор читает за раз целую страницу памяти, но бьёт её на части. А вот с программой всё не просто. Оптимизатор пытается предсказывать переходы, но это не просто. А каждая операция предсказания (верная или нет - не важно) приводит к очистке кеша.

vahtu
()
Ответ на: комментарий от Artificial_Thought

Ну скажи. Из-за этого интел архитектуру (отлаженную - это важно) менять не будет. Даже если ты генеральный директор.

vahtu
()
Ответ на: комментарий от vahtu

Я тут, понимаешь, распинаюсь.

да ты чудак в квадрате просто. тебе уже туча людей задали конкретные вопросы, но кроме как знания куска даташита к р1, пару алгоритмов работы кеша и (о боже!) знания, что есть целых два вида кешей ты не продемонстрировал. ах да! ещё ты вычитал в пособии для студентов пту по програмированию на «с/c++», что goto - это очень плохо. а ещё ты знаешь слово лисп-машина. всеми этими знаниями ты гордишься, мол, «во какой я умный», просто звиздец! но ни на один из заданных тебе вопросов ты так и не ответил конкретно и по существу. вместо этого ты просто переливаешь с пустого в порожнее. типа нельзя поставить метку на какой-то «вентиль», забыл как называется, а гуглить лень. лихо перешёл от goto к архитектуре процессора от знаменитой компании, да.

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

успехов.

anonymous
()
Ответ на: комментарий от anonymous

... игнорчик...
...anonymous...

Сильно. И, главное многабукф.

Из того, что ты мне приписал, я не слова не написал.

vahtu
()
Ответ на: комментарий от vahtu

Но, если не ошибаюсь, даже армы переключают контекст аппаратно.

intel это тоже умел от рождения i386, только никому не надо было ибо медленнее выходило. вот amd и выпилило из x86_64.

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

TheMixa ★★★
()

Неужели все проекты со временем становятся такими?

большинство востребованных проектов такими становятся. Ибо надо чтобы работало здесь и сейчас, а идеалисты сушат этап разработки, потом происходят обидки вида «я такой умный а мне пинка».

Хороший программист должен уметь писать тот код который от него требуется и который справляется с задачей а не заявлять «я тут все это время пробелы и табуляции расставлял да классы писал, осталось только программу написать, а то без этого моя программа будет тормозить и глючить»

TheMixa ★★★
()
Ответ на: комментарий от TheMixa

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

так то оно так, да только __хороший__ программист, при всём вышеозвученном, умеет писать код так, чтобы на него потом можно было не только без слёз посмотреть, но ещё и порадоваться

shty ★★★★★
()
Ответ на: комментарий от Karapuz

Мнение ядра меня не интересует. В конце концов я использую его, а не оно меня.

vahtu
()
Ответ на: комментарий от vahtu

Не хочу ничего узнавать, хочу чтобы ты остался и приносил нам и дальше столько же лулзов ;)

OxiD ★★★★
() автор топика
Ответ на: комментарий от vahtu

В С метки - ошибки и/или блажь

Откуда инфа-то? Сам придумал?

Kiborg ★★★
()

Код - миллионы строк. Почти весь код который я вижу - макароны ;)

Почти каждый программист, который приходит на новую работу и видит код старого огромного проекта, говорит всегда одно и то же: «Здесь все надо переписывать!». Типичная болезнь российских программистов, между прочим. Острая переписома. :)

Zubok ★★★★★
()
Ответ на: комментарий от shty

посмотреть

порадоваться

Некоторым понятнее слова «сопровождение», «поддержка» и «совместно».

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

порадоваться

Некоторым понятнее слова «сопровождение», «поддержка» и «совместно».

порадоваться - это просто shortcut, или ты радуешься когда приходишь на проект видишь ситуацию как у ТС?

shty ★★★★★
()
Ответ на: комментарий от shty

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

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Ну, это я просто к тому, что не всегда можно объяснить собеседнику в таких терминах.

ну, это вне всякого сомнения, но это я наверное разбаловался маленько за последние пару проектов, ибо кто в теме тому объяснять не нать :)

shty ★★★★★
()

А куда ж от этого деться-то?

На рефакторинг времени всегда меньше, чем на новую функциональность.

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

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

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

В топку такое переписывание, в общем. Иногда лучше костыли.

Хотя я встречал также и более грамотный подход, когда сначала покрыли всю регрессию которую могли автотестами, а потом уже разработчики все перепилили почти с нуля, но с сохранением старого API. Результат относительно спокойный. Почти все проблемы нашли и пофиксили, и довольно быстро. Но это потребовало изначально нового человека, т.е. тоже ресурсов больше.

zhuravlik ★★★★
()
Последнее исправление: zhuravlik (всего исправлений: 1)
Ответ на: комментарий от Zubok

Да нет, я тут уже давно ;)

OxiD ★★★★
() автор топика
Ответ на: комментарий от zhuravlik

На рефакторинг времени всегда меньше, чем на новую функциональность.

Рефакторить надо тот код в который добавляешь функциональность. Т.е вметсо того чтобы растить функции надо делать все модульнее. Это потребует больше времени сейчас, но скоратит время потом при тестировании и при добавлении функциональности потом. Чтобы существующий код был в форме.

Но я чаще встречаю утверждения о том что рефакторить - опасно ;) Лучше скопипастить код который не понимаешь еще раз с заменой одной константы на другую чем разбить на части и сделать понятным и без копипасты.

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

И если надо добавтиь новый вид объектов, не знаешь в каких местах надо их обрабатывать и как. Очень просто забыть добавить обработку в паре таких мест из ста и потмо через неделю поймать непонятный баг и понять что данные в продакшен БД частично непоправимо испорчены ;)

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

Если у тебя есть одна функция с кучей костылей - сложно написать юнит тест. И чаще его нет. Если у тебя 20 маленьких но простых функций их покрыть просто - упрощение и удешевление тестирования.

OxiD ★★★★
() автор топика

Неужели все проекты со временем становятся такими?

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от vahtu

Расскажи, как прыжок на вентиль оформить в виде метки. Жду с нетерпернием.

Извиняюсь что таки вмешиваюсь, но не смотря на то, что своим постом, вы явно уходите от темы, не могу не заметить, что в C с раширениями стандарта от gcc имеется возможность получения адреса метки, и перехода по на метку по ее адресу, т.е. по идее можно подменить адрес метки на системный адрес гейта, и прыгать туда. Впрочем - это вы ни о чем сказали все равно, т.к. goto используется в ядре для совсем других целей, а для переходов меж контекстами и режимами - существуют куски кода писанные на ассемблере, т.к. такие вещи сложно сделать на языке вроде C, да так, что-бы работало на тех 2-3 десятках архитектур, поддерживаемых linux-ом.

qrck ★★
()
Ответ на: комментарий от vahtu

В intel'ах это реализовано аппаратно: JMP <адрес>, если он находится в пространстве другого процесса, вызывает переключение контекста. Но это, если он валидный. Если нет получишь сегментэйшен фолт. Валидные адреса (иначе говоря точки входа в процесс) называются вентилями.

кстати да, не знаю про 64 бита, а на классическом х86 линукс не использует нигде данный способ переключения контекста: системный вызов - int $80, переключение меж задачами - сделано вручную, из-за тормознутости аппаратного переключения контекста задач на интеле, т.к. там все сводится к iret-у, с предварительной махинацией на стеке, вроде так.

qrck ★★
()
Ответ на: комментарий от qrck

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

qrck ★★
()
Ответ на: комментарий от tensai_cirno

В c++ goto не нужен.

Последним языком, где мне был нужен GOTO, был, кажется, ZX-Basic :) Уже на QBasic вопроса GOTO просто не возникало. Ну, не считая ассемблеров, конечно.

Не могу вспомнить, чтобы за всю практику программирования на Си/Си++ мне хоть раз довелось goto использовать.

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.