Короткая статья о методах и их оформлении. Данная часть стандартов направлена на людей в разной стадии понятия дзена программирования. Людей, которые находятся в стадии эксперимента на уровне написания самого кода внутри методов, обработчиков и свойств. Их, абсолютно также, как и во время именования переменных, можно написать так, что другие программисты понимать не будут. Поговорим об этом…

Количество строк в методах.

Некоторые программисты целенаправленно делают вместо 10 методов по 100 строк, 200 методов по 10 строк, искренне считают, что это хорошо. Суть в том, что разбитый на такие мелкие части код легче тестировать, когда у Вас в команде есть тестеры, и вероятно в больших коммерческих проектах это чистое благо. Однако. Имея в команде пару человек, которые не будут за Вами писать тесты, это ЧИСТОЕ ЗЛО.

Некоторые программисты, кто делает вместо 10 методов Один, также искренне полагают, что это круто. Используют тонну синтаксического сахара, вызовы методов в методах и прочее… Это в свою очередь вызвано юношеским максимализмом и увлечением языками вроде Питона, что провоцирует людей на эксперименты с сахаром. Добавляя такое в проект, Вы также наносите ему непоправимый ущерб.

Каждый коннектор в OsEngine должен (в итоге, а тем более новые) содержать определённый набор регионов. В которых должны располагаться определённые методы, свойства и обработчики.

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

1. Регионы должны быть отмечены номерами.
2. Безномерные регионы не допустимы.
3. Их должно быть минимум 10 штук. Максимум 20. Но постарайтесь разместиться в стандартных!
4. Код вне региона не допустим.

Далее, каждый регион будет показан на примере коннектора к бирже криптовалют BitGet, расположенном в проекте вот здесь:

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

Поддержка колоссальная. За что сразу ОГРОМНОЕ, ДУШЕВНОЕ СПАСИБО!!!

Но обо всём по порядку.

1. Скорость набора рейтинга УДВОИЛАСЬ.

Именование переменных нормальным языком – важнейший признак уважения к другим программистам. А первый признак неуважения одного программиста к другому – запутанные названия переменных.

Можно было бы просто сказать, следи за тем, что пишешь. Пожалуйста обращай внимание на переменные. Но это не наш метод)

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

Обфускация кода.

Процесс запутывания названия переменных и методов с целью недопущения использования этого кода другими программистами.

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

Если Вы хотите, чтобы код был нечитаемый и не был никем переиспользован, Вы должны дать вашим методам, переменным, событиям, etc… нечитаемые названия.

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

Заканчиваю интеграцию робота арбитражника для фьючей на коммодитиз (Москва/Китай) для очень крупной компании экспортёра в РФ.

И вот, значит, вечер. Я и Топ менеджер, только что вернувшийся с выступления Путина. Стоим и смотрим на Москву сверху вниз, из его нескромного офиса.

– ты когда уедешь, может посоветуешь мне программиста на поддержку?

— эээ. Давай лучше я буду поддерживать пока. Посоветовать мне некого.

Большой алготрейдинг — это тебе не питонирование.

Чтобы участвовать в чём-то таком, знания Метатрейдера, ТсЛаб или Питона недостаточно и даже бессмысленно (вредно). Подключая вторую ногу из Китая, пришлось написать 2 тыщи строк кода на С++. Сделать сервер на С++ и связать его с клиентами на СиШарп. Всё это очень сложно и может быть сделано только настоящими программистами. Т.ч. учите СиШарп и то, как делать к OsEngine коннекторы. Иначе в Москва-сити не попасть.

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

Запрет на создание полей и свойств для объектов во время создания объекта.

 
Рис. 1. Как не надо создавать переменные. 

Подобный способ создания класса приведёт к следующим проблемам:

1)      В случае перехвата ошибки отладчик не будет указывать на строку проблемы.

2)      В случае пошаговой отладки невозможно будет определить быстро, в каком месте какая переменная откуда берётся, и где кроется ошибка.

3)      В данном конкретном примере также возникнут проблемы с выбором некоторых перечислений, т.к. вариантов несколько, а использовать адекватно IF с отладкой не выйдет.

Девятого числа, в субботу собирается наше сообщество. Встречаемся в офисе АЛОР. Продолжаем в баре на Шаболовке. Подробности можно прочитать здесь: https://smart-lab.ru/company/os_engine/blog/965467.php

Билеты за 2.5 т.р. закончились в течении суток. Мне жаль, но полноформатную конференцию мне организовывать в данный момент некогда. Не раньше следующего лета. Надеюсь на понимание.

Остались следующие виды билетов:

-  4 благотворительных за 20 т.р. С которых 85% суммы будут переданы в «Динской социально-реабилитационный центр для несовершеннолетних»

—  1 мегаблаготворительный билет за 100 т.р., 97 % от цены которого будут переданы в «Динской социально-реабилитационный центр для несовершеннолетних»

Друзья. Я в Вас верю.

Появилось ещё одно внезапное правило: На входе, придётся подписать договор о неразглашении информации.

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

Сегодня поговорим про месторасположение конечной логики коннектора. То место, где надо написать 98% кода, когда делаешь новый коннектор. Это класс ServerRealization.

Вновь возвращаемся к упрощённой схеме работы с конечной реализацией сервера:

1. Это часть AServer.

Первое, что надо создать в конструкторе любого коннектора, это IServerRealization. Класс с конечной логикой коннектора:

Сегодня поговорим про разницу между IServer (интерфейс) и AServer (абстрактный класс) внутри Os Engine. Зачем они в проекте и как появились?

Это часть серии постов «Коннекторы к OsEngine», в которой мы с нашими читателями учимся быть не просто алготрейдерами, но и настоящими программистами, а многие из них станут ими, навсегда, изменив свою жизнь к лучшему.  Пролетарии СмартЛаба, присоединяйтесь!

Упрощённая схема работы с конечной реализацией сервера из любого робота в OsEngine:

1 IServer.

IServer – интерфейс для доступа к реализациям серверов почти во всём проекте. Нужен для того, чтобы унифицировать методы и свойства, нужные для роботов и OsData.

Проект OsEngine открытый и публичный. Так вышло, что многие его части писали разные люди. И дальше будет больше кода, написанного разными людьми.

Разные люди пишут код совершенно по-разному. Если Вы читаете это до того, как стали «крутым» программистом, возможно это звучит странно, но поверьте, всегда есть от 10 до 100 способов справиться с задачей.

Данная серия постов, «стандарты написания кода», призывает всех тех, кто занимается созданием кода в проекте, соблюдать определённые правила.

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

Как писалось ядро OsEngine.

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

Ядро это:

1. Примитивы;
2. Слои совместимости;
3. Слои инверсий зависимостей для интеграции расширений в будущем;
4. Слои создания роботов;
5. Источники для слоя создания роботов;
6. Слои создания индикаторов;
7. Слои тестирования функциональности модулей.