Какие наихудшие анти-паттерны вы встретили в своей карьере программиста?

Я в основном занимаюсь Java, хотя, вероятно, это не зависит от языка.

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

Закомментированный код. Блоки этого, возможно, сотни строк. Теория такова: эй, это закомментировано, это не приносит никакого вреда, и, возможно, нам это понадобится в будущем.

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

Это особенно распространено в некоторых функциональных и API-тестовых кодах конца 90-х годов: буквально сотни (или даже тысячи) практически идентичных тестовых примеров, которые можно было бы разбить на несколько функций, которые принимают 3 или 4 параметра - или, что еще лучше что-то управляемое данными. Моей первой работой после колледжа было буквально 8 месяцев переписывания и рефакторинга тысяч строк копировальной пасты с использованием устаревших методов. К тому времени, как я закончил, тестовые файлы были менее чем на десятую часть от их первоначального размера и намного более удобны в обслуживании (и читаемы!).

Я думаю, что я могу много написать о Pattern Mania и решениях, которые можно решить с гораздо меньшими усилиями, но я бы скорее указал на большую статью, которую я недавно прочитал, с фантастическим примером того, как простое решение может быть слишком сложным ,

Как (не) писать Факториал на Java или так, мы вводим фабрику в ваш алгоритм

Золотой Молот

«У меня есть молоток, а все остальное - гвоздь».

районы

В C # вы можете определить область кода, которая может быть свернута в IDE, тем самым скрывая ее, если вы не хотите иметь дело с этим кодом. Я принимал (в настоящее время включаю) проект, в котором регионы охватывали сотни строк (если бы я преувеличивал), и в функции из тысячи строк было несколько регионов (опять же, я хотел бы шутить).

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

Регионы поощряют разработчиков «прятать» свое дерьмо на виду.

Для меня худший шаблон это Копировать / Вставить .

Не перегруженные методы:

// Do something
public int doSomething(Data d);

// Do same thing, but with some other data
public int doSomething2(SomeOtherData d);

Наглядно видно, что программист не понимал перегрузки.

Последовательности петлевого переключателя

http://en.wikipedia.org/wiki/Loop-switch_sequence

Они бесконечно раздражают меня и показывают, насколько неопытным был

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

Сохраняйте состояние в клиенте.

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

Массивные Checkins

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

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

В настоящее время я работаю с устаревшим кодом, и мне нравится, как предыдущий кодер получает первый элемент списка:

String result;
for(int i = 0; i < someList.size(); i++) {
    result = someList.get(i);
    break;
}

Но самое худшее, что я видел в этом коде, это определение классов встроенных страниц JSP, написание всего HTML, CSS и Javascript с использованием scriptlet и out.println :-(

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

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

Блокировка на строковом литерале

synchronized("one") { /* block one A*/ }

synchronized("one") { /* block one B*/ }

Очень длинные имена классов. (в JRE)

com.sun.java.swing.plaf.nimbus.
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Плохая структура наследования

com.sun.corba.se.internal.Interceptors.PIORB extends
com.sun.corba.se.internal.POA.POAORB extends
com.sun.corba.se.internal.iiop.ORB extends
com.sun.corba.se.impl.orb.ORBImpl extends
com.sun.corba.se.spi.orb.ORB extends
com.sun.corba.se.org.omg.CORBA.ORB extends 
org.omg.CORBA_2_3.ORB extends
org.omg.CORBA.ORB

Исключение, которого нет.

public interface FlavorException { }

Бессмысленная и загадочная обработка ошибок

if (properties.size() > 10000)
   System.exit(0);

Ненужное создание объектов

Class clazz = new Integer(0).getClass();
int num = new Integer(text).intValue();

Бросать исключение для других целей

try {
    Integer i = null;
    Integer j = i.intValue();
} catch (NullPointerException e) {
    System.out.println("Entering "+e.getStackTrace()[0]);
}

Использование объектов экземпляра для статических методов.

Thread.currentThread().sleep(100);

Синхронизация на не финальном поле

synchronized(list) {
   list = new ArrayList();
}

Бессмысленная копия постоянной строки

String s = new String("Hello world");

Бессмысленный вызов String.toString ()

String s = "Hello";
String t = s.toString() + " World";

Вызов System.gc () для освобождения памяти

Установка локальной переменной на ноль для освобождения памяти

    // list is out of scope anyway.
    list = null;
}

Использование ++ i вместо i ++ по соображениям производительности (или любой другой микро-микро-оптимизации)

Код посыпан:

// TODO: 

или

// TODO: implement feature 

без дополнительной информации.

Итератор для чайников:

Iterator iCollection = collection.iterator();
for(int i = 0 ; i < collection.size() ; i++ ){
    if(collection.get(i) == something){
       iCollection.remove();
    }
 }

Singletono-Factory:

public class SomeObject{
   private SomeObject() {}
   public static SomeObject getInstance(){
       return new SomeObject();
   }
}

разработка, управляемая if-else (также называется принципом открытого закрытия - открытым для модификации, близкого для понимания):

if (sth1){
...  
}else if(sth2){
..
}
...
..
else if(sth1000000000000){
...
}

StringPattern (также называется StringObject):

a) sendercode
if(sth1)
   str+="#a";
if(sth2)
   str+="#b";
...
if(sth1000)
   str+="#n";

b) receiver
   regexp testing if str contains #a, #b, ... #n

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

Это связано с более общим шаблоном, который будет делать , вот примерная строка кода для него:

int num = new Integer( stringParam ).parseInt( stringParam );

Это работает, в конце концов.

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

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

2. В MATLAB и R настойчивое требование, что все является вектором / матрицей, а не примитивом.

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

4. Чисто функциональные языки, где вы должны использовать вызовы функций для написания цикла.

Это было бы определенно копирование / вставка, из-за этого я видел много плохого кода, это и ковбойское кодирование и все, что вытекает из этого. (Классы Бога, очень большие методы, плохо продуманные алгоритмы и т. Д.)

И если бы разрешались шаблоны проектирования, я бы сказал: «Выполнение проекта как набора действий из плана, без какого-либо проектирования или анализа предметной области».

Многофункциональный боб Java -

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

Кроме того, не могу забыть любимого

try{ 
   ... //many lines of likely dangerous operations
}
catch(Exception e){}

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

Что-то, что вызвало у меня много горя, это шаблон «Большая карта в небе». Бродить вокруг карты вместо использования правильных объектов. Вы не представляете, какие «переменные» он содержит, без отладки, и вы не знаете, что он может содержать, не отслеживая код в обратном направлении. Обычно отображает строки в объекты или строки в строки, которые вы потенциально должны анализировать в примитивы.

Один из моих любимых шаблонов разработки - использование «дизайна» базы данных, который требует постоянного добавления дополнительных столбцов в одну или несколько таблиц программным способом . Это двоюродный брат «дизайна», который создает новую таблицу для каждого экземпляра объекта. И то, и другое неизбежно затрагивает ограничения сервера базы данных, но обычно это происходит до тех пор, пока система не будет работать в течение достаточно долгого времени.

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

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

Наш проект имеет довольно сложный алгоритм, который сохраняет промежуточные значения для последующей обработки. Вместо того, чтобы инкапсулировать временные объекты в ... объектах, была создана таблица базы данных, например, "t_object". Каждый раз, когда значение вычислялось, оно добавлялось в эту таблицу. После того, как алгоритм завершит свою работу, он выберет все промежуточные значения и обработает их все в одном большом объекте Map. После завершения всей обработки оставшиеся значения, помеченные для сохранения, будут добавлены в реальную схему базы данных, а временные записи в таблице "t_object" будут отброшены.

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

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

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

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

ПРИМЕЧАНИЕ: я не говорю, что этот паттерн по своей сути плох, но в этом примере я обнаружил, что он не нужен, когда основных принципов ОО было бы достаточно.

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

Тележка перед лошадью - так называемый YouMightNeedIt

Например:

• Создание схемы RDMB с абстрактными понятиями, перекрестными ссылками - по сути, чрезмерно обобщенным кубом данных ... И ТОГДА написание функций вокруг модели "все делает".

IMO худший антишаблон, который я когда-либо видел, это анти-паттерн «Нам не нужны вонючие паттерны»: идея в том, что паттерны проектирования - это пустая трата времени, и вы можете писать код быстрее, просто вставляя его вместе и копируя / вставка по мере необходимости.

Похвальное упоминание - наличие кода, который загружает объект из базы данных, используя старый стиль VB6:

Foobar oFoo = new Foobar();
oFoo.FooID = 42;
if (oFoo.Load()) { 
    // do something with oFoo
}

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

Кроме того, такие вещи:

// this name is misleading, we may not always want to stand in fire,
// we may want to stand in slime or voidzones or ice patches...
public Foobar StandInFire() { }

// why is this here???
public string BeatWithNerfBat(string whom) { }

// ????
public int GivePony(string to) { }