Программист на фортранеджаве на любом языке может писать на фортране?
А если по теме — то если у нас сущность подписывается на изменение одного поля в модели — то зачем тянуть наблюдение за остальными? (пусть даже на уровне протокола)
А если на изменение нескольких — то не проще ли (и не чище ли) подписываться на изменение объекта модели в целом?
Ну что вы, я, разумеется, не считаю авторов Go за недоучек, напротив — опытнейшие и матерые ребята. Однако все остальные языки так же писались отнюдь не дураками, которые тоже читали Брукса. И они почему-то пошли другим путем. И пока я не понимаю до конца почему — я и отношусь с некоторым недоверием к тому, что простота Го окончательна.
Давайте возьмем, например, метрику «количество вопросов на SO по отношению к репам на GH»
Большинство приведенных в списке языков имеют такое большое число по одной очень простой причине — новички крайне редко пишут на Go, Rust, Haskell,… зато много пишут на Ruby, JS, C++, Java, C#,…
Вот если на Go появится много вакансий по миру, в него придут джуны, в общем, в случае успеха — через 5 лет можно будет еще раз посмотреть на эту метрику.
Говоря же о других метриках, по моему субъективному ощущению количество кейвордов говорит о том, что
1. Сколько же в этом языке кейвордов (удивительно)
2. К насколько широкому классу задач стараются приложить этот инструмент
3.… Привнесенная сложность
Да, Го действительно прост, но, на мой взгляд, он пока еще не прошел испытания злобным продакшеном в полной мере и хотя бы 3-4 мажорных версий. Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
На данный момент ГО нерепрезентативен для таких вот исследований и его данные будут врать. Возможно даже в разы.
Большое спасибо за статью! Очень замечательный, жизненный, применимый и уникальный опыт, читать о котором было огромным удовольствием.
Увидел здесь множество своих граблей, преодолеть которые, в отличии от вас, мне не хватило мотивации в свое время. Однако после вашей статьи я теперь знаю, что вернусь к незаконченному проекту и попробую еще раз. Возможно даже с нуля.
Спасибо вам :-)
А в этом мире где-то существуют прочие равные? :-)
А вообще — для стартапов решают языки, с большим количеством стабильных и удобных third-party и прочих building blocks — чтобы стартаперы не столько писали очередной oauth-client или еще что-то такое — а просто собирали из кирпичиков свой Proof Of Concept — который, в случае успеха, и можно будет начать переписывать на более подходящем для этого языке.
Но, к слову, Го действительно хорош и приятен в мире, где third-party менее важны
Конкуренты сотрут вас с лица земли если
1. Они лучше представляют себе доменную область
2. Они имеют большую экспертизу в области
3. Они имеют больший ресурс на маркетинг
4. Они имеют более квалифицированных программистов, способных создавать более предсказуемые и сопровождаемые продукты
5. Они принимают более правильные решения
…
101. Они пишут на Go, а вы — нет.
Кейс достаточно простой. Если ручной тестировщик хочет «симулировать» на устройстве какой-то специфичный ответ, а по тем или иным причинам делать это через прокси не очень удобно.
Пример — в приложении, сильно зависящем от бэкенда можно симулировать цепочку ответов из некоторого записанного заранее файла и запустить этот процесс по кнопке в дебаг-панели.
Лаги UI — в самой простой реализации — просто запускает таймер в параллельном потоке, который время от времени интересуется — не повис ли главный поток больше чем на длину фрейма. Если повис — нотифаит об этом тестировщика/разработчика и можно сформулировать точный кейс, когда проседает FPS. В более сложной реализации можно заморочаться и получить стэктрейс главного потока при потере фрейма
P.S. Людям, которые пока еще не вкурили TDD я предлагаю не пытаться начинать свой опыт в тестировании именно с него. TDD — довольно спорная практика и, как правило, на реальных проектах при сильной изменчивости требований в начале разработки от нее больше вреда, чем пользы.
А тестировать свой код надо. Почему надо?
1. Банальное сравнение. Для того, чтобы проверить свой код без тестов — вам надо запустить проект, дощелкать до нужного места (на одном из проектов, где я работал, это занимало порядка полутора минут), после этого проверить требуемый кейс. В то время как собственно тест займет в худшем случае секунд 15 (при правильной настройке окружения)
2. Более того мало у кого хватит терпения при таком раскладе проверить все возможные ветки исполнения кода (особенно, если это касается edge-кейсов, что программа работает корректно, когда что-то идет не так)
Так что предлагаю вам начать с простого. Настройте тестовое окружение и на любую чисто логическую функциональность напишите тест. В практически любой программе есть 1-2 чисто функциональных модуля, которые берут какие-то данные и что-то с ними делают. Да, поначалу это будет казаться довольно очевидным, но это пройдет довольно быстро :-)
P.S. посмотрите репозитории по ссылкам в комментарии ниже — там можно найти довольно много вдохновения по тестам.
В этой статье вы разбирали XCTest, в основном.
Возможно, вы итак в курсе, но я бы предложил (например, читателям) поинтересоваться такой концепцией как BDD
В мире мобильной разработки она сейчас больше удовлетворяет нуждам. Под обжектив BDD фреймворком является expecta, как надстройка над specta
Под Свифт — это пара Nimble/Quick которая реализует примерно такую же функциональность.
Значительными преимуществами BDD перед TDD является включенное by-design описание тестовых сценариев, соответственно вернувшись к тестам через год, тебе по прежнему будет легко с ними работать. Кроме этого, BDD фреймворки захватывают помимо, непосредственно, юнит тестов еще и часть соседнего домена — интеграционных тестов. Соответственно связки Expecta + Cucumber хватает для практически полного покрытия приложения тестами.
Пы сы. Вот на мой взгляд очень неплохие примеры протестированного кода. Эти репозитории стоит время от времени перечитывать до просветления, так как в них можно найти решения практически всех типовых задач — тестирования контроллеров, тестирования функциональных модулей, асинхронность, тестирование нетворкинга, моки.
1. Facebook iOS SDK — тут мало юнит тестов, но много моков и интеграционных тестов
2. Eigen — этим проектом вообще стоит поинтересоваться с точки зрения организации кода и рабочего процесса, невероятно ценный репозиторий
3. РАК — просто замечательно протестированный код.
P.P.S автору рекомендую подумать над тестированием Swift-кода в качестве умственного эксперимента — тестировать код без нормального мокирования гораздо сложнее и гораздо больше способствует самодисциплине в организации кода. Моки в этом плане в Objective-C немного расхолаживают программистов
О, НГУ это здорово :-) Да и то, что людей из индустрии привлекают — тоже здорово. Поздравляю с хорошим и правильным образованием :-)
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях)
Нам тоже такого не давали, а ведь, на минуточку, МГУ и все-такое. В России тоже с computer science все довольно таки плохо. И я, наоборот, очень рад, что есть факультеты, где такое рассказывают, чем печалюсь обратному.
А еще. А еще у меня есть стойкое подозрение того, что есть некоторые концепты, которые можно реально понять только лишь собственной болью. SOLID — один из них. Вообще, это довольно таки поздний концепт, по моему мнению. По крайней мере я не знал людей, которые начинали писать действительно SOLID код до тех пор, пока они не начинали писать грамотные тесты, пока они не осваивали методологий разработки(в боевой обстановке, ессно), как например Code-Review и так далее. Так что в университете о них, конечно, рассказывать, прикольно, но рано. (Если вы, конечно, не про MIT)
Хотелось бы вставить свои 5 копеек — очень популярно сейчас говорить «прикрутите статистический модуль в начале разработки».
1. Крэш-аналитика однозначно нужна на первом этапе. В этом плане от себя могу порекомендовать HockeyApp — у них есть отличный клиент, облегчающий работу с крэшами. И в хороших деплоймент-скриптах навроде fast lane есть интеграция с этим сервисом в отличии от Яндекс.Метрик
2. Статистика же использования сама по себе абсолютно бесполезна до понимания двух вещей:
-Статистика до 5-10к пользователей попросту нерепрезентативна
-Покрывать приложение статистикой «авось пригодится» рано или поздно приводит к тому, что выдача статистики становится бесполезной и ненужной — крайне рекомендую перед тем как включать сбор статистики — написать на отдельной страничке — а что вы, собственно, хотите узнать. Набор гипотез, которые вы хотите проверить — и уже для этих гипотез формируете минимальный набор лог-ивентов, которые позволяют разделить все гипотезы.
Ничем не лучше — синглтон — он и есть синглтон — и это громадный недостаток PureMVC, однако несмотря на обилие способов приготовить его неправильно — приготовить правильно его возможно. И вызов этих самых «синглтонов» при правильном приготовлении увеличивает связность не более чем обычный Объектно-ориентированный код
Согласен, о чем и написал в статье — промисы — это более узкий пример реактивного программирования и работы с потоками данных. Этот фреймворк полезен тем, что позволяет сконцентрироваться на более узкой области прежде, чем переходить к более фундаментальной ReactiveCocoa.
К сожалению, я лентяй :-(
И с одной стороны, вроде, набрался приличный набор знаний, которые можно шарить с разработчиками, а с другой стороны недостаточно мотивации для того, чтобы разобрать их все в максимально подробной форме. Поэтому, по итогам этой статьи я бы хотел еще и определить для себя — на чем сфокусироваться в будущих статьях.
Спасибо за отзыв :-)
Ну и да, еще раз, во всех разобранных проектах есть просто изумительная документация с множеством примеров использования. Моей задачей было среди огромного множества наработок в этой сфере — указать на те, которые по моему мнению заслуживают подробного изучения.
В целом я с вами согласен, PureMVC — неслабое такое испытание для неокрепшей психики.
Однако
1. На околоигровые проекты, ориентированные не на UIKit, а, например на Cocos 2D он ложится чуточку лучше.
2. Пожалуй это одно из основных достоинств ПурМВЦ — что он позволяет говнокодить ГОДАМИ и при этом иметь приемлемое время на внесение изменений.
То есть на мой взгляд — это архитектура, которая очень подходит, когда приложение «ищет себя» и готово меняться много-много и часто. Когда спецификациюю начинают быть немного более надежными, его имеет смысл максимально локализовать, или вообще убрать из проекта.
P.S. ваш пример говнокода не очень-то Pure-MVC специфичен) обычный антипаттерн God-Class — класс со слишком большим количеством ответственности)
P.S. небольшая личная рекомендация — избавляйтесь от автоимпорта во всех его проявлениях. Честный Dependency injection и жесткий контроль за зависимостями класса — делает код значительно более поддерживаемым и стабильным, удобным для тестирования.
Набивание руками импорта — просто еще один шаг подумать над тем — а так ли тебе нужно вызывать этот класс именно в таком виде именно тут.
фортранеджаве на любом языке может писать нафортране?А если по теме — то если у нас сущность подписывается на изменение одного поля в модели — то зачем тянуть наблюдение за остальными? (пусть даже на уровне протокола)
А если на изменение нескольких — то не проще ли (и не чище ли) подписываться на изменение объекта модели в целом?
Большинство приведенных в списке языков имеют такое большое число по одной очень простой причине — новички крайне редко пишут на Go, Rust, Haskell,… зато много пишут на Ruby, JS, C++, Java, C#,…
Вот если на Go появится много вакансий по миру, в него придут джуны, в общем, в случае успеха — через 5 лет можно будет еще раз посмотреть на эту метрику.
Говоря же о других метриках, по моему субъективному ощущению количество кейвордов говорит о том, что
1. Сколько же в этом языке кейвордов (удивительно)
2. К насколько широкому классу задач стараются приложить этот инструмент
3.… Привнесенная сложность
Да, Го действительно прост, но, на мой взгляд, он пока еще не прошел испытания злобным продакшеном в полной мере и хотя бы 3-4 мажорных версий. Возможно низкая сложность языка является следствием не окончательного понимания предметной области, не полной «вынужденной сложности»?
На данный момент ГО нерепрезентативен для таких вот исследований и его данные будут врать. Возможно даже в разы.
Увидел здесь множество своих граблей, преодолеть которые, в отличии от вас, мне не хватило мотивации в свое время. Однако после вашей статьи я теперь знаю, что вернусь к незаконченному проекту и попробую еще раз. Возможно даже с нуля.
Спасибо вам :-)
А вообще — для стартапов решают языки, с большим количеством стабильных и удобных third-party и прочих building blocks — чтобы стартаперы не столько писали очередной oauth-client или еще что-то такое — а просто собирали из кирпичиков свой Proof Of Concept — который, в случае успеха, и можно будет начать переписывать на более подходящем для этого языке.
Но, к слову, Го действительно хорош и приятен в мире, где third-party менее важны
1. Они лучше представляют себе доменную область
2. Они имеют большую экспертизу в области
3. Они имеют больший ресурс на маркетинг
4. Они имеют более квалифицированных программистов, способных создавать более предсказуемые и сопровождаемые продукты
5. Они принимают более правильные решения
…
101. Они пишут на Go, а вы — нет.
Пример — в приложении, сильно зависящем от бэкенда можно симулировать цепочку ответов из некоторого записанного заранее файла и запустить этот процесс по кнопке в дебаг-панели.
Лаги UI — в самой простой реализации — просто запускает таймер в параллельном потоке, который время от времени интересуется — не повис ли главный поток больше чем на длину фрейма. Если повис — нотифаит об этом тестировщика/разработчика и можно сформулировать точный кейс, когда проседает FPS. В более сложной реализации можно заморочаться и получить стэктрейс главного потока при потере фрейма
А тестировать свой код надо. Почему надо?
1. Банальное сравнение. Для того, чтобы проверить свой код без тестов — вам надо запустить проект, дощелкать до нужного места (на одном из проектов, где я работал, это занимало порядка полутора минут), после этого проверить требуемый кейс. В то время как собственно тест займет в худшем случае секунд 15 (при правильной настройке окружения)
2. Более того мало у кого хватит терпения при таком раскладе проверить все возможные ветки исполнения кода (особенно, если это касается edge-кейсов, что программа работает корректно, когда что-то идет не так)
Так что предлагаю вам начать с простого. Настройте тестовое окружение и на любую чисто логическую функциональность напишите тест. В практически любой программе есть 1-2 чисто функциональных модуля, которые берут какие-то данные и что-то с ними делают. Да, поначалу это будет казаться довольно очевидным, но это пройдет довольно быстро :-)
P.S. посмотрите репозитории по ссылкам в комментарии ниже — там можно найти довольно много вдохновения по тестам.
Возможно, вы итак в курсе, но я бы предложил (например, читателям) поинтересоваться такой концепцией как BDD
В мире мобильной разработки она сейчас больше удовлетворяет нуждам. Под обжектив BDD фреймворком является expecta, как надстройка над specta
Под Свифт — это пара Nimble/Quick которая реализует примерно такую же функциональность.
Значительными преимуществами BDD перед TDD является включенное by-design описание тестовых сценариев, соответственно вернувшись к тестам через год, тебе по прежнему будет легко с ними работать. Кроме этого, BDD фреймворки захватывают помимо, непосредственно, юнит тестов еще и часть соседнего домена — интеграционных тестов. Соответственно связки Expecta + Cucumber хватает для практически полного покрытия приложения тестами.
Пы сы. Вот на мой взгляд очень неплохие примеры протестированного кода. Эти репозитории стоит время от времени перечитывать до просветления, так как в них можно найти решения практически всех типовых задач — тестирования контроллеров, тестирования функциональных модулей, асинхронность, тестирование нетворкинга, моки.
1. Facebook iOS SDK — тут мало юнит тестов, но много моков и интеграционных тестов
2. Eigen — этим проектом вообще стоит поинтересоваться с точки зрения организации кода и рабочего процесса, невероятно ценный репозиторий
3. РАК — просто замечательно протестированный код.
P.P.S автору рекомендую подумать над тестированием Swift-кода в качестве умственного эксперимента — тестировать код без нормального мокирования гораздо сложнее и гораздо больше способствует самодисциплине в организации кода. Моки в этом плане в Objective-C немного расхолаживают программистов
Но общего тезиса это не отменяет. Знание правильных концепций без правильного опыта приводит к очень разнообразным и интересным ошибкам. Видел довольно много кода, который порочит концепции паттернов, ООП, ФП и другие.
Вообще, все больше прихожу к необходимости групповых дипломов на IT специальностях)
А еще. А еще у меня есть стойкое подозрение того, что есть некоторые концепты, которые можно реально понять только лишь собственной болью. SOLID — один из них. Вообще, это довольно таки поздний концепт, по моему мнению. По крайней мере я не знал людей, которые начинали писать действительно SOLID код до тех пор, пока они не начинали писать грамотные тесты, пока они не осваивали методологий разработки(в боевой обстановке, ессно), как например Code-Review и так далее. Так что в университете о них, конечно, рассказывать, прикольно, но рано. (Если вы, конечно, не про MIT)
1. Крэш-аналитика однозначно нужна на первом этапе. В этом плане от себя могу порекомендовать HockeyApp — у них есть отличный клиент, облегчающий работу с крэшами. И в хороших деплоймент-скриптах навроде fast lane есть интеграция с этим сервисом в отличии от Яндекс.Метрик
2. Статистика же использования сама по себе абсолютно бесполезна до понимания двух вещей:
-Статистика до 5-10к пользователей попросту нерепрезентативна
-Покрывать приложение статистикой «авось пригодится» рано или поздно приводит к тому, что выдача статистики становится бесполезной и ненужной — крайне рекомендую перед тем как включать сбор статистики — написать на отдельной страничке — а что вы, собственно, хотите узнать. Набор гипотез, которые вы хотите проверить — и уже для этих гипотез формируете минимальный набор лог-ивентов, которые позволяют разделить все гипотезы.
И с одной стороны, вроде, набрался приличный набор знаний, которые можно шарить с разработчиками, а с другой стороны недостаточно мотивации для того, чтобы разобрать их все в максимально подробной форме. Поэтому, по итогам этой статьи я бы хотел еще и определить для себя — на чем сфокусироваться в будущих статьях.
Спасибо за отзыв :-)
Ну и да, еще раз, во всех разобранных проектах есть просто изумительная документация с множеством примеров использования. Моей задачей было среди огромного множества наработок в этой сфере — указать на те, которые по моему мнению заслуживают подробного изучения.
Однако
1. На околоигровые проекты, ориентированные не на UIKit, а, например на Cocos 2D он ложится чуточку лучше.
2. Пожалуй это одно из основных достоинств ПурМВЦ — что он позволяет говнокодить ГОДАМИ и при этом иметь приемлемое время на внесение изменений.
То есть на мой взгляд — это архитектура, которая очень подходит, когда приложение «ищет себя» и готово меняться много-много и часто. Когда спецификациюю начинают быть немного более надежными, его имеет смысл максимально локализовать, или вообще убрать из проекта.
P.S. ваш пример говнокода не очень-то Pure-MVC специфичен) обычный антипаттерн God-Class — класс со слишком большим количеством ответственности)
Набивание руками импорта — просто еще один шаг подумать над тем — а так ли тебе нужно вызывать этот класс именно в таком виде именно тут.