Оффтоп _Программинг

Описание: Офф-топы, юмор, поздравления, радости и печали.

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 22
Сообщения: 4107

#141 ADF » 21.08.2019, 11:53

Смотри. Тут очень много аспектов, моментов и нюансов. Попробую по порядку:

1. С точки зрения себя и своих умений, надо пробовать всё. Т.е. устанавливаешь и реально пробуешь что-то на этом сделать!
2. Если встаёт вопрос об анализе самой технологии, то надо иметь достаточный опыт, надо владеть хоть какими-то другими технологиями, чтобы иметь возможность сравнивать лично. Потому, что в каждом языке и в каждой среде есть 100500 нюансов и рекламщики тебе совершенно точно не расскажут про недостатки и подводные камни, с которыми ты будешь ебаться, если начнешь на (любой) новой для себя технологии работать. А косяки и проблемы, как говорит мой личный опыт, есть в любых технологиях: я пока ещё не видел ни одного языка программирования без ошибок в его проектировании (кроме brainfuck).
3. Есть такое понятие, как взрослость технологии. Насколько она стабильна для реальных проектов, особенно для крупных и долгоживущих (в том числе, не умрет ли язык и его поддержка через 3-5 лет), насколько полноценно там поддерживаются разные возможности платформ, куда этот язык собирается. Насколько много к этому языку готовых библиотек и фрэймвёрков. Насколько стабильно и наскллько одинаково оно работает на разных платформах и устройствах? Многим языкам/технологиям потребовались годы и даже десятилетия прежде, чем они стали "взрослыми". А что на какой-либо новой/малоизвестной хернюшке сбацали что-то крутое - не пркпзатель, а иногда и вовсе тупая реклама. Надо смотреть на картину в целом: как массово эту штуку применяют, как много на ней крупных и долгоживущих проектов.
4. Скорость работы кода. Сама по себе, в отрыве от конкретных решаемых задач, не значит буквально ничего. Да и во всех ли случаях код быстрее? Насколько велика разница в производительности? По факту, очень редкие задачи в приложениях требуют максимальной пооизводительности, т.е. производят хоть какие-то обьёмные вычисления. Зачастую, вычислений нет вовсе, только тупая обработка пользовательских событий. А вот "взрослость" технологии - чтобы работало везде одинаково, чтобы была поддержка и уверенность в будущем, вот эти вещи почти всегда оказываются решающими при реальной разработке.
5. Кроссплатформенность - вообще не преиммущество в 2019 году, так как есть практически во всех современных языках-технологиях. И всё опять упирается в то, насколько стабильна конкретная технология, насколько одинаково работает на разных платформах и все вот это.

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 23
Сообщения: 4701

#142 Сергей » 21.08.2019, 12:57

Про скорость не согласный. Если так подходить - то получится как в той статье, которую ты как-то тут уже приводил, где телевизор две минуты включается. И вообще что до андройда - это же глупость, взять ядро линуха и вкорячить туда джаву с ее виртуальной машиной. Возможно взгляд несколько дилетантский, но факт остается. Это как типа на ноде писать приложения для десктопа. А чего?, работает же. И все более менее современные компы это тянут. И я например как проггер js могу и сайты делать и на полставки приложения для десктопа. Условно. И никому не интересно, что там внутри браузер зашит, который тебе по факту сайт демонстрирует, вместо того чтобы с железом напрямую работать и контролы рисовать. А для чего джаву в андройд включили не совсем ясно, наверное дань моде, а может оракл старался. Ну и потом я не совсем голословен. У нас в компании митапы бывают нередко, там про флаттер было как-то. Правда больше с react-native сравнивалось.
Все вышеописанное является моим мнением и моим оценочным суждением. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 22
Сообщения: 4107

#143 ADF » 21.08.2019, 14:41

Частично повторюсь:

0. Интересно - пробуй, пробовать разное - нужно и полнзно!

1. Джаву в андроид очень не зря "вкорячили". Это во-первых безопасность на уровне дизайна системы (к сожалению, безопасность андроида нарушена другими путями, но это другая история), во вторых - джава это далеко не плохой вполне современный ЯП, отодвинутый от железа. А разделение от железа очень полезно: заставляет тебя, как разработчика, не думать, как поддерживать каждую железку, а лишь писать значимую часть кода. И программа везде, где есть ВМ джавы, будет одинаково работать. Это очень хорошо. Это то, к чему вся индустрия шла десятилетия!
2. Скорость выполнения джавы, с учетом всех этих jit, уже давно как сравнима со скоростью нативного кода. Это не является узким местом, технология хороша.
3. Теперь про скорость выполнения кода: реальное узкое место, почему всё тормозит, не потому, что выбраный ЯП / технология недостаточно быстры, а потому, что низкоквалифицированные программисты пишут так. И тестируют лишь на своей супер-мощной современной машине, замечая тормоза только тогда, когда даже у них будет раком вставать. В коде 100500 зависимостей, выполнение тонн бесполезного кода под капотом выбраного фрэймвёрка и т.д. Делай больше руками, не подключай всё подряд - и программа будет быстрой и легковесной!

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

...
Рисовать напрямую контролы - ты их все равно через какое-то апи будешь рисовать, ты уверен, что это напрямую?!
А если именно напрямую, т.е. писать байты в графическую память, то твоя программа будет работать ровно на одном устройстве, под которое написана...

Добавлено спустя 30 минут 59 секунд:
И ещё информация для размвшлений.

У гугла - много технологий, было и есть. И этот flutter - далеко не первый яп от гугла. Никто не знает, где он будет через, допустим, пять лет и будут ли о нем вообще помнить. :pardon:

Вопрос для самопроверки: назовите другие языки программирования от гугла, которые вы знаете. :drink:

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 22
Сообщения: 4107

#144 ADF » 01.10.2019, 21:02

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

Но из всего многообразия, в последнее время посоветовали игру - https://store.steampowered.com/app/375820/Human_Resource_Machine/

Вроде как и на русском есть. Так что у кого есть ребёнки возраста 9+ и кто хочет замучить приобщить их к программирвонью - советую. :drink:

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 22
Сообщения: 4107

#145 ADF » 08.10.2019, 23:06

(немного скучных буков)

В последние месяцы стал углубляться в тему паттернов, архитектур и практик. Путём чтения выбраных книг. И возникли кое-какие мысли (ни в клем случае не претендую на внезапную новизну и 100% правоту, но...).

1. Сами по себе паттерны и архитектура - это попытка описать недостижимый в реальных проектах идеал. Но сам по себе этот идеал не описывает процессы и не гарантирует результат. Хотя-бы потому, что вначале никогда не известны все требования, цели и задачи (и хотелки пользователей) меняются по мере развития проекта. ВСЕГДА.

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

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

4. Не всегда можно сразу знать все подходы и принципы, но полезно знать типовые опасности: грани той ЖОПЫ, куда может скатиться проект. И крайне желательно, чтобы в коллективе разработчиков это понимали все, вплоть до джунов. Впрочем, код-ревью требуется все равно, особенно если джуниор что-то там с энтузиазмом кодил по 100500 знаков каждый день. :shok:

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 23
Сообщения: 4701

#146 Сергей » 08.10.2019, 23:38

1. Основное это практики и принципы и как следствие архитектура, которая получается соблюдением их думаю. А паттерны это на вроде инструментов для достижения цели -они могут быть хорошими или нет, могут подходить к конкретной работе или нет, просто их надо применять с умом. И как раз приложение и становится поддерживаемым и масштабируемым благодаря этому. Понятно что все меняется, но всякие хотелки свистелки и перделки - это уже отдельный разговор, и если приложение спроектировано с учетом бизнес-целей, которые решает заказчик заказываемым продуктом и договор составлен и подписан, то все дальнейшее - это уже новая работа, радуйся, ты голодным значит не останешься. И насколько приятна будет эта работа и решается на стадии проектирования, когда создается та самая поддерживаемая и масштабируемая архитектура.
2. Эти подходы и есть принципы и практики, и мне лично кажется, что скажем условные лет 50 последних они достаточно известны и особо не меняются. Какие-нибудь принципы MVC и разделение ответственностей скажем. MVC с 70 годов прошлого века скажем.
3. Согласный. Хорошо хоть у нас руководители сами прогеры и могут позволить себе выбирать клиентов.
4. Тоже согласный. И эти твои типовые опасности и есть обратная сторона всяких практик и принципов, которые уже лет 50 не меняются. Ну и тут опять же от руководства многое зависит, насколько оно понимает необходимость постоянного обучения своего персонала. А код-ревью для джунов это один из инструментов роста. Хотя и не для джунов только, но и для компании. И вообще без код-ревью на постоянной основе IT-компания уже не компания, а шарашка.

А вообще на мой взгляд в погоне за баблом у нас не редко в компаниях как раз таки стадию проектирования и пропускают или делают очень поверхностно. И тут один из корней всех зол и кроется. И первый тут шаг - понимание руководством компании важности этой стадии и как следствие второй шаг - убеждение руководством заказчика в этом.
Все вышеописанное является моим мнением и моим оценочным суждением. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 22
Сообщения: 4107

#147 ADF » 09.10.2019, 21:57

Смотри. MVC - он-то конечно с 70-х годов, но тогда он был практически единственным и, возможно, первым паттерном вообще. Полноценно паттерны застолбили своё место в разработке только с выходом книги от "банды четырёх", это начало 90х годов. И то, поначалу там не всё правильно было описано. Например, тогда ещё не понимали, что допустим синглтон - это АНТИпаттерн и использовать его следует крайне осторожно.

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

Проектирование - это не какая-то отдельная стадия, это то, что должно происходить постоянно, наравне с рефакторингом и анализом.

Но это все лирика и попытки залезть в философию :pardon:
Более призёмленно, интересно рассматривать конкретные подходы и типовые ситуации, приводящие к геморрою в проектах. Личная подборка жареных примеров (из того, с чем сталкивался лично).
1. Глобальный стэйт / синглтон, жиреющий бесконтрольно. Изначально был создан, видимо, для каких-то очень конкретных вещей - например хранить айдишник сессии на клиенте и прочее такое, но позже стал использоваться для "удобного" прокидывания данных между частями программы. Чтобы не менять сигнатуру метода, дополнительные параметры взяли и хуйнули в глобальный стейт, видимый отовсюду...
2. Бесконтрольное использование событий / сигналов, особенно у мелких низкоранговых сущностей. Некотролируемый ад из спагеттин, которые даже увидить невозможно. Регулярный race condition и вообще изначальная непредсказуемость последовательности выполнения разных частей кода.
3. Ещё один вариант получения спагетти кода: была функция foo(a, b). Понадобилось добавить туда ещё один параметр, c. Но функция уже используется в 100500 местах проекта! Программист знает, что делать как в п.1 - плохо. И вместо этого берёт и изменяет функцию один раз, но с заделом на будущее: foo(a, b, other_params[]). И вот этот самый злоебучий массив вскоре превращается в помойку с торчащей во все стороны лапшёй.
4. База данных! В таблице нехватает поля, но переделывать базу данных и код, конечно-же, лень. Стиснув булки, программист всё-таки делает ещё одно поле типа text и захуяривает туда json или xml с произвольными данными, а иногда даже с кусками кода. Куда позже сра достью начинают добавляться новые произвольные данные, кому что захотелось.

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


Вернуться в «Обо всём»

Кто сейчас на форуме (по активности за 5 минут)

Сейчас этот раздел просматривают: 1 гость