Что Вы сделали бы, если бы Вам просто вывели этот код в Вашей полировке?
Может быть, у тебя та же проблема, что и у меня. Поэтому для меня решение было простым, если вы используете AppCompat, просто не используйте это свойство:
android:showAsAction="always"
вместо этого используйте его так:
<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto">
<item
android:id="@+id/option"
android:title="@string/option"
android:icon="@drawable/option"
app:showAsAction="always">
</item>
</menu>
Существует разница в дополнительном xmlns : app и showAsAction является свойством app .
Надеюсь, это кому-нибудь поможет.
14 ответов
Глобальный поиск и замена - ваши друзья.
Начало:
- Разделение огромного «if ... else» на отдельные функции, которые вы сможете переименовать позже, когда выясните, что они делают.
- Выполните глобальный поиск / замену в $ _GET [.. .] и $ _SESSION ['dash'], чтобы дать им более понятные имена
- Продолжить очистку
Короче говоря, используйте базовую технику компьютерного программирования: разделяй и властвуй. Разделите функциональность на более мелкие части, а затем очистите отдельные части. Не должно занять больше часа.
Программное обеспечение - это бизнес.
Вам вручили код, который по существу невозможно поддерживать, и вас попросили что-то с ним сделать. Это потребует серьезного рефакторинга.
Плохая новость в том, что это отстой .
Хорошая новость в том, что в обмен на ваше время компания даст вам денег , которые вы сможете обменять на товары и услуги , такие как еда, одежда, пиво и билеты на концерты.
Если у всех есть правильное или хотя бы приблизительное представление о временных затратах, вы должно быть хорошо.
Поверьте, я видел гораздо худший код. Как сказали другие ребята, примените некоторый рефакторинг.
Мой обычный план атаки:
- Если код не тесно связан со всем остальным в системе, напишите много модульных тестов. Это поможет вам убедиться, что поведение рефакторинга не изменилось.
- Извлеките как можно больше функций, разделив их на логические операции. Даже если это означает, что какая-то функция будет содержать две строки кода.
- Вставьте некоторые из 200 созданных вами методов:)
Рекомендуемое чтение:
(источник: martinfowler.com )
Я бы сказал тому, кто свалил мне проект, что полная перезапись необходима, если они хотят что-то сделать с сайтом. (Этот совет не гарантирует, что вас не уволят.)
Моя обычная реакция на наследование такого кода - это отслеживание домашнего адреса исходного разработчика в качестве «на всякий случай-мне-нужно-это».
Будь сильным, мой друг.
Это действительно уродливый код, но не невозможно нечитабельно.
Мое предложение, помимо ранее заявленной стратегии замены (которую я также предлагаю), заключается в делать заметки о том, что происходит в функции, как вы лучше понимаете - это может быть во временных комментариях в коде, в отдельном текстовом файле или на листе бумаги. Важно то, что вам есть к чему обратиться в случае, если у вас будет длительный перерыв или наступят выходные. С неприятным кодом приходит умственная привычка забыть о нем - убедитесь, что у вас есть резервные копии ваших открытий.
Еще одно предложение, учитывая длину вашего примера функции, состоит в том, что как только вы поймете код достаточно, чтобы определить разделы общей логики, разбейте эти мегафункции на более мелкие.
Похоже, кому-то нужно немного освежить в памяти принцип высокой сплоченности.
Я бы поддержал вариант перезаписи, однако, если бы я также рекомендовал написать как можно больше модульных тестов для исходного кода, которые охватывают почти все, что этот код делает, прежде чем приступить к полной перезаписи, очень важно будет убедиться, что ваша перезапись выполняет ту же работу.
Я писал такой код, когда был ребенком. Это было ужасно. Хуже всего было то, что большие куски этих функций просто копировались / вставлялись где-то еще. Я помню, как создавал целый реестр фан-сайтов группы. Он дал вам карту мира и указал на местоположение всех, кто ее подписал. Вы могли нажимать на разные страны, искать по имени и т. Д., И вы получали списки и списки всех этих фанатов со всего мира, у каждого из которых был свой небольшой профиль, который они могли редактировать (любимая песня, участник группы и т. ). Все это на PHP выглядело так. Все с использованием простых текстовых файлов ... Это было ужасно. Я просто переписал большинство функций парсинга файлов ВЕЗДЕ, в каждой функции я снова и снова обрабатывал текстовые файлы ... Боже мой, это было ужасно.
Однажды у меня была куча такого мусора. Лучшая стратегия, которую я в итоге придумал, заключалась в том, чтобы выяснить, что она делает снаружи вовнутрь, а не изнутри. Так что это своего рода противоположность первого респондента (который описывает то, что я начал делать). Это имеет смысл, если код имеет некоторую замаскированную структуру, но это не может быть чем-то само собой разумеющимся. Я закончил тем, что выяснил, например, кучу кода, который никогда не мог бы быть вызван. В некоторых из этих случаев одна и та же функциональность была реализована несколькими разными способами. Много времени, потраченного зря.
В конце концов, он создает веб-страницу. Может быть проще понять, как выглядит веб-страница и как она обычно работает, и просто использовать код для подсказок о том, что не является самоочевидным.
Сообщите Человек, который дал вам это, потребует переписать.
Похоже, эта функция определяет тип пользователя, устанавливает флаги и контент для генератора страниц. Вы можете поместить эту функцию в блок-схему и реорганизовать этот проект. Кажется, что все это очень хорошо подходит для объектно-ориентированного программирования. Вы действительно могли бы снизить степень взаимозависимости глобальных объектов сеанса, иметь меньший код и сделать все это более надежным.