Я сюда не яйцами потрясти пришёл и не пузом помериться. Для разговоров о квантовой физике надо, чтобы у людей был определённый уровень образования. Для разговоров о живописи Возрождения надо, чтобы люди познакомились хотя бы с репродукциями. И только в ИТ всё всё знают.
Ссылка — это не аргумент. Это уровень для начала разговора.
Про «мне» там ничего не было. Скорее, «чтобы не изображать слепых котят».
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада. Второе совершенно не интересно и да и смысла не имеет, пока за это не платят.
Мне всё-таки надо начать излагать тут теорию надёжности?
Нафиг-нафиг.
Пример был, естественно, только для объяснения ошибочности воззрений оппонента. Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода. Можно, конечно, всё разжёвывать, но это не интересно. Играться мне тоже надоело.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица. С другой стороны видел системы с предсказанной надёжностью с кучей девяток, которые вставали при первом же запуске.
Единственное, что могут сделать подобные тесты — выявить некоторые ошибки и описки. Обычно «полностью оттестированный» код валится на первом же тесте, сделанном не для того, чтобы «писать под него функционал».
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место.
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
И это крайне сложно спрогнозировать.
Для «программиста на С/С++» — да. Для профессионала — нет.
За это вас будут ненавидеть.
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
Четвёртый пункт вообще не понятно зачем и для кого.
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Естественно, не правильно. Не надо выискивать в словах тот смысл, которого там нет и додумывать то, что к делу не относится. Выше стоит ссылка на книжку. Разговаривать про то, сколько стоит качество, имеет смысл только, имея минимальный базис.
Если мне предполагается поспорить с безграмотным графиком «из интернета», то я совершенно не вижу смысла этим заниматься. Если есть конкретные цифры по конкретным проектам не со слепыми шкалами, то говорить имеет смысл о конкретных вещах.
Это вот это?
Вода-вода-вода.
Забавное место, забавные люди.
Если в вашей системе понятий программист — это тот, кого до реальных данных и процессов не допускают, то, естественно, нет.
Офигеть. Сюда можно ходить вместо цирка.
Ссылка — это не аргумент. Это уровень для начала разговора.
Предлагаю не терять время. Вы сразу составьте список обвинений, я подпишу.
Если под решение придумывать задачу, можно далеко уехать.
У меня тут пользователь картинку прислал, и написал, что там jpeg. Я в вашу библиотечку запихнул его, а в файлике на самом то деле gif оказался.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
пользователь то знать не желает, что у него там внутри, он картинку залить хочет.
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Остальное настолько грустно, что оставлю без внимания.
Про «мне» там ничего не было. Скорее, «чтобы не изображать слепых котят».
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада. Второе совершенно не интересно и да и смысла не имеет, пока за это не платят.
Благородный дон в книжку заглядывает, или магическими методами выясняет содержание по обложке?
Я совершенно не вижу смысла опровергать миражи, которые кому-то померещились.
Кстати, PHP в имени — это образ мыслей?
Меня подпустят. Впрочем, я и не «программист» или «разработчик»
Нафиг-нафиг.
Пример был, естественно, только для объяснения ошибочности воззрений оппонента. Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода. Можно, конечно, всё разжёвывать, но это не интересно. Играться мне тоже надоело.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица. С другой стороны видел системы с предсказанной надёжностью с кучей девяток, которые вставали при первом же запуске.
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место.
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
И это крайне сложно спрогнозировать.
Для «программиста на С/С++» — да. Для профессионала — нет.
За это вас будут ненавидеть.
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
Четвёртый пункт вообще не понятно зачем и для кого.
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
У меня разные проекты на разных языках.
Нет, его цель — проверить соответствие кода поставленным требованиям.
Когда мне покажут техзадание на уровне unit test, я может быть даже немного в это поверю.
Откуда у вас во время написания кода «реальная ситуация» и «реальные данные»?
Умение добывать их — ещё одно отличие профессионала от дилетанта.
Для того, чтобы пытаться наехать, надо знать хотя бы основы. Мне начать постить сюда курс по теории надёжности?
Мне начать читать курс по теории надёжности?
Если мне предполагается поспорить с безграмотным графиком «из интернета», то я совершенно не вижу смысла этим заниматься. Если есть конкретные цифры по конкретным проектам не со слепыми шкалами, то говорить имеет смысл о конкретных вещах.