GD Star Rating
loading...

Пост ваших фейлов. Постим самое ужасное, что вам пришлось написать или разгребать в рабочей практике.

www.hardblog.net  - сервера, компьютеры, ноутбуки, windows, linux, unix, nix

Tagged with →  

76 Responses to Пост ваших фейлов.

  1. 96mNix:

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

    public void TestConstructor()
    {
    Assert.IsInstanceOf(new UserController(), typeof(UserController));
    }

    всем покрытие тестами!

  2. Xuaef:

    Однажды я видел функцию на Java, которая принимала несколько десятков параметров. А ещё я видел класс на Java с несколькими сотнями методами. Enterprise такой Enterprise… И да, никогда не доверяйте написание кода крупным корпорациям, которые пишут софт для компаний из Fortune 500.

  3. LagVelo:

    Я однажды читал сорцы и лоадтестировал легаси код для одного стартапа. По сути – чатик для мобильных сокетах. НодеЖС, МонгоДБ, старбакс, рисёч вот это всё.

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

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

  4. LagVelo:

    Ещё имел счастье помогать с iOS-проектом, где техлидом стоял начинающий мидл-левел разработчик с амбициями архитектора. Из счастья:
    – вынесение всяких вспомогательных методов для работы с интерфейсом в хелпер-класс в виде статических методов (вместо базового класса или категории над UIViewController). Выглядит как чистой воды процедурное программирование, как в турбо-паскале.
    – методы с безымянными аргументами. Кровь из глаз. (Технически это не имена, а части имени метода, состоящие из одних двоеточий, но неважно).
    – возврат значения из метода не через return а через передачу туда указателя на указатель. Так в Cocoa делать можно строго в одном случае — передаче &error для последующей проверки. Кроме того, битый час потом вместе с другим синиором убеждали его что так делать нельзя.

    Ну там ещё много чего менее весёлого, но такого что можно сделать гораздо проще, да и вообще весь проект снизу доверху с какой-то не такой кармой.

  5. PrtZlo:

    Прохладная былина от меня.
    Лет 5 назад я работал в небольшой конторке, которая разрабатывался скоринговую систему. Там процесс был реализован так, есть такая чудесная программа под названием ErWin, для описания сущностей. В общем, в ErWin заносился какой-либо объект, на его основе генерировалась туча говнокода на яве и jsp(теги, странички и тд), по идее после этого можно было взять кинуть тег на страницу, указать ему какие поля отображать и вуаля, форма сохранения готова. Вся бизнес логика была вынесена в jsp. Благодаря широкой душе разработчика вот этого всего, проект занимал 700 мегабайт, в нем были классы по 2 мегабайта и именно тогда я узнал, что ява не может скомпилировать метод размером больше 64 кб. О том, что 2 разработчика параллельно это вести не могут я уж не говорю.

  6. Seken:

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

  7. FdmAll:

    Код на Делфи, в котором цикл был сделан копипастом кода на три экрана 12 раз, с изменением одной-двух строчек в этих повторяющихся блоках.

  8. LizSm:

    Ты фрагментацию на уровне read не увидишь, если специально не стараться.

  9. Iamin:

    возврат значения из метода не через return а через передачу туда указателя на указатель.
    На самом деле – это очень распространенная практика. В том же directx sdk так создаются почти все объекты – функция возвращает код ошибки (hresult) а указатель на объект ты получаешь как раз из аргумента, который указатель на указатель.
    В общем, еще один способ и я не могу сказать что он плох.

  10. Ots01:

    мне на Java/Netty как-то удавалось

  11. Xuaef:

    можно увидеть как нефиг делать, если захотеть. Достаточно пойти на сервак самописный через телнет в режиме посимвольного ввода (:

  12. Ots01:

    по поводу возврата через аргументы — вообще нет, Cocoa просто предлагает для таких аргументов префикс “get”, например -[UIColor getRed:green:blue:alpha:], но конечно такое стоит делать только если совсем припрет и return value уже занято чем-то полезным и логично разделить на два метода не выходит.

  13. Ots01:

    ну у DX convention такой, возвращать всегда hresult

  14. Xuaef:

    на сколько я понимаю, в DX так сделано из-за отсутствия исключений. Или в iOS в O-C тоже их нету?

  15. Xuaef:

    не лучше ли тогда вернуть структуру, например?

  16. Iamin:

    dx не использует исключения, да. Что, в общем-то, логично и оправдано для такой низкоуровневой штуки.

  17. Iamin:

    ну я вообще про способ возврата, иногда такой способ действительно удобен.

  18. KkeNo:

    увидел в соседнем модуле

    lastInfoWindow = myMap.toMap(new Point((InfoWindow)(myEditor.attributeIns pector.parent.parent.parent.parent).anch orX, (InfoWindow)myEditor.attributeInspector. parent.parent.parent.parent).anchorY));

    товарищ объяснил изъеб как фундаментальный недостаток API/SDK

  19. Xuaef:

    угу, я просто к тому, что кагбе вроде в иос они есть, не? Посему такой возврат не особо нужен.

  20. Iamin:

    захламлять код одноразовыми структурами тоже не дело. Уж лучше std::pair юзать и аналоги.

  21. Iamin:

    некоторые вещи лучше писать без использования исключений, блогер.

  22. Xuaef:

    ну я не знаю какие штуки есть в обжси, структуры-то точно есть.

  23. KkeNo:

    там же

    var list:List = (List)((AttributeInspectorSkin)(myEditor.attributeInspector.getChildAt(0)).getCh ildAt(1));

    не ходите, дети, в ArcGIS API for Flex

  24. Iamin:

    это ты говнокода на actionscript не видел, там цепочка parent.parent… может быть на пару строк.

  25. KkeNo:

    так я из .mxml и выдернул. мучаемся.

  26. Iamin:

    да ладно, вполне читаемый кусок.

  27. KkeNo:

    да, но выглядит meh.

  28. Xuaef:

    а сделать функцию поиска родителя не?

  29. Iamin:

    как и почти любой другой код, написаный другим прграммистом

  30. Iamin:

    говнокода на actionscript

  31. Xuaef:

    забыл о чем пост, лол.

  32. YnNko:

    пусть это полежит здесь. и не благодарите.

  33. LetSpb:

    у меня больше железная ориентация.

    1. Одна известная японская фирма пару десятков лет назад сделала некий массовый прибор. В котором помимо прочих также присутствует кириллический знакогенератор. Якобы CP866. Но неизвестный японский пидарас перепутал расположение символов мягкого и твердого знака. (хули ему до варварских закорюк)
    Потом набижали китайцы и прочие, и начали клонировать. Естественно полностью. И это стало стандартом! Теперь в это говно наступают все. Тысячи наших прикладных программистов.

    2. Железо вообще все забагованное. В процессорах всегда есть ROM с программой зашитой однократно на заводе. После включения начинает работать этот код и ищет носитель откуда ему стартовать.
    Пару лет назад разрабатывал железку на гигагерцовом ARM’е. По ТЗ было необходимо 256 МБ NAND flash. Собрали плату – не работает.
    Подключаю аппартный отладчик и начинаю дебажить.
    Этот предзагрузчик очень маленький по объему. Все что он может это спроецировать самого себя в кэш, потом спроецировать первый сектор любой микросхемы NAND в кэш и передать управление на него.
    Но даже в этом предзагрузчике есть баги. Перед тем как передать управляение он на лету патчит сам себя исходя из информации из первого сектора… Ну хрен бы с ним.
    Далее получает управление загрузчик который должен определить тип текущей микросхемы NAND: количество и размеры всех страниц, секторов, таблиц чтобы корректно работать с этим хозяйством. – Понимаю что это не работает.
    Лезу в исходники загрузчика.
    Неизвестный программист бодро начал: красиво парсит структуры разных микросхем согласно стандарту (типов и размеров там туевы хучи), а потом хуяк вставляет костыли: если тип такой-то, то параметры такие-то. И на мой размер – ошибка.
    Я правлю логику, пересобираю загрузчик – все работает.
    Радовался пару недель.
    Потом пришла следующая партия процессоров новой ревизии с которыми ничего не работает. Читаю описание: “бла бла бла мы теперь крутые у нас мегазагрузчик мы все запиздрядчили в ROM процессора!”.
    Заказал NAND памяти кучи производителей (разные ID и железные параметры): Samsung, Micron, Numonix, Toshiba, Hynix… Перепробовал все. Естественно болт. Казлы намертво заканапатили баг в процессор.
    Пришлось просить манагеров пересмотреть себестоимость и ставить микросхему в 512 МБ. – Продукт у нас массовый и пара баксов это заметно.

  34. Sukblack:

    Я вот увидел тут в javachesslib забавный в своей нелогичности цикл.

    Щаз с работы чо-нить вспомню.

  35. Sukblack:

    Ну например, из моих прелестей:

    ChatDisplay::ChatDisplay(QWidget *parent)
    : QTextBrowser(parent), window(static_cast(parent->parent()->parent()->parent()->parent())) /// FIXME YUCK! this depends on designer generated ui. please use some other way to get to the parent ChatWindow. Yes, this is 5 calls to parent().
    {
    qDebug(“Constructing ChatDisplay, parent %p / %p”, parent, window);
    }

  36. LetSpb:

    3. Есть мнение что “синий экран смерти” это по причине кривых драйверов сторонних разработчиков. M$ же белый и пушистый.
    Я делал мультиинтерфейсную USB-железку. Через один провод одновременно: тач панель, самодельный HID, виртуальный RS232… Решил не разрабатывать драйвера (тем более нужно было работать с кучей операционок) а воспользоваться штатными драйверами: драйвером композитного девайса, хаба, HID.
    При подключении по стандарту система собирает из железки дескрипторы с детальным описанием. Это куча битовых полей. В моем случае больше килобайта. Легко сделать ошибку. Виндовые драйвера – черный ящик. Либо система отвергает твою железку, без объяснения причин, либо работает. Так вот в процессе отладки получился дескриптор который валил любой комп под XP в синий экран если просто воткнуть в порт USB мою железку. Без необходимости ставить драйвера, без прав администратора…
    Не схоронил, так как было совсем не весело)

  37. YmmNix:

    Когда давно унаследовал код на C#, в котором параметры всегда передавались строками. То есть, при вызове всему делался.ToString(), а в методах всё первым делом парсилось обратно. Там же встречались странные конструкции типа bool foo = bool.Parse(“True”) или даже что-то типа такого: if (bool.Parse(blah.ToString()).ToString() == “True”) {…}. Не помню точно, но что-то близкое к этому.

  38. CaKen:

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

    www.hardblog.net  - сервера, компьютеры, ноутбуки, windows, linux, unix, nix

  39. Sukblack:

    видел такое на TheDailyWTF как-то.

  40. YmmNix:

    Там же был замечательный метод, принимающий Control (ASP.Net) и что-то там с ним делающий в зависимости от типа контрола. Но, вместо проверки типа, там было подряд несколько десятков конструкций типа try { Button btn = (Button)control; … } catch {} try { TextBox btn = (TextBox)control; … } catch {} и так далее. Раннего выхода в случае успеха приведения типа и обработки контрола не было, так что это веселье продолжалось дальше до конца метода. Метод вызывался в цикле для каждого контрола на каждой странице, так что тормозило всё это просто чудовищно.

  41. YmmNix:

    О, а еще меня как-то попросили слегка доработать один CRM проект на PHP, сделанный одной прилично выглядящей веб-студией. Проект внешне также выглядел довольно аккуратно, но когда заглянул внутрь, у меня волосы дыбом встали. Я никогда не видел такого количества копипасты, и настолько чудовищно замороченной “организации” кода. На то, что бы просто найти, в каком файле исходников нужно смотреть код вот этого куска вот этой страницы, уходило несколько минут, причем, каждый раз. Проект состоял из пары десятков директорий, по десятку-другому файлов в каждом, код в которых был практически одинаковым и отличался только тем, что запрашивается из MySQL, как оно отображается и что спрашивается у юзера.

  42. YmmNix:

    “…код в которых был практически одинаковым и отличался только тем…”
    То есть, каждый файл из себя представлял огромную простыню, где делалось всё с начала и до конца, одно и то же. Никакой отдельной библиотеки для чего бы то ни было не было.

  43. CaKen:

    У меня были “модели” – класс с кучей методов для каждого запроса, каждый параметр запроса был параметром функции. Т.е. вместо селекта в контроллере писался метод с 15-20 параметрами, половина из которых была 0 или 1. Если что-то пропустишь – потом мучительно отлаживаешь…
    Ад со скриншота – это “контроллеры”, где была собрана почти вся логика, копипащенная по несколько раз. А остатки логики, порою довольно значительные, были в шаблонах смарти. И в джаваскрипте, тоже функции с миллионом параметров.
    Ух, как вспомню, так вздрогну.

  44. Xuaef:

    откуда такие вылазят?

  45. LesVelo:

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

  46. Xuaef:

    Spring для Java – та же хуйня. Во время любого запроса одни и те же проверки делаются в сотни мест. Энторпрайз, йопт, лол.

  47. Sukblack:

    Ох, обалдеть. *стащил методику себе*

  48. Sukblack:

    Я тут свой старый пхп код откопал, там тоже жуть.

  49. 999nod:

    приди пожалуйста в тред и расскажи, потому что я – (горе-)js-кодер – не понимаю, какие могут быть проблемы с фрагментацией пакетов в ноде. Ну или не сталкивался с такими проблемами. Можешь ткнуть даже в вики или живой пример

  50. Sukblack:

    Да никаких в принципе, если она работает нормально и в TCP. С клиентской стороны ничего не видно.

  51. 999nod:

    тогда о чем пишет ?

  52. EraAdm:

    Защита кода

    private const string F_GET_HIERARCHICAL_ENTITY = “c_dfmanager_f_get_hierarchical_entity”; // DO NOT drop! Used from other functions
    private const string F_GET_HIERARCHICAL_CHILD = “c_dfmanager_f_get_hierarchical_child”; // DO NOT drop! Used from other functions
    private const string F_GET_PLAIN_HIERARCHY = “c_dfmanager_f_get_plain_hierarchy”; // DO NOT drop! Used from other functions

  53. LagVelo:

    В cocoa конвеншенах явно сказано что так можно делать только с NSError. Ну и возвращалось через return там что-то бесполезное типа BOOL.

  54. LagVelo:

    : я похоже криво сформулировал мысль. Бились/клеились не TCP-пакеты, а высокоуровневые мессаджи которые бежали по сокету. Ну то есть там был голый JSON без сепараторов или указания длины месаджа, соответственно надёжно их было никак не разделить.

  55. LagVelo:

    Там был тупо результат фетча из базы, можно было его вполне нормально вернуть через return.

  56. XibaTa:

    “© 2001” – хе-хе, я вот недавно нашел свое тех же времен. Был в шоке. 🙂

  57. NorAdm:

    Я может чогой-то не втыкаю, но XMPP так же работает, как ты описал, только xml.

  58. Xuaef:

    между пакетами всегда надо ставить разделители. Или каким-то другим образом за этим следить. Во всяких XMPP всё это сделано на уровне библиотек и ты про это даже не знаешь. Штука в том, что ты читаешь из сети поток какими-то кусками. Тебе может придти десять байт, сто байт, потом ноль байт, потом два. Как карта ляжет. И если ты не палишь за границами своих высокоуровневых пакетов, то тобi пiзда.

  59. LagVelo:

    Ммм да, в XMPP непрерывный XML, который парсится SAX-парсером. Тут же была ситуация “читаем из сокета байтики, пока они есть и надеемся что это окажется валидный JSON”. Иногда в буфере оказывалось несколько склеенных сообщений, либо фрагмент, и тогда этот контент тупо втихую выкидывался.

    В принципе, понятно, тут тоже можно было обойтись без сепараторов и эмиттить новое сообщение как только мы вышли за последнюю ‘}’, но этого тоже никто не сделал.

  60. Sukblack:

    Ты будешь смеяться, но на самом нижнем уровне это тоже работает.

  61. Sukblack:

    Первый мой проданный за деньги пхп код.

    Я тут свой код 1998 года нашел…

  62. Seken:

    не знаком с предметной областью и особо с плюсами – что не так?

  63. Sukblack:

    там везде какой-то очень черезжопный форматтинг, комменты на русском через один, но вычислительная часть вроде вся правильная.

  64. Xuaef:

    к говнокоду это сложно отнести. Вот PHP пример зачётный!

  65. Sukblack:

    Ну значит в 1995-98 я на плюсах лучше писал чем в 2000 на пхп 🙂

  66. 96mNix:

    ето же пехапе, оно обязывает

  67. Astin:

    Из недавнего:
    class A
    {
    A& getRef()
    {
    return (A&)(A*)this;
    }
    };

  68. OHA01:

    if ($someCondition->isTrue()) {

    // …

    class ID {
    private static $id = 42; // for example

    public static function getID () {
    return $id;
    }
    }

    // …

    }

  69. Sukblack:

    А зачем ты this кастил к (A*) внутри non-const метода A? Обычно просто return *this;

  70. Sukblack:

    Специальный хелпер класс внутри ифа? А как он потом использовался?

  71. Astin:

    это не мой код, когда я его увидел, то тоже озадачился.

  72. Kixsuper:

    var myCondition = true;
    while( true ) {
    console.log(“Samaya tupaya oshibka, bleyat’ :)”);
    myCondition = false;
    }

  73. LanNo:

    эффективно!

Добавить комментарий