Еще на тему
Полиамория и дакимакуры
Популярные geek
 | it-юморРейтинг: 99,609.0 |
 | программированиеРейтинг: 16,745.0 |
 | geek pornРейтинг: 2,854.0 |
 | матанРейтинг: 2,576.0 |
 | Приколы для математиковРейтинг: 1,900.1 |
Сейчас на сайте
Всего пользователей на сайте: 1922
Сейчас можно на чём угодно, что угодно писать.
Я утрирую, но чаще всего так и бывает.
И вот в таком разбираться без типизации - это лучше сразу отправиться за тем архитектором в дурку.
Всё равно придётся начать писать е2е тесты, юнит тесты, рефакторить, внедрять внятный линтинг(sonarjs, complexity, max-statements, unicornjs) и код ревью.
Иначе придётся разбираться не только в уже существующей каше но и как натянуть тайпскрипт на говнокод. Тогда уже можно в дурку.
Разбираться в чужом коде на порядок сложнее чем писать с нуля, но этому всё равно придётся учиться как ни крути.
Текущий проект и маленький дашборд с D3 до этого писал сам, покрытие тестами 95%, не считая е2е, каждый кусок кода рефакторился 1-2 раза.
Я просто представил себе кровавый энтерпрайз на жабаскрипте, и ужаснулся.
- Тестов может вообще не быть, и оно как-то работает
- Тесты есть но тестирует то что легче тестировать, а не то что важно для проекта, т.е. размер шрифта именно 16 пикселей тестируется, а то что компонент/страница в целом вообще работает нет.
- Тесты могут быть чисто для виду, т.е. они не краснеют когда что-то перестаёт работать.
- Могут быть только юнит тесты с кучей моков, ломаются часто, но мало что гарантируют
- когда сам пишешь и сам тестируешь... важен результат. Никто на стандартизацию тестов, подробной справки тратить время=деньги не будет. Обычно "мало работающая" альфа версия устраивает заказчика на пару лет.
- когда команда до 6 рыл. Тесты формальны - написаны на парочке листов А4. Упарываются обычно по написанию подробной справки для людей с IQ менее 20 из 150. Там Программное Обеспечение 1 Мбайт и к нему 20 Мбайт справка с картинками и пару гиг роликов.
- когда команда более 6 человек то стандартизация наше ВСЁ - причём стандарты не какие модные, а в какие умеют конкретно взятые люди, а то и свои вводят(обозвав новомодным словом).
Все возможные баги начинаются когда код становится излишне запутанным/нечитаемым. Слышал наверно про Биг О и что это значит.
Особенности языка на котором кодишь должен знать, для JS это приведение типов, this и прочее.
Тесты в этом плане на порядок полезней, минимум на 40% уменьшит количество багов. Плюс можно учиться и рефакторить.
Хуй его знает, как понимать, даже какие поля в этом объекте, если не видеть описание объекта сходу.
Писать что-то не вникая что это делает и как в любом случае плохая идея, только сделает энтерпрайз чуточку кровавей.
И да, 50+% времени в энтерпрайзе ты код не пишешь, а читаешь. Написанный тысячами разных людей в разное время, большинство из которых уволилось, а некоторые и умерли. Основанный на библиотеках, последнее обновление которых датируется 2009 годом. Спроектированного разными людьми с разными подходами.
Маленький, свежий проект, который может охватить один или несколько человек, стерпит всё, даже нетипизированность. В крупном проекте на миллионы строк, который старше некоторых текущих разработчиков, и который один человек не может знать весь физически, совсем другие правила.
В среднем проекте под конец всё упёрлось именно в сложность, неочевидные зависимости и то что не вникали в то как работают стороние библиотеки, в результате гвозди забивались микроскопом, ситуация когда меняешь в одном месте и ломается в другом.
Сложно, но с е2е тестами вникал и рефакторил. Разгрёб кашу в нескольких местах, но так и не закончил, появились проекты поважнее.
Суть в том что система в целом может быть сложной, но каждый отдельный компонент должен быть понятным и должен быть единый подход как связать это всё в единое целое.
А если тупо добавить в кашу ещё и ТС то будет чуть удобней разбираться, но в долгосрочной перспективе код продолжает становиться хуже как и ситуация.
И по-другому не бывает, потому что ни один бизнес не даст времени на переписывание и оптимизацию всего проекта. А переписывание маленьких кусков в 9 из 10 случаев кончается тем, что в прокте теперь две версии одного и того же, старая и новая, и тянуть надо обе.
Ещё одна правда жизни в том, что большинство кода в таких проектах тебе просто достается как есть, ты не выбираешь, каким он будет. И это может быть как лютое говно, так и вполне правильно спроектированный кусок. Или сразу и то, и другое, когда спроектированно хорошо, но из-за ебанутых требований, появившихся позже, обложено тысячью костылей.
И это, несмотря ни на что, работает, и дописывается. Без типизации это было бы тупо невозможно (точнее, возможно, но настолько дорого, что проще выбросить).
Очень большие проекты будут распадаться на модули и микросервисы.
"И по-другому не бывает, потому что ни один бизнес не даст времени на переписывание и оптимизацию всего проекта"
На текущем месте дают. 2 недели на рефакторинг сейчас сэкономят 2 месяца в будущем, но не все это понимают.
"Я тебе пытаюсь сказать, что в большом проекте всегда будет много говна."
Зависит от компании и кодеров, не всегда и не везде жесть в виде кровавого энтерпрайза.
"Или сразу и то, и другое, когда спроектированно хорошо, но из-за ебанутых требований, появившихся позже, обложено тысячью костылей."
Если спроектировано хорошо то должно быть достаточно гибким, если требования сильно изменились то нужно переписывать.
Стремление по-быстрому решить что угодно с помощью костылей/типизации и делают энтерпрайз кровавым как мне кажется.
Нет прямой корреляции между типизацией и качеством кода или количеством багов, да багов может меньше на 3-5%, но цена за это велика и это не решает основную проблему.
- Код становится сложнее читать, больше бойлерплейта. Может в случае с лапшой ТС как-то помогает, но это постоянно расходует время и силы. В один момент можешь держать в голове очень ограниченное кол-во вещей
- Типы/интерфейсы тоже могут быть кривыми и с ними придётся разбираться, это тоже время, практически дублируешь код на ещё одном уровне
- Скорость компиляции
- Даёт ложное чувство что если типизация строгая то код хороший и багов быть не должно. Качество архитектуры проверяется когда меняются требования, а баги чаще из-за логики, подхода и незнания языка/библиотеки а не из-за типов
- Гибкость кода страдает, код становится сложнее менять/рефакторить
Пробовал в своё время и тайпскрипт и флоу(та ещё гадость), не увидел особых плюсов.
Нормальные тесты для сравнения даёт огромный эффект, вопрос жизни и смерти. Хотя их тоже муторно осваивать и писать.
И вот как раз когда типы прописаны явно - тебе не приходится держать их в голове.
> Скорость компиляции
Ну и что, что в рантайме распидорасило, вместо того, чтоб на этапе компиляции упасть. Главное, что быстро.
> Даёт ложное чувство что если типизация строгая то код хороший
Какие странные фантазии...
> Гибкость кода страдает, код становится сложнее менять/рефакторить
Ровно наоборот
А мне и не надо, по названию функции/переменной я знаю что там за данные могут быть.
"Ну и что, что в рантайме распидорасило, вместо того, чтоб на этапе компиляции упасть. Главное, что быстро."
Для этого есть тесты, QA и настроенный CI.
"Какие странные фантазии..."
Главное что типы прописаны, а то что там лютая жесть, поддерживать, которую боль это не важно.
Осталось доказать корреляцию строгой типизации с количеством говнокода и задачу о натягивании совы на глобус можно считать выполненной.
Нанимают 5-10 джуниоров -> они пишут лютую лапшу -> появляются баги и становится сложно поддерживать -> пытаются исправить налепив сверху ТС.
Там где много джуниоров, нет внятной культуры ревьювить код, тестов и прочего и вероятно текучка кадров там тайпскрипт сильно пригождается.
Выход проще не работать на таких галерах.
рассказывает охуенные истории что на жсе бекенд писать можно
в конфе сидят еще 2 бекендера и тиха ржут
ты его брат чтоле?
Бэкендеров с 10 летним опытом и руками из задницы тоже видел, могут ржать сколько угодно.
Можно посочувствовать твоему знакомому.
Ты этого конечно делать не будешь т.к. будет заметно что кроме заявлений ничего показать не можешь.
Мухахахахахахаха!
Вот ты явно не видел даже средних проектов, на каких-нибудь всего пару сотен тысяч строк.
Обычно в переменных не простые типы, а объекты, ебучие деревья объектов. Потому что бизнес-сущности сложные, и если не паковать их в объекты, мы получим тысячи переменных, такой трэш был до изобретения ООП.
Различных объектов в проетах сотни тысяч. И структуру каждого помнить физически невозможно.
Если бизнес логика отражается в таких "деревьях" а не в модулях/компонентах/архитектуре тут проблема не с типами. И поддерживать такое наверное ад.
На заборе "ХУЙ" написано, а за ним дрова.
Ровно, блять, наоборот. Сложный код без типизации читать радикально труднее, чем типизированный. А для простого кода похуй.
>- Типы/интерфейсы тоже могут быть кривыми и с ними придётся разбираться, это тоже время, практически дублируешь код на ещё одном уровне
Я нихуя не понял, что ты хотел сказать.
>- Скорость компиляции
Компиляция? А какие языки без типизации компилируемые?
И, скорее всего, будет ровно наоборот, если таки будет возможна компиляция. Ибо компилятору инфа о типах нужна, а значит, ему откуда-то надо её получить. А раз она не задана явно, компилятору придется типы выводить, и это всяко сложнее, чем прочитать заданные.
>- Даёт ложное чувство что если типизация строгая то код хороший и багов быть не должно. Качество архитектуры проверяется когда меняются требования, а баги чаще из-за логики, подхода и незнания языка/библиотеки а не из-за типов
Чистая демагогия.
Со строгой типизацией нет багов, связанных с динамической типизацией, и это не ложное чувство, это факт. Остальные баги одинаково возможны.
>- Гибкость кода страдает, код становится сложнее менять/рефакторить
Тут необходим пример.
Про SOLID, DRY, KISS что-нибудь слышал? Про то что большая задача дробиться на маленькие и код тоже делиться на небольшие модули/блоки как угодно.
"Сложный код" - вежливое название для говнокода.
Пока что везде где я видел "сложный" код его можно было отрефакторить до состояния когда понятно что и как он делает.
"Я нихуя не понял, что ты хотел сказать."
То что это нет так просто и очевидно как эти типы объявлять в разных ситуациях.
"Компиляция? А какие языки без типизации компилируемые?"
Правильней сказать транспиляция с ТС, сути это не меняет. Компиляция JS кода происходит Just-In-Time прямо перед выполнением, ТС типы никак на неё не влияют.
"Чистая демагогия.
Со строгой типизацией нет багов, связанных с динамической типизацией, и это не ложное чувство, это факт. Остальные баги одинаково возможны."
Каков процент этих багов?
Если в функцию прокидывается 10 аргументов или используются сложные объекты с вложенной структорой то это в любом случае ад и шиткод, это по-любому будет сложно поддерживать.
Тайпскрипт получается как такой фонарик на голову чтобы удобней было в кале ковыряться.
Можно раздробить код на миллион простых функций, но он от этого станет только ещё более сложным, особенно без типизации, ибо будет невозможно разобраться, какие именно объекты какая функция принимает. А в серверном коде, если ты пишешь бизнес-приложение, в 99% это сложные объекты с дохуя полей, отображающие реальные бизнес-сущности, и куча сопутствующих объектов, в которых есть ещё и логика. С простыми типами работы очень мало и редко.
Это же блять не UI, мы с самого начала про серверный код.
Не видел там ни "сложного" кода, ни вложенных обьектов, ни типизации. API возвращает кучу полей, разные сущности, но код в нормальном состоянии.
Пока что ничего не падает.
"ибо будет невозможно разобраться, какие именно объекты какая функция принимает. "
Мне кажется эта идея с объектами так себе.
На самом деле, ты говоришь про то, как лучше, а я - про то, как бывает.
Относительно новые проекты действительно спроектированы лучше, чем старые, да и идея раздельных микросервисов не просто так родилась.
А за копание в древнем говнокоде больше платят.
Вот и весь спор.
А за отсутствие интерфейсов/классов, описывающих объекты - надо увольнять сразу. Потому что опыт человек может еще приобрести, а от долбоебизма вряд ли вылечится.
Тесты ловят 40%-80% багов, типизация 3%-15%.
Не больше 15% багов
http://earlbarr.com/publications/typestudy.pdf
https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/
В таком случае действительно удобно, но сложные обьекты и наследование это практически антипаттерн.
Плохой код всегда сложно тестировать, хороший код - почти всегда на порядок проще, могут быть исключения но обычно так.
Про недостатки наследования много материала, я понимаю что ты провёл последние несколько лет в этом кровавом энтерпрайзе, но иногда стоит читать что-то для расширения кругозора.
https://en.wikipedia.org/wiki/Composition_over_inheritance
https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern
https://medium.com/@lord.peeve/inheritance-hell-4a17d6782f69
- На языке для браузера (JS)
- На языке для мобильных приложений (Java)
- На языке для игрушек (C#)
- На языке для анализа текста (Perl)
- На фреймворке для языка анализа текста (PHP)
- На бейсике (VB)
- На очень тормозном бейсике (Python)
А Паскаль - молодец! Нахуй никому не впёрся и даже не пытается.
Код там с вкраплениями ассемблера или шестнадцатеричного кода но он не на x86... а какой Гугл в помощь. И пойми что это. Я видел в одном институте сигнализацию из 80 годов так она реализованная на паскале была под проц типо двойки(2х86) и пару сот килобайт ОЗУ и задача перевести на более новое железо...полтора года люди делали...кто-то решил "сэкономить"...люди матерились но сделали почти за мин оклад(времена такие были). Потом выяснилось что таких модулей еще РАБОЧИХ по стране с 10 и туда всё портировали - труд не пропал.
А в чем именно, паскаль (осовремененный) хуже плюсов, кроме оценочного мнения?
Что именно он не может, что может С?
Я говорю не о каких-то экзотических кейсах, а про типовые решения для производственных задач.
Поддержка и реализация ооп - есть,
Полноценная работа с указателями, адресная арифметика, работа с ассемблером есть.
Многопоточность есть
Кроссплатформенность - есть. Интерфейсы, множемтвенное наследование и тд и тп..
Отсутствует синиаксический "сахар", на который все непрерывно дрочат последнее время?
Дык для компилируемых ЯП это вообще пох.
Ещё раз акцентирую - 90% задач, гле испольщуются ЯП - типовые, прикладные.
Что то более вменяемое, чем оценочное мнение, основанное на мемах и собственной безграмотности есть?
С такими предъявами ты пиздуешь нахуй, а паскаль с его бесящими заморочками, типа бегин-енд, и определения переменных в начале функции, которые хороши только для препода в институте, проверяющего лабу, на помойку.
Впрочем, вы с паскалем уже достигли этих целей, так что сидите тихо, и не выебывайтесь.
Благодаря таким ебанистически самоуверенным хуеплетам, сейчас в отрасли процветает полный пиздец с тоннами говнокода под видом современных технологий и очередных "философий".
Ты представляешь такую прослойку, которая не хочет думать, уметь и вникать, но всегда любят пиздануть чего, как им кажется, остроумного.
безопасность. в новых языках еблю с указателями стремятся минимизировать и выносить в явно помеченные загончики.
дженерики. ну и вообще более крутые системы типов.
интроспекция. твой код берет переданный ему тип, и смотрит, что с ним можно сделать. меняет алгоритм в зависимости.
метапрограммирование.
какие-нибудь асинк-эвэйты.
хреновее всего, что в паскале этого всего скорее всего уже никогда не появится. хотя даже плюсы в год по чайной ложке эволюционируют.
Все начинают с паскаля - есть готовые методики по выращиванию программиста... для иных языков нет - там самообразование.
нет ни единого преимущества для обучения новичков на паскале. в середине обучения придется подтягивать другие языки, на примере которых разбирать новые концепции, потому что там их тупо нет.
а если их не разбирать - это херовое обучение, оторванное от потребностей индустрии. или мы программировать учимся только для галочки?
есть языки для детей, визуальные, игровые.
для студентов уже лучше учить сразу что-нибудь из того, что они смогут применить для того же диплома.
"переводить на другие языки методики обучения ДОРОГО"
вообще-то всё уже есть, достаточно вытащить голову из задницы и оглядеться вокруг
потому что не настольео ёбнулись, чтоб на досовском паскале с 1Мб озу детец учить?
уж насмотрелся я на вас "продвинутых". заучиваете как мантры всякую ахинею без понимания происходящих процессов. Тысячи их. Насмотревшихся видосиков и онлайн курсов и т.д. и т.п.
следуя твоей логике детей надо учить сразу на горных лыжах финты крутить вместо постепенного обучения хождению.
ты думал это сработает? сразу все твой авторитет признают
дебил, бля!
Для прототипирования интерфейса десктопного приложения делфи/лазарус, наверное, вообще самый быстрый вариант.
[Небольшая поправка - если речь про ооп, то там не С, а плюсы]
Такие дела
Так и в посте речь про осовремененные ЯП
Сам пост вообще странный. Как можно сравнивать компиляторы с интерпретаторами?
Допуская, что не про физическую реализацию речь и базовые возможности (хотя это очень странно) сравнивать JS с C++ .. даже не знаю.
Я согласен с тем, что ООП - это немного про другое.
И в системных ЯП, важнее иные приоритеты.
.
> Потому что ФП
FP? C? WAT? :-)
шарп или котлин, имхо, где-то в середине спектра того, что есть. и ооп и фп затронуты. в обоих церемониал есть, но без фанатизма (когда его нет - тоже плохо)
1)изучая его ты понимаешь как работает программирование, по тому что придется ебаться с кучей говна
2) у него широкая сфера применения
3)он будет у тебя в унике с вероятностью 192239842094%
4)по нему есть куча материалов и даже если у тебя что то не будет получаться 100% был кто то кто уже решил эту проблему
5) ну и после него тебе будет намного проще выучить любой другой язык
2) JavaScript тоже простой, но есть недостатки, пока сайт сделаешь пол экосистемы изучишь, а она замороченная.
Если первый или второй пошли хорошо и хочется знаний поглубже и пошире тогда уже берись за С++, Java, Golang и прочих.
Английский разумеется тоже потребуется, документация и глупые вопросы с ответами будут на нём.
Дальше смотри по количеству вакансий/ зарплатам что востребованней. Так же я бы не гнался за изучением новых и хайпанутых, поковырять их успеешь, если они не вымрут. Как и с естественными языками изучив один - будет проще освоить новый. А жрат надо сейчас.
Если для тебя программирование станет работой или очень серьезным хобби, то ты не будешь ограничиваться только одним языком в течение жизни.