Цели рефакторинга? [закрытый]
Вы можете добавить обработчик событий щелчка в документе. если целевой элемент не имеет предка элемента .menuBar (см .: .closest () ), вы можете закрыть меню:
document.addEventListener('click', function(e) {
if (e.target.closest('.menuBar') == null) {
document.querySelectorAll('.menuBar ul').forEach((ele) => ele.style.display = "none");
}
});
function menuClick (x, e) {
e.preventDefault();
var dropMenu = document.getElementById(x);
var dropAccounts = document.getElementById('menuAccounts');
var dropLoans = document.getElementById('menuLoans');
if(x === 'menuAccounts'){
if(dropMenu.style.display !== "block"){
dropMenu.style.display = "block";
dropLoans.style.display = "none";
}else{
dropMenu.style.display = "none";
};
}else if(x === 'menuLoans'){
if(dropMenu.style.display !== "block"){
dropMenu.style.display = "block";
dropAccounts.style.display = "none";
}else{
dropMenu.style.display = "none";
};
}
};nav {
color: #ffffff;
background-color: #0000ff;
}
.menuBar li{
display: inline-block;
text-align: center;
}
.menuBar li a{
color: #ffffff;
text-decoration: none;
}
#menuAccounts{
display: none;
position: absolute;
background-color: #0000ff;
margin: 0 0 0 3em;
}
#menuLoans{
display: none;
position: absolute;
background-color: #0000ff;
margin: 0 0 0 6em;
}
#menuAccounts li, #menuLoans li{
display: block;
text-align: left;
padding: 0 1.5em;
}15 ответов
Понятность
Больше простого и хорошо организованного (учтенного) кода легче понять.
Правильность
Легче определить дефекты контролем в коде, который это легче понять. Чрезмерно сложный, плохо структурированный, код стиля Rube Goldberg намного более трудно осмотреть для дефектов. Кроме того, хорошо разбитый на компоненты код с высокой когерентностью компонентов и слабой связи между компонентами значительно легче подвергнуть тесту. Кроме того, меньшие, правильно построенные биты под тестом делает для меньшего количества перекрытия в покрытии кода между тестовыми сценариями, которое делает для быстрее и больше защищенных тестов (который становится самоукрепляющимся управлением цикла к лучше и лучшие тесты). Также, больше простого кода имеет тенденцию быть более предсказуемым и надежным.
Простота обслуживания и эволюции
Хорошо учтенный, высокое качество, легкое понять общие компоненты, легче использовать, расширить, и поддержать. Много изменений в системе теперь легче внести, потому что они оказывают меньшее влияние, и более очевидно, как внести соответствующие изменения.
Рефакторинг кода действительно имеет заслугу самостоятельно только с точки зрения качества кода и проблем правильности, но где рефакторинг окупается, больше всего находится в обслуживании и эволюции дизайна программного обеспечения. Часто хорошая тактика, когда добавление новых опций к старому, плохо учтенному коду должно осуществить рефакторинг целевой код затем, добавляет новую опцию. Это часто будет прилагать меньше усилий по разработке, чем попытка добавить новую опцию, не осуществляя рефакторинг, и это - удобный способ улучшить качество кодовой базы, не предпринимая много "журавля в небе" гипотетический рефакторинг преимущества / работа модернизации, которую это твердо выровнять по ширине к управлению.
Рефакторинг используется для оплачивания Технического Долга.
- Устранить/уменьшить "Запахи Кода"
- Легче для любого разработчика понять код
- Сделать это удобным в сопровождении.
- Увеличить сцепление и уменьшить связь"
На очень простом уровне цель состоит в том, чтобы улучшить код, делая это большим количеством читаемых, менее двойных, уменьшающихся коэффициентов ошибок, и так далее.
На другом уровне рефакторинг появился как альтернатива BigUpfrontDesign. Также при использовании в контекстах, таких как рефакторинг Экстремального программирования обязанность. Вы выплачиваете ипотечный кредит на своих технических долгах каждый день каждый час. Вместе с принципами как Коллективное Владение Кода это также делает каждого человека ответственным за рефакторинг кода где угодно, не только кода записанный (или писавший совместно) собой.
Я обычно не осуществляю рефакторинг код только, чтобы уменьшить запахи кода или сделать его 'более хорошим '/more удобный в сопровождении. Я действительно осуществляю рефакторинг, когда я должен исправить ошибку, и я хочу оставить код в лучшей форме, чем это было прежде. Другая причина состоит в том, когда я хочу добавить функциональность, и было бы трудно обойтись без рефакторинга. Третья причина состоит в том, чтобы сделать код более тестируемым. Иногда я осуществляю рефакторинг для изучения кода, который я не понимаю :-)
Цели рефакторинга?
Passtime?
Серьезно, я делаю это к:
- избегайте дублирования кода, когда я буду видеть его (после принципа DRY)
- упростите код (удалите ненужные специальные сложности, посмотрите KISS),
- удалите старый/устаревший/устаревший код (чистящий отходы, когда-то старый код заменяется),
- устраните побочные эффекты
- сделайте вывод и повторное использование существующий код
- сокращение сложности отдельных функций - делает тестирование легче
- устранение повторенного кода - уменьшает возможности для ошибок
Рефакторинг может иметь стимулы кратных чисел:
- улучшите удобочитаемость кода
- упростите структуру кода
- улучшите пригодность для обслуживания
- улучшите расширяемость
Причина начать осуществлять рефакторинг обычно зависит от проблем, с которыми Вы столкнулись.
Если Вы расширяете свое программное обеспечение и задержку через ошибки, и Вы не можете найти источник ошибок, то Вы могли бы начать осуществлять рефакторинг для упрощения структуры кода, чтобы помочь разработчикам разыскать ошибки.
Иногда ошибки прибывают из function/class/..., который использовался не как он, был предназначен. Это указывает, что код не было легко понять или плохо зарегистрированный.
Теперь при улучшении документации, удобочитаемости кода и структуры кода, Вы также приведете к лучшей пригодности для обслуживания...
Конечно, когда Вы уверены, что никогда не должны будете касаться части кода снова, нет никакой потребности осуществить рефакторинг тот код.
Но большую часть времени, необходимо будет коснуться его снова, потому что необходимо будет добавить опции, исправить ошибки или оптимизировать его.
Так, да, конечно, это должно проложить путь к будущим изменениям. Код всегда изменяется.
Вообще говоря, я только осуществил бы рефакторинг производственный код для многократного использования его или когда модификации требуются.
Например, я должен был обновить функцию по причинам производительности, но не было легкого тестового интерфейса, таким образом, я осуществил рефакторинг его в отдельный модуль, который мог быть протестирован на единицу более легко, затем внес изменения, таким образом, я мог повторно выполнить тесты и показать, что он работал как прежде.
Рефакторинг кода, который не должен быть изменен, является залогом провала; это, как гарантируют, представит ошибки.
Рефакторинг кода является необходимостью наблюдения того, что изменение неизбежно. Это - основная цель, должен улучшить текущий код или дизайн для создания этого подсудным и конгруэнтным с новыми функциональными или нефункциональными требованиями или сделать это более терпимым для изменения.
Примеры сценариев, где рефакторинг может быть необходимым:
- Введение нового бизнес-правила, которое требует, чтобы текущий дизайн был абстрагирован к новому уровню;
- Распознавание того, что текущий дизайн мог быть изменен для лучше наблюдения ТВЕРДЫХ принципалов объектно-ориентированного дизайна;
- Когда тестируемость кода должна быть увеличена---, это касается 2 выше.