Как стать автором
Обновить
3
0.1
Евгений Матюшкин @Skipy

Разработчик, архитектор, главный архитектор

Отправить сообщение

При платной подписке тоже можно. Удалять часть файлов и требовать за из возврат деньги. Это следующий логичный шаг. Куда там программам-вымогателям! Эту вы сами, добровольно, себе ставите.

Windows 13. Вы нам должны. Мы потом скажем, сколько.

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

Эти "советы" написаны кровью. Не успел за два часа разобраться в чужом коде, найти ошибку, исправить, протестировать, собрать патч и поставить заказчику - получил штраф в 2 млн. Работали в таких условиях? Я работал. Там нет времени на понимание очередного синтаксического сахара ради экономии двух слов в месяц. Кстати, у нас лямбды были запрещены.

А Oracle на всё имеет право. В том числе и на снижение использования языка. Что мы и наблюдаем по индексу TIOBE. С 2020 на первое место Java не поднялся ни разу, за всю историю индекса такого не было.

просто теперь внутри case разрешено ставить не только константу, но и "паттерн" (фактически "условие")

Тут не просто условие. Тут во-первых, совершенно неочевидный instanceof. В case всегда стояло значение того, что указано в switch, это важно. А тут неявно проверяется тип. Напишите value.class - и такой case будет интуитивно понятен.

Пусть у вас value типа Class. А передается туда Class<Number>. И есть два case - case Class и case Number. По типу (неявный instanceof) это Class, по значению Number. Какой case сработает? У вас приблизительно полсекунды на понимание. Дальше это уже "запнулся и потерял скорость восприятия".

Во-вторых, совершенно очевидное объявление переменной, но неочевидная связь этой переменной с тем, что стоит в switch. По отдельности это можно было бы понять, но вместе это уже вызывает ровно тот эффект, о котором я писал - смотришь и не понимаешь. Уйдет этот switch за пределы экрана - и теряется нить восприятия, надо проматывать код назад и искать, а что же там было, откуда присваивание идет

Императивные языки - они более-менее одинаковые по выразительности. Я могу читать код на C#, С++, питоне, Го и еще много чем. Это не вызывает сложностей, это как диалекты одного языка, слова чуть разные, но правила построения фраз совпадают. А тут нарушены именно правила построения. Не получается читать логику, надо читать синтаксис. Отдельные слова.

Лямбды. Анонимные функции. Всё, что привело к потере именования кода. Вторая глава "Чистого кода" - она про именование. Если коротко - "именуйте всё, что можно именовать". Когда в метод передается функция двух целых параметров - ты принципиально не можешь сделать предположение о том, что она делает. Это надо целенаправленно разбираться. Если передается Comparator<Integer> - разбираться не надо, тут всё очевидно. Разница в том, что во втором случае надо написать целых лишних несколько слов:

new Comparator<Integer>{
    public int compare(Integer i1, Integer i2){
        // код функции
    }
}

Аж 8 штук. Один раз. Это такая затрата времени! Быстрее написать (i1, i2) -> // код функции

А о том, сколько лишнего времени уходит на разбор при поддержке этого кода - никто не думает. И SLA на поставку патча в течение двух часов со штрафом в 2млн тоже мало кто встречал.

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

Что, кстати, проявляется и в этой статье - по мнению автора код под 21 читать проще и приятнее, а по мне это трэш и содомия. Полное несоответствие исходной семантике языка. Это даже не речь мастера Йоды, это хаотично добавленные слова, которые ты знаешь, но смысл всего предложения от тебя ускользает. Смотришь и не понимаешь, приходится прилагать усилия для перевода, несмотря на использование языка с 1996 года.

А код под 17 читать сложно не потому, что это 17, а потому что руки надо оторвать тому, кто его так отформатировал. В норме этот код читается намного проще:

public Double convert(Object value){
    if (null == value){
        return null;
    }
    if (value instanceof Double){
        return (Double)value;
    }
    if (value instanceof String){
	    String sValue = (String) value;
		return (sValue.trim.isEmpty()) ? null : Double.parseDouble(sValue)
    }
	if (value instanceof Number){
        return ((Number)value).doubleValue();
    }
    throw new AdvImportException("Can't convert value " + value + " to double");
}

Не соглашусь с "любыми" задачами. Я Вам сейчас ресурсоемкую задачу сгенерирую, которую эта сборка не то что среднепаршивенько, она ее никак не решит. Крякнуть не сможет. То, что говорите Вы - это не универсальная сборка, это сборка, которая по минимуму тянет абсолютно любые задачи. Это очень сильно разные вещи.

Есть такое понятие как профиль использования. Если 95% времени этот блок будет использоваться для сёрфинга, скачивания с торрентов и просмотра видео, то мощная видеокарта ему ну просто не нужна. Если игры занимают существенную часть профиля - это уже игровой компьютер. По описанию, еще раз - собирается именно игровой блок, в описании пяти компонент явно упомянуто их предназначение для игр.

И, да, игры играм тоже рознь. Какие рассматривать будем? Тетрис? Или те, которые на топовых конфигурациях едва 20fps вытягивают?

Изначальный посыл никак не определяет профиль использования, это камень в огород автора. Как тесты проводятся в серьезных пакетах? Берется разный софт и гоняется на разных типовых задачах. Каждая задача имеет вес, по результату считается итоговый результат. А пока вот этого всего в статье нет, а есть пять раз заточенные под игры компоненты - ну, мне лично сложно считать этот блок универсальным. В моем понимании он остро игровой. Не за гранью добра и зла, как требуют некоторые игры, но для универсального явно перебор.

P.S. Если что, моему универсальному ноутбуку 7 лет. И только в этом году я память с 8 до 16 увеличил, перестало хватать для некоторых (!) задач. Обработка изображений (мне и 9-го фотошопа хватило бы за глаза, но он тупо не поднимается под десяткой, а последний память жрет как свинья желуди), обработка звука (хотя audacity совершенно не требователен), очень редко разработка (опять-таки последние версии инструментов аппетит увеличили). Это из специфики. Для остальных, универсальных, задач его более чем хватает.

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

Интересно. В первой фразе черным по белому -

народный ПК под универсальные задачи

А дальше по тексту - игровой, игровой, игровой. Видеокарта "обеспечит комфортный гейминг", материнка MSI B760 GAMING PLUS WIFI, Накопитель для игрового компьютера, памяти будет достаточно для современных игр, "корпус для ПК, особенно игрового".

Вы какой блок собираете в итоге? Для универсального он, мнэ... немножко запредельный по характеристикам. Универсальному хватит встроенной видеокарты и 8Гб памяти на всё. Если держать открытых 500 вкладок в браузере, среду разработки, сервер БД, как у меня - 16Гб. Работаю и не жалуюсь. У вас 32Гб оперативки и 12Гб видеопамяти отдельно. А вот накопителя в 1 Тб для универсального блока откровенно мало - без учета резервирования мне лично нужно минимум 4Тб.

Поменяли бы название на честное - "собираем не топовый игровой блок".

P.S. Отдельно доставляет сочетание "народный" и 100К стоимости без периферии. Вы вообще в курсе медианной зарплаты в России? Если уж мы о народе говорим...

Дай мне возможность, я бы в институте с удовольствием изучил основы права. Бухучет я считал совершенно для меня бесполезным, по факту работаю в банковском IT последние 15 лет, и периодически эти знания оказываются ох как необходимыми. Кстати, основы бухучета преподавал Макс Поташев. Да, тот самый.

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

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

Вот аналогично. 1992-1998г., физтех. На большей части экзаменов можно было пользоваться при подготовке литературой. И с первого же курса "проходных" экзаменов практически и не было. Всегда был долгий разговор на понимание. Собственно, это началось еще со вступительных экзаменов, я одну задачу по математике часа два решал, чуть не десяток разных подходов попробовал. Не решил. Это была одна из аксиом (!!!) метрического пространства, о чем я узнал только на первом курсе. Преподавателю было интересно, как я подойду к решению.

Не все предметы были такими, но как минимум половина. А диплом я писал приблизительно так. Приходит завлаб и говорит - я тут краем уха услышал о новом языке программирования - Java. Посмотри, на что он способен. Исследование растянулось на два с половиной года, вылилось в диплом и определило всё дальнейшее развитие. А дипломная работа, кстати, пошла в пром и работала лет 10, пока летали спутники серии NOAA.

А у меня обратный опыт. Приемы в частных клиниках вдруг появляются на госуслугах. С диагнозами и т.п. Есть ощущение, что все клиники постепенно стали к ЕМИАСу подключать. И, соответственно, все всех видят

К сожалению, именно разработчики. Я недавно интервьюировал одного претендента на solution-архитектора. При обсуждении ситуации с таймаутом вызова бэка из приложения в качестве обработки ситуации он настаивал на максимально неудобоваримом сообщении об ошибке для пользователя. При том, что я несколько раз повторил, что ситуация с таймаутом - штатная, в 90% случаях мы его поймаем. Вопрос был на правильное асинхронное взаимодействие.

Менеджеры тут не при чем. Тут нужны аналитики и специалисты по UI/UX, которыми должны быть дизайнеры в норме

Меня в принципе не перебрасывает в приложение банка, мне это ни к чему. Интернет-эквайринг специальных приложений не требует, вне зависимости, организован он через 3DSecure или без него. Если 3DSecure включен - одна смс. Всё. Если не включен - даже телефон не нужен

Я в онлайне если что и покупаю, то исключительно с декстопа. Со смартфона в лучшем случае повторить покупку в WB, и то через web-доступ, приложение у меня не стоит. Всё остальное с большого экрана. А то, что можно - непосредственно в магазине. Чтобы не возиться потом с возвратом того ..., которое мне пришлют.

Вот неистово плюсую! Разработчики, которые полностью разучились в UI/UX - убивают. Это поколение, которое не знает даже основ - активная область должна быть выделена визуально

Почему я не могу установить мобильный онлайн банк ВТБ, не давая ему доступа к телефонной книге пользователя?

Ну, наверное, потому что первое, что он делает - скачивает Вашу книгу к себе. И он не одинок, Сбер делает то же самое. Пользуйтесь веб-приложением, оно этого не сможет сделать при всём желании.

Там не только хайпануть результат получился. Еще -9 к карме - и автор в read only уйдет.

Недавно видел феерический универсальный обработчик. Сообщение пользователю: "Дело в нас. Войдите еще раз"

Ну что, поехали душнить.

Негативизм: Постоянные жалобы, критика без конструктивных предложений.

Принесли мне как-то разработчики список интеграций по проекту. Из более чем 50 - ни одной целевой. JDBC к чужим БД, DB-линки, SOAP. Корпоративным стандартом была сервисная шина. Внимание вопрос. Какое конструктивное предложение мне им дать? Использовать рекомендованные? Тогда они не успеют за две недели вау-эффект дать. Это основная их цель была. А моя цель - контроль соблюдения стандартов и проверка применимости правильных технологий. Это мои должностные обязанности, я не имею права им разрешать этот лютый трэш

Дальше больше. Собрались на троих директор программы, директор проектного офиса и технический директор. И решили, что архитектору, то есть мне, хватит пять дней на создание архитектуры проекта. Потом три дня на согласование, потом два дня на утверждение, и через две недели они откроют проект. Регламент - согласование БТ сколько потребуется, 15 рабочих дней минимум на архитектуру, 22 рабочих дня на согласования, минимум неделя на утверждение, если звезды сойдутся. БТ нет как явления. Проект - дичь. Критически важны НФТ, но их никто не в состоянии сформулировать. Уровень аналитики - мне пришлось объяснять, что части заложенного в проект бизнеса в банке нет как явления. И никогда не будет. Внимание вопрос. Какое конструктивное предложение им дать? Почитать регламенты и следовать им? Разработать БТ? НФТ? Тогда они не успеют за две недели вау-эффект продемонстрировать, цели не изменились глобально.

Итог. Жалоба моему руководству, что я всем вставляю палки в колеса. Истерика руководства - этот проект надо делать проактивно. ТРИ МЕСЯЦА на согласование архитектуры - это не от меня зависело, и я с самого начала объяснил, что будут именно так, ибо проект - дичь, и НФТ нет. Утверждение... и еще одна истерика моего руководства - как мы вообще на это подписались? Проект - дичь! Именно. Я это говорил с самого начала. Но у всех складывается пост-ощущение, что именно я жалуюсь, критикую и не даю никакого конструктива.

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

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

Микроменеджмент: Стремление контролировать каждый шаг коллег, что тормозит рабочий процесс.

За следующий месяц я пять раз ловлю команду на попытках мошенничества. Реализации костылей, на которые я не согласился. Завышение трудозатрат, дикое - на xslt-преобразование на шине, на которое я на прямое и обратное потратил минут 20 с тестированием, заложили 45 человеко-дней. И т.п.

В итоге приходится контролировать каждый шаг. Микроменеджмент. Скорость реализации возрастает в несколько раз, что вызывает сильное недовольство РМ - начинаются вопросы, на что он запрашивал столько денег и времени. Проект передают другому архитектору, который позволяет всё. Через полгода в проме инцидент на 20К евро двойного списания, в котором обвиняют... архитекторов. Которые "разрешили" те самые костыли. И не проконтролировали (!!!), что их исправили. Оказывается, микроменеджмент был нужен.

Неумение принимать критику: Защита своих ошибок, отказ признавать и исправлять их.

Реализовывал я как-то, еще будучи разработчиком, визуальную раскладку графов. Через библиотеку ILOG JViews. Там были несколько менеджеров, дававших красивые и быстрые результаты. На графах узлов в 20 и строго определенной топологии.

И был у шефа любимый граф, очень неудобный для всех раскладок - 450 с лишним узлов, топология... никакая. Неклассифицируемая. Самый красивый результат давал один менеджер - секунд за 15. И это было ну ОЧЕНЬ долго. В итоге шеф сам взял толстенное руководство и отметил все настройки, которые надо применить. Дальше я непосредственному начальнику три часа рассказывал про каждую из них, показывал, как они у меня выставлены, как они меняются и к чему это приводит. По всему выходило, что оптимально всё. А значит, я защищаю свои ошибки, отказываюсь их признавать и исправлять. Далее уже искали повод, чтобы меня уволить. Поводом стало слово "рефакторинг" - я собирался ничего не делать аж две недели.

На мое место пришел студент, который посмотрел на всё это и сказал, что я м-дак, а он всё сейчас настроит. "Ага!" сказал шеф. Настроили. Во время показа шеф открыл любимый граф, нажал кнопку - и всё зависло. Перезагрузили. То же самое. Ушли разбираться. А потом оказалось, что студенческая поделка запускает раскладку в event dispatcher thread - то есть приложение даже отрисовываться перестает. И работает что-то около 45 минут. Случайно оставили после нажатия кнопки, отвлеклись - и дождались окончания процесса.

Но кто там душный, отстаивает свои ошибки? Я, конечно. Студент вообще не при делах, он студент.

Создание конфликтов: Постоянные споры и разногласия, нарушение атмосферы доверия в команде

Собственно, всё сказано выше. Если целью части команды не является сделать дело, а для другой части это задача первостепенная - конфликт неразрешим. Это будут постоянные споры и разногласия. У меня стоит задача уменьшения времени согласования в конечном итоге, это уже известная боль во многих случаях. А продукту нужно вывести в пром новую фичу, а заботиться о согласовании данных они не хотят. Когда-нибудь реплицируются. Нет времени. Нет компетенций. И т.д. и т.п. И конфликты порождает кто? Тот, кто заботится, чтобы им в итоге не прилетело. Но это будет когда-то потом. Или не будет. Бизнес в погоне за прибылью откровенно нарушает законодательство. А когда приходит ЦБ с неудобными вопросами - все бегут к архитектору: а почему мы только сейчас узнали, что мы вот это всё должны по закону делать. А потому что, а) вы не читаете этих законов, хоть это и есть в ваших должностных инструкциях, и б) вам это говорили сделать из общих соображений с самого начала. Но у вас не было времени и желания. И кто в итоге спорит и разногласит? Ну не бизнес же!

Проще говоря. А вы уверены, что всё происходящее - это потому, что я душный? А не потому, что у меня 25+ лет опыта в разработке, а у вас от силы 5?

P.S. Вот это особенно понравилось:

Четкое следование рабочим процессам

По опыту - не родилась еще компания сложнее макдачной, которая сможет досконально прописать свои процессы настолько, чтобы они работали, если им следовать от и до. Да и к макдаку вопросики есть.

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

Информация

В рейтинге
2 773-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность