Мне удалось пообщаться с Джоном и взять у него большое интервью по поводу судьбы .NET, .NET Core, нововведений в C# 7 и общем уровне развития среднего разработчика в 2017 году.
Если говорить конкретно, то обсудили следующие вопросы:
- Общее направление развития .NET и ошибки Microsoft;
- Чего ждать от .NET Core в ближайшем будущем;
- Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
- Проблемы и победы .NET на поприще кроссплатформенности;
- Java vs .NET на рынке enterprise решений;
- Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
- Небольшие, но приятные фичи C# 7;
- Деградация сообщества разработчиков (и есть ли она);
- Правильный подход к диагностике багов и постановке правильных вопросов на SO;
- Гайд по изучению новых языков и платформ;
- Проблемы с базовыми типами: числа, текст, дата и время;
Интервью получилось очень большое, но мне кажется, оно стоит каждой потраченной на него минуты.
О развитии .NET как платформы
— Приветствую, Джон, начнём с простых вопросов. В последнее время .NET Core и ASP.NET Core развиваются очень быстро и постоянно мняются. Вам, как разработчику, кажется, что платформа взяла верный курс?
— Я думаю, вопрос затрагивает два разных аспекта. Первый — это направление развития платформы, а второе — процесс поиска этого направления: Microsoft стали гораздо более открытыми во всём, что связано с .NET. сейчас почти все стало open source и это здорово. С другой стороны, это влечёт за собой изменения в ряде вещей: например, в процессе принятия решений. Мы будем наблюдать промежуточные шаги, вроде вроде project.json-проектов и KVM. Во времена «старого» Майкрософт с его традиционным корпоративным путем разработки ПО подобного бы точно не произошло, и, возможно, мы сразу увидели бы инструментарий .NET в его текущем виде. Да, в сообществе была полная неразбериха, и лично мне было многое непонятно, но со временем ситуация прояснялась. На этой неделе я задал вопрос на Stack Overflow о том, что же представляет собой .NET Standard Library, и ситуация становится все лучше.
Однако, по-моему, мы как сообщество должны понимать, что преимущество открытости платформы в виде возможности планировать, видеть и влиять на происходящее сопровождается одним недостатком: вы должны либо сознательно игнорировать ещё не финализированные изменения, либо погружаться в них, осознавая вероятность того, что вы просто потеряете время, если эти изменения откатят. Судя по всему, большинству это подходит, и открытость идёт на пользу, но для .NET-сообщества это своего рода культурный шок.
С учетом всего этого нельзя не отметить несколько, как бы сказать… коммуникативных осечек, которые можно легко понять: несложно допустить ошибку при создании принципиально новой версии чего-либо. Конечно, ещё были ошибки с нумерацией версий, с выбором дат релизов, с решениями о готовности. В общем, всё шло не так гладко, как хотелось бы, но это не страшно: в конце концов, никто не совершенен, и мы как сообщество должны это принять. Чем больше видишь, тем больше несовершенства замечаешь. Это что касается процесса развития платформы.
Если же говорить о направлении движения .NET, то здесь я крайне, крайне оптимистичен. Приятно видеть и активное развитие .NET как платформы, и её расширение на мобильные платформы, и то, как Xamarin ложится на всю эту историю. Все это сложно, но вдохновляет, и также наблюдается большой прогресс в языках, в инструментах. На мой взгляд, ситуация в целом прекрасна. Для меня это всё ещё и происходит в то время, когда я работаю над Google Cloud Platform в Google, стараясь сделать GCP отличным окружением для C#-разработчиков, и, конечно, .NET Core — важная часть этого.
Недавно на конференции Google Cloud Next 2017 мы с моим менеджером обсуждали возможность работы ASP.NET Core-приложений на GCP как в App Engine Flexible Environment, так и в контейнерах. И это одна из тех вещей, которые буквально несколько лет назад считались бы нелепыми. Требовалось провести работу с нашей стороны (в Google у нас есть расширение для Visual Studio, позволяющее деплоить в обе среды напрямую из VS), но также в этом не было бы смысла и без того, что Microsoft сделали с .NET Core. Честно говоря, мне кажется, что складывается выигрышная ситуация для всех.
— Я правильно понимаю, что сейчас вы занимаетесь Google Cloud Platform, которая является прямым конкурентов для MS Azure?
— Всё так, GCP конкурирует с MS Azure и Amazon AWS. Вообще, напрямую в разработку «кишков» платформы я не вовлечён. Все те крутые штуки, которые создают мои коллеги — вроде Cloud Spanner, BigQuery, Datastore или различных API машинного обучения — это великолепно, но не приносит пользы С#-разработчику, если он не может это использовать. Так что я создаю мост: у нас есть автогенерируемые библиотеки классов и некоторые новые виды кодогенераторов для упрощения всего процесса. И я добавляю туда немного рукописного кода в качестве клея или обёртки, чтобы сделать всё как можно бесшовнее и элегантнее.
Зачастую, видя автоматически сгенерированный код, можно понять, что он сгенерированный, так как он не очень-то хорош. Моя часть работы — сделать так, чтобы кодогенерация была максимально похожа на естественную. Представьте, что вам нужно получить список каких-либо ресурсов, а на выходе вы получаете 20 ответов на вызовы удаленных процедур, хотя вам надо всего-то проитерировать их, — я занимаюсь тем, чтобы подобные ситуации решались бесшовно и занимаюсь пишу такой код — маленькие финальные штрихи, из-за которых общая картина выглядит совсем по-другому.
— То есть ваша работа, фактически, сделать так, чтобы автогенерируемый код мог пройти тест Тьюринга? :)
— Хаха, это было бы замечательно! Я не думаю что мы близки к этому, но он проходит другой тест: когда используешь кодогенератор, то либо чувствуешь себя подчинённым его капризам, либо чувствуешь, что он работает на тебя. Я твёрдо уверен, что в нашем случае разработчик контролирует процесс.
— Возвращаясь к платформе .NET: какие наиболее масштабные изменения следует ждать .NET-разработчикам в ближайшем будущем? На годы вперёд загадывать сложно, но возможно, поделитесь ожиданиями на ближайшие месяцы?
— Всё зависит от того, где вы находитесь. Если ваш проект застрял в эпохе project.json или «я плевал на всё, я до сих пор на VS2013», то есть что наверстывать до последних релизов. Вышла VS2017, вышел .NET Core SDK, всё зарелизили, это больше не beta — и я призываю всех разобраться в том, что это значит. Да, на это нужно время, а документация всё ещё активно улучшается. Но это речь о пути, который надо проделать, чтобы нагнать текущее положение дел.
А если говорить о будущем, следующая глобальная вещь, которая нас ожидает — это .NET Standard 2.0. У нас уже были .NET Standard 1.0, 1.2, 1.3, и т.д. — это не первая попытка облегчения кроссплатформенной разработки относительно portable class libraries. Но .NET Standard 2.0 — это дивный новый мир, покрывающий гораздо больше платформ, чем мы привыкли по десктопному .NET. Будут невероятно умные инструменты, позволяющие использовать библиотеки классов, написанные только под .NET 4.5: их авторы может быть даже их уже не поддерживают, но это не помешает запустить их в .NET Standard 2.0. Кроме того, я верю, что инструментарий становится все более низкоуровневым. Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо, такую библиотеку можно использовать в контексте .NET Standard 2.0.
Нам обещают именно такой путь развития, и текущий .NET Core SDK не просто хорош, а по-настоящему хорош — огромный шаг вперед по сравнению с тем, что было раньше. И я думаю, Microsoft на этом не остановится. Поэтому, если вы не пишете пользовательские приложения (где, очевидно, UI будет важен, и от платформы будет многое зависеть), вы во многом можете полагаться на то, что .NET есть .NET, и кроссплатформить по полной. Что всё это будет означать в контексте деплоя из Xamarin для Android и iOS — пока непонятно, но мне будет очень интересно посмотреть, как все получится.
— Вы рекомендуете всем по мере возможности переходить на новые версии .NET Core как можно раньше, поскольку он уже стабилен. А что делать с древними .NET 4.0 легаси проектами?
— В таком случае нет необходимости обновляться до .NET Core. Я бы сказал, что если используешь .NET Core со старой SDK, используешь project.json, то вот тогда определённо стоит мигрировать на новый инструментарий как можно поскорее. Торопиться не надо, но в roadmap это добавить стоит.
А если у вас только унаследованное приложение, которое работает только с .NET 4… тут все зависит от конкретного случая: если вы видите у него долгосрочное будущее, то может быть смысл инвестировать время в его обновление до .NET Core есть. Если у вас TargetFramework это .NET 4.0, и вы не используете какие-нибудь сомнительные библиотеки, то, скорее всего сможете просто портировать его на .NET Core и обнаружить, что выбор сред развёртывания сильно расширился.
Скажем, у вас уже есть некоторое количество сервисов, крутящихся на Windows Server, и вы слышите много хорошего о Linux-контейнерах (я в курсе, что существуют win-контейнеры, но в случае с Linux выбор куда шире). Если вы портируете их в .NET Core (а если предположить, что у вас ASP.NET-приложение, то в ASP.NET Core, это немного другое), то выиграете от улучшений тулинга и ширины выбора платформ. Скажем, когда дело дойдёт до Continuous Integration, у вас будет куда больше доступных окружений: вы можете использовать Travis, который не поддерживается Windows: «Эй, это не проблема, я всё также могу запускать тесты на Travis в рамках моей обычной CI». Все эти вещи улучшают жизнь.
Конечно, это относится не ко всем. Если у вас старое приложение, в котором не ожидается больших изменений, и которое в идеале вообще будет заменено в ближайшее время, то вся работа по портированию будет бессмысленна. Но я думаю, мы склонны недооценивать время, которое проект будет находиться в продакшене, и то количество изменений, которое ему предстоит. Не стоит думать «ничего, вот тут допилю, соберу билд на какой-нибудь старой VS или типа того, в конце концов, таких изменений больше толком и не будет». После того, как вам придётся сделать 20 подобных изменений, год за годом расходуя силы на деплой в устаревших окружениях, вы наконец придёте к мысли «мне стоило постараться раньше и перейти на что-то более современное».
Кроссплатформенность .NET и конкуренция на рынке серверного enterpise
— Понятно. Есть ещё вопрос о кроссплатформенности .NET: вы действительно думаете, что поддержка многих платформ — это хорошая идея? Вы уже упомянули, что у вас огромная инфраструктура, но сможет ли .NET соперничать с Java в категории кроссплатформенного энтерпрайза и бэкенда?
— Абсолютно! Я бы сказал, что это не просто хорошая идея для .NET, это необходимая идея для .NET. Я считаю, что судьба .NET в виде Windows-only платформы с поддержкой сторонних не-очень-то-хорошо-поддерживаемых окружений, нишевых платформ, с которыми люди больше страдают, чем работают, никогда не была перспективной. Так что это была необходимая работа, которая не просто высвободила большой потенциал, но также и не позволит .NET устареть через несколько лет. Я думаю, не-кроссплатформенным серверным решениям придётся несладко. Мы видим то же с окружениями, которые раньше были Linux-only или относились к среде Windows как к «бедной родственнице»: в Windows появилась поддержка для Ruby и Python, которая с течением времени стала заметно лучше. То же самое с Git… Да даже Bash (Shell) теперь есть на Windows. Я думаю, что мультиплатформенность сейчас — это «прожиточный минимум».
— Понятно. Не могу не задать холиварный вопрос: что вы думаете про .NET в сравнении с Java? Особенно на энтерпрайз-рынке, который, насколько я понимаю, глядя на работу Microsoft над Azure и энтерпрайз-инфраструктурой, является одним из целевых для компании.
— Я бы сказал, .NET определённо может конкурировать с Java, и если быть честным, я лично всегда предпочту разрабатывать на C#. Просто потому что сам язык намного лучше.
Тем не менее, у Java есть определенные преимущества: гораздо больше библиотек с открытым кодом (хотя не факт, что они лучше), больше вариантов решения какой-либо проблемы. Если ты выбираешь фреймворк вебсервиса, в Java у тебя, скорее всего, будет не менее 30 вариантов, а в .NET, возможно, 5. Но в любом случае использовать вы будете только один из них, так что в случае, когда и в Java, и в .NET есть хотя бы один хороший вариант, разнообразие Java помогает, но в то же время может сбивать с толку. А если нет доминирующего игрока, разнообразие только усложняет процесс поиска хороших решений. Так что, если вы хотите просто найти фреймворк с хорошей реализацией, это получается почти преимуществом на стороне .NET.
Кроме того, существует инерция. Мы знаем, что в мире много энтерпрайзных Java-программистов и приложений, и я не думаю, что многие люди скажут «Давайте возьмем это работающее Java-приложение и перепишем его под .NET». Скорее будет так: «Нам по-любому переписывать приложение, поэтому надо выбрать из парочки платформ». А если вы создаете новое приложение — неважно, веб-приложение, сервис или что-то подобное, я думаю, в этом случае Java и .NET должны идти ноздря в ноздрю. Я предполагаю что энтерпрайз будет остерегаться .NET Core ещё год-два, пока он не докажет свою состоятельность, но после этого ожидаю рост использования в энтерпрайзе, и тогда преимущества C# должны дать о себе знать.
— Да, я понял, спасибо. Я не буду здесь затрагивать более developer-friendly JVM-языки, потому что мы здесь не для холивара :) Но у меня ещё один вопрос: у вас уже есть реально накопленный опыт актуального живого опыта разработки приложений или сервисов под Linux на .NET?
— Вообще я не разрабатываю приложения в чистом виде, но недавно для Google Cloud Next 2017 вместе с моим менеджером мы внедрили очень маленькое веб-приложение на ASP.NET Core, которое я потом задеплоил в контейнер в AppEngineFlexible Environment. В таком масштабе — да, опыт есть. Также сайт Noda Time построен на ASP.NET Core, сейчас он задеплоен на Windows, но я надеюсь перенести его на Linux, и я не вижу абсолютно никаких причин, почему оно не должно заработать из коробки.
И по моему опыту, .NET Core для Linux очень хорош, пока вы используете только его. Места, в которых я нашёл проблемы, были в билд-скриптах: только сегодня утром я установил VS Code на мой Linux box, и с Noda Time всё было прекрасно для netcoreapp и netstandard-версий, но при попытке собрать код для .NET 4.5.1 оно сказало: «Эй, я понятия не имею что такое .NET 4.5.1» — поэтому потребовалось включить в билд пару ссылок на референсные сборки. Итак, если вы абсолютно кроссплатформены и нацелены только на .NET Core, я думаю всё хорошо, но если у вас уже есть несколько сборок, где некоторые куски кроссплатформенны, а другие привязаны к полному .NET Framework, тогда все не так хорошо, как хотелось бы. Я уверен, MS работают над этим, и я сам бы мог исправить ситуацию установкой референсных сборок в определённых местах, но я не хочу запускать Windows-код под Linux — я просто хочу кроссплатформеннный код. И эта часть, как я уже сказал, особенно хороша.
Пара слов о С# 7
— Я крайне доволен C# 7. Сейчас я пишу о нём в четвёртом издании «C# in Depth», поэтому узнаю его гораздо лучше, чем раньше. Прямо сейчас я пишу о кортежах (tuples), фиче, которая выглядит простой, но имеет много скрытых мелочей. Изначально я настороженно относился к кортежам, но теперь вижу их преимущества в реализации. В чём я сейчас не уверен, так это стал бы ли я писать публичные API и выставлять кортежи наружу. Это решение ограничивает разработчиков языка легковесным неинкапсулируемым возвратным типом. В то время как, если возвращать определённый класс, это можно было бы улучшить с течением времени.
Кортежи станут большим подспорьем для ленивых разработчиков, а мы все должны быть в какой-то мере ленивыми. В пределах определённого класса или даже библиотеки, использующей кортежи (tuples) как легковесный способ группировки переменных вместе, всё должно быть круто.
Другая важная фича, которую ты упомянул — pattern matching. И самое ценное в pattern matching в С# 7 — это не паттерны, которые мы получили, а введение самой идеи паттернов. Я сознательно разделяю эти понятия. В данный момент мы можем использовать паттерны в операторе «is» и в switch cases. Единственные паттерны, которые у нас есть сейчас — это эквивалентность и совпадение типов. Так что можно или задать «case x is 5», и найдётся совпадение, если значение равно 5, или можно искать совпадение по типу: «x is String». Ранее type matching вызывал возражения, но на практике оказался реально полезным.
Я уже принял первый C# 7 пулл-реквест в Noda Time от моего друга Билла Вагнера, и этот пулл-реквест наглядно показывает преимущества pattern matching на конкретных примерах. Но на самом деле это показывает извлечённые уроки из F# и Haskell, позволяющих описать функцию через то, как она будет вести себя в разных ситуациях — это по-настоящему понятный путь описания по сравнению с if-else-if-else-if-else. Когда мы говорим «этот case соответствует такому результату, а этот такому», по сути, мы делаем то же, что и if-else, но в гораздо более простом для понимания виде. Все это выглядит многообещающе, и я надеюсь, что в каких-то промежуточных релизах, вроде C# 7.1, мы увидим больше паттернов, таких как деконструкция значений.
Представим такую ситуацию. У вас есть DateTime, вы можете деконструировать его и найти с pattern matching случаи, где год больше 2016. Вы можете сделать нечто подобное и в C# 6, но поиск соответствий не будет использовать деконструкцию. Так что pattern matching в будущем может дать ещё многое. Это самые большие фичи С# 7, и их не стоит недооценивать.
Другое большое преимущество для большинства ASP.NET Core пользователей лежит в плосткости async/await: если раньше async-метод мог вернуть только Task, Task или void, то теперь можно вернуть что угодно, совпадающее с определённым паттерном (но это не то же, что pattern matching!), если там есть атрибут, говорящий если ты не создаёшь значение данного типа, используй эту фабрику». Я не думаю, что многие люди будут применять этот паттерн в своем коде, но они могут использовать имплементацию других людей. И ValueTask — более легковесную версия Task — будут использовать почти все, это структура, которую команда ASP.NET Core оптимизировала различными способами, и она будет особенно полезна в ситуациях с низким временем отклика, когда хочется получить все преимущества async, но при этом не нагружать GC заботой о лишних Task-объектах. На мой взгляд, это интересная фича, которую многие будут использовать, не вникая в детали «как имплементировать свой собственный возвратный тип».
Если просто посмотреть на список фич, то C#, помимо крупных нововведений, получает и небольшие — штуки вроде ref-local и ref-return, довольно сложные для понимания (по крайней мере, для меня). Я полагаю, они будут весьма полезны для Unity-разработчиков высокопроизводительных игр, которые весьма чувствительны к определённым аспектам перфоманса, вроде GC и тому подобного — есть ощушение, что они используют structs больше, чем другие разработчики.
Также есть замечательные маленькие улучшения вроде out-переменных: возможности объявить переменную в то же время, когда вы используете её для аргумента для выходного параметра, так что больше нет необходимости объявлять:
int x;
if (int.TryParse("some text", out x))
{
// ...
}
достаточно просто
if (int.TryParse("some text", out int x)), это объявит и распарсит одновременно. Это просто устранение маленького неудобства, и оно показывает намерения проектировщиков C#: везде, где есть какой-то дискомфорт и приходится писать какой-то код, который не хочется писать, потому что он выглядит некрасиво, это исправляют. И out-переменные помогают в этом, как и числовые литералы.
Наконец, локальные функции. У меня есть пара юзкейсов для локальных функций, связанных с проверкой аргумента, где раньше могло потребоваться разделить метод на два: или async-метод, где вы хотели сделать асинхронную проверку аргумента до перехода к асинхронной части, или, в похожем случае, у вас есть iterator-метод, то при предполагаемом вызове он фактически не исполнит ничего, включая проверку аргументов, поэтому зачастую у меня есть обычный метод, который занимается проверкой аргумента, а потом возвращает FooImpl, где происходит реальная имплементация с итератором. И теперь я смогу писать этот FooImpl как локальный метод. Возможно это не та вещь, которую все будут использовать каждый день, это решение, которое сглаживает шероховатости при написании кода.
О сообществе разработчиков и умении диагностировать проблемы
— Я думаю, на этом мы закончили с вопросами по .NET, но у меня есть еще пара более общих вопросов. В данный момент вы #1 в рейтинге Stack Overflow — вы годами отвечали там на тонны вопросов. Можете ли вы сказать, эволюционируют ли разработчики или становится всё больше глупых вопросов?
— Дело не в том, становятся ли программисты умнее или нет. Я бы сказал так: в ранние периоды вопросы на Stack Overflow были в целом качественнее, так как сайт был не так популярен. Уже давно его использование стало обычным делом, но сейчас это повсеместная практика — а это означает, что менее опытные разработчики, которые были всегда, теперь с большей вероятностью задают свои вопросы. Кроме того, множество хороших вопросов были заданы давно и остаются актуальными и по сей день, и если их задают сейчас, их по вполне понятным причинам закрывают как дубликаты. И я поймал себя на том, что я меньше отвечаю на вопросы, зато оставляю куда больше комментариев вида: «Вам следует попытаться продиагностировать проблему чуть глубже до того, как задавать вопрос, вот несколько советов, как это сделать, а пока что вопрос не очень хороший по содержанию». Я куда больше времени трачу на это, чем непосредственно отвечая на вопросы, потому что, по сути, сейчас не так много вопросов, на которые требуется ответ. Хотя в свете выхода C# 7 должны начать появляться хоршие вопросы конкретно об этой версии.
Нельзя сказать, что разработчики хуже, чем они должны быть, или что не осталось интересных вопросов. Просто баланс слегка сместился… А вто что меня действительно расстраивает: я вижу множество неопытных разработчиков (часть из которых не считает себя неопытными), демонстрирующих невнимание к другим людям. Они просто думают: «У меня есть проблема, но я не собираюсь сам искать решение, поэтому я попросту задам вопрос», — после чего идёт либо простыня кода, либо вообще никакого кода и фраза: «У меня тут проблемка, можете помочь?». Мы действительно сталкиваемся с вопросами, где нет никакой информации, кроме такой. Хотелось бы, чтобы люди прикладывали больше усилий к формулировке вопроса или учились исследовать проблему, если у них пока недостаточно навыков в диагностических техниках. Когда я учу новый язык или у меня возникает проблема, я всегда пытаюсь свести пример к необходимому минимуму. Ведь даже если люди ожидают, что я знаю ответ, это не всегда так.
Некоторое время назад я написал блог-пост о том, как запускал некоторые тесты на NUnit для Noda Time, и по каким-то причинам на Linux они работали сильно медленнее, чем на Windows. Следует заметить, что я запускал тесты с культурой en-uk, где было немного кода на NUnit, и в итоге оказалось, что он приводил к использованию String.EndsWith() на каждый assert.EndsWith() делает проверку с учётом культуры, хотя NUnit это не требовалось, в итоге это было исправлено. В итоге я обнаружил, что эта проверка и вызывала проблемы. Это было примерно так:
- я вижу, что это занимает очень много времени
- задаю себе вопрос — это мой код тормозит процесс, или какой-то другой?
- я нашёл один тест, который показал проблему
- далее я убрал столько кода, сколько мог из этого теста
- после этого я исключил Noda Time, написав маленький проект, запускающий NUnit вообще без логического кода
- после чего исключил NUnit из схемы, покопавшись в коде NUnit-код и найдя проблему «ааа,
String.EndsWith(), окей, давай посмотрим, как оно выполняется» - в этот момент я уже мог воспроизвести проблему с кодом 10 строк длины, запускавшим
String.EndsWith()в цикле тысячи раз - стало понятно, что именно этот код на Linux отрабатывал медленно, а на Windows очень быстро
- и предоставив всю эту информацию на SO, я смог получить ответ о том, что причина в культурной информации: она оптимизирована под Windows с UK English и не оптимизирована для Linux
- в итоге я смог подтвердить это путём запуска этого куска на US English, который был быстр и на Linux.
Это большой объем работы, надо сделать много шагов для того, чтобы исключить из вопроса все несущественное.
И я обнаружил, что многие люди не знают, как это делать, или просто не запариваются — они предпочитают задавать вопросы. Еще многие прыгают с головой в языки и платформы до того, как будут действительно готовы. Лично я пытаюсь изучать вещи по одной, зато как следует, но есть куча людей, которые говорят: «Я совершенно новенький в программировании. Сейчас я пишу приложение под Android на Java, взаимодействующее с SQLite. И этот код не работает», — окей, а это проблема Java, проблема Android или проблема SQLite? Вряд ли все три сразу. Что вы сделали, чтобы понять, что является источником проблемы? Поймите, я не докапываюсь, я пытаюсь научить людей помогать самим себе. Я твёрдо убежден, что понимание «как работает мой язык», отдельное от «как работает моя платформа» — это реальное преимущество в отношении того, как быстро вы сможете разобраться и начинать применять что-то при изучении нового.
— Что вы посоветуете начинающим программистам для относительно гладкого старта в целом или на какой бы то ни было платформах? Стоит ли мне обучаться самостоятельно, или лучше начать с фундаментального образования? На что делать в первую очередь?
— Учиться можно по-разному, для рекомендую начать с книги, — я сам автор, так что это и в моих интересах тоже, но мои книги не предназначены для новичков. Я пытался написать книгу формата «С# для начинающих», но это сложно. В целом, я бы выбрал конкретный язык, и большинство языков подходят для того, чтобы освоиться в них с нуля, если есть подходящий обучающий материал. Так что просто найдите книгу, и убедитесь, что она относительно свежая и охватывает последние изменения языка/платформы. Я бы не начинал с платформ, на которых сложно заниматься диагностикой.
При изучении новой платформы или языка я всегда начинаю с небольшого консольного приложения, если там вообще есть консоль. С JavaScript сложнее, если только не учишь Node.js или что-то подобное. Для обычных языков вроде C#, Java, Ruby, Python убедитесь, что у вас есть набор инструментов, подходящий для старта. И не пытайтесь сразу сделать веб-приложение или веб-сервис — начните с маленького консольного приложения. У меня есть небольшой набор приложений, которые я пишу на старте. Одна из них — игра, которая загадывает число, а задача пользователя за 5 попыток угадать его, а она говорит, твой вариант больше правильного, меньше или правильный.
Разработка подобной программы отлично подходит в качестве первого шага овладения языком, потому что нет необходимости знать много о структурах данных, которые поддерживает платформа, о том, как работают словари и другие подобные вещи. Но ее достаточно, чтобы начать. А после этого уже можно сказать: «Окей, теперь я знаю, как выводить в консоль, как читать из консоли». Это может быть не слишком нужно для веб-приложения, но просто необходимо для диагностики: можно разбираться с кодом в отладчике, и вы скорее будете делать это в консольном приложении, чем в iOS-приложении, например. Я уверен, что под iOS отладочные инструменты тоже есть, но их гораздо сложнее понять, пока вы не погрузитесь в язык полностью.
Как я уже упоминал, этот первый шаг не затрагивает словари, списки, функции и тому подобное. Поэтому дальше начинайте писать следующее консольное приложение, которое покрывает все эти возможности, например: «создать список Strings и сделать на его основе другой список из перевёрнутых Strings» — маленькое приложение, которое делает только это. И если у вас появятся какие-либо проблемы, вы будете знать, что проблема только в понимании той конкретной темы, над которой вы сейчас работаете. Если вы хотите создать бесподобное приложение или игру, то держите это в голове. Но никогда не начинайте погружение в проект с нее. Вам нужен серьёзный фундамент, прежде чем создать что-то большое. Это всё равно что сказать «Мне хочется пробежать марафон, так что завтра, никогда раньше не бегав, я пойду и пробегу марафон». У вас не получится, это деморализует вас, и это только навредит вам — до этого нужно дорасти. Так же и с программным обеспечением.
Сложности в создании компьютерной модели реального мира
— Ого, последний пример хорош. Вот о чем я еще хотел спросить, в своем докладе для DotNext «Back to Basics» вы говорите о связи между реальной жизнью и моделями, которые мы создаём в разработке ПО: типами данных, структурами и тому подобным. Что-либо поменялось в этой области за последние пару лет?
— Доклад посвящён трём наборам типов: как компьютеры взаимодействуют с числами, текстом, и датой/временем. В широком смысле за последние годы ничего не поменялось, легче точно не стало, возможно, даже стало слегка сложнее из-за Unicode как общемирового способа работы с текстом. Существует 65536 кодовых пунктов, некоторые из которых не назначены, и всё это называется Basic Multilingual Plane. А есть ещё другие planes, и раньше я мог говорить «можете их игнорировать, всё, что вам когда-либо понадобится, есть в BMP», так что не нужно беспокоиться о представлении не-BMP символов как пар BMP. И даже это уже неправда из-за эмодзи! 10 лет назад можно было никогда встретить символ не из BMP, а теперь большинство людей, читающих это интервью, видят как минимум один не-BMP символ в день.
Вот пример: у вас есть поле ввода, где пользователь может набрать не более 10 символов, что это значит? Даже без BMP вы можете иметь «e» с острым ударением на нём, и это может быть представлено как двумя символами, так и одним, в зависимости от нормализации. То же самое работает для emoji: в Java и .NET, если вы используете String.Length(), увидите длину два символа для каждого символа эмодзи. Значит ли это, что пользователь может ввести всего пять? Это будет странно с точки зрения пользователя: им говорят, что у них есть десять символов, но они могут ввести только пять. Так что да, эмодзи сделали жизнь сложнее.
В отношении чисел, похоже, ничего не изменилось. В отношении даты и времени с момента, когда я выступал с этим докладом впервые, кое-что поменялось на фронте .NET: Noda Time, моя собственная библиотека для работы с датами и временем. Она дошла до релиза, а сейчас я уже выпустил версию 2.0. Я бы сказал, что в случае с датой и временем всё постепенно становится лучше, всё больше людей проникаются пониманием, что проблема существует. У меня есть пара друзей, которые работают над улучшением основных типов даты и времени в JavaScript и добавлением новых, потому что мы использовали Date в JS очень долго, а оно во многих случаях работает неправильно. Поэтому они усердно работают над созданием более практичного JavaScript API для даты и времени, чем есть сейчас.
Все развивается, но базовые задачи компьютеров предполагают простые модели, а разработчики считают, что компьютер должен понимать и предметную область, и тогда возникают вопросы вроде: «я разделил 5 на 10 и получил 0, а не 0.5», — ну, стоило использовать числа с плавающей точкой или ещё что.
Вместо заключения
— Да, последний пример ярко демонстрирует тот факт, что люди все чаще вместо самостоятельных поисков задают вопросы в интернете. Поэтому может быть, есть пара вещей, которые хотелось бы добавить к концу интервью для своих читателей — возможно, пару советов?
— Хорошо, я перейду от некоторых очень конкретных идей к некоторым обобщениям:
1. Определённо, попробуйте Noda Time, если вы используете где-либо в вашем коде дату и время. Если у вас есть DateTime.Now() где-то в вашей кодовой базе, то есть вероятность, что у вас есть ошибки. Поэтому я настоятельно рекомендую изучить Noda Time.
2. Если говорить в общем, мне также хочется, чтобы люди больше думали о документации. Есть проект под названием DocFX, который в некотором роде превзошёл Sandcastle, но я думаю, что мы можем сделать намного больше. Дополнительная документация с перекрёстными ссылками между разными элементами. Только представьте мир, в котором документация является достаточно машиночитаемой, чтобы, когда вы ссылаетесь на какую-либо документацию в Stack Overflow, вы просто нажимаете кнопку, начинаете вводить имя типа, и видите предварительный просмотр: «это тот тип, который вы имеете в виду?» Я думаю, жить в таком мире было бы замечательно.
3. Ещё важнее этого разнообразие людей в мире технологий. Я выступаю на многих конференциях, и аудитория, как правило, — белые мужчины, и это расстраивает меня. Нам нужно больше гендерного разнообразия, нам нужно больше расового разнообразия, просто взгляните на статистику… она расстраивает. Каждый должен участвовать в искоренении всех форм сексуального домогательства, всех форм расизма в нашей отрасли. Более того, поощрять окружающих, понимать подсознательные предубеждения и бороться за то, чтобы создать как можно более равное условия деятельности для всех.
Если отстраниться от нашей индустрии, мои личные интересы — это гендерное равенство в целом, скажем так, я уже 2,5 года начинающий феминист. Поэтому я рекомендую всем прочитать что-то вроде «Everyday sexism», чтобы посмотреть, как этот мир выглядит с точки зрения других людей. Все это довольно страшно, и это, безусловно, изменило мой взгляд на многие вещи.
Отдельно хочу поблагодарить Женю phillennium Трифонова и Андрея DreamWalker Акиньшина за помощь в подготовке поста. Плюсы вам карму!
Комментарии (0)