Поддерживаю любые F#-начинания, но называться dotnet-разработчиком это, скорее, про понимание основных концепций dotnet ("что это такое" в целом, GC, CLR, CTS, IL) и основных встроенных и сторонних библиотек для работы с БЛ, сетью.
И, конечно, отличное знание языка и понимание, как он маппится на те же CLR, CTS, IL.
Лучше, конечно, больше чем один язык.
Но F# это скорее, все-таки про функциональное программирование. Хотя тут очень важно и понимание, как он маппится на механизмы dotnet.
Другое дело, актуальный разработчик должен давно использовать не только linq, но и придти к другим фунциональным парадигмам в использовании C#.
И тут совершенно логичным выглядит как минимум интерес к F#. А вот дальше сложнее — с вакансиями и реальным его использованием в проектах.
Одна из основных мыслей статьи — создание на F# чисто модели, и вынос ввода-вывода на периферийный контур — очень импонирует.
Спасибо за статью!
Работа со временем — очень важная вещь.
Сам давно задумывался над этим и пытался выработать решения на распространенные кейсы, плюс на обработку краевых случаев.
Радует, что одни и те же мысли приходят одновременно разным людям.
Хочется, однако, риторически прокомментировать вот это :
Так линейно вы, в общем, и пишете код. Дата начала — сегодня минус одни сутки, дата окончания — сегодня. Казалось бы, все работает, но потом ровно в полночь у вас случается странное. У вас дата начала вот здесь. Дата начала минус одни сутки — получается, такая. После этого почему-то дата окончания отчета совершенно другая.
Вы, а точнее ваш начальник получаете отчет за двое суток вместо одних. Технический начальник и менеджер приходят, жалуются и вежливо предлагают вам через шесть месяцев перейти в другую команду.
Абсолютно типовая ошибка, проистекающая из неаккуратности, нежелании разобраться в природе вещей (времени в данном случае), низкой культуры кодирования, незнания и нежелания разобраться в реализации стандартной библиотеки, и как она (реализация) маппится на ту самую природу вещей.
Но… Скажите, где вы находите компании, где за такое просят покинуть команду или лучше компанию?
Сколько помню, везде в энтерпрайзе попадался именно код такого характера, со временем, включая прямо вот описаную вами ошибку, другие типовые ошибки со временем и другими сущностями.
И что характерно, авторы такого кода были всегда в почете (такой код можно писать быстро, перформанс наше все! — почти ж никто в ИТ не в курсе, что нужно перформанс для разрабов нужно переводить вторым главным значением — "эффективность", а не первым "производительность", интерпретируемую как скорость закрытия тасков на гора, а дальше не волнует).
Другое дело, что, как правило, авторы такого кода были уже далече, только не их попросили, а они на гребне волны славы сами успели уйти на повышение — в другие компании, реже в той же компании.
Коллега, ваша статья кажется мне очень актуальной и важной, и хотелось бы, чтобы её увидело больше людей.
Просится, чтобы она была добавлена в хаб "управление проектами" (там точно ей место, наряду с изначально добавленным "управлением персоналом").
Возможно, хаб "программирование" — все-таки мы обсуждаем тему в контексте разработки, а в другие сферы аджайл только приходит. И в этом хабе статью точно увидит много людей, причем релевантных.
При этом у меня сложилось впечатление, что на эту тему, причем именно в связи с аджайлом и скрамом, стали писать/переводить/комментировать больше именно в последнее время.
Ну, и если говорить о 2014-м, то к этому времени скрам и подобное уже успели себя проявить в индустрии несколько лет точно, и о выгорании уже нельзя было говорить только как о таковом (по традиционным причинам), без учета контекста скрама.
Когда то это должно закончится, и вижу, что кухонные бурления под ковром начинают прорываться наружу.
И да, хабр я бы все-таки отнес к андеграунду пока.
Да, в последнее время он "вышел в свет", и как тут говорят, вновь прибывших тут даже больше.
Но тут разработчики откровенно говорят о том, что боятся сказать вслух менеджерам в компаниях.
Спасибо, ваша статья, это прямо мои мысли ещё несколько лет назад. Что работа, проект это марафон.
И его нельзя (в смысле, физически невозможно, т.е, это фундаментальные ограничения нашей вселенной) пробежать серией спринтерских дистанций.
Или же нужно между спринтами делать отдых не меньше самого спринта.
Но ведь нет же — к понедельнику деплой? Ну значит, в пятницу овертайм, а в понедельник бегом на новый спринт.
Я работал в компании, где вообще шли параллельно две серии двузнедельных спринтов, со сдвигом в неделю (один для поставки в тестирование, другой в прод). Это значит, что выходных нет вообще.
А потом удивляются, и пишут статьи, что, де, выгорание (да чего там — сжигание), что сотрудники в ИТ постоянно куда то уходят и переходят, а оставшиеся формально выполняют kpi.
Я не говорю уж о том, что даже если между спринтами через один вставлять спринты отдыха (на отдых и переключение контекста — ага, а про переключение контекстов тоже отдельный разговор), то исходную задачу (сделать длительный проект, коли до людей дела нет) это не поможет решить — тк ну не разбивается большинство реальных задач на эти ваши спринты.
И потом начинают писать статьи/говорить, почему же все проекты в итоге сваливаются в "плохой код" (ну вы поняли), никакую (отсутствующую) анатитику и закрываются, а потом открываются новые и далее по кругу.
Удивительно, что в последнее время на уровне андегаунда пока, но стали об этом говорить.
Мне же это было ясно сразу, как прочитал манифесты и статьи про аджайл и скрам, когда это стало модным и стало требовать я везде. Хотя вот недавно прошел тренинг у сертифицированных тренеров и получил сертификат.
Статья производит впечатление, будто автор хочет прорекламировать, что подобные практики являются чем-то хорошим, и это подается под соусом, де, смотрите, вот пример цивизизованных «отношений».
И в комментариях выше видно справедливое возмущение комментаров с примерами, что на Западе, где есть эта практика, это создает проблему для сотрудников и ущемляет их права, и решается это где-как, кто-то «забивает» на это, кто-то офомляется как private entrepreneur, где-то есть ограничения, но разумные (6 мес, которые могут компенсироваться предыдущей высокой зп в корпорации), и тд.
Но это среда, где эта практика прижилась, и более-менее все как-то решается.
Можно встретить много статей, и переводы на том же хабре, как чел работал в западной Computer Science-корпорации, потом уволился на неск месяцев или даже лет (sabbatical или любые другие причины), а потом как ни в чем не бывало, устроился в аналогичную корпорацию, и не тужит.
А если попытаться применить чуждые практики там, где все по другому, то получится все как всегда.
У нас же другие реалии — стоит, к примеру поработать со смежной технологией полгода (к примеру, C# => Java), так потом следуют вопросы вида «а не забыли ли вы шарп», «а почему меняли платформу» (лично я сталкивался с этим 3 года назад, хотя платформы — близнецы, и мне интересно работать с обеими).
Не говоря уж о том, если у человека был перерыв в работе, или просто уволился по своим причинам.
И представляете, что будет, если к этим реалиям применить чуждую практику, в результате которой люди будут вынуждены иметь перерыв в работе по профилю от нескольких мес.
Хотя, с другой стороны, может в итоге это приведет к обратному эффекту — нормализации практики, когда перерыв перестанет считаться чем-то фатальным.
Интересно, а почему в мптематических около-ИТ кругах, где делают подобные обработки биг дата, столь непопулярен .NET (а ведь уже есть вполне зрелый Core под Линукс)?
В .NET есть LINQ с готовыми функциями, и даже LINQ to SQL, чтобы писать на C#, а выполнялось это в СУБД.
Это если, конечно, нужно написать «обычном» на языке программирования, а не на SQL
Да, понял вас, с вашими тезисами согласен.
Если делать аутсорс по правилам аутсорса — ок.
Мой же коммент базировался на моем опыте, когда довелось работать несколько раз в компаниях, которые работали на аутсорс, но при этом это была разработка продуктов, и в процессах разработки имели место взаимоисключающие требования "аутсорс — продукт".
А даже если по-вашему, а вот когда ожидаешь решения чужого блокера, что делать?
просто ждать (точно не будет конфликтов?), или переключаться на другие задачи?
Если последнее, то, секунду, мы и так погрузились в немалый контекст ради мелкого бага (а это беда большинства мелких тасков — размер контекста обратно пропорционален размеру таска), а теперь нужно его держать в голове (ведь к нему нужно возвратиться скоро, как блокер будет решен), и параллельно погружаться в контекст другой таски.
Я бы предпочел, чтобы у разраба была своя сфера отвественности в проекте (плюс смежные для ± взаимозаменяемости), и чтобы был скоуп задач (да, не на 4 часа, не на 8, и на 16; и, может быть, даже не на две недели).
Так и разрабу лучше (может планировать и распределять свою работу), и (!) проекту — большинство багов вида «4 часа» и появляться не будут (потому что разработка ведется не фрагментарно, и разработчик сам управляет переключением контекстов), те, которые будут появляться, будут фикситься за 5 минут (потому что нет оценок «4 часа», и никто не висит над душой), а высвободившееся время будет использоваться для основной нефрагментарной разработки, а также для решения багов, которые кажутся простыми, а не деле сложные и/или зависят от блокеров.
Но да, это не по скраму и аджайлу.
Точнее, по аджайлу, только по настоящему аджайлу.
Тут ниже привели хорошую ссылку на A class with custom equality — вроде получается читаемее и короче, чем если то же самое реализовывать на C#.
Но дело в том, что если нужно сравнивать по ID, то, возможно, лучше зайдествовать для этого кастомные компараторы — сегодня нужно по ID, завтра по имени-фамилии (да еще с учетом/без учета культуры/регистра) и т.д.
А "структуры" (не struct, а именно структуры/рекорды в широком смысле) пусть по умолчанию сравниваются по полям "как есть".
Это используют как известые крупные "платформы", так и мелкие компании, работающие с удаленными сотрудниками.
Можно конечно сказать, что решение по оценке количества нажатий принимается менеджерами конкретной компании/заказачка, но штука в том, что если что-то начинает измеряться, то именно это измеряться и оцениваться и будет — так что обольщаться не стоит.
Прямо чистую математику для разработчика вряд ли нужно спрашивать — это разные скиллы.
Разработчик должен понимать математику, и как математика маппится на компьютер.
Задачи на понимание сложности алгоритмов — вполне можно давать.
В какой форме — на компе/экране скайпе выбранном кандидатом языке программирования (если этот язык близок к тому, на котором нужно будет писать), на доске, устно на листке со схемами графа и какими-то пометками — зависит от выбора команды и кандидата.
Но, пожалуй, только не код писать на листке.
Если программирование не именно математическое, этого достаточно, чтобы хотя бы потом не рождался код вида:
foreach (var item in list)
{
int i = list.IndexOf(item);
}
Чтобы коллекции нужные использовались, и т.д.
Спрашивать по базовым вещам платформы и языка.
Тут тоже есть фундаментальные вещи — к примеру, много общего у .NET и Java, и многие решения вытекают из природы вещей, а не из прихоти архитекторов платформ.
Если предполагается, что нужно будет реализовывать модель в БД, то проверять навыки моделирования как со стороны предметной области, так и со стороны БД.
Можно спрашвиать базовые вещи по тому, как делить приложение на слои или слой внутри реализовывать — понять, понимает ли кандидат в принципе что такое контроллер (а не то, что под ним имеется в виду непременно в MVC-фреймфорках).
Можно накидать еще, это конечно не готовая инструкция.
Взять того же Макконнела — когда начал его читать, то с первых страниц увидел, что там прям более формализованно описаны подходы, которые я сам выработал ранее во время учебы и работы.
Кстати… А вот что-то давно не было видно упоминаний Макконнела в статьях, комментах, разговорах коллег… Получается, был хайп, но большинству это было не нужно (да и что-то не виду в реальных проектах кода по Макконнелу)?
И важны еще психологические скиллы интервьера — нужно понять, кандидат действительно считает, что тот же контроллер нужен (даже если не знает, что это называется контроллер) и будет топить за его использование, или он просто научился проходить собеседование, а на деле будет #####кодить?
> Проверять отчёты о проделанной работе. Например, если в отчёте сказано, что потрачено, к примеру, 16 часов на заливку дампа базы, тут сразу понятно, что самозванец.
Не-а. В аутсорсорсном энтерпрайзе, про который вы, видимо, и говорите, задачи выдаются не скоупом (разумное количество на разумное время, чтобы исполнитель мог сам распределить свою работу), а по одной по мере выполнения.
И бывает, что, чтобы залить дамп базу (сделать что-то другое простое), приходится продраться через блокеры, которые зависят не от тебя, не от твоей команды и даже не от части компании на твоем континенте, узнавать какие-то тысячи логинов, паролей от каких-то мутных логов (и все это структурно не описано, а в головах у старожилов), и прочая.
Особенно, когда входишь в проект или новую для себя его часть.
Какие тут 16 часов.
В одном из проектов у меня была таска «проапдейтить обработку XML файла таким то образом».
Ну ок, проапдейтил, прогнал через юнит тест — ок.
Но было правило — чтобы закрыть таску, нужно самому вручную прогнать через UI на DEV-сервере, т.е., загрузить файл через UI на фактически боевом окружении.
И на стороне UI где-то в конфигах был баг, что файл недетерминированным образом мог не загрузиться с выдачей неинформативной ошибки (т.е., до того, как попал на бек).
Все мучались, и только с моим приходом в проект, когда попинговал всех уполномоченных по этой теме, фронт-команда поправила что-то у себя.
К слову, баг тот я смог закрыть через 3 недели только из-за этого.
И не только из-за этого — в том проекте CI-сборки шли прямо на DEV-сервере, каждые 10 минут кто-то что-то коммитит, начинается пересборка на 20 минут, ты только загрузил файл, и хочешь, проверить — все отваливается, жди, и начинай заново (да, а для крупных тасков провести все это повторно для всей команды).
И еще до кучи в это же время коллеги на другом конце континента что-то мутили со сменой VPN, через который мы работали.
Это я все к тому, что мягко говоря, очень и очень удивляет эта манера в современном энтерппрайзе, разрабатываемом по аджайл, кидаться такими оценками: это 2 часа (спасибо, что не 5 минут, хотя и такое бывает), это 4, это 8, ох, а это «шеф, все пропало — аж целые 16».
Еще такой момент, судя по моему опыту и коллег — на рынке синхронно появляются «баззворды», по которым вдруг все начинают спрашивать на собеседованиях.
И часто собеседующие не могут донести, что же именно хотят.
Вот несколько лет назад всех массово спрашивали внезапно про SQL (и это тогда, когда уже расцвели ORM), толком не поясняя, что именно нужно.
Когда оказалось, что большинство вопросов сводятся к тому, чтобы кандидаты понимали конструкцию вида (читай — научились проходить интервью):
SELECT * FROM // выборка
%Table1% %JOIN KIND% JOIN %Table2% // одна из операций над множествами, к результату операции применяется выборка с условием
WHERE %CONDITION% // условие выборки
GROUP BY %SOME_COLUMN% // условие группировки
HAVING %AGGREGATE_FUNC% // аггрегирующая функция, чтобы выбрать строки из нужных групп
То интервьютеры резко потеряли к этому интерес, и стали спрашивать «А вот JOIN/UNION что такое?» — «Да операции над множествами, такие то и такие виды» — «А, ну ок».
То же самое было, когда появившийся еще в 2001-м REST вдруг внезапно стал резко популярен несколько лет назад, и тоже все и вся спрашивали «непонятные» вопросы.
Ну сразу бы сказали, что де всего лишь нужно понимать, что известный CRUD-паттерн теперь в лучших домах делается с помощью т.н. REST, который представляет собой текстовые вызовы /GET/POST/PUT/PATCH/DELETE поверх HTTP, и что в наиболее пополярных фреймворках это реализуется навешиванием соответствующим атрибутов на класс контролера и его методы или ручным описанием дерева разбора для описания «роутинга» (всего то соответствие пути метода в HTTP-запроса конкретному метода конкретного класса).
Ну т.е. по сути — концепция контроллера абсолютна понятна, и была до всякого РЕСТа, и будет после.
Теперь — вместо Application Binary Interface внутри приложения, нам нужно, чтобы части приложения общались по сети, желательно без Remoting/Binary вызовов, для этого придумываем простую надстройку над текстовым HTTP.
Но — ей же ей, как же изгалялись интервьюеры, сами не понимая, как сформулировать то, как хотят спросить. Некоторые просто спрашивали, что же такое веб и веб-сервисы, не понимая, что есть разные веб-сервисы (начиная от SOAP) с различными вариантами использования протоколов и надстройками в конкртеных фреймворках и т.д., а не просто реализация REST в их любимом фреймворке.
А теперь, когда кандидаты научились это «проходить», то максимум на интервью спрашивают, как написать контроллер в общих чертах, может еще попросят набросать прототип контроллера с атрибутом на классе и на методах.
(Хотя за год до этого все спрашивали про WCF с его «биндингами»).
И таких баззвордов с хайпом — уже легион их был.
Может, пора спрашивать реальную базу программирования/Computer Science?
Ведь все эти «баззворды» — лишь варианты реализации известных и вечных концепций, а то и вовсе не вариант реализации концепции, а вариант реализации обертки (адаптера) вокруг концепции.
Может, пора проявлять некоторое уважение к разработчикам, и понимать, что если они знают базу (и тем если более работали с несколькими поколениями «систем» разработки), то понять, как та или иная новая обертка ложится на известную концепцию — дело короткого времени и небольшой техники, и что это вообще не то, что нужно спрашивать?
Это программа, которая считает количество нажатий клавиш за каждый 5-минутный интервал и делает скриншот.
Если нажатий не было/было мало, то даже наличие скришота с IDE не позволит это включить это время рабочее/учтенное/оплачиваемое.
Примерно так.
Так было бы очень логично — высокоуровневый ОО- и ФП-код (большинство кода) писать на F#, небольшую часть кода (средний уровень, соответствующий терминам IL) — на идиоматическом C#, а совсем небольшую (unmanaged) — на C# с fixed, указателями, stackalloc и прочим.
Жаль, что такого нет.
Проекты на C# скатываются в легаси с портянками кода, где перемешана предметная логика с техническим бойлерплейт-кодом.
Вы хорошо написали про Котлин, но именно по описанным вами причинам на нем есть риск программировать «как на Java», а это неправильно.
У Котлина есть своя парадигма (в основном функциональная), чтобы писать идиоматический код.
Да и ОО-код на нем тоже можно писать «как на Java», и «как на Котлин».
Про это уже не раз писали.
А у F# действительно большие отличия от C#, связанные с тем, что первый — именно функциольны язык, а не мультипарадигменный.
На нем можно писать как на C#, но приходится это делать явно и не очень удобно.
Примерно как на C# можно делать низкоуровневые вещи, но писать для этого fixed (+ синтаксис указателей и их разыменования), (un)checked, требовать для сборки повышенные права, и т.д.
И это хорошо, что F# не позволяет сходу писать как на C#.
Тот же Kotlin, когда/если станет действительно популярным (т.е., когда на нем будут писать не только тесты и вьюшки для Андроида, а нормальный бек), то, вангую, будет проблема — тонны кода в модели Java с синтаксисом Котлин.
Идиоматического Котлин-кода будет исчезающе мало.
F# действительно работает на инфрастуктуре .NET, но от многого позволяет абстрагироваться.
Например, при работе с коллекциями в ФП- терминах F# вы абстрагированы от бардака в коллекциях. Конечно, до тех пор, пока не потребуется сделать что-то более специфическое и обратиться напрямую к возможностям платформы.
Ну и возможности общего характера, которых в C# нет и неизвестно, когда завезут.
Те же Discriminated Unions — а в продуктовом коде приходилось много раз встречать код, где разраьботчики что-то велосипедили, хотя Discriminated Unions решили бы вопрос.
В Котлине, к слову, Discriminated Unions нет.
Повторюсь, я бы с удовольствием программировал под .NET на F#, проблема только с популярностью самого .NET и решениями компаний по актуализации техногического стека в легами .NET-проектах.
Поддерживаю любые F#-начинания, но называться dotnet-разработчиком это, скорее, про понимание основных концепций dotnet ("что это такое" в целом, GC, CLR, CTS, IL) и основных встроенных и сторонних библиотек для работы с БЛ, сетью.
И, конечно, отличное знание языка и понимание, как он маппится на те же CLR, CTS, IL.
Лучше, конечно, больше чем один язык.
Но F# это скорее, все-таки про функциональное программирование. Хотя тут очень важно и понимание, как он маппится на механизмы dotnet.
Другое дело, актуальный разработчик должен давно использовать не только linq, но и придти к другим фунциональным парадигмам в использовании C#.
И тут совершенно логичным выглядит как минимум интерес к F#. А вот дальше сложнее — с вакансиями и реальным его использованием в проектах.
Одна из основных мыслей статьи — создание на F# чисто модели, и вынос ввода-вывода на периферийный контур — очень импонирует.
Под одну операционку это ныне замороженный (is done) .NET 4.8.
А актуальный .NET ныне — это Core 2.2/3.0 для бек-енд разработки, которую ведут обычно под Windows, но таргетируют как для Windows, так и для Linux.
И сейчас Core прямо выстрелил — после многих и многих лет застоя стартовало много бек-енд проектов на рынке.
Ну а с кроссплатформенной разработкой, похоже, в итоге не сложилось. И надо ли? Есть много других современных средств.
Спасибо за статью!
Работа со временем — очень важная вещь.
Сам давно задумывался над этим и пытался выработать решения на распространенные кейсы, плюс на обработку краевых случаев.
Радует, что одни и те же мысли приходят одновременно разным людям.
Хочется, однако, риторически прокомментировать вот это :
Абсолютно типовая ошибка, проистекающая из неаккуратности, нежелании разобраться в природе вещей (времени в данном случае), низкой культуры кодирования, незнания и нежелания разобраться в реализации стандартной библиотеки, и как она (реализация) маппится на ту самую природу вещей.
Но… Скажите, где вы находите компании, где за такое просят покинуть команду или лучше компанию?
Сколько помню, везде в энтерпрайзе попадался именно код такого характера, со временем, включая прямо вот описаную вами ошибку, другие типовые ошибки со временем и другими сущностями.
И что характерно, авторы такого кода были всегда в почете (такой код можно писать быстро, перформанс наше все! — почти ж никто в ИТ не в курсе, что нужно перформанс для разрабов нужно переводить вторым главным значением — "эффективность", а не первым "производительность", интерпретируемую как скорость закрытия тасков на гора, а дальше не волнует).
Другое дело, что, как правило, авторы такого кода были уже далече, только не их попросили, а они на гребне волны славы сами успели уйти на повышение — в другие компании, реже в той же компании.
Коллега, ваша статья кажется мне очень актуальной и важной, и хотелось бы, чтобы её увидело больше людей.
Просится, чтобы она была добавлена в хаб "управление проектами" (там точно ей место, наряду с изначально добавленным "управлением персоналом").
Возможно, хаб "программирование" — все-таки мы обсуждаем тему в контексте разработки, а в другие сферы аджайл только приходит. И в этом хабе статью точно увидит много людей, причем релевантных.
Вы правы, проблема действительно не новая.
При этом у меня сложилось впечатление, что на эту тему, причем именно в связи с аджайлом и скрамом, стали писать/переводить/комментировать больше именно в последнее время.
Ну, и если говорить о 2014-м, то к этому времени скрам и подобное уже успели себя проявить в индустрии несколько лет точно, и о выгорании уже нельзя было говорить только как о таковом (по традиционным причинам), без учета контекста скрама.
Когда то это должно закончится, и вижу, что кухонные бурления под ковром начинают прорываться наружу.
И да, хабр я бы все-таки отнес к андеграунду пока.
Да, в последнее время он "вышел в свет", и как тут говорят, вновь прибывших тут даже больше.
Но тут разработчики откровенно говорят о том, что боятся сказать вслух менеджерам в компаниях.
Спасибо, ваша статья, это прямо мои мысли ещё несколько лет назад. Что работа, проект это марафон.
И его нельзя (в смысле, физически невозможно, т.е, это фундаментальные ограничения нашей вселенной) пробежать серией спринтерских дистанций.
Или же нужно между спринтами делать отдых не меньше самого спринта.
Но ведь нет же — к понедельнику деплой? Ну значит, в пятницу овертайм, а в понедельник бегом на новый спринт.
Я работал в компании, где вообще шли параллельно две серии двузнедельных спринтов, со сдвигом в неделю (один для поставки в тестирование, другой в прод). Это значит, что выходных нет вообще.
А потом удивляются, и пишут статьи, что, де, выгорание (да чего там — сжигание), что сотрудники в ИТ постоянно куда то уходят и переходят, а оставшиеся формально выполняют kpi.
Я не говорю уж о том, что даже если между спринтами через один вставлять спринты отдыха (на отдых и переключение контекста — ага, а про переключение контекстов тоже отдельный разговор), то исходную задачу (сделать длительный проект, коли до людей дела нет) это не поможет решить — тк ну не разбивается большинство реальных задач на эти ваши спринты.
И потом начинают писать статьи/говорить, почему же все проекты в итоге сваливаются в "плохой код" (ну вы поняли), никакую (отсутствующую) анатитику и закрываются, а потом открываются новые и далее по кругу.
Удивительно, что в последнее время на уровне андегаунда пока, но стали об этом говорить.
Мне же это было ясно сразу, как прочитал манифесты и статьи про аджайл и скрам, когда это стало модным и стало требовать я везде. Хотя вот недавно прошел тренинг у сертифицированных тренеров и получил сертификат.
И в комментариях выше видно справедливое возмущение комментаров с примерами, что на Западе, где есть эта практика, это создает проблему для сотрудников и ущемляет их права, и решается это где-как, кто-то «забивает» на это, кто-то офомляется как private entrepreneur, где-то есть ограничения, но разумные (6 мес, которые могут компенсироваться предыдущей высокой зп в корпорации), и тд.
Но это среда, где эта практика прижилась, и более-менее все как-то решается.
Можно встретить много статей, и переводы на том же хабре, как чел работал в западной Computer Science-корпорации, потом уволился на неск месяцев или даже лет (sabbatical или любые другие причины), а потом как ни в чем не бывало, устроился в аналогичную корпорацию, и не тужит.
А если попытаться применить чуждые практики там, где все по другому, то получится все как всегда.
У нас же другие реалии — стоит, к примеру поработать со смежной технологией полгода (к примеру, C# => Java), так потом следуют вопросы вида «а не забыли ли вы шарп», «а почему меняли платформу» (лично я сталкивался с этим 3 года назад, хотя платформы — близнецы, и мне интересно работать с обеими).
Не говоря уж о том, если у человека был перерыв в работе, или просто уволился по своим причинам.
И представляете, что будет, если к этим реалиям применить чуждую практику, в результате которой люди будут вынуждены иметь перерыв в работе по профилю от нескольких мес.
Хотя, с другой стороны, может в итоге это приведет к обратному эффекту — нормализации практики, когда перерыв перестанет считаться чем-то фатальным.
В .NET есть LINQ с готовыми функциями, и даже LINQ to SQL, чтобы писать на C#, а выполнялось это в СУБД.
Это если, конечно, нужно написать «обычном» на языке программирования, а не на SQL
Да, понял вас, с вашими тезисами согласен.
Если делать аутсорс по правилам аутсорса — ок.
Мой же коммент базировался на моем опыте, когда довелось работать несколько раз в компаниях, которые работали на аутсорс, но при этом это была разработка продуктов, и в процессах разработки имели место взаимоисключающие требования "аутсорс — продукт".
А даже если по-вашему, а вот когда ожидаешь решения чужого блокера, что делать?
просто ждать (точно не будет конфликтов?), или переключаться на другие задачи?
Если последнее, то, секунду, мы и так погрузились в немалый контекст ради мелкого бага (а это беда большинства мелких тасков — размер контекста обратно пропорционален размеру таска), а теперь нужно его держать в голове (ведь к нему нужно возвратиться скоро, как блокер будет решен), и параллельно погружаться в контекст другой таски.
Я бы предпочел, чтобы у разраба была своя сфера отвественности в проекте (плюс смежные для ± взаимозаменяемости), и чтобы был скоуп задач (да, не на 4 часа, не на 8, и на 16; и, может быть, даже не на две недели).
Так и разрабу лучше (может планировать и распределять свою работу), и (!) проекту — большинство багов вида «4 часа» и появляться не будут (потому что разработка ведется не фрагментарно, и разработчик сам управляет переключением контекстов), те, которые будут появляться, будут фикситься за 5 минут (потому что нет оценок «4 часа», и никто не висит над душой), а высвободившееся время будет использоваться для основной нефрагментарной разработки, а также для решения багов, которые кажутся простыми, а не деле сложные и/или зависят от блокеров.
Но да, это не по скраму и аджайлу.
Точнее, по аджайлу, только по настоящему аджайлу.
Тут ниже привели хорошую ссылку на A class with custom equality — вроде получается читаемее и короче, чем если то же самое реализовывать на C#.
Но дело в том, что если нужно сравнивать по ID, то, возможно, лучше зайдествовать для этого кастомные компараторы — сегодня нужно по ID, завтра по имени-фамилии (да еще с учетом/без учета культуры/регистра) и т.д.
А "структуры" (не struct, а именно структуры/рекорды в широком смысле) пусть по умолчанию сравниваются по полям "как есть".
Это используют как известые крупные "платформы", так и мелкие компании, работающие с удаленными сотрудниками.
Можно конечно сказать, что решение по оценке количества нажатий принимается менеджерами конкретной компании/заказачка, но штука в том, что если что-то начинает измеряться, то именно это измеряться и оцениваться и будет — так что обольщаться не стоит.
В том то и дело, что буквально.
И сам так работал некоторое время — больше не буду.
Прямо чистую математику для разработчика вряд ли нужно спрашивать — это разные скиллы.
Разработчик должен понимать математику, и как математика маппится на компьютер.
Задачи на понимание сложности алгоритмов — вполне можно давать.
В какой форме — на компе/экране скайпе выбранном кандидатом языке программирования (если этот язык близок к тому, на котором нужно будет писать), на доске, устно на листке со схемами графа и какими-то пометками — зависит от выбора команды и кандидата.
Но, пожалуй, только не код писать на листке.
Если программирование не именно математическое, этого достаточно, чтобы хотя бы потом не рождался код вида:
foreach (var item in list)
{
int i = list.IndexOf(item);
}
Чтобы коллекции нужные использовались, и т.д.
Спрашивать по базовым вещам платформы и языка.
Тут тоже есть фундаментальные вещи — к примеру, много общего у .NET и Java, и многие решения вытекают из природы вещей, а не из прихоти архитекторов платформ.
Если предполагается, что нужно будет реализовывать модель в БД, то проверять навыки моделирования как со стороны предметной области, так и со стороны БД.
Можно спрашвиать базовые вещи по тому, как делить приложение на слои или слой внутри реализовывать — понять, понимает ли кандидат в принципе что такое контроллер (а не то, что под ним имеется в виду непременно в MVC-фреймфорках).
Можно накидать еще, это конечно не готовая инструкция.
Взять того же Макконнела — когда начал его читать, то с первых страниц увидел, что там прям более формализованно описаны подходы, которые я сам выработал ранее во время учебы и работы.
Кстати… А вот что-то давно не было видно упоминаний Макконнела в статьях, комментах, разговорах коллег… Получается, был хайп, но большинству это было не нужно (да и что-то не виду в реальных проектах кода по Макконнелу)?
И важны еще психологические скиллы интервьера — нужно понять, кандидат действительно считает, что тот же контроллер нужен (даже если не знает, что это называется контроллер) и будет топить за его использование, или он просто научился проходить собеседование, а на деле будет #####кодить?
Не-а. В аутсорсорсном энтерпрайзе, про который вы, видимо, и говорите, задачи выдаются не скоупом (разумное количество на разумное время, чтобы исполнитель мог сам распределить свою работу), а по одной по мере выполнения.
И бывает, что, чтобы залить дамп базу (сделать что-то другое простое), приходится продраться через блокеры, которые зависят не от тебя, не от твоей команды и даже не от части компании на твоем континенте, узнавать какие-то тысячи логинов, паролей от каких-то мутных логов (и все это структурно не описано, а в головах у старожилов), и прочая.
Особенно, когда входишь в проект или новую для себя его часть.
Какие тут 16 часов.
В одном из проектов у меня была таска «проапдейтить обработку XML файла таким то образом».
Ну ок, проапдейтил, прогнал через юнит тест — ок.
Но было правило — чтобы закрыть таску, нужно самому вручную прогнать через UI на DEV-сервере, т.е., загрузить файл через UI на фактически боевом окружении.
И на стороне UI где-то в конфигах был баг, что файл недетерминированным образом мог не загрузиться с выдачей неинформативной ошибки (т.е., до того, как попал на бек).
Все мучались, и только с моим приходом в проект, когда попинговал всех уполномоченных по этой теме, фронт-команда поправила что-то у себя.
К слову, баг тот я смог закрыть через 3 недели только из-за этого.
И не только из-за этого — в том проекте CI-сборки шли прямо на DEV-сервере, каждые 10 минут кто-то что-то коммитит, начинается пересборка на 20 минут, ты только загрузил файл, и хочешь, проверить — все отваливается, жди, и начинай заново (да, а для крупных тасков провести все это повторно для всей команды).
И еще до кучи в это же время коллеги на другом конце континента что-то мутили со сменой VPN, через который мы работали.
Это я все к тому, что мягко говоря, очень и очень удивляет эта манера в современном энтерппрайзе, разрабатываемом по аджайл, кидаться такими оценками: это 2 часа (спасибо, что не 5 минут, хотя и такое бывает), это 4, это 8, ох, а это «шеф, все пропало — аж целые 16».
И часто собеседующие не могут донести, что же именно хотят.
Вот несколько лет назад всех массово спрашивали внезапно про SQL (и это тогда, когда уже расцвели ORM), толком не поясняя, что именно нужно.
Когда оказалось, что большинство вопросов сводятся к тому, чтобы кандидаты понимали конструкцию вида (читай — научились проходить интервью):
SELECT * FROM // выборка
%Table1% %JOIN KIND% JOIN %Table2% // одна из операций над множествами, к результату операции применяется выборка с условием
WHERE %CONDITION% // условие выборки
GROUP BY %SOME_COLUMN% // условие группировки
HAVING %AGGREGATE_FUNC% // аггрегирующая функция, чтобы выбрать строки из нужных групп
То интервьютеры резко потеряли к этому интерес, и стали спрашивать «А вот JOIN/UNION что такое?» — «Да операции над множествами, такие то и такие виды» — «А, ну ок».
То же самое было, когда появившийся еще в 2001-м REST вдруг внезапно стал резко популярен несколько лет назад, и тоже все и вся спрашивали «непонятные» вопросы.
Ну сразу бы сказали, что де всего лишь нужно понимать, что известный CRUD-паттерн теперь в лучших домах делается с помощью т.н. REST, который представляет собой текстовые вызовы /GET/POST/PUT/PATCH/DELETE поверх HTTP, и что в наиболее пополярных фреймворках это реализуется навешиванием соответствующим атрибутов на класс контролера и его методы или ручным описанием дерева разбора для описания «роутинга» (всего то соответствие пути метода в HTTP-запроса конкретному метода конкретного класса).
Ну т.е. по сути — концепция контроллера абсолютна понятна, и была до всякого РЕСТа, и будет после.
Теперь — вместо Application Binary Interface внутри приложения, нам нужно, чтобы части приложения общались по сети, желательно без Remoting/Binary вызовов, для этого придумываем простую надстройку над текстовым HTTP.
Но — ей же ей, как же изгалялись интервьюеры, сами не понимая, как сформулировать то, как хотят спросить. Некоторые просто спрашивали, что же такое веб и веб-сервисы, не понимая, что есть разные веб-сервисы (начиная от SOAP) с различными вариантами использования протоколов и надстройками в конкртеных фреймворках и т.д., а не просто реализация REST в их любимом фреймворке.
А теперь, когда кандидаты научились это «проходить», то максимум на интервью спрашивают, как написать контроллер в общих чертах, может еще попросят набросать прототип контроллера с атрибутом на классе и на методах.
(Хотя за год до этого все спрашивали про WCF с его «биндингами»).
И таких баззвордов с хайпом — уже легион их был.
Может, пора спрашивать реальную базу программирования/Computer Science?
Ведь все эти «баззворды» — лишь варианты реализации известных и вечных концепций, а то и вовсе не вариант реализации концепции, а вариант реализации обертки (адаптера) вокруг концепции.
Может, пора проявлять некоторое уважение к разработчикам, и понимать, что если они знают базу (и тем если более работали с несколькими поколениями «систем» разработки), то понять, как та или иная новая обертка ложится на известную концепцию — дело короткого времени и небольшой техники, и что это вообще не то, что нужно спрашивать?
Это программа, которая считает количество нажатий клавиш за каждый 5-минутный интервал и делает скриншот.
Если нажатий не было/было мало, то даже наличие скришота с IDE не позволит это включить это время рабочее/учтенное/оплачиваемое.
Примерно так.
Жаль, что такого нет.
Проекты на C# скатываются в легаси с портянками кода, где перемешана предметная логика с техническим бойлерплейт-кодом.
У Котлина есть своя парадигма (в основном функциональная), чтобы писать идиоматический код.
Да и ОО-код на нем тоже можно писать «как на Java», и «как на Котлин».
Про это уже не раз писали.
А у F# действительно большие отличия от C#, связанные с тем, что первый — именно функциольны язык, а не мультипарадигменный.
На нем можно писать как на C#, но приходится это делать явно и не очень удобно.
Примерно как на C# можно делать низкоуровневые вещи, но писать для этого fixed (+ синтаксис указателей и их разыменования), (un)checked, требовать для сборки повышенные права, и т.д.
И это хорошо, что F# не позволяет сходу писать как на C#.
Тот же Kotlin, когда/если станет действительно популярным (т.е., когда на нем будут писать не только тесты и вьюшки для Андроида, а нормальный бек), то, вангую, будет проблема — тонны кода в модели Java с синтаксисом Котлин.
Идиоматического Котлин-кода будет исчезающе мало.
F# действительно работает на инфрастуктуре .NET, но от многого позволяет абстрагироваться.
Например, при работе с коллекциями в ФП- терминах F# вы абстрагированы от бардака в коллекциях. Конечно, до тех пор, пока не потребуется сделать что-то более специфическое и обратиться напрямую к возможностям платформы.
Ну и возможности общего характера, которых в C# нет и неизвестно, когда завезут.
Те же Discriminated Unions — а в продуктовом коде приходилось много раз встречать код, где разраьботчики что-то велосипедили, хотя Discriminated Unions решили бы вопрос.
В Котлине, к слову, Discriminated Unions нет.
Повторюсь, я бы с удовольствием программировал под .NET на F#, проблема только с популярностью самого .NET и решениями компаний по актуализации техногического стека в легами .NET-проектах.