Интервью
Комментарии 293
+18

Читать было неожиданно занятно.
Вот только непонятно — чем юнит тесты провинились?

+3
IMHO: Они не провинились, но fuzzing тесты лучше, — они получаются дешевле, их делать легче и они выявляют ошибки по всей глубине стэка приложения. И fuzzing тесты разрабатывать интереснее, а юнит тесты, это рутина, это рабский труд.
+14
Я думаю, правильнее сказать, что «в некоторых ситуациях fuzzing тест может дать больше полезной информации». Все эти абсолютные категории — такое… практика показывает, что серебрянной пули нет, даже чтобы застрелиться.

они выявляют ошибки по всей глубине стэка приложения
Вот тут погодите. Это характеристика end-to-end тестов. Те которые через GUI как правило. А их то, как раз, разрабатывать не редко сложнее, (например из-за отсутствия нормального интерфейса для доступа «робота» к графической оболочке, постоянного изменения или динамики/анимаций в графическом интерфейсе), и они дороже.

это рутина, это рабский труд
Это систематический подход. Да, может в выявлении ошибок не самый эффективный способ, но систематический.

Я боюсь, что в fuzzing тесте, ошибку скорее сделают при составлении граничных значений для параметров. Например 0-255, и толку тут от рандомизации, если область определения недостаточна, нет отрицательных значений. А при составлении юнит-теста, ты возьмешь четыре значения и все. И если я захочу делать рефакторинг — мне будет спокойней от прогона юнит тестов. Они скажут мне, что все то, что работало до этого работает и теперь. Что я никому не наступил на ногу, т.е. не нарушил никаких контрактов с другими подсистемами. А сколько прогонов случайных тестов нужно чтобы убедиться, что все работает как и раньше? Вот вам и вывод, что fuzzing тесты нельзя сравнивать с юнит тестами. Полезны и те и те, и нужно понимать где, когда и зачем применять разные методики тестирования.
0
> Полезны и те и те, и нужно понимать где, когда и зачем применять разные методики тестирования.

Ну естественно. Моё IMHO, было относительно ключевых слов «провинились». Я как-бы не против юнит тестов, ибо «Они ничем не провинились».

> Вот тут погодите. Это характеристика end-to-end тестов. Те которые через GUI как правило.

Согласен, моя ошибка, — fuzzing тест выступит в данной ситуации вместо GUI.

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

Fuzzing тесты делаются не для того, что-бы вводить граничные параметры, а что-бы выявить при каких условиях происходит сбой, в этом их вся суть. Если вы разрабатываете систему fuzzing тестов, которые как-либо ограничены в «рандоме данных», то это неправильные fuzzing тесты. Более того range overflow это один из базовых fuzzing кейсов.

> А сколько прогонов случайных тестов нужно чтобы убедиться, что все работает как и раньше?

Дни, недели… Какая разница, сколько, если тест предназначен для того, что-бы свалить систему, а не для проверки работоспособности её компонент?
+2
Они скажут мне, что все то, что работало до этого работает и теперь.

Они могут только сказать о том, что сломалось. По построению.

0
фишка unit-тестов как раз в рутине. Когда на каждый лишний if приходиться писать отдельный тест да еще и дать осмысленное название, а на вложенные еще больше. Когда просто невозможно покрыть говно-метод из 500 строк. Вот когда появится лень такое писать, unit-тесты уже не понадобятся.
А вот фаззинг не предназначен для тестирование логики. Мне вообще не понятен его смысл, он только толкает делать ненадежный код.
0
Когда на каждый лишний if приходиться писать отдельный тест

просто невозможно покрыть говно-метод

Вот из-за такого использования тестов у разработчиков и появляется отвращение к тестированию и мысли типа юнит-тесты не нужны. Потому что где-то на каком-то проекте уже успели наесться такими тестами, где надо покрыть каждый if, потому что чуть что может и сборка упасть из-за недостаточного code coverage.
0
Когда просто невозможно покрыть говно-метод из 500 строк.

Вы к тому, что захочется его переписать или к тому, что захочется просто забить и протестировать по методу «вроде работает»?

0
Это я о своем опыте говорю)
И о том, что проще написать простые тесты заранее, а потом уже писать код под них.
Но unit-тесты применимы только к чистой логики. Для остального кода нужно нечто подобное, кроме функциональных
+7
Зачем же писать тесты которые ничего не проверяют. Это даже по определению уже не тесты. ))
+5
Ну как же — чтобы получить высокий процент покрытия кода тестами.
+3
Давайте будем честны, 90% unit-тестов проверяют, что 1+1=2 и не приносят абсолютно никакой пользы. Наибольшее кол-во проблем возникает не в работе конкретного модуля, а во взаимодействии между модулями и интеграционное тестирование в этом плане гораздо продуктивнее.
+9

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

+2
Я как то писал код который должен был рассчитывать приоритеты каких-то звуковых каналов. У меня была только таблица-спецификация на 15 тысяч полей с указанными приоритетами для каждой пары каналов, причем значения рассчитывались динамически. И после первого наброска кода я тут же стал писать юнит-тесты чтобы проверить, а удовлетворяет ли код спецификации. Берем охапку типичных сценариев, по таблице пешком выясняем что должно быть вычислено и пишем на это проверки. А потом допиливаем код. Берем еще охапку сценариев — шлифуем код. Иначе никак. Руками/глазами/мозгами это не проверить в таком объеме. Это пожалуй самый яркий случай на моей памяти где юнит-тесты сами собой напрашивались.
0
Вот в этом и проблема, что есть задачи, для которых тесты реально нужны и на которые они прекрасно ложатся. А потом приходит условный «менеджер» со своими метриками и «performance management» (будь он неладен) и начинается… coverage, SonarQube и прочее «1+1=2». А куда деваться? Большая компания, хорошая з/п, жить надо на что-то.
0
SonarQube чем вам не нравится? Правильно настроенный выдаёт вполне годные замечания.
0
Я так же компилятор делал. Есть мануал для пользователя, там есть набор примеров с получаемым результатом. Формализуем, запихиваем в табличку, делаем.

Только это не совсем юнит-тесты. Они не тестируют конкретную функцию или класс. Это ближе к интеграционным тестам: вы именно что проверяете, удовлетворяет ли весь пайплайн спеке.

Ну, да, в моём случае я начинал с фронтенда компилятора, поэтому оно всё началось с таблички «выражение → AST». Потом начал писать интерпретатор, поэтому появилась табличка «выражение × вход → результат». Потом кодогенератор, на той же табличке, плюс quickcheck-тест, что интерпретатор и сгенерированный код работают одинаково на рандомных данных. Всё равно ИМХО не юнит-тесты.
+8
Если в команде один разработчик и кода не слишком много — то пользы от юнит тестов мало. А вот если много людей и большой проект — они необходимы. Я рассматриваю юнит тесты как живую документацию. На мой взгляд они помогают решить следующие проблемы:
— Если ты изменил поведение — они напомнят тебе, что раньше было иначе и надо бы изменить юнит тесты (т.е. документацию)
— Новый человек может неверно понять принципы работы модуля. Когда он сделает правку, которая противоречит дизайну — юнит тесты скорее всего об этом оповестят.
— В юнит тестах можно подсмотреть примеры вызова методов и того, что они возвращают.
— Ну и наконец это отличный способ отладки модуля в процессе разработки, чтобы не стартовать все приложение.
0
95% людей — альтернативно умные, как известно, я думаю у них количество тестов «1+1=2» может доходить до 100 и более процентов от их общего количества. В этом смысле вы правы, но если ориентироваться на то, как это должно быть, юнит-тесты это по сути требования к системе, под них пишется код, ну по методологии TDD. Требования должны быть достаточно четкими, ясными и исчерпывающими. А то, что юнит-тесты позволяют до некоторой степени сохранять устойчивость кода при его изменении, это побочный эффект.
+3
Потому что концепцию тестов обычно неправильно понимают и используют.

1. Не существует тестов, которые гарантируют правильность работы программы. Тесты лишь фиксируют поведение программы при определённых наборах входных данных и обеспечивают сохранение поведения программы при вмешательстве в код.

2. Тесты — это, в первую очередь, документация. Если из теста непонятно, как работает тестируемый кусок кода, значит, это плохой тест.
-1
Как-то оно действительно непонятно)

Мы пошли совсем просто, наняли математика, он доказывает что наши функции «работают», или же не «работают». И естественно занимается оптимизацией алгоритмов. Для него юзается а-ля псевдокод, наибоычнейший с-образный с примесью паскаля, что бы он перешел потом в тестеры.
Наш математик ошибки ловит наура, на бумашке))
Достаточно сложно было объяснить почему байты и инты и почему иногда юзать два инта выгоднее чем лонг, но он въехал) Более того, он щяс топит за стек ну потому что наконец-то понял как он работает, и уже полез в спид-тесты.

Что бы мы без него делали я хз… Незаменимый человек.

И да, теперь для меня тесты делятся на логические, ну это когда 2+2 все же равно четыре, или не равно.
И скоростные, т.е. тут оптимизация алгоритмов, структур данных и собственно хаки.
Так вот все кроме хаков сваливается на проверку математику, и это дает фееричные результаты) Иногда он приходит и вместо наших монструозных конструкций выдает гениальные решения в одну строку псевдокода, которая имеет абсолютные мат.доказательства на трех листах, которые даже тестить не надо, ибо оно совершенно бессмысленно.

Но это наш путь) Ага, мы странные ребята, делаем как положено логически железобетонно, а не как заведено у всех непонятно кем и главное зачем?
0
А всем по-маленьку занимаемся) Ключевое слово тут — «всем».
Потому что появился математик, а значит можно заниматься «всем».
Давайте поясню.

Боролись со шрифтами, искали нормальную библиотеку, и естественно не нашли. Откуда ей взяться, если оные либы пишут дурачьки?
Задача: сообразить универсальную библиотеку, работающую с любыми шрифтами и способную рендерить шрифты хоть под что хоть где.
Обыскались) и не нашли, оного не существует в природе.
Написали свою, за неделю, но готовились к написанию два месяца, в развалку.
В итоге сделали следующее: писано оно на фреймворке втором, потому что его можно запустить хоть где, и еще кое какие причины имеются на это. Сами шрифты специально обработаны, не спрашивайте зачем. Шрифты внедрены в либу и хитро запакованы. Сама либа следит за вызываемыми шрифтами из нее, и имеет свой кеш, но кешируются ФонтФемили, а не шрифты Фонт. Кеш сам следит когда почистить неуправляемый gdi например. Почему gdi? Потому что только gdi выдает вменяемые результаты на винде. Потому что gdi способен работать без видеокарты вообще. А значит оное работает на серверах и оно работает) Более того, математик разработал свой рендер. Он въехал как шрифты рендерятся виндой, и написал очень эффективный кеш в котором хранится именно готовое графическое представление строк. В системах где оно стандартным способом не будет работать — можно запросить битмапы с графикой. И да, он заодно разобрался с dpi, т.е. выдал формулу как его считать корректно))) И он нашел кучу ошибок, почему нынешний расчет dpi люто гонит. Только он предложил кешировать самые частовстречающиеся сочетания символов, и сразу хранить не графику отдельных символов, а наборы символов. И на это тоже он рассчитал и написал алгоритм)
Теперь хоть где мы можем шрифт прицепить вот так просто: System.Drawing.Font f = SysDrawing.Fonts.Metro.Get(14, SysDrawing.Weight.SemiBold, SysDrawing.Style.Italic);
И да, только у нас шрифты наконец-то видятся любых начертаний. Если вы думаете что это просто — да, это просто) Но вы попробуйте сделать так же, у вас ничего не получится, причин этому неимоверная гора. Все эти причины вы должны обойти, и получить ровно то что нужно хоть где работающее.
Нужно всего-то разбираться в шрифтах, разработать точную архитектуру библиотеки, рендер на всякий случай, и написать все в кучу почти готовое за неделю) Что и было сделано. Без математика мы бы погрязли в чортовых тестах. Щяс же ничего не тестилось вообще, зачем?

А есть совсем банальные вещи. Вы как конвертите число в шестнадцатеричную строку?) И даже на это есть математик. Потому что он доказал, что можно конверитить без массива чаров, и без единого if-а) Код ровно в одну строчку. Казалось бы а оно надо? Надо)) Там где вы будете массово конвертить числа в hex-строчки — вам понадобится производительность.

А с криптографией что вы будете делать? Опять сами? Ой да не смешите… Вы не специалист никак, вашу криптографию мой математик пробьет нараз) А вы мою не пробьете, потому что она писана моим математиком) А он знает что делает.

А с трехмерными и прочими штуками вы что делать будете? Или снова и опять с первым курсом аналитической геометрии сунетесь в это?))

Послушайте, есть вы — программист, но это не значит что вы шарите в математике. А значит?.. Наймите математика)
0
И вы даже не представляете, как хорошо мне программировать, когда можно звякнуть нашему математику Михаилу и спросить влоб: Миша!!! Есть данные из интов, каждый инт образован другими данными битовыми сдвигами и все свалено в кучу. Нука сообрази мне разряженную таблицу или можт еще чего, что бы я это все дергал из таблицы неимоверно быстро ридонли))))
И через час я получаю псевдокод каторый пишу десять минут и мне ничего тестить не нужно) Причем, то что я переписываю с бумашки — я в этом вообще почти ничего не понимаю. Я почти не понимаю как оно работает. Но математически доказано, что оно будет работать. И я и не обязан понимать математику. Потому что это не моя работа.
И да, имейте ввиду, что математик НЕ МОЖЕТ ОШИБАТЬСЯ. Потому что это математик) Он пользуется принципиально иными способами «тестирования», а именно доказательствами. Каторые тестировать нет никакого смысла. Проще говоря — тестировать за математиком — полнейший бред. Или вы собрались тестировать математику?) Ого…
0
А математики не могут ошибаться? Я вот помню прилично «доказательств» теормы Ферма, например. И только консиллиум из кучи народа может просмотреть и сказать «ну вроде ошибок нет».

Напомню, что даже реальное доказательство 1997 года содержало ошибки, и до их исправлений было неверным.
-2
Смысл не в этом. Конечно могут ошибаться и ошибаются все.
НО!
Одно дело ошибаться в новом. А другое дело разруливать то что известно и известно хорошо.
При этом. Тут как бы два угла зрения. Например мой, программистский, на известные математикам вещи. Но для меня они сложные, для меня это как раз почти теорема Ферма) А для математика это банальность. Так вот люди в банальностях не ошибаются. И доказательства тут достаточно простые, т.е. для математиков это банальщина. А для меня и для вас — это почти темный лес.

Плюс ко всему конечно же тут нужно иметь ввиду то, что доказывать можно по-разному, оценочно например, или получать доказательства принципиально разными мат.методами. Наш Миша этим сильно грешит) Когда у него уже и так все доказано, а на основе этого уже и так все работает, он все равно с упорством числогрыза иногда приносит доказательства вдовесок. При этом, эти доказательства только улучшают старые доказательства. При этом, иногда получается так, что новыми доказательствами он расширяет область доказуемого, т.е. делает доказательство более обобщенным. А значит?)) А это значит, что у нас появляются мысли на более общий код. Без математика обобщить что-либо программистом вообще никогда не получится.

И т.д. и т.п.
0
Напишите про это статью. Я не слышал нигде о каком-либо подобном опыте.
-3
Не представляю о чем будет статья)
О том как мы раскалупали адобовский код обрабатывающий цветовые профили, и о том что только математик понял на какой формуле оно работает и какое преобразование применяется? И о том как мы это дело увели под себя? Это можете и вы. Легко. Но вы ничего не поймете) И никто не поймет. Поймут только математики) Ну и зачем такая статья, которую ни я ни вы не понимаете?

Увести можно все, запрограммировать можно все, но как понять на основе чего оно работает, что бы перепилить под себя? В основе математика со сложным матаном — оно вам надо вообще?)) Мне — НЕТ.

Или может быть замутить статью о четверичном кодировании представления картографических данных, например в викимапии старой версии, где я отчасти понял кое что, но у меня на это ушло два года))) А математик это понимает за пять минут. Про это написать?) Увольте…
0
Я про статью с примерами, типа «смотрите какую мы хрень сделали, а математик принес вот это, мы переделали, и получилось вот так. Так вот мы экономим по 1М ежемесячно, заодно поднимая общее качество кода». Что-то в таком духе, я ж деталей не знаю.
-1
Какую хрень мы сделали написано выше. Как пример.
Деньги на этом никак не экономятся.
У нас другой смысл.
Без математика никак нельзя собрать что-либо вменяемое. А мы собираем свое. Потому что нет смысла юзать чужое готовое. Оно невменяемое. Невменяемость заключается в том, что не понятно — работает оно или нет. Весь свободный код — не вменяемый совершенно. Как только свободный код становится вменяемым — он резко перестает быть свободным. Тут вариантов не много. Или пользоваться чужим и свободным, но абсолютно кривым, или коммерческим и не свободным, и тоже кривым. В любом случае вы не будете знать как оно работает и все тестами никогда не покроете.
Остается поглядеть как написали другие или же украсть, и дописать свое. Но в обоих случаях всегда лежит математический алгоритм, и знает как оно работает только математик.

Мы пришли к простой мысли. Контроль за кодом только один — когда он наш и мы понимаем как он работает.

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

Ровно так же делаем и мы. Вот по-этому у нас все работает. А там где не работает — всегда можно посмотреть и подправить.

Других вариантов программирования для нас уже не существует. Мы устали бороться с чужими багами. Тем более это абсолютно бессмысленно.
0
Я не понимаю, как математика помогает бороться с багами, почему кроме вас об этом в мире никто не знает и так далее…
-1
Как это никто не знает?) Да знали об этом прекрасно. До определенного времени.
Смотрите как оно было когда-то. Во времена чистого функционального программирования без этих ваших юи и прочих излишеств программировали математики) Ну потому что важен был алгоритм, а как что выводится — на это ваще всем было пофигу. Никаких «странных» телодвижений типа ооп вообще не было. Так называемые старперы до сих пор так и прогают. Им важна суть, а не хрень какая-то непонятная и не нужная. Ну это их взгляд на программирование, чисто математический.
Далее все чуть поменялось. Появились какие-то окошечки-кнопачки и прочий трешак. Те программисты которые математики — начали удаляться, потому что это уже не их.
Щяс же все упарываются в эти самые окошечки и прочую хрень, где математика вообще не используется.
Смотря что вы программируете. Если хрень — ну да, вам естественно дико за мысль, что программист — это математик прежде всего. Вы же собираете из готового. А позвольте вас спросить — А ГОТОВОЕ ВАМ КТО СОБИРАЕТ?)
Так вот собирают фреймворки, компиляторы и прочие крутые штуки как раз таки эти самые старперы-математики. И хрен они затаращщили на эти ваши окошечки. Резвитесь с ними сами, потому что это вообще ни уму ни сердцу. С этим справится любая обизьяна. И конечно же математики там нет и не будет.
0
Помогает — формальная логика, Карри-Говард, теория типов, это всё. Но это, судя по всему, сильно не то, что описывает ваш собеседник.
0
Компилятор и микрокод в процессоре вы уже переписали, я так понимаю?
-1
«смотрите какую мы хрень сделали, а математик принес вот это, мы переделали, и получилось вот так. Так вот мы экономим по 1М ежемесячно, заодно поднимая общее качество кода»
Мы не делаем что-то новое) Мы не пишем велосипеды. Мы берем решения или же воруем их, разбираемся с ними, смотрим какое лучше, перепиливаем под себя и получаем почти то же самое.
Что на выходе? То же самое))) Почти.
Разница тут в том, что мы понимаем как оно работает и где косяки. Где нужно тестить, а где не нужно тестить.
Что-то перепиливаем под собственный фреймворк, он работает гораздо лучше и понятнее, чем все что есть щяс из коробок.

Что такое качество кода я понятия не имею. Это похоже термин из юриспруденции что ли… Хз)
0
Он пользуется принципиально иными способами «тестирования», а именно доказательствами. Каторые тестировать нет никакого смысла. Проще говоря — тестировать за математиком — полнейший бред. Или вы собрались тестировать математику?) Ого…

А корректность доказательств он как проверяет? Пишет на Coq, Agda или Idris, я надеюсь?

А про использование самописной криптографии есть известное высказывание. Надеюсь, у вас там ничего mission-critical от неё не зависит.
0

Unit-тесты помогают дробить систему или какой-то блок системы на отдельные элементы (юниты). Если кто-то тестирует 1+1=2, это его проблемы. Тем не менее, unit-тестами можно тестировать и довольно сложную логику. А если еще эти тесты написаны как следует, то можно и по ним понять, как работает этот отдельный юнит.

+18
На правах бреда:
Я считаю такие интервью вредными потому, что их могут прочесть настоящие дураки,
и принять их как руководство к действию.
0
Считаю что данное интервью может послужить руководством к действию с не самыми разрушительными последствиями для окружающих. А посему пусть действуют в своё удовольствие.
+2
Вот тут вы правы. У меня младший брат ходил учиться в компьютерную академию (ШАГ) 3 года, после которой спокойно берут на работу джуном. Какой-то дибил, который там то ли преподавал, то ли учился с ним ляпнул что получать диплом необязательно — на работу берут по знаниям (нужно пройти интервью). Малому 16 лет (что с него взять?) и он принял это за чистую монету. Кто бы ему рассказал что перед собеседованием ещё нужно чтобы тебя отобрали для того самого интервью из десятков кандидатов. В итоге заплачено куча денег, а корочки нет. Может ему конечно повезёт — но некоторые бумажки в этом мире знатно упрощают жизнь.
+3
Скажите ему, что уехать заграницу даже просто поработать пару лет без диплома сильно сложнее. Просто миграционным службам плевать сколько у человека звезд на github'е, ему бумажку хочется увидеть.
+2
Просто миграционным службам плевать сколько у человека звезд на github'е, ему бумажку хочется увидеть.


Некоторые страны да, но есть и те, кому плевать на бумажки, скилл важнее. Нидерланды, например.
0

Документально подтвердить эти 5-10 лет будет сложнее, чем диплом показать. Или думаете вам на слово поверят?

0
Тем не менее, процедура есть www.cdrreport.org/acs-australia-migration-skill-assessment

" ACS Australia assesses the skills of the applicant, who do not have ICT qualifications or any tertiary ICT qualifications. "

«вышка» давно уже перестала быть исключительной необходимостью для эмиграции айтишного люда.
0
Документально подтверждается письмами от прошлых работодателей. При этом даже не особо важно, были ли вы, скажем, официально трудоустроены и платили ли налоги в России. Контрактором на удалёнке на зарубежную фирму тоже вполне норм.
0
Ой, что мы ему уже только не говорили — сам живу и работаю заграницей. Некоторые люди не принимают чужой опыт. Я и сам таким был, но мне посчастливилось найти себя в науке. Посчасливится ли ему — очень большой вопрос.
0
Ну вообще, по моим небольшим наблюдениям — зависит от области.
Если что-то технически сложное, что обычно пишут на C/C++ — диплом спрашивают весьма часто(сужу по вакансиям). Если это ВЕБ — диплом вообще никого не интересует, 1С/Мобильная разработка — иногда спрашивают диплом только у кандидатов, что ещё не имеют опыта.
Я в 17 устроился (месяц назад), никто не спрашивал где/как я учусь(Пошёл в колледж ради того чтобы быстрее влиться в рабочую среду).
Если малый бывал за границей, можете рассказать ему что дорога туда в 90% с вышкой, может передумает =)
0
На начальных должностях дипломы, понятное дело, не особо нужны. А вот дальше может быть по разному.
+3
C++, машинное обучение, зарубеж. Диплом спрашивали после оффера, чтобы построить план релокации.
-1
5 съэкономленных лет это очень много. В реалиях нашей страны можно заработать на любую бумажку и еще останется. Миграционные ведомства стран повменяемее принимают стаж как подтверждение квалификации.
+5
Студенчество это не 5 лет заключения после которых дают бумажку. Это и прекрасно интересное время (больше половины которого проходит за пределами Альма-матер), и источник знаний, которые вы сами себя узнать не смогли бы заставить.
-1
Я не к тому что универ — тюрьма. А к тому что не тратить на него время нормальный выбор со своими достоинствами и недостатками.
0

Сначала мы тратим время чтобы получить деньги, потом тратим деньги чтобы купить время
Вечный вопрос — в чём смысл жизни?

0
В итоге заплачено куча денег, а корочки нет.


А знания есть?
-1
Ну, я вот жалею, что не ушёл курса так со второго, например. Потраченные вникуда деньги и время ради бумажки, которую у меня ещё ни разу за четыре года не спросили.
+6

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

+1
Да и по фото видно. Слишком хмурый для смузи-хипстора. Сразу видно собрата по несчастью.
+10
Я похож на смузи-хипстера, потому что жена затащила меня в смузи-хипстерскую кофейню. Если бы фото было сделано на 10 минут позже (когда я понял, что они налили джем в мои бургеры), я бы уже совсем не был похож на хипстера
+2
По фото подумал что очередной смузи-хипстор.


Та же фигня. Начинаю читать и думаю — «сейчас начнется про новые фреймворки для node.js или про очередную конференцию...»
Ан нет, внезапно годнота.
+3

Пожалуйста-пожалуйста, дайте определение смузи-хипстора. Кто такой и почему это плохо? А то часто натыкаюсь в комментах на это слово, а смысл найти не могу.

+6
Просто некоторые люди не хотят обучаться новому. И будут до потери пульса топить за старье, в котором все якобы «ламповее», «надежнее» и «удобнее». А из зависти к тем, кто может и любит изучать новое, и эффективно использует это в своей работе, придумывают про них оскорбительные прозвища, типа «смузи-хипсторов».
+3

Надо им тоже погоняло придумать. Типа "вата-кодеры" или что-то в этом роде.

0

Предложите лучше. Я выбрал вату, как антоним к смузи. Открыт к предложениям.

+3
Не вижу смысла заниматься изобретением «обзывалок» для интернет-баталий.
Но меня заинтересовала ваша логика связи ваты с консервативными программистами. Возможно, что я ошибаюсь, но в кустах мерещится камуфлированный наступательный диван)
+2

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


Не вижу смысла заниматься изобретением «обзывалок» для интернет-баталий.

Иногда можно и поприкалываться.

0
Кмк, главное здесь — не заиграться с обобщениями, так уже JavaScript можно сделать политической позицией)
0
Я скорее о границах разумного) Заставить людей думать шире и видеть лес за деревьями никакие законы не могут.
0

У разумного не границ. Есть границы нашего понимания. А насчёт конвертации яваскрипта в политическую позицию. Был, например, цех строителей в Средневековье, который превратился в орден масонов.

0
У разумного не границ. Есть границы нашего понимания.

Альтернативная одаренность?)

цех строителей в Средневековье, который превратился в орден масонов

Систематическая ошибка выжившего же.
0
Если учесть, что смузи — это всего лишь навсего молотые блендером фрукты-ягоды с добавлением молока, то выбор антонима, мягко говоря, странен.

К тому же лично я «смузи-хипсторами» склонен называть тех, кто только и делает, что бесконечно катается по конференциям, фанатично рекламирует какие-то супер новые фреймворки и библиотеки, языки и модные концепции, пишет претенциозные «лонгриды» о том, как нам правильно программировать и на чем, но не делает главного для программиста дела — не пишет, собственно говоря, программный кот.
+2

Я не верю в мантры "просто пиши код", "надо работать" и прочий популизм. Можно бездумно кодить 24 часа в сутки, пока кровь из носа не пойдет. И на выходе получить мегабайты неуправляемого спагетти пополам с кривыми велосипедами. А потом месяцами перебрасывать баги из бэклога в стейджинг и обратно. Многие проекты так и живут, благо маржинальность в IT зашкаливает. Только гордиться тут нечем.
А можно сесть подумать, почитать статью с Медиума, посмотреть видос с конференции или съездить. И добиться как минимум того же результата с меньшими затратами, большей расширяемостью и прочими плюшками. IT это не стройбат, где копают от забора до обеда.

+1
А вы просто рассматриваете кардинально противоположный случай — когда человек только и делает, что бездумно пишет кот 24/7. Это тоже такой себе подход, хотя, как вы заметили, в некоторых случаях он работает.
Я же описал человека, который НЕ занимается кодингом вообще, и вся его деятельность заключается в том, что (см. выше), однако же он считает себя зомфг разработчиком и двигателем нового в массы. Мы просто рассмотрели черный и белый случаи, а тут, думается мне, серенький-то все-таки идеален — когда человек сочетает и конференции, и кодописательство. А бездумные кодеры, равно как и бесполезные болтуны со сцены — это такое себе.
+1

Вы привели в пример не существующий в реальности edge case. Я в ответ предложил свой противоположный. У вас нет монополии на преувеличения.
Насчет разумной середины. Ну, я в ней. Кодю и езжу на конференции, пишу маленькую статью сейчас. Смузи-хипсторов на конференциях не замечал. Есть евангелисты, но это другая вообще тема. Зато часто читаю комменты вот таких лесорубов как вы. При это никогда не видел их вклада в сообщество. В отличие от смузи-хипсторов, которые способствуют развитию технологий.
Без обид, но со стороны ваши комменты звучат как нытье обиженного неудачника.

0
У вас нет монополии на преувеличения.


«Мы Тетраграмматон, у нас есть право на все» Разумеется, нет. Однако же, по поводу мантры «просто пиши» — просто писать необходимо, ибо это и есть суть работы программиста. Называть себя художником, если ты в жизни не нарисовал ни одной картины — это как-то странно, согласитесь.
0

Не туда приклеилось, сорян.


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

+2
Зато часто читаю комменты вот таких лесорубов как вы


Ну на личности-то зачем, нормально же сидели.

При это никогда не видел их вклада в сообщество.


А что, все те, кто не считает нужным вкладывать в сообщество — второй сорт и «лесорубы»?

Без обид, но со стороны ваши комменты звучат как нытье обиженного неудачника.


Меня это не волнует совсем абсолютно никак, тем более, что вы ошибаетесь.

+1

Не хотел обидеть, пардон.


А что, все те, кто не считает нужным вкладывать в сообщество — второй сорт и «лесорубы»?

Вкладывать или не вкладывать — личное дело. Но вот обзывать тех, кто вкладывает это плохо.

+2
обзывать тех, кто вкладывает это плохо.


Согласен. Мысль простая — не каждый, кто вкладывает = смузихипстер и не каждый, кто НЕ вкладывает = лесоруб. От человека же зависит.
0
мой ТЛ, по моим наблюдениям, придерживается в работе догмы, что все что непосредственно улучшает продукт должно быть сделано и только это. Таким образом он максимум своего времени тратит на устранение проблем в продукте, и соответственно считает ненужными всякие автоматизации, фигации и прочие современные штуки. Как он говорит, мы не продаем автоматизацию, мы не продаем симуляторы и моки, мы продаем работающий продукт. И достигает этого непосредственным образом — находит, правит баги, добивается чтобы другие подрядчики чинили блокеры. И это работает. Он просто за день может разгрести кучу с которой трое за неделю не управятся. Никаких придумываний архитектуры, досок, диаграмм, документации, собраний и совещаний — просто чинит продукт. Сидит как египетское изваяние и фигачит. Да его код не самый легкочитаемый. Но эффективность такого подхода феноменальна. И это его заслуга, что наша фирма все эти годы среди остается конкуррентноспособной в тендере.
Так что в философии "programming motherfucker" — что-то есть.
0
Он просто за день может разгрести кучу с которой трое за неделю не управятся.

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

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

0
в данном конкретном случае наверно должны разверзнуться небеса. Редкой лояльности человек. Ему предлагали уйти на гораздо более выгодные условия работать к заказчику. Он отказался.
Говоря в общем случае — тогда будет команда как все. И тогда мне наверное мне тоже захочется уйти. Потому, что весь этот западный детсад-стайл-менеджмент, философии компании, игра в аджайл и прочаяя муть «зальют водой» и утопят проект через год.
+5
Постараюсь ответить детально по пунктам:
У меня не самый плохой девбокс, но с одним значимым минусом — я попытался сэкономить и купил проц от амд. Это был страшный провал. Не смотря на высокую заявленную мощность, этот кусок говна прогоняет мои тесты в 5!!! раз медленнее, чем его интеловский аналог.

Вот это кстати вызвало наибольший вопрос. Я собирался апгрейдить свой компьютер на Ryzen, потому что по всем тестам он сильно выигрывает у интела. А тут такой облом. Нет, я не буду покупать проц в котором все так плохо, даже будь он в 2 раза дешевле :)

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

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

Мне кажется, человек плохо понимает, насколько один PR может принести пользу человечеству. Ведь если каждый коммит увеличивает продуктивность каждого пользователя технологии в 1.000000001 раз, то очень быстро их продуктивность изменится просто в разы. Кумулятивность эффекта программирования и взаимной помощи (особенно в OSS) это очень мощная штука. По крайней мере, когда я задумывался над этим, я пришел именно к таким выводам.

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

Не знаю, как это можно совмещать, но я обожаю разрабатывать и ненавижу работать разработчиком. Я пытаюсь успокоить себя тем, что просто мне ещё не попался интересный проект, но в то же время сам в это не верю. С этим действительно тяжело жить.

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

Чем юнит-тесты провинились тоже непонятно. Зависимые типы ни в одном мейнстрим языке еще не появились (и, наверное, не случайно), а без них многие отношения в коде не выдержать. Я лично не знаю другого изолированного способа воспроизводимо тестировать функционал. Я пользоваляся иногда тулзами типа quickcheck! (которые автоматически генерируют кейсы, и в случае провала пытаются сформировать MRE), но я их считал теми же юнит тестами. И без них весьма тяжко.

Что касается пожеланий:

Вывод типов и компайл-тайм иммутабельность — System.Collections.Immutable. Проблемы только с иммутабельными классами, проблему осветил Джон Скит на дотнексте.
Чтобы разработчики C# послали, наконец, к чертям собачьим обратную совместимость — не случится никогда
Автоматические backing fields в C#, какой-нибудь сахар над Func<T1,T2>. — непонятно, что имеется ввиду. Автоматические филды есть, ручные я почти не вижу в реальном коде. Сахар для Func<T1,T2> непонятно какой имеется ввиду. Я бы предпочел иметь адекватный Unit-тип, чтобы объединить наконец Func/Action, Task/Task/…
Контракты для C# — есть пропозал, вроде даже чемпион
Аналог jsx для языка F#. — мне казалось jsx во-первых устарел (все фронты просто .js используют), а во-вторых функциональщина с интерфейсами как по мне слабо сочетается. Мб не прав, тут не знаю, не использовал серьезно
Чтобы сообщество пришло к пониманию, что юнит-тесты — бесполезный мусор — выше написал
Чтобы архитектура процессоров была больше рассчитана на функциональный подход. — ограничения физики это не то, что можно легко обойти. Лисп-машины были не сильно удачными, и не потому, что их не старались сделать производительными. На низком уровне императив правит миром, а языки, которые близки к ним идейно — быстрые. Вряд ли с этим глобально можно что-то сделать
Оптимизация хвостовой рекурсии в js/ts — не вижу особых проблем, чтобы это реализовали в любое время, это ведь совсем несложно.
Опциональная возможность статической типизации в js из коробки
1. не будет сделано никогда
2. уже есть ts, смысла большого нет
Чтобы штуки вроде web-assembly прочно заняли своё место в практиках — так и будет
Значимого усовершенствования web-клиентов гитхаба и ему подобных. — неплохая идея, будем надеяться. Пока что гитхаб даже ревью не очень показывает, приходится использовать сторонние сервисы
Больше конвенций по совместимости. Насколько бы всё было бы проще, если бы jvm умела интерпретировать и jit-ить дотнетный cil. — было бы наверное неплохо, но кмк это нереализуемо, чтобы было и эффективно, не говоря про саму возможность договора между MS и Oracle.

У меня несколько своих проектов с друзьями. Люблю специально делать им пассивно-агрессивные код-ревью («не мог бы ты предложить мотивацию для использования столь непродуманного решения?») и наблюдать, как это меняет наши взаимоотношения.

Лучший способ поссориться с людьми, которыми дорожишь. Иронизировать и подкалывать — это одно, а ПА атаковать — другое.
Учебная — «clr via C#» Джеффри Рихтера. Столько знаний про то, как устроен дотнетный рантайм в одном труде — настоящая находка. Если заучить эту книгу, пройдёшь любой собес на дотнетера.

Вот сколько читаю про дотнетеров — все на эту книжку чуть ли не молятся. Пробовал читать её дважды — оба раза не мог дойти дальше 50 странцы. Столько воды, что засыпаешь на ходу. Про устройство дотнета намного полнее и интереснее было почитать Pro .Net Performance за авторством Саши Гольдштейна. Вот уж и глубоко, и понятно, и приколы вроде фич, которые есть в CLR, но не доступны напрямую из C#. Очень рекомендую.

— Ну и ответ на вопрос, конечно же
— Изучение какой технологии вызвало у тебя наибольшее удовольствие в процессе?

Сначала Delphi после pascal, потом схожие чувства от C# после Delphi, сейчас же Rust после C#.
+3
купил проц от амд. Это был страшный провал. Не смотря на высокую заявленную мощность, этот кусок говна прогоняет мои тесты в 5!!! раз медленнее, чем его интеловский аналог

— тут не ясно о какой модели идет речь. У меня Ryzen 7 1700X 3.4 GGz — я доволен как слон (перед этим была мать с двумя двухядерными ксеонами — AMD кратно их превзошел). Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.
+2
Видимо никто не читает мою простыню, абыдн, старался расписать подробно :)
Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.

Очевидно, речь о прогоне юнит-тестов в VS средставми самой IDE или R#. Конечно же, они прогоняются параллельно, я лично видел до 16 тестов одновременно на 8-ядерном (с HT) процессоре. Так что вопрос явно не в однопотоке (он кстати по тестам у рязани нормальный).
+5

Скорее всего да. Рязань у коллег-дотнетчиков рвет и мечет не только в синтетических тестах.

+2
Вот не знаю что она там рвет и мечет, но моя попытка перейти на рязань 1800х с i7 4790K закончилась эпическим фейлом. Наивно предполагал что 8/16 даст солидный буст по сравнению с древним 4/8, но эффект прямо противоположный.

Текущее на то время решение состояло из 37 проектов и примерно 5к юнит тестов, прогон тестов на интеле шел в фоне, никак не отражаясь на работе VS, на амд начались лютые фризы всей студии. Пришлось отдать рязань племяшу под игрушки и задуматься о i9.

Возможно это кривая оптимизация винды/студии для амд. Но мне, честно, пофиг. Я хочу чтобы все работало, так быстро, как это возможно, не создавая дискомфорта. И если амд не может мне это обеспечить, то извините пожалуйста.
0
Менять железо чаще чем раз в 4-5 лет накладно, да и нет особого желания. Будут ли 6 честных ядер котироваться в 2022-23, так же как 8 ядерные и более решения — большой вопрос. Так что, по мне лучше подкопить дополнительные 40к на 10ядерник и не заморачиваться в ближайшие годы. Чем сэкономить сейчас и думать, стоило оно того или нет.
+1
Я перешёл на 8700k не столько из-за числа ядер, сколько из-за высокой частоты одного ядра. Был значимым фактором против линейки i9. Всё ещё полно задач, которые тупо в скорость одного ядра упираются. Больше ядер — меньше скорость каждого, чтобы в TDP держаться.
0
У AMD вот-вот выйдет 16/32 решение, если вам ядра важнее синглтреда. Сам смотрю на него с вожделением.
0
16/32 уже есть: Threadripper с ценником ~800$. А вот-вот выйдет 32/64 с ценой 2к. Будут ли наращивать кол-во ядер в десктопе пока непонятно.
0
Да, вы правы, конечно же, 32/64. Греться будет, конечно, ужасающе, надеюсь мой Dark Rock Pro 4 его вытянет.
0
Еще интересно, насколько оно всякими AVX'ами матрицы вертит, по этой части информации сильно меньше.
0
А все, оказывается продажи уже начались, так что тестов сейчас подвезут достаточно.
Но цена конечно адовая.
0
Ну там тесты обычно немного другого рода.

У меня есть некоторый вычислительный код, который я считаю вообще достаточно репрезентативным для тех задач, что мне интересны, но я всё ленюсь его упаковать в какую-то воспроизводимую форму, чтобы потом рассылать счастливым обладателям райзенов и тредрипперов с просьбой побенчмаркать.
0
Ну если все-таки отважусь на покупку этого адища — черкну, побенчмаркать мне не жалко.
0
Могу сказать что 8700k — монстр, особенно если довести до 4.8 или 5.0.
Все открывается за доли секунды. Но скальп все же требуется если 5.0.

Так что берите :)

P.S. Лучше в связке с 970 pro.
+1
Возможно, какие-то проблемы с i/o. Помню, подобный эффект был на асроке 1156 после фенома2: формально, процессор пошустрее, по всем бенчмаркам, но есть ощущение затупливания. Обновил биос — и всё стало сново гладко и быстро.
Рейзн пока толком не щупал (пришли первые 3 компа с 2400g, но на моём рабочем компе стоит 7, а на них — 10, напрямую не могу сравнить), но и7 славится затупами при высокой нагрузке — что на зионах замечал, что на текущем станционарнике, что на ноутах.
Ну и биосы сырые, сырые и ещё раз сырые — очень много нового добавили, в целом, платформу наконец более-менее вылизали, но надо обновиться, а производители материнок не спешат как-то.
+1
Очевидно, речь о прогоне юнит-тестов в VS средставми самой IDE или R#.

— для меня не очевидно (VS я не пользовался никогда), а в тексте статьи явных указаний на то как именно интервьюируемый гонял тесты (и какие? может интеграционные?) нет.
0
Какие бы они ни были, онит или нет, они гоняются по числу логических ядер, и отлично параллелятся. Поэтому вопрос именно в многопоточной производительности.
0
Мне кажется, человек плохо понимает, насколько один PR может принести пользу человечеству. Ведь если каждый коммит увеличивает продуктивность каждого пользователя технологии в 1.000000001 раз, то очень быстро их продуктивность изменится просто в разы. Кумулятивность эффекта программирования и взаимной помощи (особенно в OSS) это очень мощная штука. По крайней мере, когда я задумывался над этим, я пришел именно к таким выводам.

Мне кажется это сложный вопрос. Я вот не знаю, растет ли моя продуктивность. Каждый день каждый разработчик создает все новые PR'ы. В итоге, чем дальше, тем больше тратишь времени не на работу, а на изучение того, что изменилось, починку того, что поломалось (вышел какой-нибудь MegaElasticRedisSearch версии 7.5 — половина кода поломалась, тратишь от 4 часов до нескольких дней на починку)… У меня есть интуитивное ощущение, что через 5 лет такими темпами можно будет утром писать код, который к вечеру будет уже устаревать.


А помогает ли это все человечеству в целом?.. Не уверен.


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

Утопия. Никогда так не будет, скорее всего. Причины выгорания скорее не в зарплате, а в отношении к работе.

0
Чем не поможет? Уйти на ЗП в 2 раза меньше можно не чтобы самобивечанием заниматься, а чтобы получать нематериальные фишки. Выбор стека/коллег/фич в продукте/..., это все может вернуть человеку веру в себя.
0
Или даже большее количество свободного времени — порой нужно просто отдохнуть.
0
Пропустили пунк про
а языки с динамической типизацией (не путать со слабой) — самый крупный провал в истории индустрии.
+1
Этот пункт очень провокационный, поэтому я не стал его комментировать. Лично для меня языки со статической типизацией более продуктивны, чем динамические.
0
Автоматические филды есть

Автор имел виду backing fields, как в Kotlin, автоматически доступные в геттерах/сеттерах, и только в них, чтобы для свойства вида int Age { get; set; } не приходилось объявлять поле int _age, если вдруг нужно реализовать какие-то проверки или иные действия в геттере/сеттере.
А только в геттере/сеттере поля должны быть доступны, не только, чтобы не засорять код декларациями, но и чтобы не было разнобоя в обращениями внутри класса Age или _age (поди разбери, когда то или иное обращение было сделано специально, а когда от неаккуратности).

+1
>1. Это почти никогда не нужно. Большого количества подобных филдов не бывает обычно.

В приложениях с UI их очень много, взять хотя бы INotifyPropertyChanged.
0
Это плохой дизайн самих фрейморков. Ну и я советую больше серверной разработкой заниматься, чтобы нервы поберечь. Помню писал одно WPF и другое Winform приложение, мурашки по коже при воспоминании бегать начинают… А на сервере — тишь да благодать, последнии плюшки, удобные тулчейны,… Попивай чай да реализуй очередную задачу, одна благодать.
+11
Интересный формат. Как-то искренне и по настоящему были ответы, без притягиваний всяких «казаться». Без галстуков и с бургером)
+18
Пилю с этим парнем один проект. И он доканал меня с требованием предложить мотивацию по использованию какого-либо очевидного ключего слова или конструкции))
0

Правильно ли вас понимаю, что от вас требуют, к примеру, обосновать, почему вы используете, допустим новые конструкции C# 6-7 — паттерн матчинг (новое слово when в switch/case), фильтр исключений (when), или какие-то новые конструкции, связанные с тем же паттерн матчингом в части апгрейда работы с is/as, или "out var _"?


Если так, то странно, если учесть, что автор высказал много пожеланий в части апгрейда того же C# (именно в части радикального обновления конструкций и подходов) и JS до кучи.

+1
На вроде мотивации по использованию sealed, той или иной коллекции. Часто он это делает, на сколько я понимаю, для лучшего своего понимания того или иного решения. Лично на мой взгляд, не плохой подход — пытаться опровергнуть решение для получения доказательств его верности.
0
Лично на мой взгляд, не плохой подход — пытаться опровергнуть решение для получения доказательств его верности.

На мой взгляд, так себе решение — это неплохо работает в математике, но в человеческих и рабочих отношениях работает уже сильно хуже, с учетом моментов психологии.
И еще хуже работает в ИТ, где есть такой тренд — под маской критики и вопросов прятать троллинг и/или желание ничего не менять.

+6
Это очень странное ощущение — читать то, что как-будто про тебя написано.
На фоне всех этих успешных успехов, как глоток свежего воздуха.

Сам выгорел из-за однообразной рутинной работы и ушёл в никуда. Перед уходом поймал себя на мысли, что интересный проект лично для меня — приоритет номер 1. Если этого нет, то даже высокая ЗП и плюшки — это временная радость. А фрустрация — это вещь, которую нельзя просто оставить за порогом офиса.

Не знаю, как это можно совмещать, но я обожаю разрабатывать и ненавижу работать разработчиком

Это, пожалуй, лучшее описание моего внутреннего состояния. Точнее и не скажешь.

Чтобы сообщество пришло к пониманию, что юнит-тесты — бесполезный мусор

Тут ещё вопрос, что считать юнит-тестом. Unit — единица весьма условная. Но вообще по моему опыту бэкенд веб-дева получалось так, что чистых юнит-тестов в проекте меньше всего. Не складывается пирамидка-то :)
Т.е они не совсем бесполезны, но очень часто их пишут просто до кучи и это не более, чем бесполезный шум. Имитация бурного тестирования :)
+1
Если этого нет, то даже высокая ЗП и плюшки — это временная радость.


Зато не очень высокая зп — это постоянное несчастье ;)
+5
Ответ на первый вопрос потрясающ. Интересно, много ли HR-ов можно загнать в синий экран таким вот ответом?
Да и вообще, было неожиданно интересно.
-5
Как раз такой ответ HR и ждут. Он сразу говорит о том, что человек ошибочно выбрал профессию.
0
Думаю, не 95%, а 80% разработчиков всех людей. Остальные 20%, что называется, are making a difference.
+6

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


Навскидку:


  • Разработать движок EAV-базы для нашей задачи? — Велосипеды не нужны, есть готовые фреймворки и графовые базы.
  • Задействуем готовый фреймворк или графовую базу? — Бизнесу это не нужно, нужно делать продуктовые таски.
  • Переведем проект на .NET Core? — А что это? Не нужно.
  • Мы много месяцев делаем однообразные таски, тратим на каждый много времени, при этом копипастя один и тот же код. Может, вынесем общий код в базовый класс, а под каждую таску будем делать легкий класс-наследник? — Не нужно, давай к пятнице закроем такую очередную таску.
  • У нас в истории и трекера несколько лет и на ближайшие полгода вперед какие-то одинаковые баги, постоянно переотрываются и/или заводятся очень похожие. Они относятся к двум-трем блокам в приложении. За месяц-два стало ясно, как их сгруппировать, и что нужно сделать в каждой группе, чтобы "закрыть" каждый блок на 95%, потратим по 2 недели на каждый блок? — Бизнесу это не нужно.
  • Далее везде.

В итоге, чтобы ответить на подобные вопросы, "что классного было сделано", нужно либо рассказывать stories (что и делает большинство), либо таки найти возможность сделать что-то крутое, но это будет наперекор индустрии и мейнстриму.

+1
Почему бы не рассказать о том что было сделано для собственного маленького проекта?
+1
Может быть, потому, что нет собственного маленького проекта?
-6
Если нет собственного маленького проекта, то крайне вероятно, что человек не очень то и любит заниматься разработкой. Как следствие, возвращаемся к моему начальному утверждению.
0
я, к примеру, люблю заниматься разработкой, но у меня нет ни одной идеи для своего маленького проекта. А делать очередной туториал или воплощать чужие идеи в свое свободное время мне скучно.
0
Все сильные программисты, с кем доводилось работать, что-то пишут дома. Александр Соловьев в одной из лекций даже объяснял, какой в этом смысл.
0
Так мы говорим о «силе» программиста или о любви к области деятельности?
Или только «сильные» программисты любят свою работу?
+1
Может не каждый программист, кто любит свою работу уже «сильный», потому что он еще джуниор, но в будущем вырасти до сильного у него определенно больше шансов. И едва ли вы сможете найти сильных программистов среди тех, кто не любит свою работу.

Как бы одно является следствием другого. Программист и стал сильными, потому что любил свою работу, лучше усваивал опыт и даже искал его во вне рабочее время, таким образом получив преимущество над остальными коллегами.
+2
Я не представляю, как это, у меня этих идей всё время миллион роится.

Сейчас байндинги для хаскеля к libclang пилю, интересно, как выражать AST языков вроде C++ на функциональных языках, чтобы потом по ним можно было удобно и изящно писать всякие запросы и анализы? А, кстати, если ещё и парсер cmake или compdb сделать, то можно будет прям искаропки анализировать проекты целиком. А, вот, кстати, нужно было построить диаграмму Венна для пятка множеств, получилась какая-то херня, да и библиотек таких толком нет, может, подумать, как такие вещи ещё представлять? О, тут, кстати, да, граф же получается, если смотреть смежные по ребру области, надо сделать библиотеку, чтобы она dot-файл выплёвывала, а потом graphviz'ом рендерить. Хм, графвиз, может, сделать потом ещё библиотеку и совместить fgl и graphviz, чтобы визуализировать fgl'ные графы?
0

И в конце еще не хватало «и всё заверте...». Так и до готового продукта не далеко)

0
То, о чем вы пишете, интересно разве что двум с половиной фанатикам. В большинстве же своем люди предпочитают писать что-то практичное, что в 2018 в 100% случаев оборачивается велосипедированием.
0
Ну почему фанатикам и что-то непрактичное, это ж не ещё один способ вычисления факториала на очередном подклассе морфизмов.
+3
Отсутствие фанатичного отношения означает, что человек неверно выбрал профессию? Мир не делится на черное и белое, а проекты, которыми можно гордится наверняка требуют много сил и времени. Да и прецеденты намекают, что радикальных фанатиков не так уж много среди профессиональных программистов.
+1
Я не это имел ввиду. По вашей логике получается, что 95% процентов художников — фанатики.
0
95% художников я склонен относить к ремесленникам (художников-оформителей, работающих по четким ТЗ или, скажем, рисующие виды города или шаржи на прохожих, т.е. ориентируясь на рынок). Не уверен, что каждый из них дома годами сидит над своей «Мона Лизой».
Остальное меньшинство вполне можно называть фанатиками, верно.
0
Я имел ввиду обычных современных художников, которые занимаются созданием цифрового контента.
0
Честно говоря, я не вижу разницы с точки зрения самого творца. Это так же можно делать как под заказ, так и упиваясь самовыражением.
+1
Вы явно не в теме: под заказ редко бывает, что приходится рисовать то что интересно. Сколько я не смотрел портфолио — там либо собственные работы, либо в перемешку с коммерческими. Собственные обычно более эффектные.
0
Как выглядит типичный заказ? «Здравствуйте! Нарисуйте нам что-угодно на ваш вкус»? Или все же «Мы — компания Х, нам нужен арт на тематику Y, у нас есть пожелания Z».

Хорошо. В какое количество человекочасов можно оценить типичную собственную работу из портфолио художника?

При сравнении еще важно понимать, что программисты крайне редко создают самостоятельный продукт, в отличие от художников. Более того, программные продукты чаще всего закрытые, а наиболее интересные нюансы алгоритмов еще и под NDA попадают.
0
Наверно, я нажал предпросмотр вместо отправить. Продублировал ответ.
+1
программисты крайне редко создают самостоятельный продукт
Все опенсорс сообщество смотрит с недоумением на этот коммент.
0
Единоличные авторы годных опенсорсных проектов вполне подпадают под категорию «крайне редко». Причина недоумения остальной части сообщества для меня не очевидна.
0
И именно из-за того, что это так «крайне редко» случается, таким компаниям как Microsoft приходится признавать то, что с open source бороться не стоит, а стоит в него влится, а еще лучше — возглавить)
0
Тот опенсорс, о котором вы говорите, пишется в основном (по количеству коммитов) тучей программистов на окладе в крупных компаниях. А теперь еще и из MS.
0
А что было раньше, курица или яйцо? Моя компания работает с друпалом. Мечтаем писать для него модули и вообще влиться в комьюнити. Зачем? Чтобы привлекать разработчиков на работу :).
0
Но вы же не станете записывать себе в портфолио модули, которые вы командой разрабатывали или сам друпал (если патчили его)?
0
А как вы определяете годный или не годный? Мой проект форкнула пара индусов, это считается?
0
Исключительно субъективные ощущения, сертификатов годности не выдаю) Интересует популярность, качество и актуальность той проблемы, которую софтина решает.
0
Как вероятно и то, что он не делает из разработки культа, а просто продает свои умения и знания 8 часов 5 дней в неделю. С течением лет мне лично такой подход кажется все более и более здравым.
0
Я очень люблю заниматься разработкой (и у меня это неплохо получается, судя по отзывам коллег и зарплате), но в жизни есть еще и другие вещи. Я говорю не только про другие любимые занятия, такие как туризм, спорт и литература, а еще про жену, родителей, и в перспективе детей. Они для меня важнее любви к разработке. И к тому же на основной работе я выкладываюсь на сто процентов. Может, именно поэтому у меня нет «собственных маленьких проектов»?
0
Вопрос самореализации. Кому-то люто нужен ответ на вопрос «нафига я живу, что я после себя оставлю и в чём смысл конкретно моей жизни». А дальше уже кто как самореализуется.
+1
Или он отъебашил 9 часов еще 2 часа провел в транспорте, имеет нехилую перспективу похерачить в субботу и хочет тупо пожрать и спать.
0

Мне, к примеру, есть что рассказать и про продуктовую работу, и свои (не)маленькие проекты.


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


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


Или могут спрашивать про авторизацию клиента на ендпойтах REST-контроллеров с помощью встроенных воможностей ASP.NET (тот же атрибут Authorize) или готового стороннего фреймворка, но попробовать вы могли это действительно только в своем pet-проекте, т.к. в предыдущем продуктовом легаси проекте вы добавляли методы в готовые контроллеры с велосипедной авторизацией клиента (ну когда у вас свой контейнер сессий, вы передаете в методы id клиента и токены, и прочая).

+8
Потому что свой умственный ресурс, связанный с ИТ, я практически целиком трачу на работу или околоработу. И приходя домой, последнее, что мне хочется, это запускать IDE.
Гораздо приятнее взять в руки гитару или кисть с красками, лобзик или напильник, гантелю или шпагу. Пойти пробежаться или с женой в лесу погулять, в конце концов.
Но нет, программистом у нас имеет право называться только тот, кто пялится в монитор 24/7. Обязательно аккаунт на гитхабе с тыщей звёзд, пачка статей на хабре, непременно свой проект, в котором обязательно должны присутствовать блокчейн, машин лёрнинг, биг дата, nosql и десять фреймворков не старше одного месяца.
-1
Но нет, программистом у нас имеет право называться только тот, кто пялится в монитор 24/7. Обязательно аккаунт на гитхабе с тыщей звёзд, пачка статей на хабре, непременно свой проект, в котором обязательно должны присутствовать блокчейн, машин лёрнинг, биг дата, nosql и десять фреймворков не старше одного месяца.
Это вы сами выдумали, я такого не говорил. Бывает, что программисту не хватает рабочих задач, чтобы попробовать свои идеи, тогда он начинает что-то писать дома. Мне кажется, это нормально. То что вы написали выглядит, будто бы вы просто сдаете свой мозг в аренду на фиксированное время за фиксированную плату, и только когда приходите домой, то начинаете заниматься тем, что вам действительно нравится в жизни.
+8
А у некоторых людей программирование — не единственное дело, которое им нравится в жизни. Внезапно, да?
-2
Ой, людям не надо себе льстить и называть программирование делом, которое нравится в жизни, если им даже нечего ответить на «Расскажи о фиче, которую ты реализовал и которой гордишься».
0
А. Ну конечно же, вам про них лучше знать, чем им самим. Извините, чего это я.
0

В жизни есть гораздо больше интересного чем все фичи в бОльшей части ПО которое существует на текущий момент ;), с точки зрения ПО гораздо больше эмоций вызывает неадекватное число багов (причём в том ПО которое 5-10 лет назад работало.

0
Только вот фичи в большей части имеющегося ПО едва ли соотносятся с программированием и смежными дисциплинами.
+3

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


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


Просто не понимаю, как таким людям удается все успевать.

+1
Ключевая фраза коммента, с которого началась эта ветка — это что вам не дадут сделать так, чтобы вам было, чем гордиться.

Это не так. Гитары, лобзики и прочие гантели — это не «вам не дадут».
+2
Знакомо, только у меня стадия «работа настолько достает за день, что даже уборка в доме и поход в магазин — в огромную радость». Что не мешает держать пару пет-проектов, надо же как то развиваться.
0
Предполагаю, что — придумывать, выдумывать, врать и т.д. )
+1

ну зачем так) это же популярная тема — "to tell a story", "рассказать историю", это давно пропагандируется в статьях про собеседования, и здесь, на хабре, не раз говорилось, что это, мол, помогает производить впечатление.


чуть ниже BingoBongo привел хороший пример, позволю себе протицировать:


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

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


"Был какой-то кипиш, я прямо из аэропорта за 10 минут до показа закоммитил исправление опечатки моего коллеги в develop-ветке, из-за которой билд не собирался, он там забыл поставить точку с запятой в строке int i = j +1;"


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


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

0
Аа-а-а, ну я если кого-нибудь готовлю к собеседованиям, советую все же на содержательную часть истории обращать внимание, заодно ориентируясь на того, кто тебя интервьюирует. То есть история про кипиш, на мой взгляд, довольно слабенькая, она ни технаря не удивит, ни менеджера. Имея пару-тройку лет опыта на любой работе можно найти более интересный случай, который либо позволил писать более элегантный и быстрый код, или сэкономил бизнесу денег.
0
Это рассказать о ситуации из прошлого, например, когда от тебя ждали версию игры для показа на выставке в Германии, но внезапно обнаружилось, что билд стал крашиться без причины в случайные моменты времени. И на часах уже 22:00, выставка завтра, а ты единственный кто может что-то сделать.


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

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

История должна содержать изящное решение технической проблемы, а не бизнес-задачи. Если без опоры на предметную область никак не объяснить, то интервьюера такая куллстори и не заинтересует.
0
Это рассказать о ситуации из прошлого, например, когда от тебя ждали версию игры для показа на выставке в Германии, но внезапно обнаружилось, что билд стал крашиться без причины в случайные моменты времени. И на часах уже 22:00, выставка завтра, а ты единственный кто может что-то сделать.
+1
а ты единственный кто может что-то сделать.


Кто виноват в том, что у команды такой bus factor? Уж точно не программист.
+1
А зачем тут вообще искать виноватых? Или вы просто любите найти грязь?

п.с. Для маленьких проектов, которые, по сути, ведет один программист, а остальные нужны чтобы разгрузить от «тупых задач» — это частое явление. Поэтому ваш bus factor в пролете.
+1
А зачем тут вообще искать виноватых? Или вы просто любите найти грязь?


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

Конечно, зачем обвинять менеджера/тимлида, который не учел, что у него басфактор равен единичке, проще позвонить кодеру, пофигу, что 22 вечера на часах, ничего, встанет как миленький, да пофиксит… а если не встанет, мы его премии лишим, а то и по собственному написать попросим, так, что-ли?

Для маленьких проектов


… которые кровь из носу должны быть показаны завтра на выставке в Германии, но кто-то сломал твой маленький билд?
У вас одно с другим не вяжется.
0
Опасная близость к переходу на личности — признак того, что аргументы заканчиваются.
Так и зачем вы перешли со своим bus facor'ом, намекая что знаете больше меня и лучше разбираетесь в ситуации?

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

Конечно, зачем обвинять менеджера/тимлида, который не учел, что у него басфактор равен единичке, проще позвонить кодеру, пофигу, что 22 вечера на часах, ничего, встанет как миленький, да пофиксит… а если не встанет, мы его премии лишим, а то и по собственному написать попросим, так, что-ли?
Менеджер, тим лид и прочие виноватые — это я.

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

п.с. Предупреждая вашу дальнейшую атаку: все усилия конечно же были компенсированы хорошим денежным вознаграждением по итогу проекта.
+2
Так и зачем вы перешли со своим bus facor'ом, намекая что знаете больше меня и лучше разбираетесь в ситуации?


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

Вам какое дело до этого?


Вы задали вопрос — я на него ответил, только и всего. А с вашей стороны сразу какая-то агрессия пошла.

Менеджер, тим лид и прочие виноватые — это я.


Ну допустим кодер не взял трубку, дальше как развивалась бы ситуация, можете обрисовать? Мне действительно интересно.

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


Да бога ради, главное — чтобы всех все устраивало, и гендиректора, который получил билд за премию разработчикам, и разработчиков, которые считают нормальным то, что им звонят в ночи с просьбой пофиксить внезапно сломавшийся билд.
Я выражал только свое личное отношение — в эти игры с ночными звонками я наигрался 12 лет назад, и успешно от них избавился. Но если кому-то нравится что его дергают и постфактум платят за это — кто я такой, чтобы осуждать?

С другой стороны, если работодатель ожидает от меня, что я отвечу на рабочий звонок в свое личное время — пусть платит мне за нахождение в режиме ожидания звонка. Пусть платит мне за то, что я не напиваюсь, не ухожу далеко от компа, не уезжаю туда, где в принципе связи нет. Это называется «дежурство», и именно так это должно быть организовано. В принципе, в той сфере, где я работаю, а это куда более life-critical вещи, нежели мобильные игрушки, это именно так и организовано, что позволяет сильно снизить уровень стресса — ты просто знаешь, что вот в эти сутки тебя могут набрать и попросить чего-то там пофиксить, и точно так же знаешь, что в эти сутки — никто тебя не дернет. А уж если ты в отпуске — смело клади рабочий мобильник на полку.
0
Ну допустим кодер не взял трубку, дальше как развивалась бы ситуация, можете обрисовать? Мне действительно интересно.
Во-первых, я же сказал, что тим лид — это тоже я, когда баг критичный и «непонятный», то помощь простого кодера = 0 (если только это не тот кодер, который очень любит работу и даже пишет дома что-то свое).

Во-вторых, с чего вы взяли, что кто-то нужный вообще ушел домой? )

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

Считаю, тему лучше закрыть.
0
Во-первых, я же сказал, что тим лид — это тоже я


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

Во-вторых, с чего вы взяли, что кто-то нужный вообще ушел домой? )


С того, что у него есть трудовой договор с указанным в нем временем работы, нэ? :)

В некоторых фирмах кранчи — это вообще норма.


А вы — лично вы — как думаете, это норма? Мне интересно ваше мнение.

Проблема не в людях, а в требованиях самой индустрии. Вы себе неправильно все представляете.


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

Хотя, могу представить — если у вас таких историй 2 или 3 за пять лет, разумеется, никто не будет тратить деньги/ресурсы на организацию полноценных дежурств.

Считаю, тему лучше закрыть.


Отнюдь, самое интересное только начинается.
+1
Да конкретные-то вопросы выше были. Но почему-то мне упорно видится, что вы пытаетесь скрыть ответы на них, вот в чем дело.
+2
Это одна из причин, почему с такими-то слухами о геймдеве лично я туда не пойду никогда ни за какие деньги. Кранчить приятнее дома хиломорфизмы на хаскеле без давления дедлайнов, чем чужой говнокод подпирать новым говнокодом.
+1
Задействуем готовый фреймворк или графовую базу?


А этим надо гордиться? Я всегда это видел как обычную рутинную часть работы.
Несомненно это намного интереснее чем фиксить очередной баг или добавлять еще один вызов к API/впиливать кнопочку в приложение, но чем тут гордиться я не особо понимаю.
0
А я говорил, что этим нужно гордиться? Тут началось с того, что HR/интервьеры задают вопросы, чем вы гордитесь за последние 2 года.

По сути вашего вопроса:

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

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

Вполне себе интересная задача, которой, да, можно гордиться — это интересная и важная задача и для бизнеса, и для архитектора, и для аналитика, и для программиста.

Но да, рассказ об этом будет выглядеть иначе, чем stories, как эта.
0
Я просто из-за вот этой фразы
вам просто не дадут сделать что-то, чтобы на этот вопрос «что сделано, чем можно гордиться» ответить положительно.

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

Я нисколько не пытался сказать что прикрутить графовую базу — это мелочь и гордиться тут нечем. Я пытался показать почему некоторые разработчики могут просто не воспринимать такие вещи как что-то чем нужно гордиться просто потому что им кажется, что это такая же рутинная часть их работы как и «написание формочек».

Мне бы, например, не пришло в голову рассказать про прикручивание графовой базы в качестве ответа на такой вопрос HR.
+1
Можно об этом рассказать в разрезе решение задач/проблем бизнеса, или еще на каком языке, доступном HR.
Ну и конкретно эту фразу вы вырвали из контекста, обратите внимание (это было как продолжение диалога к первой фразе).

Но это делали. Проблема тут шире, включая порочность вопроса:

Чем гордиться? — Рассказать story, как ты за 5 минут до дедлайна решил проблемы, являющимися следствием чужих (или, еще хуже, ваших) залетов? — Сомнительное геройство.

Рассказать о том, как ты выбрал и задействовал нужные фреймворки, при необходимости дописав свои механизмы (с минимизацией ведосипедостроения), разработал архитектуру и внедрил процессы, дающие эффект в том числе и в ваше отсутствие, и в средне- и долгорочной перспективе?
Тоже где тут предмет гордости — обычная квалификация, в связи с которой и ведутся переговоры и месте приложении своих сил в проекте/компании и компенсации за это.

Или предмет гордости — способность генерировать плохо пахнущий код «здесь и сейчас» (а дальше хоть трава не расти)? Тоже что-то сомнительное, на что поведется не самый лучший менеджер.
+1
Все проблемы можно решить. Манагеры понимают только язык денег вот и надо на нем с ними разговаривать. Работаю на новом месте. Год происходило все как вы описали. Последние два месяца я втихую пилил модуль, который позволяет часть таких вот однообразных рутинных тикетов свести к нескольким кликам в админке. После демонстрации как за 1 минуту можно сделать то, что обычно делается несколько часов, разговоры тут же поменялись. Теперь все будем делать такими модулями. Конечно история еще не закончена, даже этот мой модуль нигде не внедрен, но меня хотя бы уже услышали и согласились. Не нужно говорить с менеджерами о негативных сторонах ваших начинаний, нужно говорить как мы на этом заработаем, а еще лучше непосредственно показывать.
0
Это да. В одной международной корпорации, практически этот энтерпрайз и выдумавшей — веселье бьет ключом. Хакатоны, IoT и 3-D печать творятся чуть ли не каждый день на каком-нибудь из многих этажей офиса. А потом хакатон заканчивается и все продолжают пилить 100500-ю версию основного продукта на технологиях начала 90х.
+2
По поводу первого пункта:
Довольно трудно чем-то гордиться, так как постоянно всё меняется, особенно в IT. И то, что раньше котировалось, через некоторое время забывается и никому не нужно. Я например когда жутко гордился, что работал на БЭСМ-6 в системе «краб» в институте гидродинамики. И что? Когда-то гордился, что запустил первый браузер Мозаик и увидел одну из первых веб страниц. Если я это на интервью скажу, никто не поймет о чем речь.
+1

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

0
сплошные костыли и хаки, порожденные ограничениями технологий

А я бы про это почитал )
Особенно если это истории из геймдева.
+3
Мне ваши сравнения напомнили один случай. Я в течении почти трех лет помогал организовывать митапы архитекторов систем, причем мы старались приглашать докладчиков с довольно неоднозначными теориями — чтобы было интереснее. И вот, в пылу очередной словесной баталии я замечаю убеленного сединами товарища, заходящегося в приступах смеха. Когда все успокоились и был обьявлен перерыв, я его отловил в кулуарах и спросил, над чем/кем он так смеялся. В ответ мне было сказано, что проблемы над которыми ломают копья программисты 2000х они решали в телекоме еще в 80х…
0
Решили — но новые поколения «слесарей-самоучек с мотором» понятия не имеют про давно существующие решения.
0
Я человек, несколько далекий от темы БД, но где-то мне приходилось читать, что все вот эти NoSQL-идеи, за которые так люто последние годы топили хипстеры евангелисты, как за новую модную серебряную пулю, были изобретены годах этак в 70-х.
Могу, впрочем, ошибаться, но не приснилось же мне это.

p.s. с моим любимым ФП, кстати, та же история.
0

Ничто не ново под Луной. Нюанс в отношении. Круто когда ветераны делятся опытом. Но никому не нужно стариковское нытье про хипстеров и молодежь. В 2000х IT сделало колоссальный рывок. Мы, конечно, стоим на плечах гигантов. Но какое отношение к этим гигантам имеет Вася Пупкин, ноющий про хипстеров в комментах?

0
Как раз «ограничения технологий» и вынуждали сначала думать, а потом писать — а на написанном в то время коде до сих пор держится изрядная часть IT. А современные решения я имею счастье наблюдать лично — и в области NOSQL куда срочно приделывают старый добрый SQL обратно, и в области обработки видео, где при наличии всяких динамически собираемых пайплайнов, фильтров и прочих красивых идей по прежнему лучше всего работает обычный код на Си.
-11
Писать на дотнете и называть golang «тупиковая ветвь», это же кем надо быть…
-3
Лично мое мнение, дотнет и в целом все что связано с windows, такое себе, но это лишь мое мнение, в целом я ничего не имею против разработчиков под винду. Но почему человек который имеет основной профиль в ООП под одну платформу, судит о новом языке, в котором вообще не разбирается и даже толком не изучал его?
Мое возмущение заключалось в этом, никого не хотел обидеть!
+3
Он бы ответил, но еще не изобрел ИИ, который изучит и напишет для этого хорошую аргументацию
0
Лично мое мнение, дотнет и в целом все что связано с windows, такое себе, но это лишь мое мнение

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

Но почему человек который имеет основной профиль в ООП под одну платформу, судит о новом языке, в котором вообще не разбирается и даже толком не изучал его?

Ну, я например тоже на го не писал, но читал очень много статей, и для себя сделал вывод, что на нем писать адекватному разработчику невозможно. Почему? Потому что он слишком простой, и это становится ограничивающим фактором. Окончательно для себя я на нем поставил крест после статьи who needs generics, в котором гуру Go на полном серьезе советует:

But what if a project just seems to cry for generics?
  • Step back and revisit the requirements. Review the technical or functional specification (you should have one). Do the specs really demand the use of generics? Consider that while other languages may support a design that is based on type systems, Go’s philosophy is different
  • Consider copy & paste


Человек на полном серьезе дает совет «ну если нужны генерики, вы ими не пользуйтесь, ну или накопипастите что хотите». Подобные извраты тоже на пользу не идут.

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

Поэтому да, я признаю, если бы я пописал на этом языке, возможно я проникся бы философией и всем таким. Но пока по сторонним признакам похоже на то, что это будет неприятный опыт. Примерно как сделать язык из одного только молотка (чтобы не учить людей пользоваться отверткой и шпателем), а потом радоваться, как все вокруг похоже на гвозди. ИМХО.

P.S. Я признаю, что могу быть неправым. Если вы несогласны, опишите в комментариях, какой момент я упускаю. Потому что я уже почти год пытаюсь понять, что же такого хорошего в го, и все, что я нашел — что гугл экономит на обучении студентов (что хорошо для гугла, но плохо для них), и как следствие зарабатывает много денег.

P.P.S. На вопрос в го чате в телеге «почему го так жрёт cpu на этом коде» ответ был «покажите какой у вас бюджет проекта что вас так cpu волнует».
+1
Я согласен, что наброс на Go неуместен, но ваш комментарий не лучше.
Во первых, дотнет это уже давно не только про винду.
Во вторых, это не обазательно ООП, т.к. для дотнета есть, например, F#.
+1
Потому что не все языки нужно досконально изучать, чтобы понять, стоит на них писать или нет. Конечно, про тупиковую ветвь развития — это как-то толстовато даже, но понять, что лично тебе этот язык тебе ничего дать не может, писать ты на нём не хочешь, и тому подобное, можно и так.
+1
Кем угодно, но точно не заслуживающим осуждения. Потому как, он поделился своим сугубо личным мнением, никак и никому его не навязывает.
-3
Любимый текстовый редактор — Visual Studio Code

Текстовый редактор? лолшто?
-6
Пришёл к директору, сказал: «я — бесполезный дурак, и хочу уволиться, чтобы не мучить вас». Но в ответ мне сильно подняли з/п.
Прикольно, у нас з/п поднимают, когда ты хорошо работаешь, а не когда плачешься в жилетку начальства.
+5
В тех словах сокрыт глубокий смысл выгоревшего и настрадавшегося сотрудника. Только очень хорошо подобранная ободряющая речь, либо неожиданный поступок, вроде повышения зарплаты мог вернуть беднягу из тупика.
-7
Просто для меня самобичевание на публике является признаком подскочившего ЧСВ, ну или как минимум бабским поведением ( это устоявшееся выражение, а не попытка оскорбить слабый пол ). А нормальный начальник, когда его время тратят на на такие разговоры, должен сказать что-то вроде «соберись, тряпка», а не ЗП поднимать. Хотя возможно в веб-разработке просто так принято, а меня заминусили, потому что я этого не знаю.
+5
Ну он вроде не на публике, а напрямую начальству. И потом… все мы люди, у всех есть свой предел, а в погоне за «небабским» поведением можно и за окно выбежать в один прекрасный день. Разрядка иногда нужна, как ни крути. А в том, чтобы признать собственные ошибки — нет ничего постыдного.
-3
Разрядка иногда нужна, как ни крути.
Мне тоже, но я в это никого не вовлекаю.
А в том, чтобы признать собственные ошибки — нет ничего постыдного.
Конечно нет, просто не надо спектакль разыгрывать.
0
То, что это не спектакль, а настоящая реакция вы не рассматриваете за возможность? Или это «по-бабски» и недостойно?
+2
Прочитал с удовольствием, но что-то не увидел возраст Филиппа. А это важно для такого интервью.
0
очень быстро вы выгорели, вам еще работать и работать :)
+3
Несколько удивил ответ на первый вопрос. Мне кажется, что если сместить фокус с того, насколько сложные (или несложные) вещи ты разрабатываешь, на то, зачем они нужны, можно найти очень много поводов для гордости. Мне вот последние пять лет практически все равно, что за технология используется для проекта — главное чтобы проект был нужен людям.

Про «хочу работать на 30%» — нужно иметь стальные яйца для того, чтобы такое озвучить во всеуслышанье, достойно уважения.
-8
Вы бы лучше в виде аудио подкаста рубрику выпустили, сейчас это модно к тому же. Читать много буков если честно не особенно есть время, а слушать можно в фоне и при интересе перейти к комментариям.
+10
Решительно наоборот. Дико негодую от современной привычки тащить все в подкасты и видео.
Текст воспринимается легко, удобно сохраняется и цитируется, а главное — его можно быстро «пробежать глазами» не теряя контекста.
-3
Одно другому не мешает, некоторые подкасты снабжаются текстовой расшифровкой. Существуют вещи которые полноценно воспринимаются только в виде чтива, но интервью к этой категории не относятся.
+2
А я то думал, что это Я плохо и бессмысленно живу…
а ннет, вот оно как ещё бывает.
Прочёл, и прямо настроение поднялось!
-3
Просто человек выбрал .NET. Он выбрал не правильную сторону. Он хотел много зарабатывать, и теперь дорого за это платит.
+2
nanshakov
UNIX (Android, Linux, FreeBSD, QNX)
OpenGL, GLSL
Python, Lua.
Qt, PostreSQL.

В конце концов, если прям сильно нужны деньги, ну на худой конец Oracle SQL.
+5
Вы уж простите, но C# приятнее всего вышеперечисленного. дотнет на формочках с бесконечными button1_Click не заканчивается. К слову, ставить в один ряд дотнет и Lua несколько странно.
-5
В Unix-way на каждую задачу существует отдельный инструмент.
Для формочек есть Qt например. Для других задач — другие библиотеки, которые поддерживают тысячи талантливых программистов по всему миру.
.NET находиться в руках одной корпорации, которая использует труд рабов, а во главу угла ставяться деньги и пиар. Что хорошего может получиться из такой технологии?
+2
В Unix-way на каждую задачу существует отдельный инструмент.
Для формочек есть Qt например.

Забавно. Qt противники как раз ругают за то, что *nix-way — это не про него (ведь действительно, GUI — это всего пару модулей из целой кучи), а заступники — сравнивают функциональности и универсальности с .NET

.NET находиться в руках одной корпорации

Тот же Qt контролирует не одна корпорация? Да и .NET уже вполне себе опенсорсный.
0
Некрокоммент конечно, но всё же выскажусь) Видится, что Qt и .NET вообще так себе затея сравнивать. Qt нативен, от сюда появляется мысль, что быстрее и компактнее. Где-то недавно здесь кто-то рассказывал, как они пилили интерфейс к какому-то девайсу (SmartTV вроде) чисто на Qt. Они даже забили на STL, ибо Qt, в силу своего не Unix-way, полностью сам покрывал их задачи.
Конечно, всё имеет свою цену:
— Нативность даёт более высокий шанс словить платформозависимые ахтунги.
— C++. Есть конечно у Qt привязки к другим языкам, но в первую очередь он написан для плюсов. Если бы не моя любовь к нативности и отсутствию тормозов, я бы наверно для написания UI предпочёл бы что-нибудь по новее. C# или Java. Думаю они больше подходят для этого.

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

Удивительно, как в ветках не вспомнили Electron. Сейчас тоже хайповая штука. Учитывая скорость появления всякого софта на нём, наверное по удобству и скорости разработки потягаться может. Вот правда скорость и прожорливость оставляют желать лучшего.
+3
Для формочек есть Qt например. Для других задач — другие библиотеки, которые поддерживают тысячи талантливых программистов по всему миру.

Надо полагать, .Net это такой монолит, в котором все есть. Но нет, даже стандартная библиотека распилена на ~1000 мелких пакетов, каждый их которых "решает одну задачу"™.


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

  1. .Net не находится в руках одной корпорации, около 40% коммитов после открытия дотнета — от сообщества
  2. Деньги и пиар во главе угла — можно пруф? Я пока майкрософту ни копейки не заплатил, но он мне уже подарил бесплатно лицензию на VS pro и Win10, просто за участие в бета-тестировании. Не вижу каких-то денег во главе угла, зайдите на csharplang репозиторий, покажите, где там фичи принимают из разряда "за это будут платить бабки".
  3. Про рабство тоже очень интересно было бы почитать.

В итоге складывается впечатление, что вы из тех людей, которые не видят за деревьями леса, оперируете стереотипами (что странно сочетается с человеком, профессия которого по сути интеллектуальная элита 21 века, кто бы что там про сантехников не говорил), который выбирает технологии не из практических соображений, а по религиозным.


P.S. не сочтите за переход на личности, но вы перенесли свои проекты с опенсорсного гитхатаба на проприетарный гитлаб после его покупки злым Майкрософтом? Просто любопытствую.




P.S.S.


.NET находиться в руках одной корпорации, которая использует труд рабов, а во главу угла ставяться деньги и пиар. Что хорошего может получиться из такой технологии?

technology is moral-less

-6
Я вижу ты парень — с другой планеты. И вместо того чтобы погулять в парке, поплавать в бассейне, посчитать звёзды на ночном небе или просто насладиться прибоем, ты сидишь в комментах и строчишь многобукв и пишешь всякую белиберду.
+1
вы перенесли свои проекты с опенсорсного гитхатаба на проприетарный гитлаб после его покупки злым Майкрософтом?

эмм, разве не гитхаб — проприетарный, а гитлаб — опенсорсный?

0
Хм, пока искал пруфы, наткнулся на эту замечательную табличку. Видимо, я все же ошибся, прошу прощения.

Но все же смысла в паническом бегстве с гитхаба я в итоге так и не понял. Люди разломали себе CI и все процессы, и больше месяца их восстанавливали, просто чтобы перелезть на такую же платформу (GitLab EE), но не связанную с MS.
+3
Вы сильно идеализируете современный Unix-way. Может быть, если формочки писать под Qt — оно и канает, а мало-мальски крупная система из нескольких компонентов практически гарантированно не переживет переноса даже на следующий major того же дистрибутива.
0
Вы про линухи? Они положили толстый прибор на Unix-way в конце 90х. Сейчас набита куча скважин по вертикали и горизонтали. Ну и апофеоз в виде systemd.
0
Приятнее всего?) Однако… Вы чувствами живете что ли?

Прочитайте еще раз статью автора) Вам светит то же самое. Это если мозги есть. Если мозгов нет — значит вам вообще ничего не светит.
Исключительно и только кнопачки на формачках гонять. Не более.

И да, открою вам наистрашнейший секрет) Фреймворк из дот.нета писан для студентов, в целях ознакомления. И он никак не является тем, на чем можно и нужно писать.

button1_Click
Это особенно из ядерных кошмаров.
Кто вам запрещает наследоваться от кнопки, замутить свой объект Button1 и без проблем в нем переопределить метод OnClick()?

Даже этим дот.нет ужасен. До блевоты.

И НЕ ПИШИТЕ НИКОГДА Button1, У ВАС ЧТО ВООБЩЕ МОЗГА НЕТ??
-2
А самое ужасное тут то, что майкрософт абсолютно наплевав на ооп и запихав эту байду с буттон1_клик -ами из коробки взростил за 15 лет сказочных далб*ебов миллионами. Которые даже не понимают, до какой степени они далб*ебы.
+1

Это было ещё до Майкрософта в Делфи, созданном тем же самым Андерсом Хейлсбергом.

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

Сильно похоже на ватное «ну вы поглядите как у пиндосов, у них еще хуже».
Логика у вас тут сильно хромает, сравнение не корректное никак.
0

Не стал лучше. Майкрософт нанял Хейлсберга, и он сделал им такой же Делфи, только на C++/CLI (а позже решили сделать и C#). Вот и всё.

0
А чем, простите, здесь так сильно решает смена технологического стека?
+1
Вот тоже об этом подумал. Теперь можно еще в банк пойти порабоать — чтобы понюхать сполна дисциплины, или на какой-нибудь американский аутсорс — и все, готов инвалид интеллектуального труда.
-1
Я пробовал. Абсолютно не понравилось, дикая помесь ФП и ООП. Но это помогло мне лучше начать писать на C#, так что за это я благодарен языку. В планах — скала и хаскель, хотя бы понимать выпендрежников-теоркатовцев :)
0
По фото выглядит намного старше.

«При этом меня смущает, насколько огромные для своего города деньги я получаю за один пулл реквест. Как будто высокий скилл разработчика даёт мне право жить в десять раз лучше чем куча людей, которые в поте лица делают полезное дело по восемь часов в день.»

Уперся в потолок в своём городе. 24 года — вся жизнь впереди! Нужно развиваться, почему бы не переехать в другое место, где будут адекватно платить за каждый пул реквест (относительно других рабочих в городе)? Смена обстановки нехило так освежает :)
Нужно выправлять work-life balance: коллега одно время работал 4 дня в неделю, а 3 отдыхал. Ещё можно попробовать дауншифтинг (появление 2-го ребенка не за горами) или, наоборот, пойти выше — в архитекторы. Новый вызов нужен, и срочно.
+1
Новый вызов нужен, и срочно.


Если что-то и нужно, то только то, чтобы человека все устраивало. Если его устраивает жизнь без «срочных вызовов» — это его жизнь, и пусть он так и живет. Ну не хочет он превозмогать, так это его право.
0

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


Мне иногда кажется, что с таким подходом у меня нет морального права искать себе работу."


Что-то не чувствуется, что всё устраивает.

0
Такое выгорание в 24 (если тут правильно указывают возраст)?
Ответ на первый вопрос удивил и расстроил. Думаю, любому из нас на самом деле есть чем гордиться, даже если предмет гордости для иных может быть пустяком, ничего не значащим для других.
С другой стороны, тут говорится о разработке .NET, а это вполне могут быть реально жернова «разработка-подакшен» из которого не видно выхода, хотя если герой Senior software development engineer, то как бы должен быть некий иммунитет уже выработан, рабочий опыт должен быть уже и из статьи видно что есть.

0
С другой стороны, тут говорится о разработке .NET, а это вполне могут быть реально жернова «разработка-подакшен» из которого не видно выхода, хотя если герой Senior software development engineer, то как бы должен быть некий иммунитет уже выработан, рабочий опыт должен быть уже и из статьи видно что есть.

Я пишу на C#, и у меня отличный интересный стек, тут и ELK, и блокчейн (хотя его назвать интересным тяжело, но все же bleeding edge имеет некоторые плюсы), и кроссплатформенная разработка, и даже поконтрибьютить в Parity (ethereum-client) получилось. Мне 25, выгорания не видно, с удовольствием занимаюсь пет-проектами (в том числе такими, чтобы помогали работе). В свободное время увлекаюсь в основном компьютерными стратегиями, полгода назад открыл для себя europa universalis, с тех пор ненарадуюсь на неё.

C# прекрасный язык, на нем можно реально писать и отдыхать. Нужно только найти подходящих коллег (или быть в компании единственным бек-разработчиком шарпистом на 20 котлинистов, как на моём текущем месте :) )
0
Выгорание в 20-25-30 это для меня нонсенс в принципе. Я реально не понимаю откуда оно может взятся и как себя самого надо «загонять» что бы насчался сам процесс внутреннего выгорания. Реально, даже не понимаю зачем это делать. Что бы кому-то что-то доказать? Глупость.
Мне скоро 41 год, я пишу на С, С++, Python, работаю, в основном, в промышленном секторе, с удовольствием ковыряюсь с пет-проектами и, как и Вы, чувствую себя прекрасно. Что такое выгорание я понял лет пять назад, и, подумав, немного сменил направление работы. Я уверен, что чтобы не выгореть надо заниматься тем от чего тебя прет, но даже тут нужен регулярный отдых и смена деятельности во время того самого отдыха.
0
Везде есть, нету только там, где менеджмент немного прислушивается к разрабам и не гонит волну.
Но по моему субьективному мнению и наблюдением большинство девов с потухшими глазами я встпечал в .NET, сожет совпадение, может еще что… Думаю еще мнго зависит от того, кто есть конечный клиент.
0
Серьёзно, в языке, для которого весьма нередок код в стиле IDictionnary<IMyStupidType, IMyStupidType2> Foo(Func<IMySupidType, int, bool, string> reallyStrangeCallback не сделать норм алиасы типов — это оооочень странное решение.

  1. class DictAlias: IDictionnary<IMyStupidType, IMyStupidType2> {}
  2. delegate IMySupidType FuncAlias(int, bool, string);
  3. Совмещаем 1 и 2: DictAlias Foo(FuncAlias reallyStrangeCallback)

Чем ему это не угодило то?

+1
1. это другой тип, поэтому работать корректно во всех случаях не будет. Ну например `if typeof(obj).GetGenericDefinition() == typeof(Dictionary<>)`. В общем всё, что связано с рефлекшном работать не будет. Сюда же необходимость прокидывать конструкторы,…
2. два делегата с одинаковой сигнатурой считаются разными типами. На мой взгляд очень глупо, но как есть. Соответственно сценарии использования сильно ограничены, если не держать где-то сборку всех используемых делегатов во всех смежных проектах.

Это все костыли, причем не очень удобные.

— Погодите, я немного не понял, как это работает:
class DictAlias: IDictionnary<IMyStupidType, IMyStupidType2> {}

Вы предлагаете реализовывать весь IDictionary? Ведь вы увидели, что наследуетесь от интерфейса, а не от Dictionary? Потому что если в случае Dictionary этот костыль может еще работать, то с интерфейсами — нет.

P.S. алиасить sealed-типы как предлагаете?
+1
Мб автор статьи подразумевал нечто вроде
using MyDictAlias = IDictionary<string, string>;

public void Method(MyDictAlias dict)
{
    dict.Add("","");
}

но в скоупе проекта\солюшена, а не только класса.
0
Вы предлагаете реализовывать весь IDictionary?

Пардон, я имел ввиду это


interface DictAlias : IDictionary<IMyStupidType, IMyStupidType2> { }

Конечно ограничения есть, но


В общем всё, что связано с рефлекшном работать не будет

это сильное заявление. Вместо


if(typeof(obj).GetGenericDefinition() == typeof(Dictionary<>))

можно


if(obj is IDictionary<int, int>)

Можно юзать Type.IsAssignableFrom и т.д. ну вы поняли.
Если вы делаете "жесткую" проверку типа, на то должны быть причины.


алиасить sealed-типы как предлагаете?

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


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

Да уж, не удобно, но можно и не делать:


delegate void A();
delegate void B();

class Test
{
    public void Run(A a) => a();
}

B b = () => Console.WriteLine("qqq");

Test t = new Test();
t.Run(b);  // Error: Cannot convert from B to A
t.Run(b.Invoke); // Works :)
+2
Пардон, я имел ввиду это
interface DictAlias : IDictionary<IMyStupidType, IMyStupidType2> { }

Конечно ограничения есть, но

А дальше как? Где имплементацию DictAlias взять? Каст словаря к DictAlias то не сработает.
+1
Пардон, я имел ввиду это

И что дальше? Нет ни одного калсса (в стандартной библиотеке) который бы реализовывал этот интерфейс. В каком-нибудь расте можно было бы написать


trait MyDict : IDictionnary<IMyStupidType, IMyStupidType2> {}

impl<T> MyDict for T where T : IDictionnary<IMyStupidType, IMyStupidType2>

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


Когда-нибудь эту проблему решат концептами, но сильно лучше решение от этого не станет.


Можно юзать Type.IsAssignableFrom и т.д. ну вы поняли.
Если вы делаете "жесткую" проверку типа, на то должны быть причины.

Конечно, они есть. Например, когда я пишу (де)сериализатор.

+4
Сделать пилотный выпуск с выгоревшим разрабом, режущим правду-матку о том, как ему надоела его работа… Классное решение, на самом деле. Из-за этого читать было интересно
+1
Верно. Ведь есть же телеканал TLC, который рассказывает о правде жизни простых людей. Почему жизнь программистов умалчивается? Все думают, что программисты — это богатые и счастливые люди. Но это совсем не так, и этот миф нужно кому то развеять. Я рад что появился такой проект. Желаю успеха автору! Подписываюсь и лайкаю!
0
Ламеров пускают сюда? Это я про себя.
Планирую запилить робота-программиста. Могу рассказать.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.