Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Насчёт баланса цена-качество всё совсем не так и в больших проектах, и в бюджетных
Чтобы выслушать ваше экспертное мнение, очевидно :)
игры с кармой вас лучше не сделают
Эти ваши выкрики про «вам не место на Хабре»
Вам должно быть стыдно за то, что обвинили невиновного
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада
Это всё сказки и мифы. Один дурак написал — сотня повторила.
Ответ на вопрос «Как?» тянет на среднюю книжку.
perl -e «print 'Hello world!';»
Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица.
phprus@server:~/> perl -e "print 'Hello world!';" bash: fork: Cannot allocate memory phprus@server:~/>
Мне начать читать курс по теории надёжности?
Для разговоров о квантовой физике надо, чтобы у людей был определённый уровень образования.
Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан (Ричард Филлипс Фейнман)
1 — затраты на повышение надежности; 2 — затраты на возмещение ущерба от ненадежности; 3 — суммарные затраты на обеспечение заданного уровня надежности
Первое, что я обычно делаю на любом проекте — пишу собственный модуль диагностики.
Индустрия молится на Unit Testing. Это модно, это прогрессивно, это агильно. Вот только цель его ответить на вопрос «Я, правда, гений, да?»
в реальной ситуации на реальных данных в нужном месте остановиться и посмотреть, что на данном этапе получилось. Естественно, проще всего это делать, когда код пишется, потому что именно в данный момент программист строит предположения на счёт того, что должно и не должно получиться.
Когда мне покажут техзадание на уровне unit test, я может быть даже немного в это поверю.
Умение добывать их — ещё одно отличие профессионала от дилетанта.
Впрочем, я и не «программист» или «разработчик»
die "OK"
, добавляете и удаляете трассировку, читаете логи, а так же занимаетесь всем остальным, о чем вы пишете в вашей статье?В нормальной системе для создания софта нужен уровень допуска адекватный допуску к данным.
(Иначе ничего не мешает сделать закладки и слить данные в процессе эксплуатации).
Как минимум, такой уровень должен быть у обслуживающего инженера.
Так что я не вижу никаких проблем, в использовании (примеров) реальных данных в процессе разработки.
Естественно, речь идёт не о прямом доступе в недра системы.
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
Для «программиста на С/С++» — да. Для профессионала — нет.
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Если под решение придумывать задачу, можно далеко уехать.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Остальное настолько грустно, что оставлю без внимания.
Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
<...>
Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже…
Если вы видите, что гениальный коллега произвёл фигню, ни в коем случае не надо обращаться к нему с намёками про то, что файлы не всегда открываются или исходные данные не всегда правильны. Это приведёт только к ненужным дискуссиям о вероятностях, надёжности и тупых пользователях. Особенно, если гений получил гуманитарное образование или докторскую по программизму. В немецких условиях возникнут ещё траблы с начальством.
Настоящий циничный идиот просто вставляет в нужное место ловушку, которая производит останов, когда случается невозможное, и код гениального коллеги выдаёт мусор, и терпеливо ожидает на берегу реки.
Да, он прибежит. Да, он будет возмущён. Он расскажет про качество и искусство писать нормальный код. Намекнёт про криворуких раздолбаев, на неумение создавать правильные программы, на людей, которые вместо функциональности производят ошибки.
Вот тут главное — не поддаться моменту, не начать отстаивать свою гениальность, не указывать пальцем… Нужно искренне удивиться, не поверить, усадить рядом, попросить показать, спросить об условиях и результатах, медленно и подробно дойти до причин, а потом аккуратно и безжалостно ткнуть мордой в нассатое.
После чего изобразить искреннее удивление, поговорить о редких и невероятных случаях, и отправить гения с пойманным багом в зубах вносить «неожиданные дополнения».
Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Адекватный уровень для ошибки в логике выполнения — останов программы
die "OK"
, really.В софте, где за ошибки расплачиваются человеческими жизнями, тоже всё делается не проще чем у хирургов. Правда, делается не оптимально, не всегда правильно и очень-очень дорого
в какой именно области он эксперт?
Забавненько. Люди, похоже, текст не читают, а сразу начинают с комментариев.
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Тоже перл. Тем более, по сравнению с тем, что там на самом деле происходит и какие люди там работают.
Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Автору это совершенно не нужно. Он пишет не для людей, которые определяют правильность мысли по звёздам на погонах.
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Люди пытаются доказать, что «на самом деле всё совсем не так». Вот только попытки всё с какими-то левыми сказками и нерелевантными собственными переживаниями и от сертификаций внезапно перескакивают к страничкам на яваскрипте…
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Сочетание слов «вы понимаете / считаете / думаете, что» без вопросительного знака показывает полную профессиональную непригодность человека, их говорящего.
Source code как способ думать