Смысл защитного программирования состоит в том, что выполнение метода с неправильными параметрами - намного опаснее и страшнее, чем вывод сообщения о Runtime exception в рантайме и (о ужас!) на проде. Вы же банкиры! Вы должны понимать, что выдача сообщения на формочке в браузере - намного пустячная проблема, чем перевод миллиона хрен знает кому со счета клиента. Или для вас, быдлокодеров, самое страшное - runtime exception на экране пользователя?
Многие (джуны, да и много сеньоров) говорят "а что, если вызывающий метод (разработчик, конечно) подаст на вход null или неверные параметры?
Так не надо говно (извиняюсь за выражение) подавать на вход методу. Подача дряни в метод - грех вызывающего метода.
Вызываемый метод не должен чистить или исправлять параметры. Его задача - проверить параметры на ограничения и выполнить свою работу. Либо прервать выполнение. Какие ограничения? Об этом надо писать в доке метода, и эти доки надо читать, перед тем, как писать вызов метода.
Формируйте правильные параметры перед вызовом метода. Если эти параметры формируются комбинацией или вычислением ваших входных параметров - проанализируйте и примите решение, вызывать или нет метод. Если эти параметры приходят извне, и вы не проверили перед выполнением своего метода - также примите решение, вызывать или нет.
Использование возвращаемых результатов работы функции - вообще порочная практика, поскольку возвращает нас во времена Си, когда не было исключение и приходилось либо возвращать значения с результатом true/false, либо возвращать вместо данных, например количество чего-то, отрицательный результат, и потом идти в функции Win-API и вытаскивать код и текст ошибки. Писали на Си? Ну так попробуйте, поработайте без механизма исключений. Если у нас огромный стек вызова, и каждый метод возвращает свою структуру с результатом, как вы возвратите из глубины результат? будете переупаковывать результат от вызываемого метода в свой? А если вызываемых методов в вашем десяток, и каждый со своей структурой результата?
Мое мнение - не надо изобретать ахинею. Умные люди придумали механизм исключений. Этот механизм нужно знать, любить и пользоваться. Ну и на уровне менеджмента бить по рукам тех, кто пихает в параметры вызываемых методов всякую дрянь.
О-ля-ля! Неужели эта лапша всё ещё прокатывает? А под переклеенные шильдики продукции этих предприятий не пробовали заглядывать?
Вы хлебушек какой кушаете? Тоже с переклеенным шильдиком? Я вам открою глаза, но промышленные предприятия - это не только ноутбуки и роутеры. Это тысячи предметов и услуг, которые вы (точнее мы все) потребляете каждый месяц. И еще многие тысячи, которые мы не видим, но которые обеспечивают нашу жизнедеятельность. При производстве электроэнергии, воды и прочих благ цивилизации, к которым вы привыкли.
Делать одноразовую технику время жизни которой 20 минут на поле боя может даже автотаз.
Не может. И по результатам последних событий, похоже, не только автотаз не может
Великолепный результат, товарищ инженер-технолог, это когда вашу технику покупают люди во всём мире и в очереди за нею стоят. А потом многие годы ею успешно пользуются и вспоминают вас добрым словом.
Я вам еще одну секретную информацию подброшу - российской физической продукции во всем мире намного больше, чем софтверной.
Промышленных предприятий в России тысячи. И все у них в порядке (относитльно, конечно) со сроками, управлением и планированием. Но вы привели только два очень характерных предприятия. Причем, автовазом управляли и управляют кто угодно, только не производственники. Западные менеджеры. Наши (сейчас) "эффективные менеджеры" и по совместительству - чиновники. Ровно те-же, кто ан-масс руководит в ИТ - то есть, не производственники. Люди, ни сном, ни духом не понимающие, что такое производство.
Результат - тот-же самый. Бардак и разруха.
А вот положительный пример - на Уралвагонзаводе директор - Александр Валерьевич Потапов. Всю жизнь работал на производстве, металлург по образованию. И так всегда на Уралвагонзаводе было. Так после начала СВО уже через полгода продукция УВЗ пошла на фронт. Я, как инженер-технолог, понимаю, что это великолепный результат.
За наводку и возражение спасибо, оно отлично подтверждает мои тезисы.
Да конечно. Вы не в Советском Союзе родились, наверное. Нужно утилизировать по акту. Нужно предоставить энное количество килограммов плат в определенные организации, потому что это золото. Все подотчетно. Опись, протокол, сдал-принял.
У них хорошо. Можно купить мейнфрейм за 200 долларов и привезти в батином фургоне.
Я с мейнфреймами общался только в УПИ, когда молотком и зубилом разрубал ЕС на стойки и платы. Две книги из синьки я, правда, стащил себе домой и с интересом почитал про систему команд и общую архитектуру. И решетку памяти с колечками утащил себе домой.
Ну, как сказал Тема Лебедев на вопрос "надо ли мне?": "Нет, вам это не нужно. Сидите на жопе ровно". Вот в том же плане и я говорю "нужно". Хотите, чтобы ваш бизнес был конкурентоспособным? Повышайте инженерам зарплаты. Нет - да ради бога, инженеры уйдут к вашим конкурентам. Хотите снизить стоимость разработки - внедряйте контроль качества, специализацию, разрядность, как в промышленности, через это повышайте качество и снижайте необходимые ФОТ на разработчиков. Нет - да ради бога, живите как разожравшиеся стартапы на московских финансах, сливайте проект за проектом и уходите с рынка.
Ох, я вижу, тут будет сотня комментов про "приходится подбирать за дураками".
Добавить Upd в мой коммент я не могу, поэтому придется у вас развернуть мысль.
Проблема брака в IT - это не проблема ума и знаний, это проблема отсутствия системы контроля качества в IT (и, в каком-то смысле, отсутствие нормоконтроля).
Это дичайшая система, когда для повышения качества (чего-бы то ни было) компания вместо контроля качества и непропуска брака в продажу, набирает более умных людей, надеясь, что они будут работать более качественно. И при этом платят огромные деньги.
В промышленности никто в здравом уме не будет нанимать академиков точить детали на токарном станке. Во-первых, поставят специалиста-контролера (не другого токаря, бгг, ревью детали делать), во-вторых, будут давать детали согласно разрядам (в производстве отличная градация-разрядности).
К сожалению, менеджмент в ИТ не работал в промышленности, и элементарные вещи ему для понимания недоступны, отчего в ИТ творится дичь, немыслимая в реальном производстве.
Не вижу никаких проблем. Это капитализм, это рынок. Когда переходили к капитализму, утверждалось, что люди, движимые желанием разбогатеть, будут выводить на рынок продукты. Происходит ровно это. Все хорошо. Рынок труда программистов перегрет. Рыночная экономика насыщает рынок программистами. Через какое-то время рынок быдлокодеров вернется на справедливый уровень - чуть выше разнорабочего без образования. Все хорошо.
Это раньше было плохо. Из-за недостатка программистов, в разработку уходили настоящие инженеры (настоящие, я сказал! Программист - не инженер!), ученые и способные к научной деятельности молодежь. И на джаве и веб разработке - деградировали. При том, что как показывает практика, для быдлокодинга, web-разработки и лепки кнопочек и сайтиков, не нужно быть умным человеком. Не нужно учиться пять, семь лет. Достаточно курсов. А зарабатывают - мама дорогая!
Это несправедливо.
Рынок расставит всё по своим местам. Говнокодить будут недоученные дебилы на пару с дипсиком. Умные люди уйдут в электронику, ядерную энергетику, медицину, биотехнологии. Тысячи мест, где нужны умные люди. Вот там нужно поднимать зарплаты!
И нефиг меня минусовать. Я ушел в ИТ из машиностроения (первое образование - инженер-технолог). Потому что платят (платили) в настоящей инженерии мало, а ума требуется много. А программировать - херня работа, ума много не надо, знаний много не надо, а платят очень и очень хорошо.
"Айтишечку отравили!". Айтишечку ставят на то место, где она и должна быть.
ПС. Вышеперечисленное не относится к DL, связи, кристальщикам и разработке компиляторов.
Тащемта да. Докумнтация (проект) делается не для того, чтобы быстрее кто-то работал, или разработчику было удобненько, а для того, чтобы проект был управляемым. Чтобы в первую очередь начальство могла посмотреть, ЧТО мы делаем, покупатель - ЗА ЧТО мы платим, и СКОЛЬКО это будет стоить.
Стандарт на ЕСКД был введен еще 1960 году, а до этого были отраслевые стандарты вроде ГОСТ 3450–46, а до этого ТОЖЕ были стандарты (только я не нашел сходу и не могу сказать). И со сроками и результатами все было в порядке.
Я после прочтения поста в ЖЖ о пересадки почки сознание потерял. В прямом смысле. Причем на работе был, в офисе.
Я думаю, затем-же, зачем человек "работает" на свое тело.
Предлагаю автору доказать, что у него есть сознание.
Все, что вы привели про AI, примените к себе самому. Докажите нам, что у вас есть сознание. Что вы способны к самосознанию.
Исходный пример - правильный. Если исходные параметры метода - неверные, метод должен выбросить runtime исключение и прекратить работу.
Смысл этого кода - в недопущении выполнения кода с неправильными параметрами.
Словосочетание "Защитное программирование" вам что-нибудь говорит?
Смысл защитного программирования состоит в том, что выполнение метода с неправильными параметрами - намного опаснее и страшнее, чем вывод сообщения о Runtime exception в рантайме и (о ужас!) на проде. Вы же банкиры! Вы должны понимать, что выдача сообщения на формочке в браузере - намного пустячная проблема, чем перевод миллиона хрен знает кому со счета клиента. Или для вас, быдлокодеров, самое страшное - runtime exception на экране пользователя?
Многие (джуны, да и много сеньоров) говорят "а что, если вызывающий метод (разработчик, конечно) подаст на вход null или неверные параметры?
Так не надо говно (извиняюсь за выражение) подавать на вход методу. Подача дряни в метод - грех вызывающего метода.
Вызываемый метод не должен чистить или исправлять параметры. Его задача - проверить параметры на ограничения и выполнить свою работу. Либо прервать выполнение. Какие ограничения? Об этом надо писать в доке метода, и эти доки надо читать, перед тем, как писать вызов метода.
Формируйте правильные параметры перед вызовом метода. Если эти параметры формируются комбинацией или вычислением ваших входных параметров - проанализируйте и примите решение, вызывать или нет метод. Если эти параметры приходят извне, и вы не проверили перед выполнением своего метода - также примите решение, вызывать или нет.
Использование возвращаемых результатов работы функции - вообще порочная практика, поскольку возвращает нас во времена Си, когда не было исключение и приходилось либо возвращать значения с результатом true/false, либо возвращать вместо данных, например количество чего-то, отрицательный результат, и потом идти в функции Win-API и вытаскивать код и текст ошибки. Писали на Си? Ну так попробуйте, поработайте без механизма исключений. Если у нас огромный стек вызова, и каждый метод возвращает свою структуру с результатом, как вы возвратите из глубины результат? будете переупаковывать результат от вызываемого метода в свой? А если вызываемых методов в вашем десяток, и каждый со своей структурой результата?
Мое мнение - не надо изобретать ахинею. Умные люди придумали механизм исключений. Этот механизм нужно знать, любить и пользоваться. Ну и на уровне менеджмента бить по рукам тех, кто пихает в параметры вызываемых методов всякую дрянь.
Вы хлебушек какой кушаете? Тоже с переклеенным шильдиком? Я вам открою глаза, но промышленные предприятия - это не только ноутбуки и роутеры. Это тысячи предметов и услуг, которые вы (точнее мы все) потребляете каждый месяц. И еще многие тысячи, которые мы не видим, но которые обеспечивают нашу жизнедеятельность. При производстве электроэнергии, воды и прочих благ цивилизации, к которым вы привыкли.
Не может. И по результатам последних событий, похоже, не только автотаз не может
Я вам еще одну секретную информацию подброшу - российской физической продукции во всем мире намного больше, чем софтверной.
Промышленных предприятий в России тысячи. И все у них в порядке (относитльно, конечно) со сроками, управлением и планированием. Но вы привели только два очень характерных предприятия. Причем, автовазом управляли и управляют кто угодно, только не производственники. Западные менеджеры. Наши (сейчас) "эффективные менеджеры" и по совместительству - чиновники. Ровно те-же, кто ан-масс руководит в ИТ - то есть, не производственники. Люди, ни сном, ни духом не понимающие, что такое производство.
Результат - тот-же самый. Бардак и разруха.
А вот положительный пример - на Уралвагонзаводе директор - Александр Валерьевич Потапов. Всю жизнь работал на производстве, металлург по образованию. И так всегда на Уралвагонзаводе было. Так после начала СВО уже через полгода продукция УВЗ пошла на фронт. Я, как инженер-технолог, понимаю, что это великолепный результат.
За наводку и возражение спасибо, оно отлично подтверждает мои тезисы.
Да конечно. Вы не в Советском Союзе родились, наверное. Нужно утилизировать по акту. Нужно предоставить энное количество килограммов плат в определенные организации, потому что это золото. Все подотчетно. Опись, протокол, сдал-принял.
У них хорошо. Можно купить мейнфрейм за 200 долларов и привезти в батином фургоне.
Я с мейнфреймами общался только в УПИ, когда молотком и зубилом разрубал ЕС на стойки и платы. Две книги из синьки я, правда, стащил себе домой и с интересом почитал про систему команд и общую архитектуру. И решетку памяти с колечками утащил себе домой.
Ну, как сказал Тема Лебедев на вопрос "надо ли мне?": "Нет, вам это не нужно. Сидите на жопе ровно". Вот в том же плане и я говорю "нужно". Хотите, чтобы ваш бизнес был конкурентоспособным? Повышайте инженерам зарплаты. Нет - да ради бога, инженеры уйдут к вашим конкурентам. Хотите снизить стоимость разработки - внедряйте контроль качества, специализацию, разрядность, как в промышленности, через это повышайте качество и снижайте необходимые ФОТ на разработчиков. Нет - да ради бога, живите как разожравшиеся стартапы на московских финансах, сливайте проект за проектом и уходите с рынка.
Вольному воля, а рынок заставит.
Ох, я вижу, тут будет сотня комментов про "приходится подбирать за дураками".
Добавить Upd в мой коммент я не могу, поэтому придется у вас развернуть мысль.
Проблема брака в IT - это не проблема ума и знаний, это проблема отсутствия системы контроля качества в IT (и, в каком-то смысле, отсутствие нормоконтроля).
Это дичайшая система, когда для повышения качества (чего-бы то ни было) компания вместо контроля качества и непропуска брака в продажу, набирает более умных людей, надеясь, что они будут работать более качественно. И при этом платят огромные деньги.
В промышленности никто в здравом уме не будет нанимать академиков точить детали на токарном станке. Во-первых, поставят специалиста-контролера (не другого токаря, бгг, ревью детали делать), во-вторых, будут давать детали согласно разрядам (в производстве отличная градация-разрядности).
К сожалению, менеджмент в ИТ не работал в промышленности, и элементарные вещи ему для понимания недоступны, отчего в ИТ творится дичь, немыслимая в реальном производстве.
Это вторая проблема в IT - отсутствие контроля качества.
Не вижу никаких проблем. Это капитализм, это рынок. Когда переходили к капитализму, утверждалось, что люди, движимые желанием разбогатеть, будут выводить на рынок продукты. Происходит ровно это. Все хорошо. Рынок труда программистов перегрет. Рыночная экономика насыщает рынок программистами. Через какое-то время рынок быдлокодеров вернется на справедливый уровень - чуть выше разнорабочего без образования. Все хорошо.
Это раньше было плохо. Из-за недостатка программистов, в разработку уходили настоящие инженеры (настоящие, я сказал! Программист - не инженер!), ученые и способные к научной деятельности молодежь. И на джаве и веб разработке - деградировали. При том, что как показывает практика, для быдлокодинга, web-разработки и лепки кнопочек и сайтиков, не нужно быть умным человеком. Не нужно учиться пять, семь лет. Достаточно курсов. А зарабатывают - мама дорогая!
Это несправедливо.
Рынок расставит всё по своим местам. Говнокодить будут недоученные дебилы на пару с дипсиком. Умные люди уйдут в электронику, ядерную энергетику, медицину, биотехнологии. Тысячи мест, где нужны умные люди. Вот там нужно поднимать зарплаты!
И нефиг меня минусовать. Я ушел в ИТ из машиностроения (первое образование - инженер-технолог). Потому что платят (платили) в настоящей инженерии мало, а ума требуется много. А программировать - херня работа, ума много не надо, знаний много не надо, а платят очень и очень хорошо.
"Айтишечку отравили!". Айтишечку ставят на то место, где она и должна быть.
ПС. Вышеперечисленное не относится к DL, связи, кристальщикам и разработке компиляторов.
Можно определить, что означает "стала выпускать " и "продолжала разрабатывать"? Как эти два процесса могут быть независящими друг от друга?
Врать будут ("галлюцинировать", научно выражаясь). Они и сейчас так делают.
Сын рядом сидит, руководит и архитектурит. Я, как джун, только реализую.
Тащемта да. Докумнтация (проект) делается не для того, чтобы быстрее кто-то работал, или разработчику было удобненько, а для того, чтобы проект был управляемым. Чтобы в первую очередь начальство могла посмотреть, ЧТО мы делаем, покупатель - ЗА ЧТО мы платим, и СКОЛЬКО это будет стоить.
Точно, только заметил. Слои и DI прослеживаются. Спагетти бесит, начинаешь отдельными заводами делать.
Только вчера освоил светофоры в factorio, а тут такая статья!
Появятся новые языки, новые вопросы, на которые бямы не смогут дать ответа - люди пойдут на sof.
Стандарт на ЕСКД был введен еще 1960 году, а до этого были отраслевые стандарты вроде ГОСТ 3450–46, а до этого ТОЖЕ были стандарты (только я не нашел сходу и не могу сказать). И со сроками и результатами все было в порядке.
Стандартизация ускоряет.