Что такое безопасное программирование ?

Ну народ уже словил попаболь при переходе с gcc4 на gcc5 (касательно С++). По идее, переход с gcc6 на gcc7 тоже должен ещё одну попаболь добавить. Но в целом жить можно.
У меня в системе из коробки идёт 4.8.5, но также доступны и 5, и 6 gcc. Но, видимо, не спроста дистростроители не торопятся переводить всю систему на gcc5+, хотя Leap-ветка, вроде, уже при помощи gcc6 собирается.

 

Даже если соблюдать все эти правила конкретного скрипта, это не решит проблему. Первая из них - RC ошибки. Они не решаются или предсказываются алгоритмически, так же эти сотни правил не помогут их избежать. Какого бы индуса не заставили выучить все эти правила, он всё равно накосячит, а косяк будет именно на уровне асинхронной работы с данными(RC). Это никак не резолвится правилами или автоматикой. Алгоритмические ошибки - к ним правила оформления скрипта отношения не имеют

 

SadKo,

> Вы неправильно прочитали: математика не ломается.

Нужно наверно поправить. Математика и прочее всё не ломается, если на это не обратили внимание и нет такой задачи. По умолчанию любая система уязвима.

 

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

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

Так-вот, ну написал я, сделал свои тесты простые. Все ОК, можно сдавать заказчику подумал я.

Отдали мою ФС крутым тестерам, которые обнаружили не много, не мало около 5000 ошибок. Блин там сама ФС около 2000 строк, если не считать драйверы носителей. Я ухайдокался фиксить, то неверный код ошибки вернет, то неработает там что-то. Несколько раз ложили вообще систему, короче изнасиловали мой проект как могли, даже вспоминать больно.

Вот пример хороших тестов, но чтобы тесты были хорошими, тестировщику нужно знать как работает проект и сервисы проекта. А что-бы это знать, нужна документация. Если нет нормальной документации, как вы будете писать тесты ?

 

В нормальном Agile обычно тестировщики сидят рядом с разработчиками, и наличие документации обычно скорее опция, чем необходимость.

 

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

Да, такое практикуют, я например могу тестить чужой код, мой код также кто-то может тестить.

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

Поэтому часто тесты пишут сторонние организации, которые только тестами и занимаются и ничем больше.

Ну либо нужен специальный отдел тестировщиков.

 

Каких?

Я знаю что Юнит-тесты пишутся прямо в коде. Зачем дёргать разработчиков? Это прямая обязанность разработчика писать тесты. В документе SRS или ТЗ вы планируете процент покрытия тестами. Далее менеджер должны заложить время на разработку тестов. Оно в 1,5-2 раза больше чем на написание кода. И далее уже разработчик не дёргается, а планомерно пишет тесты и код. Причём в зависимости от методологии тесты можно писать до, так и после.
При объеме в 1,5-2 раза один тестировщик ничего не сможет сделать и даже отдел. Поэтому юнит-тесты и должны писать разработчики.

Если приём сдаточные тесты, то они пишутся по ТЗ. В Agile это карты ...
Если юнит-тесты то они пишутся по названию метода либо по его внутреннему устройству. Черный ящик и белый ящик соответственно.

 

Что-то типо IBM RTRT, есть его аналоги. Но не у всех есть сертификаты.

Данные программы помогают автоматизировать разработку тестов, например подача на функции параметров и т.д.

Можно писать как динамические тесты, так и модульные.

Вручную тестировать можно долго, если проет громадный.

 

Обсуждение корпоративного организационного устройства какое отношение имеет к теме?
У меня образование "Управление организацией", могу вам сказать, что организационные иерархии выстраиваются вовсе не из соображений по снижению ошибок в коде ))
Здесь задачи по наращиванию инструментов контроля и наличие управляемости рабочим коллективом, тестировщики выполняют задачи по контролю за работой программеров для их манагеров, что-то вроде аудиторов в бухгалтерии. Подражание корпоративной иерархии это уже карго культ, о котором писал Стив Макконнелл в работе под названием "Professional Software Development".

Давайте придерживаться понятия "безопасное программирование".
Что касается проверки входных параметров, опять же рассмотрено Стивом Макконнеллом подробно в книге Совершенный код "по мере возможности делайте интерфейсы программными, а не семантическими", "Любой аспект интерфейса, который не может быть проверен компилятором, потенциальный источник ошибок.... Старайтесь преобразовывать семантические элементы интерфейса в программные, используя утверждения (assertions)...".
Здесь можно увидеть простой принцип, семантику конвертим в программные утверждения. Двойная деаллокация чекаться должна через assert и это разумно. Ответ на вопрос ранее озвученный "как я узнаю, что произошла ошибка".

P.S. Кому интересна тема корпоративной организации, вот интересная статья http://hbr-russia.ru/management/korporativnyy-opyt/a11165/ Можно найти на торрентах если заинтересует вступление. Меня вдохновила в свое время.

 

TermoSINteZ,

Вот вы это всё хорошо обсуждаете и возникает вопрос. Вы никогда за всё время не написали ни строки кода. Но вы его обсуждаете как будто в теме. Раскажите лучше кто вы.

 

Indy_, да эт местное элито ..... начитанное наших с Вами постов && оказавшиеся в модерах, странно но опять, я по этой теме вообще молчу, имхо бредотопик, далекий от релизов etc

 

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

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

Опять-же вернулись к корпоративной организации. Если тестировщики выполняют карательные функции, то нахрен эти тестировщики нужны.

Реально-же тестировщики, это неотьемлимая часть разработки практически любого софта, без них ну никак.

 

Согласен, что до маразма не нужно доходить.

Видел организации, где считают строчки кода в день. Ну бред, если я напишу 1000 строчек, то типо работаю, ога.

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

Но разумеется еще и влияют кадры, если мракобесов набрать, никакая структура не поможет.

 

Indy_,
> Раскажите лучше кто вы
А что вы ожидаете услышать от него? Уж очень общий/фундаментальный вопрос.

 

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

1. сделать 100500ую защиту от дурака НЕВОЗМОЖНО.
2. аки б ты тщательно не строфал свой код == он (твой код) подгружает бинарники/скрипты/вм-ки от третьих сторон, то бЫшь в твоей вариации разработки нужно ладить кучу чужого кода. И не надо говорить, мол-де ты токЪ проверенный используешь: житухи тебе не хватит на проверку всего и вся.
3. имеют место быть косяки железок и от них опять НЕВОЗМОЖНО 100500ую защиту.
4. проблемы лицух: в коде может использоваться проприетарный дравер/кодек/.. третьей стороны и си лицухи могут не просто ограничивать диапазон возможных решений, они ещё могут меняться в одностороннем порядке.
5. магия опенсорца нам допомо}|{Э 777 увы и @}{, ни }{¥.. == нормальная дистра линя сейчас напичкана проприетарщиной, а труЪ линь можно себе поставить, если захотел порыдать

 

в защиту РМН приведу забавный пример..

 

UbIvItS,
И? OpenSSL хорошая разработка.
Есть фанаты сверх-надежных решений, которые создали LibreSSL с более параноидальным подходом к безопасности в работе со строкам/памятью.
Именно об этом я и веду речь.
Я сам не использую OpenSSL и собрал билд Tor'а через LibreSSL, в своих проектах отдаю предпочтение MBEDTLS ранее известному как PolarSSL.