Как переписать код программы

Сообщений: 5

Сказал(а) спасибо: 0

Поблагодарили 0 раз(а) в 0 сообщениях

Регистрация: 18.05.2007

Как переписать программный код — 18.05.2007, 14:05

Самая главная проблема у меня вот в чём нужно изменить эту прогу так чтобы число в стек добавлялось не кусками как у меня а из строки чисел в программе [Помогите]
т.е как я понял где то в тексте программы должен осуществляться переход из char в int.

//———————————————————————- #include #include #include #pragma hdrstop typedef struct st < int info; struct st *next; > node; node *s1 = 0, *s2 = 0, *s3 =0; node *insert( node *root, int x ) < if (root==0) < root = (node *) malloc (sizeof(node)); root->info = x; root->next = 0; > else root->next = insert ( root-> next, x ); return root; > void display( node *p ) < if ( p != 0 ) < display ( p->next ); printf(«%-3d», p->info); > > node *add( node *s, node *t ) < int x, c=0; node* res=0; while ((s!=0) || (t!=0)) < if (s == 0) x = t->info + c; else if (t==0) x = s->info +c; else x = s->info+t->info+c; if (x > 9) < x-=10; c=1;>else c=0; res = insert( res,x ); if(s!=0) s = s->next; if(t!=0) t = t->next; > if (c == 1) res = insert( res, 1 ); return res; > int main(int argc, char* argv[]) < clrscr(); //Очистка экрана printf(«nn»); printf(«Pervoe chislo zapisannoe v stek:nn «); s1 = insert (s1,2); s1 = insert (s1,6); s1 = insert (s1,4); display(s1); printf(«nnVtoroe chislo zapisannoe v stek:nn «); s2 = insert (s2,6); s2 = insert (s2,5); s2 = insert (s2,5); display(s2); printf(«n»); printf(«nnRezult slogenia dvyx chisel v steke:nn «); display( add(s1,s2)); getchar(); > //———————————————————————-

Возникла загвоздка переделайте программу кто может и знает как ! Очень нуждаюсь в вашей помощи помогите начинающему пожайлуста !

КАК ИЗМЕНИТЬ КОД СТРАНИЦЫ

Источник: www.hardforum.ru

Рефакторинг легаси кода: cоветы, шаги и лучшие практики

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

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

Легаси код обычно всегда ассоциируется с техническим долгом – ценой достижения быстрого запуска и оптимального времени выхода на рынок; однако пренебрегая качеством и долговечностью кода, который впоследствии все равно придется переделывать. По данным консалтингового исследования Hitachi, легаси системы препятствуют эффективности по меньшей мере 90% организаций.

Как взламывают игры? Часть 1 Структура исполняемого файла

Несомненно, легаси код постепенно становится серьезным бременем для предприятий. Недавнее исследование консорциума по качеству программного обеспечения в IT показало, что в 2018 году легаси системы обойдутся компаниям в США более чем в 500 миллиардов долларов, а в последующие годы эти цифры будут еще выше.

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

Что такое рефакторинг устаревшего кода?

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

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

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

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

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

В отчете Управления правительственной отчетности США объясняется, что нарушение в значительной степени стало прямым следствием легаси кода на сайте Equifax. Впоследствии устранение последствий взлома обошлось компании более чем в 1 миллиард долларов. Легаси код становится проблематичным в основном из-за грязного кода, загнивания кода, сломанного кода или просто устаревшего кода.

И для решения этой проблемы рефакторинг – не единственный метод, который может быть использован. Некоторые эксперты выступают против рефакторинга и предлагают только переписать код. Мы не будем рассматривать спор между переписыванием и рефакторингом. Признаем, что это разные средства для достижения одной и той же цели. Однако важно знать преимущества каждой концепции и то, когда лучше применять рефакторинг или рерайтинг.

Рефакторинг легаси кода против переписывания кода

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

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

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

Вот причины, по которым вам стоит задуматься о переписывании: – При крупных переходах: вам следует подумать о переписывании, если вы делаете какой-либо крупный переход в своей архитектуре, например, переходите от монолита к микросервисам или переходите с angular js на angular. Здесь каждый элемент старой программы может быть воссоздан с нуля.

– Когда большая часть кода грязная или неработоспособная: иногда весь код или большая его часть откровенно грязны и неработоспособны. В таких ситуациях начинать рефакторинг будет пустой тратой времени; лучшим решением будет переписать код. Некоторые эксперты предлагают правило 80% – если 80% кода нуждается в рефакторинге, его следует переписать.

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

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

Когда следует выбирать рефакторинг легаси кода Вот причины, по которым вам следует рефакторить легаси код: – Если вы не можете позволить себе прервать непрерывность работы: иногда переписывание может означать, что вам придется прекратить работу, что нанесет ущерб вашему бизнесу. Поэтому, вместо того чтобы закрывать магазин и заставлять клиентов ждать, вы можете применить прогрессивный рефактор.

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

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

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

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

Простые шаги по рефакторингу легаси базы кода

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

Реализация легаси кода в их нынешнем виде слишком рискованна, поскольку это может поставить под угрозу работоспособность и безопасность архитектуры вашего продукта. Итак, каков же подход к рефакторингу легаси кода? Ниже будут описаны шаги, которые помогут начать рефакторинг. 1.

Разбиение всего процесса на части Когда вы смотрите на модуль, первое, что приходит вам в голову, — как и с чего начать. Не стоит сразу же бросаться в бой: вы будете перегружены и запутаетесь. Разбейте модуль на мелкие относительные кусочки. Это поможет вам легко определить точки изменения.

На этом этапе также необходимо разбить огромные или монолитные классы на более мелкие группы. После разделения каждого класса монолита вы можете создать новые файлы и переименовать все переменные, следующие модальностям Java. 2.

Выявление и устранение зависимостей После того как вы получили доступ к коду, следующее, что нужно сделать, – это выявить и удалить зависимости; это не только делает программу читабельной. Написание тестов становится проще, когда зависимости разделены и удалены. 3.

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

Определение и внедрение соответствующей архитектуры Информация, собранная на предыдущих этапах, даст достаточное представление о том, какой тип архитектуры будет наиболее подходящим для данного проекта. Кроме того, небольшие компоненты, созданные в предыдущем упражнении, пригодятся при реализации этой архитектуры. Советы и основные принципы рефакторинга легаси кода – Разбейте программу на более мелкие и относительные пункты. – Делайте по одному шагу за раз. – Определите области изменений и запишите их. – Составьте график и придерживайтесь его. – Используйте тест-кейсы. – Автоматизируйте процесс рефакторинга, где это возможно. – Проанализируйте и сравните результаты. – Проверьте еще раз.

Лучшие практики рефакторинга легаси кода

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

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

Двигайтесь маленькими шагами Вы должны рефакторить свой код небольшими кусочками. Вносите незначительные изменения в свою программу; каждое небольшое отличие немного улучшает вашу программу и сохраняет функциональность приложения. Выполняйте тесты Операция рефакторинга должна сопровождаться соответствующими тестами, чтобы убедиться в эффективности изменений и отсутствии ошибок. Рефакторинг не должен привносить новые возможности Рефакторинг не должен изменять операции или функциональность программы. Скорее, он делает ее лучше, быстрее, повышает удобство использования и делает программу более эффективной.

Заключение

Легаси программы и функциональные приложения должны регулярно обновляться. Обновление устаревших систем приводит к повышению производительности, упрощению продвижения, постоянному развитию и улучшению пользовательского опыта, в то время как отсутствие обновлений может нарушить безопасность. Перевод статьи: «Legacy Code Refactoring: Tips, Steps, and Best Practices», Pavel Tantsiura.

Источник: kata.academy

Когда стоит переписывать код проекта и как это донести до заказчика

Елена Шаровар, Lead Node.js developer в Waverley Software, в своей статье на DOU.UA рассмотрела ситуацию, когда программисты говорят: «Нужно все переписать», но это тяжело донести до заказчика.

Давайте разберемся, как помирить программистов и бизнес, если вы — Lead проекта, Project Manager или тот самый программист, который хочет улучшений, а вас как будто не слышат. Скорее всего, об этой проблеме вы знаете не понаслышке: такое случается то с вами, то с вашими друзьями или коллегами, и в очередной раз начинается обсуждение: а что же делать?

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

Стейкхолдеры проекта

Чем больше заинтересованных лиц в проекте, тем более разнообразные у них цели. Давайте определим всех стейкхолдеров, участвующих в проекте. Заметьте, что с некоторыми из них вы, возможно, даже не знакомы. Но они есть, и они имеют влияние на принятие тех или иных решений.

1. Инвесторы — потому что они вкладывают свои финансовые средства в этот проект и ожидают хороший Return on Investment (ROI).
2. Product Owner — человек, который занимается управлением этого проекта и приоритизирует функционал, который вы разрабатываете. Он общается с программистами и инвесторами.
3. Пользователи — те, кто использует ваш продукт и, скорее всего, платит за него.
4. Программисты — да-да, они также являются стейкхолдерами, проект должен их устраивать, иначе у вас не будет программистов.

Как проект выглядит для всех, кроме программистов

Извините, но это все! Магия, которая происходит внутри, интересна только программистам. Пока программа делает то, что нужно — она устраивает владельца продукта, инвесторов и даже пользователей.

Почему программисты хотят переписать код проекта

Во-первых, потому что у нас есть потребность делать хорошо. К сожалению, понятие «хорошо» у всех разное. Например, код хочется переписать тогда, когда достался legacy-проект, а у тех, кто писал его — понятие, что такое «хорошо», было другим, отличающимся от вашего. Или если вам достался прототип, который делался в спешке, и программисты и сами понимали, что работают не очень качественно.

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

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

Где интересы программистов и других стейкхолдеров пересекаются

Кроме функциональных характеристик, у программ есть нефункциональные характеристики. К ним относятся:

• скорость ответа (response time, performance);
• отсутствие багов (reliability, usability);
• доступность (availability);
• устойчивость к отказам (resilience);
• расширяемость (extendability);
• поддерживаемость (maintainability);
• среднее время починки (mean time to repair);
• стоимость разработки и поддержки (cost);
• тестируемость (testability);
• возможность аудита и отладки (auditability).

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

Остальные характеристики — начиная с расширяемости — интересуют владельца продукта и программистов, но они необходимы, чтобы поддерживать первые четыре на должном уровне. А также чтобы вовремя выпускать новые фичи.

Так вот, именно в зоне нефункциональных характеристик находится точка пересечения интересов программистов, продакт-оунера и пользователей. Когда просите рефакторинг — указывайте, какие именно нефункциональные характеристики в данный момент вас не устраивают.

Если в проекте очень сложный и запутанный код, то, скорее всего, хромает maintainability, скорость разработки и тестируемость. Если там старые библиотеки и фреймворки, то, скорее всего, у вас проблемы с расширяемостью. Если архитектура не предполагала большого количества запросов, а они ожидаются — это грядущие проблемы с scalability и performance. Если вы тратите половину рабочего времени на поиск причин багов — явно стоит улучшать auditability

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

А где ваш план!

Вы делали ремонт? Помните, что вас интересовало? Цена, качество и сроки, верно? Здесь то же самое. Чтобы заказчик сказал вам «да» — предоставьте ему информацию о цене, качестве и сроках.

Цена и сроки

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

• Сделайте схемы и диаграммы того, что вы хотите получить в итоге.
• Объясните в комментариях или в design document, чем новая структура лучше старой.
• Разбейте работу на этапы и составьте эстимейт (оптимистичный, пессимистичный, реалистичный).
• Продумайте риски (например, уход ключевого разработчика).
• Кто и как будет тестировать результат, есть ли у вас чек-лист для полного тестирования?
• Не забудьте включить в эстимейты работу по настройке деплоймента, переносу данных и миграции пользователей.

С этим планом вы можете обращаться к стейкхолдерам с предложением переписать.

Качество

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

Пару слов об инженерной этике

При вступлении в профессию врачи дают клятву Гиппократа. В ней несколько пунктов, и один из них — «доминанта интересов больного» — в процессе лечения врач обязуется следовать интересам больного, а не своим. Будет ли он это делать на самом деле — вопрос воспитанности врача.

При вступлении в профессию программиста мы не даем [еще пока] никаких клятв, но кодекс этики программиста существует здесь и здесь, и похожий пункт там тоже есть: «Principle 2: Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest»

Преследовать свои личные цели, а не цели бизнеса — неэтично.

Дайте цифры

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

Стоимость переписывания посчитать проще всего, она прямо пропорциональна времени на переписывание и выкатывание новой версии.

Стоимость поддержки продукта состоит из таких составляющих: это время, которое тратится на разработку новых фич, багфиксы и тестирование, ввод человека в проект, деплоймент, а также минимально необходимый для поддержки и понимания уровень программистов (Senior vs Junior).

Если вы уменьшите эти показатели — значит, вы уменьшили стоимость поддержки. Также переписывание вполне окупает себя в том случае, когда ожидается рост количества пользователей, который старая система просто не выдержит.

Выберите подходящее время

Если вы привели хорошие аргументы и разработали детальный план — у Product Owner все еще может быть достойная причина для отказа: «Не сейчас».

Действительно, roadmap проекта разрабатывается на месяцы вперед, и внезапно добавить в план большие изменения не получится. Также вы можете быть не в курсе финансового состояния проекта — он «дышит на ладан и пытается выжить» или «получил третий раунд инвестиций, и планируется развитие»? Получить время и ресурсы на рефакторинг проще во втором случае.

Mожно обсудить с Product Owner, когда, по его мнению, все это можно будет реализовать, и запастись терпением. Подумайте: можно ли переписать не все, а часть? Определите самые проблемные части проекта, просмотрев историю баг-репортов или жалоб пользователей.

Спросим коллег

Oleksandr Brychuk, Head of IT Department at UniSender

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