Самое главное, правильное и очевидное сказано в начале:
Как подсказывает мой опыт, нужно не следовать этим принципам слепо, а обдумывать их, понимать и определять, где они могут дать добавленную ценность.
Остальное - нераскрытый потенциал в узких контекстах.
Пример из моего опыта. На одной из прошлых работ переписал немаленький проект в соответствии с SOLID с примесью SOA и AOP. Коллеги не сразу въехали в то, что получилось. Надо было показать, как и почему это работает. Окончательное принятие пришло, когда коллеги распробовали две выгоды: сделать за пару часов то, что раньше занимало пару-тройку дней, и сделать исправление пары строк кода, не боясь, что это исправление надо делать ещё в кучке потаённых мест или что всё развалится на проде. А заодно в проекте появились юнит и автотесты.
С одной стороны, давно известно, что не существует полностью объективной и справедливой системы оценки эффективности работников. И её не может быть на текущем уровне развития социума.
С другой стороны тема грейдов таки не раскрыта. А чтобы понять, что такое грейды и как они работают, надо поработать с отделом управления персоналом. В нормальных случаях грейды вводят в достаточно больших компаниях для достижения двух основных целей: повышение эффективности управления ФОТ и выстраивания понятной системы вертикального роста для сотрудников. В норме появляется грейдная сетка. В упрощённом виде это таблица, где по одной оси департаменты и "специализации", а по другой грейды и "квалификации". И для каждого варианта специализация-квалификация есть хотя бы пара грейдов. В ячейках такой таблицы указаны вилки окладов и названия должностей из штатного расписания.
Эта сетка может выглядеть как-то так:
При этом вилки соседних грейдов немного пересекаются. Т.е. упираясь в потолок оклада своего грейда можно получать оклад на уровне следующего грейда.
Если в компании здоровая (не в смысле большая) система грейдов, любому сотруднику понятно, что ему надо сделать, чего достичь, чтобы выйти на следующий грейд. При этом будет понятно, почему условные программисты в разных департаментах имеет разные оклады - разные технологии, сложность и количество задач, уровень ответственности.
Для компании такая система удобна хорошей прогнозируемостью ФОТ в соответствии с рыночными условиям, будущими задачами, и не только.
Работникам понятно, чего можно ожидать, куда и как можно расти, и этот рост наглядно связан с повышением ценности.
Да, эта система не лишена субъективности, как в части роста в рамках грейда, так и в процессе вертикального роста. Но можно прийти к начальнику своего начальника и объяснить, почему тебе пора повысить грейд.
Пример из жизни: как-то я работал в компании, где грейдная сетка лежала в свободном доступе на внутреннем портале. Если кому хотелось больше денег - всегда можно было посмотреть на следующий грейд, найти людей с этим грейдом и посмотреть на их работу. Многих это отрезвляло, иных мотивировало.
Вы таки удивитесь, но ситуации бывают разные. Мне однажды пришлось разрабатывать свой видеопроигрыватель, ибо ни в одном из существующих не было возможностей, критически важных для заказчика.
И документацию я писал не мало, хотя, конечно, за последние 10 лет существенно меньше, чем за предыдущие 10. Пишу тогда, когда она необходима, и получаю за неё благодарность... Но вы же, наверняка, видели всю на свете документацию и точно знаете что нормальной не бывает?
Лично моё мнение, судя по вашим печальным цифрам успеха - только 5% полезного труда, либо вы где-то не там, либо как-то не так работаете... Может не стоит масштабировать свой опыт на всю индустрию?
Лень - она разная бывает :) Я в первый раз дзен ленивости программиста осознал ещё в школе, в 91-м. У нас тогда уже второй поток осваивал программирование в рамках информатики (я был в первом потоке). И вот, как-то раз, зайдя между делом в компьютерный класс, я наблюдал как десятиклассники пишут лабораторку, в которой надо было на бейсике нарисовать шахматную доску с шашками (схематично, квадратики, кружочки, не более). Мимоходом глянув в мониторы я узрел очень неленивого программиста - весь его экран был заполнен командами вида "draw_rect(12,24,24,36)". А ещё у него на столе лежала тетрадка, где на одной половине были расчёты, а на второй - выписаны цифры... Я бы так никогда не смог :) Собственно, моя программа годовалой давности состояла примерно из трёх циклов.
Для меня ленивый программист - это не тот, кому лень работу работать, а тот, который стремится сэкономить силы при решении задачи "сегодня, завтра и послезавтра", т.е., условно, во временя непостредственного решения задачи, при дальнейшем сопровождении, и при будущем развитии.
Парадокс в том, что ленивость требует предусмотрительности, вдумчивости и знаний. И именно это делает такого программиста хорошим.
Несмотря на много верных претензий к ангуляру, сама статья весьма однобока. У меня сильно другое отношение к этому фреймворку, и это не потому, что игнорирую проблемы, а скорее по тому, что их не встречаю.
Но начну чуть издалека. Во-первых, задолго до ангуляра и айфона появился asp.net web forms (2002 год, и да, C# - это си-шарп), вот там реально была разработка в вебе как в декстопе. К тому моменту мы в компании разработали сайт, который работал примерно на всём, от коммуникаторов до телевизоров, не считая компов. А на самих web forms я написал первое в своей работе SPA, примерно в 2005-м. Это я к тому, что многие описываемые тут проблемы пришли не после айфона и ангуляра, а раньше. И ни один инструмент/фрэймворк или что-то ещё не решает всех проблем, не является универсальным средством.
Не корректно говорить, что инструмент плох только потому, что не подходит в конкретных обстоятельствах.
А теперь про настоящее. Я разрабатываю энтерпрайз-приложение на ангуляре, который я выбрал совершенно осознанно. В частности потому, что примерно 90% проблем, описанных в этой статье никогда не коснутся нашего приложения. Зато структурная близость к бэкенд разработке, экономит дофига сил и средств в перспективе жизни проекта на многие годы.
У нас приложение для внутреннего пользования. Никогда не потребуется адаптация под мобильники (а даже если и да, что лишь крошечные фрагменты, т.к. большая часть функций в принципе невозможно использовать на мобильнике), нафиг не нужен SEO, нас даже не сильно волнует оптимизация размера бандла или то, сколько памяти съест запущенное приложение в браузере (в определённых пределах, конечно), т.к. эта оптимизация для компании дороже потенциальной выгоды, причём на много. Нам не нужны очень многие подходы в современной веб-разработке. И даже автотесты нам нужны на всё приложение, и запускаться они будут по пользовательским сценариям в режиме запуска браузера и выполнения там пользовательских действий.
Ну и в довершение, мы в команде большую часть времени тратим на разработку UX для сложного workflow/dataflow и работы с данными (таблички - наше всё), и чем меньше сил отбирает разработка фронта, тем лучше. Ангуляр с этим в наших обстоятельствах справляется, на мой вкус, лучше других популярных решений.
Из того, что я, прямо или косвенно, наблюдал за много лет, следует, что если порядок в уме есть - человек может программировать, если захочет. Если нет порядка - то человек может научиться программировать, но лучше бы он этого не делал.
Наверно, бывают исключения. Но как бы их найти? Математика в нашу жизнь приходит всё же раньше программирования.
Пользуясь таким подходом к доказательству, предлагаю автору сделать ещё один шаг: всем надо знать философию, ведь все современные науки и, как следствие, области практического применения знаний основаны на философии.
PS. тут уже напомнили цитату Ломоносова про порядок в уме. И это главное, что может дать математика большинству программистов.
PPS. хорошо бы ещё программистам не забывать язык письменности, а то читать текст сложно, равно как и код того, у кого не хватает порядка в голове.
Первое: если вы объединили тестирование кода бэкенда с тестированием БД - это не юнит тест. В зависимости от условий это может быть системный тест или e2e...
Второе: рандомная выборка из БД - отдельная тема, с которой следует внимательно разобраться, но к TDD это уже не имеет прямого отношения. (В первых же ссылка в поиске есть несколько рецептов... И проверять генератор надо на самой БД)
Третье: если так уж хочется написать тест, то но должен действительно делать большую выборку и проверять равномерность распределения и запускать такой тест можно на любом окружении, независимо от самого приложения. Иногда это называют Acceptance Tests и запускают их на целевом окружении при подготовке к установке релиза.
Вывод: Вы недооценили TDD, потому что решали не ту проблему и не тем способом.
уточняю - там вообще нет московских отделений, никаких.
По поводу инструкций - часто очень не хватает нормального описания на входе. Взять ту же замену паспорта - кажется, что онлайн-заявка это всё. Не помешало бы сразу писать все шаги.
Да, в комментарии пишут куда и что, но, во-первых, это ещё надо прочесть, и, во-вторых, плохо, что эту информацию никак иначе не добыть.
Давайте поясню как для мня выглядела процедура (не знаю, может уже поменялось, но сомневаюсь):
иду на госуслуги оформлять замену паспорта по возрасту
подаю онлайн-заявку, оплачиваю пошлину
жду, получаю отбивку, что услуга оказана
не сразу нахожу, что это ещё не всё по замене, где-то там в тексте написано, что теперь надо идти к кабинет МВД в моём МФЦ. Там даже есть время работы этого кабинета.
но буйствует ковид, посему график приёма другой. Онлайн-записаться невозможно, только в порядке живой очереди. Приезжаю - не работает до....
И вот после того, как жёсткие ограничения отменили - узнать график работы можно только лично посетив МФЦ. Я облазил сайты МВД, МФЦ - нигде нет этой информации, а на телефонах нынче тоже только роботы.
Ещё в копилку ситуаций, когда хрен разберёшься и робот не поможет:
Пытался в период очередных ковидных ограничений паспорт поменять по возрасту. После обработки онлайн заявки надо идти к представителям МВД, которые сидят в нашем МФЦ. Нигде не мог найти информации об их графике работы. И при этом в МФЦ тоже не позвонить - там тоже робот, который ничего не знает. И записаться онлайн тоже не возможно.
Пришлось ехать туда лично, на ресепшине узнавать график работы нужного кабинета, что тоже не просто, т.к. выдачей паспортов занимаются два отдела, а замена паспорта вообще другая услуга. Ну, т.е. нельзя быть уверенным, что по запросу "куда мне обратиться, чтобы получить паспорт после обработки онлайн-заявки", девочка с ресепшина пошлёт именно в кабинет, где принимает МВД. Это надо быть опытным, чтобы задать правильный вопрос.
"Всё сложно" :) Он же у нас общий, обслуживает его отдельная команда. Базовый набор правил - owasp. Периодически накатывают новую версию - приходится вычёсывать очередную пачку срабатываний. Хорошо хоть он их запоминает (хотя иногда и забывает). А настраивать.... Ему логику править надо. Он плохо понимает структуру сложных систем (много приложений с общей кодовой базой). Теоретически можно тестировать каждое приложение по отдельности, но это слишком сложно организовать и будет занимать слишком много времени.
да, .net + oracle + angular в моём solution. Сканируется где-то час, но это он ещё не все исходники берёт. Весь объём исходников он не осилил, так что пришлось часть исключить из сканирования.
Важное примечание: у нас в компании очень много разрабатываемых систем и ежесуточно проходят тысячи сканирований - это накладывает некоторые ограничения.
У нас в компании он живёт уже более года и сканирует каждый дистрибутив (точнее версию исходников, из которых дистрибутив собирается). Я за это время отметил как ложно-положительные несколько тысяч срабатываний. И нашёл только пару потенциальных уязвимостей. Это та самая реальная жизнь за пределами красивых демонстраций. Да, у нас большой solution с кучей проектов, из которого собирается дистрибутив в пачкой приложений. В итоге инструмент видит несуществующие пути кода, откровенно плохо понимает asp.net и т.д. и т.п...
Вот поддержу GreenBee… ибо фигни в этой статье слишком много.
Всё же для авторских статей надо побольше разбираться в материале.
И таки да, ASP в 2000-м году уже был 4-й версии (совместно с IIS-ом), а вместе с первой версией ASP.Net пришли WebForms.
И говоря про историю развития надо говорить в первую очередь про два вектора развития — желание присутствовать на всех платформах (куда уже пролезла java) и стремление занять интернет.
Предлагая новую платформу разработчикам нужно было как-то обеспечить всё это, да ещё и заманить чем-то вкусненьким.
Поэтому и появился CLR (Common Language Runtime), который мог бы (на тот момент ещё потенциально) работать на любой платформе, и IL, который и должен был исполняться в CLR (это чтобы писать на любом языке). С первого релиза предложили новый язык: C# и два диалекта — VisualBasic.Net и C++.Net.
VB.Net предалгался тем, кто привык юзать VB под офис/десктоп или писал asp.
C++.Net с намёком, что существующий код можно будет легко перенести на новую платформу.
C# должен был затмить Java и может даже стать «идеальным» языком разработки. При этом он не случайно C-подобен — его синтаксис не был бы чужероден и C++-разработчикам, ни JavaScript-разработчикам (для них был даже JavaScript.Net, но ввиду массы ограничений, не получил развития).
В качестве заманухи — большая библиотека классов (даже на момент выхода первой версии ни с одним других языком или с платформой не поставлялась столь богатая библиотека) и возможность писать на одном из привычных языков и для десктопа, и для сервера, и для веба. И специально для вовлечения в мир веб-разработки придумали WebForms, которые позволили делать веб-странички тем, кто до этого делал только десктоп-приложения.
Не обошлось без ложки дёгтя — в первых версиях платформы много было косяков. Но цель была достигнута — многие разработчики выбрали эту платформу, она активно развивается и по сей день. Развивается всё — и «основной» язык, и библиотека классов, и даже новые языки появляются.
А если вернуться к статье — в ней почти поровну перевранной истории, технических ошибок и агитаторской лапши… и всего это в сумме примерно половина статьи. фу.
Упомянутое тут принуждение употребляется для достижения целей, наиболее общая формулировка которых - коллективное благоденствие и процветание. Конечно, в разных странах это разные ценности, и можно много спорить, где лучше жить. Но массовое выживание населения - основной приоритет в абсолютном большинстве государств. И если население сопротивляется оному выживанию - государство применяет меры принуждения.
Самое главное, правильное и очевидное сказано в начале:
Остальное - нераскрытый потенциал в узких контекстах.
Пример из моего опыта. На одной из прошлых работ переписал немаленький проект в соответствии с SOLID с примесью SOA и AOP. Коллеги не сразу въехали в то, что получилось. Надо было показать, как и почему это работает. Окончательное принятие пришло, когда коллеги распробовали две выгоды: сделать за пару часов то, что раньше занимало пару-тройку дней, и сделать исправление пары строк кода, не боясь, что это исправление надо делать ещё в кучке потаённых мест или что всё развалится на проде. А заодно в проекте появились юнит и автотесты.
С одной стороны, давно известно, что не существует полностью объективной и справедливой системы оценки эффективности работников. И её не может быть на текущем уровне развития социума.
С другой стороны тема грейдов таки не раскрыта. А чтобы понять, что такое грейды и как они работают, надо поработать с отделом управления персоналом. В нормальных случаях грейды вводят в достаточно больших компаниях для достижения двух основных целей: повышение эффективности управления ФОТ и выстраивания понятной системы вертикального роста для сотрудников. В норме появляется грейдная сетка. В упрощённом виде это таблица, где по одной оси департаменты и "специализации", а по другой грейды и "квалификации". И для каждого варианта специализация-квалификация есть хотя бы пара грейдов. В ячейках такой таблицы указаны вилки окладов и названия должностей из штатного расписания.
Эта сетка может выглядеть как-то так:
При этом вилки соседних грейдов немного пересекаются. Т.е. упираясь в потолок оклада своего грейда можно получать оклад на уровне следующего грейда.
Если в компании здоровая (не в смысле большая) система грейдов, любому сотруднику понятно, что ему надо сделать, чего достичь, чтобы выйти на следующий грейд. При этом будет понятно, почему условные программисты в разных департаментах имеет разные оклады - разные технологии, сложность и количество задач, уровень ответственности.
Для компании такая система удобна хорошей прогнозируемостью ФОТ в соответствии с рыночными условиям, будущими задачами, и не только.
Работникам понятно, чего можно ожидать, куда и как можно расти, и этот рост наглядно связан с повышением ценности.
Да, эта система не лишена субъективности, как в части роста в рамках грейда, так и в процессе вертикального роста. Но можно прийти к начальнику своего начальника и объяснить, почему тебе пора повысить грейд.
Пример из жизни: как-то я работал в компании, где грейдная сетка лежала в свободном доступе на внутреннем портале. Если кому хотелось больше денег - всегда можно было посмотреть на следующий грейд, найти людей с этим грейдом и посмотреть на их работу. Многих это отрезвляло, иных мотивировало.
Вы таки удивитесь, но ситуации бывают разные. Мне однажды пришлось разрабатывать свой видеопроигрыватель, ибо ни в одном из существующих не было возможностей, критически важных для заказчика.
И документацию я писал не мало, хотя, конечно, за последние 10 лет существенно меньше, чем за предыдущие 10. Пишу тогда, когда она необходима, и получаю за неё благодарность... Но вы же, наверняка, видели всю на свете документацию и точно знаете что нормальной не бывает?
Лично моё мнение, судя по вашим печальным цифрам успеха - только 5% полезного труда, либо вы где-то не там, либо как-то не так работаете... Может не стоит масштабировать свой опыт на всю индустрию?
Не угадал. Обычный школьник из того же города, что и я, прошедший такой же отбор в физмат-класс (в котором и преподавали программирование).
Лень - она разная бывает :)
Я в первый раз дзен ленивости программиста осознал ещё в школе, в 91-м. У нас тогда уже второй поток осваивал программирование в рамках информатики (я был в первом потоке). И вот, как-то раз, зайдя между делом в компьютерный класс, я наблюдал как десятиклассники пишут лабораторку, в которой надо было на бейсике нарисовать шахматную доску с шашками (схематично, квадратики, кружочки, не более). Мимоходом глянув в мониторы я узрел очень неленивого программиста - весь его экран был заполнен командами вида "draw_rect(12,24,24,36)". А ещё у него на столе лежала тетрадка, где на одной половине были расчёты, а на второй - выписаны цифры... Я бы так никогда не смог :)
Собственно, моя программа годовалой давности состояла примерно из трёх циклов.
Для меня ленивый программист - это не тот, кому лень работу работать, а тот, который стремится сэкономить силы при решении задачи "сегодня, завтра и послезавтра", т.е., условно, во временя непостредственного решения задачи, при дальнейшем сопровождении, и при будущем развитии.
Парадокс в том, что ленивость требует предусмотрительности, вдумчивости и знаний. И именно это делает такого программиста хорошим.
Несмотря на много верных претензий к ангуляру, сама статья весьма однобока. У меня сильно другое отношение к этому фреймворку, и это не потому, что игнорирую проблемы, а скорее по тому, что их не встречаю.
Но начну чуть издалека. Во-первых, задолго до ангуляра и айфона появился asp.net web forms (2002 год, и да, C# - это си-шарп), вот там реально была разработка в вебе как в декстопе. К тому моменту мы в компании разработали сайт, который работал примерно на всём, от коммуникаторов до телевизоров, не считая компов. А на самих web forms я написал первое в своей работе SPA, примерно в 2005-м.
Это я к тому, что многие описываемые тут проблемы пришли не после айфона и ангуляра, а раньше. И ни один инструмент/фрэймворк или что-то ещё не решает всех проблем, не является универсальным средством.
Не корректно говорить, что инструмент плох только потому, что не подходит в конкретных обстоятельствах.
А теперь про настоящее. Я разрабатываю энтерпрайз-приложение на ангуляре, который я выбрал совершенно осознанно. В частности потому, что примерно 90% проблем, описанных в этой статье никогда не коснутся нашего приложения. Зато структурная близость к бэкенд разработке, экономит дофига сил и средств в перспективе жизни проекта на многие годы.
У нас приложение для внутреннего пользования. Никогда не потребуется адаптация под мобильники (а даже если и да, что лишь крошечные фрагменты, т.к. большая часть функций в принципе невозможно использовать на мобильнике), нафиг не нужен SEO, нас даже не сильно волнует оптимизация размера бандла или то, сколько памяти съест запущенное приложение в браузере (в определённых пределах, конечно), т.к. эта оптимизация для компании дороже потенциальной выгоды, причём на много.
Нам не нужны очень многие подходы в современной веб-разработке. И даже автотесты нам нужны на всё приложение, и запускаться они будут по пользовательским сценариям в режиме запуска браузера и выполнения там пользовательских действий.
Ну и в довершение, мы в команде большую часть времени тратим на разработку UX для сложного workflow/dataflow и работы с данными (таблички - наше всё), и чем меньше сил отбирает разработка фронта, тем лучше. Ангуляр с этим в наших обстоятельствах справляется, на мой вкус, лучше других популярных решений.
Ах, если бы.... :(
Из того, что я, прямо или косвенно, наблюдал за много лет, следует, что если порядок в уме есть - человек может программировать, если захочет. Если нет порядка - то человек может научиться программировать, но лучше бы он этого не делал.
Наверно, бывают исключения. Но как бы их найти? Математика в нашу жизнь приходит всё же раньше программирования.
Пользуясь таким подходом к доказательству, предлагаю автору сделать ещё один шаг:
всем надо знать философию, ведь все современные науки и, как следствие, области практического применения знаний основаны на философии.
PS. тут уже напомнили цитату Ломоносова про порядок в уме. И это главное, что может дать математика большинству программистов.
PPS. хорошо бы ещё программистам не забывать язык письменности, а то читать текст сложно, равно как и код того, у кого не хватает порядка в голове.
Первое: если вы объединили тестирование кода бэкенда с тестированием БД - это не юнит тест. В зависимости от условий это может быть системный тест или e2e...
Второе: рандомная выборка из БД - отдельная тема, с которой следует внимательно разобраться, но к TDD это уже не имеет прямого отношения. (В первых же ссылка в поиске есть несколько рецептов... И проверять генератор надо на самой БД)
Третье: если так уж хочется написать тест, то но должен действительно делать большую выборку и проверять равномерность распределения и запускать такой тест можно на любом окружении, независимо от самого приложения. Иногда это называют Acceptance Tests и запускают их на целевом окружении при подготовке к установке релиза.
Вывод: Вы недооценили TDD, потому что решали не ту проблему и не тем способом.
уточняю - там вообще нет московских отделений, никаких.
По поводу инструкций - часто очень не хватает нормального описания на входе. Взять ту же замену паспорта - кажется, что онлайн-заявка это всё. Не помешало бы сразу писать все шаги.
Да, в комментарии пишут куда и что, но, во-первых, это ещё надо прочесть, и, во-вторых, плохо, что эту информацию никак иначе не добыть.
А толку? (извините за сарказм)
В этом сервисе нет моего МФЦ. Точнее там вообще нет МФЦ. И да, на mos.ru та же фигня - список из 4-х отделений (https://www.mos.ru/pgu/ru/application/oiv/booking/#step_2) и все для ближайших поселений, а не Москвы.
Давайте поясню как для мня выглядела процедура (не знаю, может уже поменялось, но сомневаюсь):
иду на госуслуги оформлять замену паспорта по возрасту
подаю онлайн-заявку, оплачиваю пошлину
жду, получаю отбивку, что услуга оказана
не сразу нахожу, что это ещё не всё по замене, где-то там в тексте написано, что теперь надо идти к кабинет МВД в моём МФЦ. Там даже есть время работы этого кабинета.
но буйствует ковид, посему график приёма другой. Онлайн-записаться невозможно, только в порядке живой очереди. Приезжаю - не работает до....
И вот после того, как жёсткие ограничения отменили - узнать график работы можно только лично посетив МФЦ. Я облазил сайты МВД, МФЦ - нигде нет этой информации, а на телефонах нынче тоже только роботы.
Ещё в копилку ситуаций, когда хрен разберёшься и робот не поможет:
Пытался в период очередных ковидных ограничений паспорт поменять по возрасту. После обработки онлайн заявки надо идти к представителям МВД, которые сидят в нашем МФЦ. Нигде не мог найти информации об их графике работы. И при этом в МФЦ тоже не позвонить - там тоже робот, который ничего не знает. И записаться онлайн тоже не возможно.
Пришлось ехать туда лично, на ресепшине узнавать график работы нужного кабинета, что тоже не просто, т.к. выдачей паспортов занимаются два отдела, а замена паспорта вообще другая услуга. Ну, т.е. нельзя быть уверенным, что по запросу "куда мне обратиться, чтобы получить паспорт после обработки онлайн-заявки", девочка с ресепшина пошлёт именно в кабинет, где принимает МВД. Это надо быть опытным, чтобы задать правильный вопрос.
"Всё сложно" :) Он же у нас общий, обслуживает его отдельная команда. Базовый набор правил - owasp. Периодически накатывают новую версию - приходится вычёсывать очередную пачку срабатываний. Хорошо хоть он их запоминает (хотя иногда и забывает). А настраивать.... Ему логику править надо. Он плохо понимает структуру сложных систем (много приложений с общей кодовой базой). Теоретически можно тестировать каждое приложение по отдельности, но это слишком сложно организовать и будет занимать слишком много времени.
да, .net + oracle + angular в моём solution. Сканируется где-то час, но это он ещё не все исходники берёт. Весь объём исходников он не осилил, так что пришлось часть исключить из сканирования.
Важное примечание: у нас в компании очень много разрабатываемых систем и ежесуточно проходят тысячи сканирований - это накладывает некоторые ограничения.
Ох, как же я за
#@#^%мучался с эти чекмарксом...У нас в компании он живёт уже более года и сканирует каждый дистрибутив (точнее версию исходников, из которых дистрибутив собирается). Я за это время отметил как ложно-положительные несколько тысяч срабатываний. И нашёл только пару потенциальных уязвимостей. Это та самая реальная жизнь за пределами красивых демонстраций. Да, у нас большой solution с кучей проектов, из которого собирается дистрибутив в пачкой приложений. В итоге инструмент видит несуществующие пути кода, откровенно плохо понимает asp.net и т.д. и т.п...
Оно как бы да, так и есть, но не многие понимают, что это значит и как работает.
А потом удивляются, что написанное в методе 'someStringVar = "42"; ' не работает.
Чую, выпускники вашего курса будут заваливать интервью даже на позицию junior...
Это ж надо, так запутать простые объяснения...
Это справедливо для value-типов
Это как так-то? А в чём разница? (да, там потом есть табличка, но вот прямо тут лажа).
Требования про инициализацию параметров раскрыта неверно. И про двунаправленную передачу тоже фигня написана...
Тема про ref и out для reference типов не раскрыта.
Всё же для авторских статей надо побольше разбираться в материале.
И таки да, ASP в 2000-м году уже был 4-й версии (совместно с IIS-ом), а вместе с первой версией ASP.Net пришли WebForms.
И говоря про историю развития надо говорить в первую очередь про два вектора развития — желание присутствовать на всех платформах (куда уже пролезла java) и стремление занять интернет.
Предлагая новую платформу разработчикам нужно было как-то обеспечить всё это, да ещё и заманить чем-то вкусненьким.
Поэтому и появился CLR (Common Language Runtime), который мог бы (на тот момент ещё потенциально) работать на любой платформе, и IL, который и должен был исполняться в CLR (это чтобы писать на любом языке). С первого релиза предложили новый язык: C# и два диалекта — VisualBasic.Net и C++.Net.
VB.Net предалгался тем, кто привык юзать VB под офис/десктоп или писал asp.
C++.Net с намёком, что существующий код можно будет легко перенести на новую платформу.
C# должен был затмить Java и может даже стать «идеальным» языком разработки. При этом он не случайно C-подобен — его синтаксис не был бы чужероден и C++-разработчикам, ни JavaScript-разработчикам (для них был даже JavaScript.Net, но ввиду массы ограничений, не получил развития).
В качестве заманухи — большая библиотека классов (даже на момент выхода первой версии ни с одним других языком или с платформой не поставлялась столь богатая библиотека) и возможность писать на одном из привычных языков и для десктопа, и для сервера, и для веба. И специально для вовлечения в мир веб-разработки придумали WebForms, которые позволили делать веб-странички тем, кто до этого делал только десктоп-приложения.
Не обошлось без ложки дёгтя — в первых версиях платформы много было косяков. Но цель была достигнута — многие разработчики выбрали эту платформу, она активно развивается и по сей день. Развивается всё — и «основной» язык, и библиотека классов, и даже новые языки появляются.
А если вернуться к статье — в ней почти поровну перевранной истории, технических ошибок и агитаторской лапши… и всего это в сумме примерно половина статьи. фу.
Вы уверены? :)
В вашем опусе есть огромная ошибка в самом базисе.
Вы вообще знаете, что такое государство? Зачем вы вообще живёте в оном?
Вот вам цитата из Википедии:
Упомянутое тут принуждение употребляется для достижения целей, наиболее общая формулировка которых - коллективное благоденствие и процветание. Конечно, в разных странах это разные ценности, и можно много спорить, где лучше жить. Но массовое выживание населения - основной приоритет в абсолютном большинстве государств.
И если население сопротивляется оному выживанию - государство применяет меры принуждения.