Дорогие Наггетс, всем привет, я второй брат!
Я увидел на каком-то хвалебном ответе, который набрал около 10 000 лайков, сначала уголки рта приподнялись, и я хохотал, как свинья. Тема такая:
Давайте сначала посмотрим на ответ анонимного автора.Те, кто не читал его, не забудьте умыться слезами.
Однажды я взялся за код и наткнулся на модуль с более чем 30 вложенными операторами if-else.
Я выругался в душе: «Кто написал это дерьмо!» Потом пролистал историю кода.
Общая ситуация такова: когда первый программист писал этот код, было всего 2 if-else, затем спрос постепенно увеличивался, сначала 1, 2, а затем количественное изменение вызывало качественное изменение, поэтому ветвь логики быстро расширялась. .
К этому времени никто не хочет рефакторить коммутаторы или шаблоны проектирования, ведь сложность есть, и если она рухнет, то ее будут винить.
После того, как три или четыре программиста взялись за этот код, они запрограммировали мою текущую ситуацию.
Первый программист никак не ожидал, что такая простая логика впоследствии станет настолько сложной, и даже при добавлении первого и второго if-else он добавлялся лишь случайным образом.
Так что я думаю, что этот горшок определенно принадлежит партии А, пусть его мать меняет свои потребности. Думая об этом, я чувствую себя намного лучше.Программирование, самое главное, это прочитать!
Поэтому я добавил еще два if-else, протестировал, отправил и ушел с работы.
Прочитав ответ автора, второй брат вытерпел безымянную грусть и сказал несколько слов.
За более чем десятилетнюю карьеру программиста у меня действительно было бесчисленное количество побуждений реорганизовать исходный код и настроить его. хуже.
В конце концов, взять на себя вину - это большое дело, хе-хе.
Иногда код нельзя назвать произведением искусства, важно уметь умеренно терпеть несовершенства, чтобы программа работала, количество ошибок можно было контролировать, а любые проблемы можно было решить.
Если его рефакторят и что-то пойдет не так, он обречен взять на себя вину, и это тоже может повлиять на Miss Test.
Помню на втором курсе иностранной компании, потому что новый человек в группе слишком плохо писал, я не мог не оптимизировать его туда-сюда, ведь я как тимлид должен нести ответственность за нового человека и команда.В результате, угадайте что?
Меня отругал вождь!
Причина очень проста.Я специально ввел баг, который не был обнаружен при Code Review, и не тестировался в тесте.Результат был в официальной среде.Было так, что руководитель был в командировке в Японии, и руководитель хотел показать результаты руководителю, в результате в программе был баг, и лидер был сильно отруган.
Лидер был утвержден, поэтому, естественно, звонок из-за границы заставил меня ругаться и плакать!
Я был еще молод в то время, и это было обидой. Но что мне делать, кто не возьмет вину на себя?
Позже, после возвращения в Лоян, размер команды стал меньше, и мне пришло в голову желание провести рефакторинг, ведь на этот раз никто не может меня контролировать, когда я вижу, кто пишет плохой код, я просто действую как тигр. и рефакторинг к моему удовлетворению.
Даже если введут новый баг, не беда, ведь начальство не понимает, так что дурачиться, хе-хе.
Хоть начальник и не знает кода, но умеет писать код, как тут не быть багов - после моих неустанных усилий я успешно внушил боссу эту идею. рабочая сила тестовой группы Лидер не желает платить дополнительную зарплату.
После успешной промывки мозгов босса я действительно впал в крайность в течение определенного периода времени и даже рефакторил свой собственный код снова и снова, две книги, которые я читал чаще всего, «Путь к очистке кода» и «Это». Рефакторинг · Улучшение дизайна существующего кода».
От простого именования переменных, именования методов до сокращения количества строк метода, разбивайте его, если его можно разделить, и старайтесь, чтобы количество строк каждого метода было не длиннее мизинца. Чтобы адаптироваться к шаблонам проектирования, я также купил копию «Дзен шаблонов проектирования», которая была очень утомительной.
Безумно вспоминать те дни сейчас: иногда я действительно не спал много ночей, чтобы исправить новые ошибки, вызванные моим рефакторингом.
Но одно скажу, прогресс тех дней тоже виден невооруженным глазом.
Однако, сказав, что для проектов с относительно высокими требованиями к стабильности, если возможности не на этом уровне, мы должны стараться рефакторить как можно меньше, Может быть, в журнале обновления версии будет запись: XXX программистов принесено в жертву. на небеса!
Лучше дождаться момента, когда главарь не сможет не отдать приказ о смерти, и в течение нескольких дней ожидания обязательно убрать эту гору дерьма! К тому времени еще не поздно проявить себя.
Если вы действительно этого не переносите и не можете использовать свои идеи по рефакторингу и настройке, я рекомендую вам хороший способ — начать самостоятельно обучающий проект, который можно разработать самостоятельно или доработать на GitHub. проекты, такие как vhr, mall, miaosha и т. д., которые я всегда рекомендовал, разветвите исходный код и вытащите его, запустите локально, попробуйте прочитать исходный код, и если вы чувствуете, что есть необходимость в рефакторинге, потренируйтесь еще раз, даже если Что-то пошло не так, и никто не может на это повлиять, верно?
Если некоторые студенты считают, что они более мощные, они могут использовать эти лучшие сторонние библиотеки для экспериментов.После рефакторинга они должны не забыть протестировать и представить свой отчет о тестировании при подаче PR.Если автор проекта считает, что вы серьезны. Существует уровень структуры, возможно, вы станете сопровождающим проекта одним махом, а также это бонусный пункт в вашем резюме.
Но для кучи дерьма в компании, постарайся быть максимально убогой при использовании ножа, чтобы не закопаться.
Вернемся к Жиху на тему if-else и переключимся. Мой друг @yes упомянул в ответе, что класс ChannelEventRunnable в исходном коде Dubborun()Метод, я использовал плагин Sourcegraph, чтобы посмотреть исходный код Dubbo на GitHub, и это действительно стоит изучить.
public void run() {
if (state == ChannelState.RECEIVED) {
try {
handler.received(channel, message);
} catch (Exception e) { }
} else {
switch (state) {
case CONNECTED:
try {
handler.connected(channel);
} catch (Exception e) {}
break;
case DISCONNECTED:
try {
handler.disconnected(channel);
} catch (Exception e) {}
break;
case SENT:
try {
handler.sent(channel, message);
} catch (Exception e) { }
break;
case CAUGHT:
try {
handler.caught(channel, exception);
} catch (Exception e) { }
break;
default:
}
}
}
Видите ли, в этом коде сначала используйте if для вынесения суждения, а затем используйте switch для вынесения суждения о переходе в else. Почему бы просто не использовать switch all?
Чиновник также дал особое пояснение.
Я выделил некоторые ключевые моменты, чтобы все поняли.
Современные ЦП поддерживают прогнозирование ветвлений и конвейер инструкций, которые в совокупности значительно повышают эффективность ЦП. Для простых переходов if ЦП может достаточно хорошо выполнять предсказание переходов. Но для переключения переключателей процессору нечего делать. Переключатель в основном основан на индексе, беря адрес из массива адресов и затем перескакивая.
Так что не во всех случаях рефакторинг if-else в switch — лучший выбор, да и подстраиваться под локальные условия все равно надо. Я снова узнал что-то новое, ха-ха.
Еще одно слово, если вы действительно хотите провести рефакторинг кода, рекомендуется изучить шаблоны проектирования и продолжать доминировать на GitHubTrending. Шаблоны проектирования — это типичные решения распространенных проблем при проектировании программного обеспечения. Они похожи на готовые чертежи, которые можно корректировать в соответствии с потребностями. Их можно использовать для решения повторяющихся проблем проектирования в коде. Если вы не понимаете шаблоны проектирования, вы можете только столкнуться с этими проблемами.
Наконец, я надеюсь, что все задумаются об этом при рефакторинге if-else, есть ли какой-либо другой лучший выбор, кроме переключателя, возможно, исходный код Dubbo дает решение.
Я второй брат, увидимся в следующем выпуске, не забудьте поставить лайк~~~~~