Комментарии 147
Вода-вода-вода.
Общая идея — программисты мудаки, что допускают ошибки и плохо логируют, если бы программисты были честными — проги не падали бы?
И как это сделать? Логировать ошибки и ронять программы? Застрелить коня, если тот зацепился за камень? Или просто программисты не в том месте логируют? Или не так логируют.
Как-то не хватает примеров «было»/«стало»/«почему теперь лучше».
Ну и не забывайте, что везде соблюдается баланс качество-цена. Если сделать бесконечно качественную прогу — она будет стоить бесконечно много денег.
Общая идея — программисты мудаки, что допускают ошибки и плохо логируют, если бы программисты были честными — проги не падали бы?
И как это сделать? Логировать ошибки и ронять программы? Застрелить коня, если тот зацепился за камень? Или просто программисты не в том месте логируют? Или не так логируют.
Как-то не хватает примеров «было»/«стало»/«почему теперь лучше».
Ну и не забывайте, что везде соблюдается баланс качество-цена. Если сделать бесконечно качественную прогу — она будет стоить бесконечно много денег.
Общая идея воспринята совершенно не верно. Хотя, насчёт программистов спорить не буду.
Как сделать — про это есть толстые книжки. В частности внутренние проверки обязательны для софта класса mission critical. Потому что это самый дешёвый способ получить нужный уровень надёжности.
Насчёт баланса цена-качество всё совсем не так и в больших проектах, и в бюджетных. Но разговор можно начинать после полного прочтения хотя бы «Quality Is Free» by Philip B. Crosby Пересказывать нет ни времени, ни желания.
Как сделать — про это есть толстые книжки. В частности внутренние проверки обязательны для софта класса mission critical. Потому что это самый дешёвый способ получить нужный уровень надёжности.
Насчёт баланса цена-качество всё совсем не так и в больших проектах, и в бюджетных. Но разговор можно начинать после полного прочтения хотя бы «Quality Is Free» by Philip B. Crosby Пересказывать нет ни времени, ни желания.
Насчёт баланса цена-качество всё совсем не так и в больших проектах, и в бюджетных
Ну да, ну да.
Если нету ни времени, ни желания — зачем вообще было что-то писать на Хабр?
Чтобы выслушать ваше экспертное мнение, очевидно :)
Чтобы выслушать ваше экспертное мнение, очевидно :)
К чему Ваш сарказм? Автора не интересуют коменты окружающих? Он — единственный, кто знает истину? Все, кто не согласен с ним — неправы? Или вы считаете меня плохим специалистом?
Если это был не сарказм, то я думаю, что вы ошибаетесь и он писал эту статью не ради моего мнения.
Мой сарказм к тому, что мне глубоко плевать на то, какой вы специалист. Я этого не знаю и знать не хочу.
Ваши аргументы в старт-комменте вызывают у меня очень странные чувства.
Человек написал статью. Статья вполне адекватная. Он уже потратил на это время. Систематезировал информацию, провёл определённую работу. В конце концов, дал вам определённую пищу для ума.
Или вам только примеры решения прикладных задач на JS нужны?
В конце концов, без теории и философии не было бы практики и науки. Людям иногда надо начинать учиться думать, и начинать учиться ценить то, что кто-то уже подумал за них.
Эти ваши выкрики про «вам не место на Хабре» и игры с кармой вас лучше не сделают.
Ваши аргументы в старт-комменте вызывают у меня очень странные чувства.
Человек написал статью. Статья вполне адекватная. Он уже потратил на это время. Систематезировал информацию, провёл определённую работу. В конце концов, дал вам определённую пищу для ума.
Или вам только примеры решения прикладных задач на JS нужны?
В конце концов, без теории и философии не было бы практики и науки. Людям иногда надо начинать учиться думать, и начинать учиться ценить то, что кто-то уже подумал за них.
Эти ваши выкрики про «вам не место на Хабре» и игры с кармой вас лучше не сделают.
игры с кармой вас лучше не сделают
Вам должно быть стыдно за то, что обвинили невиновного:
Эти ваши выкрики про «вам не место на Хабре»
Не передёргивайте. Я спросил, зачем тогда человек пишет статьи, если на комметарии он отвечает: «нету мне времени вам объяснять». Если такой занятый человек — зачем тратить время?
А статья ни о чём. Отчасти — капитанство, отчасти — какие-то нереалистичные вещи, всё существенно разбавленно водой, приправленно огромным ЧСВ, а в комментах читается тон: «Вы все мудаки и нифига в этой жизни не поняли, только строите из себя гениев, а я один крутой программист, даже говорить с вами не хочу, пока не прочтёте вот эту книжку, которая открыла мне глаза».
Вам должно быть стыдно за то, что обвинили невиновного
Впрочем, я жалею, что не минусанул топик. Откровенно показался дерьмом, но потом предположил, что, может, просто не понял какой-то глубокой мысли. Теперь же, после чтения комментов, понимаю, что автор писал его просто для самолюбования, потешить своё эго.
вот эту книжку, которая открыла мне глаза
Про «мне» там ничего не было. Скорее, «чтобы не изображать слепых котят».
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада. Второе совершенно не интересно и да и смысла не имеет, пока за это не платят.
Про «мне» там ничего не было. Скорее, «чтобы не изображать слепых котят».
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада. Второе совершенно не интересно и да и смысла не имеет, пока за это не платят.
И одно дело написать текст для определённого уровня, совсем другое разжёвывать очевидное для уровня детского сада
О, Бог программирования, да не соизволите ли вы опустится ниже плинтуса, до уровня обычных смертных программистов и благословить их своим величественным просвещением?
Из комментариев можно сделать очень простой вывод, как получить 0% ошибок в коде: надо просто не писать его!
Быстро же от первого надменного комментария вы опустились до такого…
Предлагаю не терять время. Вы сразу составьте список обвинений, я подпишу.
Предлагаю не терять время. Вы сразу составьте список обвинений, я подпишу.
Тут всё просто: в качестве черновика для презентации на английском. Плюс собрать умные замечания, если, вдруг, такие появятся. А пересказывать классические источники — это совершенно не интересно.
Ответ на вопрос «Как?» тянет на среднюю книжку. Ответ на вопросы «Почему?» и «Зачем?» как минимум на три-четыре.
Ответ на вопрос «Как?» тянет на среднюю книжку. Ответ на вопросы «Почему?» и «Зачем?» как минимум на три-четыре.
Это всё сказки и мифы. Один дурак написал — сотня повторила.
Ответ на вопрос «Как?» тянет на среднюю книжку.
и т.д.
если вы так круты и знаете секрет — покажите крутое безбажное приложение за минимальный бюджет.
А лучше покажите процесс его разработки.
Хороший автор умеет высказываться лаконично, грамотно и доступно. У вас это не получилось. Книги — для более фундаментальных и обширных понятий, для того, чтобы поделится опытом, рассказать идею — их писать не нужно.
Всё бы хорошо, если бы не один поразительный факт: есть люди, которые поняли всё и согласились, есть другие, которые не поняли ни хрена и доказывают, что автор мудак. Так что реакция чисто психиатрическая, что тоже полезно изучить для определённых целей.
Вы не допускаете, что есть люди, которые поняли все, но не согласны с сутью и с некоторыми тезами?
Если автора не понимают, это отчасти его вина.
Если автора не понимают, это отчасти его вина.
Вы не допускаете, что есть люди, которые поняли все, но не согласны с сутью и с некоторыми тезами?
Я их ждал. Я на них надеялся. Но всё, что вылезло — это просто какой-то позор индустрии в общем и российской тусовки в частности.
Дельных замечаний было всего несколько и они только добавляли, но ни оспаривали ни одного тезиса.
Я их ждал. Я на них надеялся. Но всё, что вылезло — это просто какой-то позор индустрии в общем и российской тусовки в частности.
Дельных замечаний было всего несколько и они только добавляли, но ни оспаривали ни одного тезиса.
Нда. Похоже статью и комментарии писали два разных человека.
Статья: Надо признавать ошибки. надо работать на своими ошибками. Тот, кто думает, что не ошибается и он гений — идиот.
Комментарий: Мои читатели делятся на хороших, кто согласился со мной, и идиотов, которые думают, что я не прав.
Статья: Надо признавать ошибки. надо работать на своими ошибками. Тот, кто думает, что не ошибается и он гений — идиот.
Комментарий: Мои читатели делятся на хороших, кто согласился со мной, и идиотов, которые думают, что я не прав.
Ещё одно оправдание современного высокооплачиваемого работника, кстати.
«Как мне платят — так я и работаю».
Правда, обычно, уровень зарплаты совсем (вообще, вот ни капельки) не коррелирует с умением человека адекватно проектировать коуд-фло или дэйта-фло таким образом, чтобы учитывать и отсекать все граничные случаи.
«Как мне платят — так я и работаю».
Правда, обычно, уровень зарплаты совсем (вообще, вот ни капельки) не коррелирует с умением человека адекватно проектировать коуд-фло или дэйта-фло таким образом, чтобы учитывать и отсекать все граничные случаи.
Всё так.
Способность признавать ошибки как-то странно из положительной черты характера человека превратилась в отрицательную.
Индустрия закомплексованных интровертов :)
Кроме психологических причин есть вполне себе технологические — неготовность индустриальных инструментов.
Впрочем, скорость проникновения в мейнстримовые инструменты разнообразных контрактов и метапрограммирований радует.
Может быть, при использовании следующего поколения инструментов не надо будет задумываться о массивных ассертах и всё больше полагаться на методологию “let it crash", как на единственно разумный инструмент обработки ошибок.
Способность признавать ошибки как-то странно из положительной черты характера человека превратилась в отрицательную.
Индустрия закомплексованных интровертов :)
Кроме психологических причин есть вполне себе технологические — неготовность индустриальных инструментов.
Впрочем, скорость проникновения в мейнстримовые инструменты разнообразных контрактов и метапрограммирований радует.
Может быть, при использовании следующего поколения инструментов не надо будет задумываться о массивных ассертах и всё больше полагаться на методологию “let it crash", как на единственно разумный инструмент обработки ошибок.
Спасибо, пишите ещё.
Как говорил мой преподаватель, «программу без ошибок можно написать за бесконечно большее время и бесконечно большой бюджет.» :)
По сути: в статье упущено важное разделение на программы, требовательные к высокому уровню надежности, и программы, падение которых не критично. Также забыл автор и про стоимость увеличения надежности, о которой уже столько понаписано и в отечественной и в зарубежной литературе, что голословно утверждать «надо просто делать программы/станки/техпроцессы» без ошибок — непозволительно. :)
Подход к проектированию и реализации критических к надежности систем и систем обычных отличается кардинально, и совершенно не ясно, где автор собрался брать квалифицированных работников, чтобы всегда работать по самым надежным схемам. На чем автор написал примеры кода в статье? Не на PHP ли?;)
По сути: в статье упущено важное разделение на программы, требовательные к высокому уровню надежности, и программы, падение которых не критично. Также забыл автор и про стоимость увеличения надежности, о которой уже столько понаписано и в отечественной и в зарубежной литературе, что голословно утверждать «надо просто делать программы/станки/техпроцессы» без ошибок — непозволительно. :)
Подход к проектированию и реализации критических к надежности систем и систем обычных отличается кардинально, и совершенно не ясно, где автор собрался брать квалифицированных работников, чтобы всегда работать по самым надежным схемам. На чем автор написал примеры кода в статье? Не на PHP ли?;)
Это всё сказки и мифы. Один дурак написал — сотня повторила.
Да и вопрос совсем не в абсолютной надёжности. Для этого применяются другие методы, которые в тексте даже не затрагиваются.
Да и вопрос совсем не в абсолютной надёжности. Для этого применяются другие методы, которые в тексте даже не затрагиваются.
Расскажите, пожалуйста, об абсолютной надежности. :)
perl -e «print 'Hello world!';»
perl -e «print 'Hello world!';»
Поздравляю вас, упало с ошибкой "'perl' is not recognized as an internal or external command,
operable program or batch file.".
А могло упасть с еще десятком разных.
Фигня-с. Система не сертифицирована. И можно заметить, что в варианте с ёлочкой сервер квотирование переделал.
Для того, чтобы пытаться наехать, надо знать хотя бы основы. Мне начать постить сюда курс по теории надёжности?
Для того, чтобы пытаться наехать, надо знать хотя бы основы. Мне начать постить сюда курс по теории надёжности?
И много вы видели систем, сертифицированных на абсолютную (т.е., не n девяток, а единица) надежность?
Ну и да, вы же не сказали, что пример выполнять только на сертифицированных системах, и систему не приложили, так что пример ваш, гм, неудачен.
Ну и да, вы же не сказали, что пример выполнять только на сертифицированных системах, и систему не приложили, так что пример ваш, гм, неудачен.
Мне всё-таки надо начать излагать тут теорию надёжности?
Нафиг-нафиг.
Пример был, естественно, только для объяснения ошибочности воззрений оппонента. Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода. Можно, конечно, всё разжёвывать, но это не интересно. Играться мне тоже надоело.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица. С другой стороны видел системы с предсказанной надёжностью с кучей девяток, которые вставали при первом же запуске.
Нафиг-нафиг.
Пример был, естественно, только для объяснения ошибочности воззрений оппонента. Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода. Можно, конечно, всё разжёвывать, но это не интересно. Играться мне тоже надоело.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица. С другой стороны видел системы с предсказанной надёжностью с кучей девяток, которые вставали при первом же запуске.
Очень забавно, что народ начал споры совершенно не о том, обрадованно схватившись за уровень кода.
Это не уровень кода, а уровень аргументации.
С точки зрения практической, уровень надёжности можно определить после вывода системы из эксплуатации. До этого у нас только прогноз. Так вот, у тех систем, где ошибок не было, в результате получается единица.
Видимо, это и есть обещанный вами «другой метод», используемый для получения систем с абсолютной надежностью — вывести систему из эксплуатации. С другой стороны, оно и верно — неэксплуатируемая сбоев не имеет.
Только вы учтите, что надежность системы не напрямую вытекает (и не напрямую означает) из количества ошибок в этой системе. Можно иметь надежную систему с кучей ошибок, можно иметь ненадежную без единой ошибки.
Собственно, сбои и ошибки — это вообще разные вещи.
> Мне начать постить сюда курс по теории надёжности?
Да, это было бы полезней того, что вы написали.
Да, это было бы полезней того, что вы написали.
phprus@server:~/> perl -e "print 'Hello world!';" bash: fork: Cannot allocate memory phprus@server:~/>
Фигня-с. Система не сертифицирована.
Мне начать читать курс по теории надёжности?
Мне начать читать курс по теории надёжности?
В сертифицированной системе память не кончается? Или в инструкции будет написано, что можно запускать не более 1 процесса, и процесс не может потреблять более 10% ОЗУ?
Мне начать читать курс по теории надёжности?
Пожалуйста, начните!
Завтра у меня рабочий день, хоть и банкет. Мы его всей кафедрой почитаем! И докторов наук привлечем! :)
Сколько вы способны платить за своё «пожалуйста»? Для людей, которые книжки не читают, танцы только за деньги.
Я не нанимаю Вас на работу, поэтому испытательный срок с конкретной зарплатой в соответствии с штатным расписанием предложить Вам не могу.
Можно рассмотреть Ваше предложение, как предложение из области фриланса, но тогда мне бы хотелось увидеть Ваше портфолио, для оценки Вашей квалификации и принятии решения об уровне оплаты.
На текущий момент Вы не привели ни одного аргумента, кроме ссылки на стороннюю публикацию, а аргументы других участников дискуссии Вы объявляете несостоятельными. Так делать не принято, так как вы не свою точку зрения аргументируете, а дословно говорите, что автор вон той книги знает, спросите у него, что в просторечии именуется, как «перевод стрелок».
P.S. Делать предложение, и когда оно будет принято говорить о его платности — это опять-же не конструктивный подход к делу.
Можно рассмотреть Ваше предложение, как предложение из области фриланса, но тогда мне бы хотелось увидеть Ваше портфолио, для оценки Вашей квалификации и принятии решения об уровне оплаты.
На текущий момент Вы не привели ни одного аргумента, кроме ссылки на стороннюю публикацию, а аргументы других участников дискуссии Вы объявляете несостоятельными. Так делать не принято, так как вы не свою точку зрения аргументируете, а дословно говорите, что автор вон той книги знает, спросите у него, что в просторечии именуется, как «перевод стрелок».
P.S. Делать предложение, и когда оно будет принято говорить о его платности — это опять-же не конструктивный подход к делу.
Я сюда не яйцами потрясти пришёл и не пузом помериться. Для разговоров о квантовой физике надо, чтобы у людей был определённый уровень образования. Для разговоров о живописи Возрождения надо, чтобы люди познакомились хотя бы с репродукциями. И только в ИТ всё всё знают.
Ссылка — это не аргумент. Это уровень для начала разговора.
Ссылка — это не аргумент. Это уровень для начала разговора.
Для разговоров о квантовой физике надо, чтобы у людей был определённый уровень образования.
Эх:
Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан (Ричард Филлипс Фейнман)
Обоснуйте, пожалуйста, Ваше утверждение.
И скажите, пожалуйста, почему традиционный баланс затрат на надежность и затрат на компенсацию ущерба, вдруг начал иметь минимум в точке максимальной надежности?*
* График из интернета:
Или я Вас в чем-то неправильно понял?
И скажите, пожалуйста, почему традиционный баланс затрат на надежность и затрат на компенсацию ущерба, вдруг начал иметь минимум в точке максимальной надежности?*
* График из интернета:
1 — затраты на повышение надежности; 2 — затраты на возмещение ущерба от ненадежности; 3 — суммарные затраты на обеспечение заданного уровня надежности
Или я Вас в чем-то неправильно понял?
Естественно, не правильно. Не надо выискивать в словах тот смысл, которого там нет и додумывать то, что к делу не относится. Выше стоит ссылка на книжку. Разговаривать про то, сколько стоит качество, имеет смысл только, имея минимальный базис.
Если мне предполагается поспорить с безграмотным графиком «из интернета», то я совершенно не вижу смысла этим заниматься. Если есть конкретные цифры по конкретным проектам не со слепыми шкалами, то говорить имеет смысл о конкретных вещах.
Если мне предполагается поспорить с безграмотным графиком «из интернета», то я совершенно не вижу смысла этим заниматься. Если есть конкретные цифры по конкретным проектам не со слепыми шкалами, то говорить имеет смысл о конкретных вещах.
Ссылка на книжку есть, но я пока не увидел аргументов за возможность существования теории «Quality Is Free» в реальной жизни БЕЗ всяких оговорок (это важно, так как оценить затраты в 0 не так сложно, но реально они будут далеко не нулевыми) (Замечание: оценка затрат == 0 НЕ эквивалентна тому, что реальные затраты будут равны нулю. Замечание 2: зарплата сотрудника и время — это тоже затраты).
Вам предлагается обосновать, почему он безграмотный, либо привести хотя-бы один пример, где надежность повышается без затрат на деятельность по повышению надежности. (Я думаю кривая, показывающая снижение возможного ущерба при росте надежности сомнения не вызывает?)
Вам предлагается обосновать, почему он безграмотный, либо привести хотя-бы один пример, где надежность повышается без затрат на деятельность по повышению надежности. (Я думаю кривая, показывающая снижение возможного ущерба при росте надежности сомнения не вызывает?)
но я пока не увидел аргументов
Благородный дон в книжку заглядывает, или магическими методами выясняет содержание по обложке?
Я совершенно не вижу смысла опровергать миражи, которые кому-то померещились.
Кстати, PHP в имени — это образ мыслей?
Благородный дон в книжку заглядывает, или магическими методами выясняет содержание по обложке?
Я совершенно не вижу смысла опровергать миражи, которые кому-то померещились.
Кстати, PHP в имени — это образ мыслей?
Не надо переводить стрелки на книжку. Надо привести хотя-бы один аргумент в поддержку своей точки зрения. Это же так просто.
Те на конструктивный диалог Вы не настроены, а остановитесь на голословных обвинениях?
К сожалению, в моем имени нет и никогда не было буквосочетания PHP. Как следует из моего профиля на Хабре phprus, мое имя Владислав.
Те на конструктивный диалог Вы не настроены, а остановитесь на голословных обвинениях?
К сожалению, в моем имени нет и никогда не было буквосочетания PHP. Как следует из моего профиля на Хабре phprus, мое имя Владислав.
Для конструктивного диалога должен быть определённый уровень.
Про необходимый уровень очень хорошо сказал Фейнман, цитату которого я привел чуть выше: habrahabr.ru/post/164277/#comment_5651887
Кроме того, Вы свой уровень все еще не продемонстрировали.
Кроме того, Вы свой уровень все еще не продемонстрировали.
Вы не показали что этот уровень есть у вас и отсутствует у других.
Первое, что я обычно делаю на любом проекте — пишу собственный модуль диагностики.
Ну да, ведь написанный для предыдущего проекта уже устарел.
Индустрия молится на Unit Testing. Это модно, это прогрессивно, это агильно. Вот только цель его ответить на вопрос «Я, правда, гений, да?»
Нет, его цель — проверить соответствие кода поставленным требованиям.
в реальной ситуации на реальных данных в нужном месте остановиться и посмотреть, что на данном этапе получилось. Естественно, проще всего это делать, когда код пишется, потому что именно в данный момент программист строит предположения на счёт того, что должно и не должно получиться.
Откуда у вас во время написания кода «реальная ситуация» и «реальные данные»?
Ну да, ведь написанный для предыдущего проекта уже устарел.
У меня разные проекты на разных языках.
Нет, его цель — проверить соответствие кода поставленным требованиям.
Когда мне покажут техзадание на уровне unit test, я может быть даже немного в это поверю.
Откуда у вас во время написания кода «реальная ситуация» и «реальные данные»?
Умение добывать их — ещё одно отличие профессионала от дилетанта.
У меня разные проекты на разных языках.
Нет, его цель — проверить соответствие кода поставленным требованиям.
Когда мне покажут техзадание на уровне unit test, я может быть даже немного в это поверю.
Откуда у вас во время написания кода «реальная ситуация» и «реальные данные»?
Умение добывать их — ещё одно отличие профессионала от дилетанта.
Когда мне покажут техзадание на уровне unit test, я может быть даже немного в это поверю.
А что, у вас проблемы разбить нормальное техзадание на тесткейсы? Так я вам сочувствую.
Умение добывать их — ещё одно отличие профессионала от дилетанта.
К сожалению, это «отличие» надумано вами. Во-первых, данные поставляются постановщиком задачи, а не добываются разработчиком. А во-вторых, у многих заказчиков вас к реальным данным не подпустят на выстрел, потому что они составляют часть коммерческой тайны.
А во-вторых, у многих заказчиков вас к реальным данным не подпустят на выстрел,
Меня подпустят. Впрочем, я и не «программист» или «разработчик»
Меня подпустят. Впрочем, я и не «программист» или «разработчик»
Впрочем, я и не «программист» или «разработчик»
Может быть, вам тогда не стоит учить программистов их ремеслу?
С другой стороны, если вы не программист или разработчик, то зачем вы на каждом новом проекте пишете модуль диагностики?
Я и на английском могу говорить, хотя я не переводчик. Совершенно не вижу в этом проблемы.
Хорошо. Поставим вопрос просто: какова ваша роль в тех проектах, в которых вы «пишете свой модуль диагностики», отлаживаете с помощью
die "OK", добавляете и удаляете трассировку, читаете логи, а так же занимаетесь всем остальным, о чем вы пишете в вашей статье?Чаще всего, поставить задание или самому сделать то, что нельзя поручить «нормальным программистам».
Вы считаете, что когда вы делаете то, что нельзя поручить нормальным программистам, вы не выполняете роль программиста?
Впрочем, «постановщика задач» (т.е., аналитика) к реальным данным-то подпустят, вот только это будет не в момент написания кода. Так что moot point.
Впрочем, «постановщика задач» (т.е., аналитика) к реальным данным-то подпустят, вот только это будет не в момент написания кода. Так что moot point.
Вы считаете, что когда вы делаете то, что нельзя поручить нормальным программистам, вы не выполняете роль программиста?
Если в вашей системе понятий программист — это тот, кого до реальных данных и процессов не допускают, то, естественно, нет.
Если в вашей системе понятий программист — это тот, кого до реальных данных и процессов не допускают, то, естественно, нет.
В моей системе понятий до реальных данных (не процессов) не допускают исполнителя (особенно — внешнего). Просто потому, что это нарушение двух внутренних положений компании и трех законов Российской Федерации.
Нет, есть, конечно, NDA во всех его видах. Только он на обычного простого программиста, который и пишет весь код в продаваемом решении, распространяется плохо, и никто не горит желанием разглашать банковскую тайну Васе из компании, которой продали внедрение системы управления кредитами.
Поэтому конечный программист очень часто работает в условиях некоей гипотезы о реальных данных. Насколько эта гипотеза к ним близка, зависит от квалификации постановщика задачи.
Нет, есть, конечно, NDA во всех его видах. Только он на обычного простого программиста, который и пишет весь код в продаваемом решении, распространяется плохо, и никто не горит желанием разглашать банковскую тайну Васе из компании, которой продали внедрение системы управления кредитами.
Поэтому конечный программист очень часто работает в условиях некоей гипотезы о реальных данных. Насколько эта гипотеза к ним близка, зависит от квалификации постановщика задачи.
В нормальной системе для создания софта нужен уровень допуска адекватный допуску к данным. (Иначе ничего не мешает сделать закладки и слить данные в процессе эксплуатации).
Как минимум, такой уровень должен быть у обслуживающего инженера.
Так что я не вижу никаких проблем, в использовании (примеров) реальных данных в процессе разработки. Естественно, речь идёт не о прямом доступе в недра системы. Так что мне совершенно не понятно, как это может вызывать подобное удивление.
Как минимум, такой уровень должен быть у обслуживающего инженера.
Так что я не вижу никаких проблем, в использовании (примеров) реальных данных в процессе разработки. Естественно, речь идёт не о прямом доступе в недра системы. Так что мне совершенно не понятно, как это может вызывать подобное удивление.
В нормальной системе для создания софта нужен уровень допуска адекватный допуску к данным.
Зачем?
(Иначе ничего не мешает сделать закладки и слить данные в процессе эксплуатации).
Из замкнутого контура? Не смешно.
Как минимум, такой уровень должен быть у обслуживающего инженера.
Обслуживание системы происходит после ее написания, поэтому к нашему разговору отношения не имеет.
Так что я не вижу никаких проблем, в использовании (примеров) реальных данных в процессе разработки.
Пример реальных данных не является реальными данными. Система может на примерах работать, а на реальных данных — падать. Такая вот суровая жизнь.
Естественно, речь идёт не о прямом доступе в недра системы.
Если у вас нет прямого доступа, то вы работаете не в реальной ситуации и не с реальными данными. В лучшем случае вы работаете с их точной копией, вероятнее — с приближенной, еще вероятнее — с моделью.
Юношеский максимализм является неотъемлемой частью ваших 20 лет опыта?
Во-первых, в статье нету никаких выводов. Совсем. Я бы даже сказал, что есть только введение:) Да ещё и название статьи раскрывается ещё до ката, под катом же набор каких-то фактов и мыслей, слабо связанных с введением. Все знают, что все делают ошибки. Все (ну ладно, кроме заносчивых новичков) понимают, что каждый пишет код с ошибками.
Далее, по пунктам:
1. Если есть сбои в логике — останов программы. Зачем же тогда придумали try..except конструкции, если не для попыток починить возникшую проблему? Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место. Если не удалось обслужить одного клиента — ладно, отправим ему ошибку. Но зачастую это никак не мешает обрабатывать следующих клиентов в этой же программе. Более того, зачастую сбои в логике нельзя отследить автоматически в процессе работы программы. Если вы где-то проехались по стеку — вы этого нифига не заметите, просто через некоторое время ваша программа упадёт в корку, в самом неожиданном месте.
2. Прогнозирование ошибок. Дебаг сообщения в лог — это, безусловно, полезно и позволяет легче находить проблему. Да, их часто добавляют в момент написания кода. Эдакая мысль от КО :) Но даже идеальные программисты не всегда могут представить, как именно могут попортиться данные. Программисты на С/С++ меня поймут, как сложно отловить проблему, если по какой-то причине размеры структуры в разных частях программы перестанут совпадать. И это крайне сложно спрогнозировать. Очень странно читать про то, что ни один язык и ни один тул внезапно не поддерживают дебаг по брекпоинтам.
3. Ассерты. Ассерты — это, конечно, хорошо. Но вот ассерты в библиотеке вместо эксепшена — это очень, очень плохо. За это вас будут ненавидеть. Про сообщения в ассертах — ещё один совет от КО, видимо :)
4. Проверка ошибок. Простите, но ошибки не проверяют только плохие программисты. Именно поэтому код на С изобилует goto, а в коде на C++ основной цикл начинается с try {. Нельзя вызвать malloc и не проверить потом то, что он вернул. Это — нормальные стандарты индустрии, чуть ли не code style guide. В C++ именно для этого используется RAII + механизм исключений. Уж не знаю, стандарты какой именно индустрии вы имели в виду.
Отдельно стоит уточнить, что априори считается, что базовые библиотеки типа STL работают без ошибок, иначе весь код состоял бы из мешанины проверок и никогда не завершил бы свою работу.
Далее, по пунктам:
1. Если есть сбои в логике — останов программы. Зачем же тогда придумали try..except конструкции, если не для попыток починить возникшую проблему? Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место. Если не удалось обслужить одного клиента — ладно, отправим ему ошибку. Но зачастую это никак не мешает обрабатывать следующих клиентов в этой же программе. Более того, зачастую сбои в логике нельзя отследить автоматически в процессе работы программы. Если вы где-то проехались по стеку — вы этого нифига не заметите, просто через некоторое время ваша программа упадёт в корку, в самом неожиданном месте.
2. Прогнозирование ошибок. Дебаг сообщения в лог — это, безусловно, полезно и позволяет легче находить проблему. Да, их часто добавляют в момент написания кода. Эдакая мысль от КО :) Но даже идеальные программисты не всегда могут представить, как именно могут попортиться данные. Программисты на С/С++ меня поймут, как сложно отловить проблему, если по какой-то причине размеры структуры в разных частях программы перестанут совпадать. И это крайне сложно спрогнозировать. Очень странно читать про то, что ни один язык и ни один тул внезапно не поддерживают дебаг по брекпоинтам.
3. Ассерты. Ассерты — это, конечно, хорошо. Но вот ассерты в библиотеке вместо эксепшена — это очень, очень плохо. За это вас будут ненавидеть. Про сообщения в ассертах — ещё один совет от КО, видимо :)
4. Проверка ошибок. Простите, но ошибки не проверяют только плохие программисты. Именно поэтому код на С изобилует goto, а в коде на C++ основной цикл начинается с try {. Нельзя вызвать malloc и не проверить потом то, что он вернул. Это — нормальные стандарты индустрии, чуть ли не code style guide. В C++ именно для этого используется RAII + механизм исключений. Уж не знаю, стандарты какой именно индустрии вы имели в виду.
Отдельно стоит уточнить, что априори считается, что базовые библиотеки типа STL работают без ошибок, иначе весь код состоял бы из мешанины проверок и никогда не завершил бы свою работу.
Зачем же тогда придумали try..except конструкции
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место.
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
И это крайне сложно спрогнозировать.
Для «программиста на С/С++» — да. Для профессионала — нет.
За это вас будут ненавидеть.
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
Четвёртый пункт вообще не понятно зачем и для кого.
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
Если не удалось прочитать файл — это не значит, что надо сразу ошибку валить. Можно сначала попробовать прочитать файл из копии, и восстановить его в изначальное место.
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
И это крайне сложно спрогнозировать.
Для «программиста на С/С++» — да. Для профессионала — нет.
За это вас будут ненавидеть.
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
Четвёртый пункт вообще не понятно зачем и для кого.
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
И что же помещают в except реальные программисты? Просветите, пожалуйста!
А вот за это уже надо сразу давать по башке канделябром. Если в задании сказано, что нужно прочитать файл, любое творчество программиста надо пресекать на корню. Потому что не его ума дело, гадать почему его там нет.
В задании сказано «Записать файл пользователя, когда он попросит. Отдать файл пользователю, когда он попросит». Что, куда писать, как обрабатывать ошибки — это забота программиста. Вы как считаете, fsck тоже нельзя запускать, потому что оно само ошибки файловой системы при старте лечит, да? Что уж говорить про распределённые системы, каждая часть из которых по-определению ненадёжна.
Для «программиста на С/С++» — да. Для профессионала — нет.
О, раз вы профессионал, видимо, то посоветуйте, как лучше быть: в каждую функцию вместе с указателем на структуру передавать её sizeof и её «сигнатуру», или можно ограничиться только некоторыми? Или структуры нельзя в функции передавать? А сколько процентов производительности это съест?
Если не совать в библиотеку то, что туда не влазит, можно не только сохранить нервы, но и не делать фигню.
О, неплохой совет. У меня тут пользователь картинку прислал, и написал, что там jpeg. Я в вашу библиотечку запихнул его, а в файлике на самом то деле gif оказался. Библиотечка такого подвоха не ожидала, кинула assert, программа умерла, пользователь получит сообщение: «Извините, сервис временно недоступен. Попробуйте ещё раз.». А вы могли бы и exception кинуть, я бы тогда пользователю человеческим языком написал, что мол плохой формат картинки. Или попробовал картинку уже как gif обработать — пользователь то знать не желает, что у него там внутри, он картинку залить хочет.
Или вот, вчера было: приходит кука, я её значение разбираю при помощи boost::tokenizer. Если совершенно случайно значение куки оказывается пустым — токенайзер мне ассерт кидает, сервис падает. Конечно, я потом проверку добавил, но мне, как разработчику, такая библиотека не нравится.
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
А в сертифицированном софте сертифицированная библиотека надёжной не считается? Надёжная != не кидает ошибок. Если я запихнул что-то плохое — библиотека должна мне об этом сказать. Надёжная — это значит, что она соответствует всем формальным требованиям и работает именно так, как написано в спецификации на неё. Или предлагаете обкладывать добавление элемента в список проверками? А как проверки написать без использования этого же самого списка, самопальный писать?
Вообще, вопрос сертификации софта — это отдельная большая проблема, и она слабо пересекается с темами, которые вы затронули в своём посте.
В задании сказано
Если под решение придумывать задачу, можно далеко уехать.
У меня тут пользователь картинку прислал, и написал, что там jpeg. Я в вашу библиотечку запихнул его, а в файлике на самом то деле gif оказался.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
пользователь то знать не желает, что у него там внутри, он картинку залить хочет.
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Остальное настолько грустно, что оставлю без внимания.
Если под решение придумывать задачу, можно далеко уехать.
У меня тут пользователь картинку прислал, и написал, что там jpeg. Я в вашу библиотечку запихнул его, а в файлике на самом то деле gif оказался.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
пользователь то знать не желает, что у него там внутри, он картинку залить хочет.
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Остальное настолько грустно, что оставлю без внимания.
Если под решение придумывать задачу, можно далеко уехать.
Не знаю, какую задачу придумали вы, а я именно эту имел в виду изначально.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
Внесите конструктивное предложение. Есть ваша библиотека, которая принимает на входе только jpeg и умеет его ресайзить. Есть пользователь, который прислал мне какие-то данные. Есть моя программа, которая хочет вашей библиотекой отресайзить картинку и сохранить её. Что делать, если пользователь пришлёт gif под видом jpeg (камера у него такая дурацкая, а в его операционной системе картинка отображается отлично)?
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Угу, я щас пойду рассказывать девочке 13 лет, как открыть в hex редакторе бинарный файл и посмотреть его заголовок. У неё картинка внутри, она это отлично знает, потому что в просмоторщике фотографий на её компьютере картинка показывается.
Остальное настолько грустно, что оставлю без внимания.
Ну уж нет, раз написали статью — то потратьте ещё 15 минут и ответьте развёрнуто на вопросы к ней. Или времени нет? «В такой ситуации или крестик снять, или трусы надеть.»
Наверно, самое логичное решение — не использовать библиотеку для того, для чего она не предназначена. Но ваш подход мне нравится.
Простите, а разве валидацией содержимого файла, jpeg ли это, не библиотека работы с jpeg изображениями должна заниматься? А нафига она мне тогда такая нужна, если она этим не занимается?
А что с ответами на остальные вопросы? Вы не способны на них ответить?
А что с ответами на остальные вопросы? Вы не способны на них ответить?
Между библиотекой и коробочным продуктом есть небольшая разница. Если в документации написано, что строка должна заканчиваться нулём, не дело библиотеки удивляться, если вдруг ей скормили триста килобайт, когда хотели тридцать.
Если вы делаете в библиотеке assert, то вы автоматически не можете выполнить того, что написано у вас же в посте в разделе «Любой интерфейс должен возвращать ошибку на адекватном уровне». И, в ряде случаев, не можете выполнить даже то, что написано во второй половине поста, про логирование, т.к. логирование в библиотеке не всегда допустимо.
Честно говоря, где бы вы ни кидали ассерты — это автоматически лишает вас возможности проинформировать пользователя о возникшей проблеме, а из малопонятного «Assertion `jpeg_magic != JFIF' failed.» пользователь сможет узнать только то, что вы написали плохую программу.
Честно говоря, где бы вы ни кидали ассерты — это автоматически лишает вас возможности проинформировать пользователя о возникшей проблеме, а из малопонятного «Assertion `jpeg_magic != JFIF' failed.» пользователь сможет узнать только то, что вы написали плохую программу.
Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные
Подождите-подождите. А если мы пишем клиентское приложение, которое должно работать на любой машине пользователя. О какой сертифицированности вы говорите?
мы пишем клиентское приложение, которое должно работать на любой машине пользователя
Этпростопиздец.
Ну скажите, что вы так глупо пошутили. Пусть останется хоть какая-то вера в людей.
Этпростопиздец.
Ну скажите, что вы так глупо пошутили. Пусть останется хоть какая-то вера в людей.
Тут vit_r прав, сертифицированный софт требует сертифицированных библиотек, сертифицированной ОС и сертифицированного железа. Простейший пример — Oracle.
Однако сертифицированный != безошибочный. it.slashdot.org/story/11/12/20/0127215/software-bug-caused-qantas-airbus-a330-to-nose-dive. При этом в гражданской авиации одна из самых строгих систем сертификации.
Однако сертифицированный != безошибочный. it.slashdot.org/story/11/12/20/0127215/software-bug-caused-qantas-airbus-a330-to-nose-dive. При этом в гражданской авиации одна из самых строгих систем сертификации.
Я говорю о том, что не весь софт можно засертифицировать. Это может быть банковский клиент, для которого важна надёжность и безопасность, но он должен работать даже на несертифицированном железе.
Тут 2 варианта: либо писать хорошее приложение, либо тупо отвечать всем: «Вы используете несертифицированную ОС, поэтому мы вам не можем гарантировать работы нашего приложения.». И если карта ляжет, как у Оракла, то второй вариант вполне себе рабочий. Но я с вами согласен, отпинываться подобными фразами вместо починки ошибок и несовместимостей — это проблема, и её затронул автор поста:
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
<...>
Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже…
Ооо, я нашёл в вашем оригинальном посте, что же помещают в except реальные программисты:
Если вы видите, что гениальный коллега произвёл фигню, ни в коем случае не надо обращаться к нему с намёками про то, что файлы не всегда открываются или исходные данные не всегда правильны. Это приведёт только к ненужным дискуссиям о вероятностях, надёжности и тупых пользователях. Особенно, если гений получил гуманитарное образование или докторскую по программизму. В немецких условиях возникнут ещё траблы с начальством.
Настоящий циничный идиот просто вставляет в нужное место ловушку, которая производит останов, когда случается невозможное, и код гениального коллеги выдаёт мусор, и терпеливо ожидает на берегу реки.
Да, он прибежит. Да, он будет возмущён. Он расскажет про качество и искусство писать нормальный код. Намекнёт про криворуких раздолбаев, на неумение создавать правильные программы, на людей, которые вместо функциональности производят ошибки.
Вот тут главное — не поддаться моменту, не начать отстаивать свою гениальность, не указывать пальцем… Нужно искренне удивиться, не поверить, усадить рядом, попросить показать, спросить об условиях и результатах, медленно и подробно дойти до причин, а потом аккуратно и безжалостно ткнуть мордой в нассатое.
После чего изобразить искреннее удивление, поговорить о редких и невероятных случаях, и отправить гения с пойманным багом в зубах вносить «неожиданные дополнения».
Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Мне кажется, тесты и пишутся для того, чтобы ошибки не возникали вновь.
А если писать сначала тесты, а потом под них функционал, у вас не будет голого функционала, для которого нет тестов.
Единственное, что могут сделать подобные тесты — выявить некоторые ошибки и описки. Обычно «полностью оттестированный» код валится на первом же тесте, сделанном не для того, чтобы «писать под него функционал».
Чтобы не валилось — тесты должны быть фактически ТЗ выраженном в коде + несколько граничных случаев.
Тогда просто не на чем будет сыпаться. А если даже и посыпалось — тест остался и это гарантирует, что эта ошибка уже не повторится. Я не буду расхваливать TDD, но разница между написанием тестов ДО и ПОСЛЕ очень большая.
Хотя при желании уронить можно всё что угодно:
Тогда просто не на чем будет сыпаться. А если даже и посыпалось — тест остался и это гарантирует, что эта ошибка уже не повторится. Я не буду расхваливать TDD, но разница между написанием тестов ДО и ПОСЛЕ очень большая.
Хотя при желании уронить можно всё что угодно:
Напомнило
— Купил хваленую германскую соковыжималку, а она сломалась.
— А много сока вы выжали?
— Да чуть—чуть яблочного и апельсинового, а уже на березовом она и накрылась...
— А много сока вы выжали?
— Да чуть—чуть яблочного и апельсинового, а уже на березовом она и накрылась...
Я, что и понятно, книгу не читал, а только пару минут смотрел на картинку
Насколько я понял, ключевая идея в том, что система неким образом замечает и репортит проблему, после чего происходит остановка вплоть до устранения проблемы.
по этому поводу есть две мысли:
1. Не всегда подходы, работающие на материальном производстве, применимы один в один к разработке ПО. Простейший пример: если где-то как-то нашлась проблема, то пока ее не устранили — конвейер, если его не остановить, будет клепать эту проблему в каждое изделие. В случае ПО это не совсем так.
Я хочу сказать, что зачастую подходы производства нужно как-то адаптировать к разработке ПО, а не тупо копировать. Вполне допускаю, что автор подобную адаптацию делал, но не зная в деталях исходного процесса и примененных адаптаций — трудно говорить на одном языке.
2. С другой стороны, идея останова присутствует во многих практиках разработки ПО. Только эти остановы вынесены в процесс разработки, а не в процесс работы приложения. (но и на картинке останавливается производство (line), а не конкретное изделие).
Примеры остановов в разработке ПО:
— не собрался билд
— билд собрался, но приемочные тесты (на билд или фичу) не прошли
— приемочные тесты прошли, но далее нашлись критичные баги, которые блокируют релиз.
И — линия останавливается, в том смысле что новое изделие не поставляется клиентам.
Такое впечатление, что автор как раз предлагает переместить останов в саму программу, то есть в работающее изделие (автомобиль на трассе). Но не вполне понятно, как это реализовывать, какие бенефиты (насколько заметные) это дает, и как избежать останова на продакшене (выключения двигателя во время движения).
Или я статью и картинку совсем неправильно понял?
Насколько я понял, ключевая идея в том, что система неким образом замечает и репортит проблему, после чего происходит остановка вплоть до устранения проблемы.
по этому поводу есть две мысли:
1. Не всегда подходы, работающие на материальном производстве, применимы один в один к разработке ПО. Простейший пример: если где-то как-то нашлась проблема, то пока ее не устранили — конвейер, если его не остановить, будет клепать эту проблему в каждое изделие. В случае ПО это не совсем так.
Я хочу сказать, что зачастую подходы производства нужно как-то адаптировать к разработке ПО, а не тупо копировать. Вполне допускаю, что автор подобную адаптацию делал, но не зная в деталях исходного процесса и примененных адаптаций — трудно говорить на одном языке.
2. С другой стороны, идея останова присутствует во многих практиках разработки ПО. Только эти остановы вынесены в процесс разработки, а не в процесс работы приложения. (но и на картинке останавливается производство (line), а не конкретное изделие).
Примеры остановов в разработке ПО:
— не собрался билд
— билд собрался, но приемочные тесты (на билд или фичу) не прошли
— приемочные тесты прошли, но далее нашлись критичные баги, которые блокируют релиз.
И — линия останавливается, в том смысле что новое изделие не поставляется клиентам.
Такое впечатление, что автор как раз предлагает переместить останов в саму программу, то есть в работающее изделие (автомобиль на трассе). Но не вполне понятно, как это реализовывать, какие бенефиты (насколько заметные) это дает, и как избежать останова на продакшене (выключения двигателя во время движения).
Или я статью и картинку совсем неправильно понял?
Кхм, аккаунт автора зарегистрирован в 2008 году, первая активность сегодня. Если посмотреть на комментарии автора поста, то почти очевидным становится факт, что кто-то просто троллит. Нет, серьезно, разве трудно конструктивный «пост + диалог» отличить от НЕконструктивного?
Адекватный уровень для ошибки в логике выполнения — останов программы
останов — исправьте опечатку
Ну, чисто технически это не опечатка: ru.wiktionary.org/wiki/останов
Чисто технически — нет, а логически — да (http://ru.wikipedia.org/wiki/%D0%9E%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2)
ru.wikipedia.org/wiki/Точка_останова
Не придирайтесь к таким мелочам. Ещё в СССР было что-то с «остановом программы», так что термин правильный.
Не придирайтесь к таким мелочам. Ещё в СССР было что-то с «остановом программы», так что термин правильный.
Интересно, что философия создателей erlang-а тоже утверждает, что все программисты не гении, везде могут быть ошибки, все сторонние библиотеки — рассадники багов.
Но вместо того, чтобы гоняться за каждой ошибкой, они предлагают назвать любой код ошибочным по-определению, изолировать всё от всего и строить системы с супервизорами и самовосстановлением, где ошибка в любой части не критична и не мешает остальному.
В таких системах некоторые репорты вполне можно игнорировать и прагматично отправлять в /dev/null.
Но вместо того, чтобы гоняться за каждой ошибкой, они предлагают назвать любой код ошибочным по-определению, изолировать всё от всего и строить системы с супервизорами и самовосстановлением, где ошибка в любой части не критична и не мешает остальному.
В таких системах некоторые репорты вполне можно игнорировать и прагматично отправлять в /dev/null.
Я предпочитаю заказывать юнит-тесты на любой однажды упавший функционал.
Выгодно.
Выгодно.
После прочтения статьи и ваших попробую объяснить вам как вы здесь выглядете для разработчиков.
Заходите в больницу и говорите так:
автор: Вы медики работаете не эффективно. Хирурги, окулисты, онкологи не нужны. Все достаточно просто. Можно полечится дома самому с помощью трав и таблеток — быстро и эффективно. Онкологи делают химитерапию лишь для того что бы казаться умным и важным. Хирурги не нужны — они делают операцию, т.е. режут людей лишь для того что бы выглядеть гениями и разбирающимися в медицине.
медики: Ну ок — какие есть доказательства? Кого нибудь уже вылечили? Раскажете как таблетками вылечить аппендицит?
автор: Ну вам еще доказательства нужны? Что бы понять мою мысль вы должны быть определенного уровня развития.
медики: но мы каждый день сталкиваемся с болезнями и каждый день лечим людей и панацеи не нашли
автор: а у меня дома тоже есть аспирин — я не медик, но я его использую когда «нормальных врачей» не допускают.
астрономы: Так есть же целые кафедры за рубежом и у нас и все исследования показывают что панацеи нет и каждый день появляются новые вирусы.
автор: Один дурак сказал, сотни повторили. Панацея есть я вон в той книжке прочитал.
Вообщем резюмируя:
Вы говорите что программисты считают что нельзя писать программы без ошибок потому, что так сказал один дурак а сотни повторили — однако при этом вы не замечаете что своих мыслей и своих выводов у вас нет совсем — только то что прочитали в книжке.
Вы говорите что не собираетесь цитировать книги и учить недалеких людей уму разуму бесплатно, но при этом похоже вся статья из книжки а комментарии сплошные ссылки на книгу и тупизм недалеких читателей.
я считаю себя проф. разработчиком. и как все разработчики я мечтаю быстро писать программы и поставлять решение что бы зарабатывать больше денег. Именно поэтому я трачу на книги до 2-3 тыс. в месяц. И я даже принял участие в написание одной. Именно поэтому, когда осваиваю новую технологию и платформу понемногу пишу фреймворки которые позволяют следующую разработку вести значительно быстрее собирая из готовых модулей. И так пишут практически все разработчики.
Но мы видим что на вас снизошло озарение и дразните нас: Вот — можно не заморачиваться, не писать сложных тестов, не читать сотни умных книг — достаточно прочитать одну — вот эту и научитесь очень быстро и качественно писать надежный код почти бесплатно — а вы идиоты этого не можете — потому что вы не того уровня развития. А бесплатно учить вас уму разуму не хочу.
Да я не читал вашу книгу но прочитал добрый десяток аналогичных книг на эту тему и мне кажется, несмотря на то, как вы говорите, можете читать на английском — похоже вы абсолютно не поняли оттуда ни слова.
По сути вы не поняли даже своей же статьи которую написали здесь: вы советуете не писать в комментариях Stupid idea. Does not work, if N < 0. Correct ASAP.
Но фактически именно это вы и делаете, называя всех разработчиков и всех ученных идиотами а вы один познали истину и показывая что вы считаете ниже своего достоинства приводить какие либо аргументы или хотя бы примеры, не говоря уже о каких либо доказательствах.
Я думаю вас здесь смогут понять если приведете хоть что нибудь — свое портфолие/резюме, какие нибудь работы, какие нибудь примеры, какие нибудь аргументы. Хоть что нибудь подтверждающее что вы проверили на практике вашу теорию и она работает.
Заходите в больницу и говорите так:
автор: Вы медики работаете не эффективно. Хирурги, окулисты, онкологи не нужны. Все достаточно просто. Можно полечится дома самому с помощью трав и таблеток — быстро и эффективно. Онкологи делают химитерапию лишь для того что бы казаться умным и важным. Хирурги не нужны — они делают операцию, т.е. режут людей лишь для того что бы выглядеть гениями и разбирающимися в медицине.
медики: Ну ок — какие есть доказательства? Кого нибудь уже вылечили? Раскажете как таблетками вылечить аппендицит?
автор: Ну вам еще доказательства нужны? Что бы понять мою мысль вы должны быть определенного уровня развития.
медики: но мы каждый день сталкиваемся с болезнями и каждый день лечим людей и панацеи не нашли
автор: а у меня дома тоже есть аспирин — я не медик, но я его использую когда «нормальных врачей» не допускают.
астрономы: Так есть же целые кафедры за рубежом и у нас и все исследования показывают что панацеи нет и каждый день появляются новые вирусы.
автор: Один дурак сказал, сотни повторили. Панацея есть я вон в той книжке прочитал.
Вообщем резюмируя:
Вы говорите что программисты считают что нельзя писать программы без ошибок потому, что так сказал один дурак а сотни повторили — однако при этом вы не замечаете что своих мыслей и своих выводов у вас нет совсем — только то что прочитали в книжке.
Вы говорите что не собираетесь цитировать книги и учить недалеких людей уму разуму бесплатно, но при этом похоже вся статья из книжки а комментарии сплошные ссылки на книгу и тупизм недалеких читателей.
я считаю себя проф. разработчиком. и как все разработчики я мечтаю быстро писать программы и поставлять решение что бы зарабатывать больше денег. Именно поэтому я трачу на книги до 2-3 тыс. в месяц. И я даже принял участие в написание одной. Именно поэтому, когда осваиваю новую технологию и платформу понемногу пишу фреймворки которые позволяют следующую разработку вести значительно быстрее собирая из готовых модулей. И так пишут практически все разработчики.
Но мы видим что на вас снизошло озарение и дразните нас: Вот — можно не заморачиваться, не писать сложных тестов, не читать сотни умных книг — достаточно прочитать одну — вот эту и научитесь очень быстро и качественно писать надежный код почти бесплатно — а вы идиоты этого не можете — потому что вы не того уровня развития. А бесплатно учить вас уму разуму не хочу.
Да я не читал вашу книгу но прочитал добрый десяток аналогичных книг на эту тему и мне кажется, несмотря на то, как вы говорите, можете читать на английском — похоже вы абсолютно не поняли оттуда ни слова.
По сути вы не поняли даже своей же статьи которую написали здесь: вы советуете не писать в комментариях Stupid idea. Does not work, if N < 0. Correct ASAP.
Но фактически именно это вы и делаете, называя всех разработчиков и всех ученных идиотами а вы один познали истину и показывая что вы считаете ниже своего достоинства приводить какие либо аргументы или хотя бы примеры, не говоря уже о каких либо доказательствах.
Я думаю вас здесь смогут понять если приведете хоть что нибудь — свое портфолие/резюме, какие нибудь работы, какие нибудь примеры, какие нибудь аргументы. Хоть что нибудь подтверждающее что вы проверили на практике вашу теорию и она работает.
Про медицину пример хороший. Автор эдакий Кашпировский программирования.
Я написал текст про стратегию, которая поможет людям, понявшим что и почему, сэкономить массу времени и сил.
И мне абсолютно пофиг, как это выглядит для людей, не врубающихся о чём это и зачем.
Книга была упомянута одна и только как базис для разговора о мелком аспекте — экономика качества. На этой книжке основана CMMI и куча разной другой лабуды. Если благородный дон не только не читал, но даже не представляет о чём она и кто её автор, то деньги на литературу тратятся совершенно зря.
Список книг и статей для внеклассного чтения приводить — это где-то на пол сотни позиций минимум получится. Нафиг нужно. Тем более, что уровень, «книгу не читал, но посмотрел на картинку».
И мне абсолютно пофиг, как это выглядит для людей, не врубающихся о чём это и зачем.
Книга была упомянута одна и только как базис для разговора о мелком аспекте — экономика качества. На этой книжке основана CMMI и куча разной другой лабуды. Если благородный дон не только не читал, но даже не представляет о чём она и кто её автор, то деньги на литературу тратятся совершенно зря.
Список книг и статей для внеклассного чтения приводить — это где-то на пол сотни позиций минимум получится. Нафиг нужно. Тем более, что уровень, «книгу не читал, но посмотрел на картинку».
Хорошо быть программистом. Что-то пошло не так — это баг, посижу выловлю. Посидит и выловит. И баблос получит потом. А вы, программисты, сравните себя с хирургами. У хирурга нет права на ошибку, он каждое свое действие просчитывает до мелочей. У них работа такая — делать все правильно с первой попытки.
Если бы каждый программист работал в тех условиях, в которых работают хирурги, осмысливая и прогоняя в голове каждое свое действие, каждую строчку кода, тогда бы софт не был столь забагован.
И автор статьи вам прямо говорит — вы в большинстве своем чусадосы, которые максимум выучили синтаксис языка, олени, которые херачат десятки/сотни строк кода ежедневно не вникая в суть написанного и даже не пытаясь воспроизвести в голове логику рабоыт программы и возомнившие себя гениями.
В моем понимании нормальный программист — это человек, который решает задачу в голове, продумывает и просчитывает все возможные ошибки и только потом, после выстраивания логики реализует идею в конкретном синтаксисе и парадигме. И как раз как правильно пишет автор, в неопределенных местах делает фатальные чекпоинты, что бы при запуске получить в сообщении реал-тайм информацию и раскрыть неопределенность.
И в этом суть программирования. Автору респект, не обращай внимание на минусующее тебя быдло. Кодеров — миллионы, программистов — единицы. И мне почему то кажется, что ты относишься ко вторым.
Если бы каждый программист работал в тех условиях, в которых работают хирурги, осмысливая и прогоняя в голове каждое свое действие, каждую строчку кода, тогда бы софт не был столь забагован.
И автор статьи вам прямо говорит — вы в большинстве своем чусадосы, которые максимум выучили синтаксис языка, олени, которые херачат десятки/сотни строк кода ежедневно не вникая в суть написанного и даже не пытаясь воспроизвести в голове логику рабоыт программы и возомнившие себя гениями.
В моем понимании нормальный программист — это человек, который решает задачу в голове, продумывает и просчитывает все возможные ошибки и только потом, после выстраивания логики реализует идею в конкретном синтаксисе и парадигме. И как раз как правильно пишет автор, в неопределенных местах делает фатальные чекпоинты, что бы при запуске получить в сообщении реал-тайм информацию и раскрыть неопределенность.
И в этом суть программирования. Автору респект, не обращай внимание на минусующее тебя быдло. Кодеров — миллионы, программистов — единицы. И мне почему то кажется, что ты относишься ко вторым.
А ничего, что автор предлагает отлаживаться прямо на реальных данных, и отлаживать программу внесением диагностики?
Продолжая вашу метафору с хирургами, это как если бы хирург отрезал по кусочку, смотря на показания ЭКГ.
Продолжая вашу метафору с хирургами, это как если бы хирург отрезал по кусочку, смотря на показания ЭКГ.
die "OK", really.Увы, но в приборах и устройствах, которые делают что-то важное, в случае внутренних сбоев происходит останов и перезапуск в безопасном режиме. И отключение той реплики, которая сбоит, если у нас дублирование на три системы.
Про медицину не помню — в живую не видел, но в поездах и самолётах именно так.
Вещи типа die «OK» — это вообще про этап разработки. В работающих системах стоят assert или аналоги.
Про медицину не помню — в живую не видел, но в поездах и самолётах именно так.
Вещи типа die «OK» — это вообще про этап разработки. В работающих системах стоят assert или аналоги.
Несомненно, этап разработки. Тот самый, который по мнению blooderst происходит исключительно в голове, а потом единым потоком выливается на клавиатуру.
Позвольте поинтересоваться, а что вы конкретно подразумеваете, произнося фразу «в случае внутрених сбоев»?
А то, как-то нехорошо получается! Вы смешиваете в кучу все, обзываясь направо-налево непонятным словом «сбой»:
1) «Сбой» как «форсмажорные ситуации», в основном внешней, «хардварной природы», которые по определению находятся вне контроля вашей программы.
2)«Сбой»«дол^@%#изм говнокодера», который запутался в логике своего же собственного говнокода, и не нашел ничего умнее, чем «аварийно уронить всю систему», только потому что ему не было известно понятие «покрыть тестами».
Так вот, насчет таких «говнокодерских сбоев» у меня есть одна очень поучительная история:
Давным-давно в далекой-далекой галактике… жил-был nginx, выполнявший функции балансировщика, и были две ноды (потом к ним присоединилась третья и четвертая) на которых работали fastcgi-обработчики. Все выглядело супер — любую из нод можно было «прозрачно» погасить/перезагрузить/выткнуть/переткнуть/подоткнуть/проапгрейдить! Котороче с первого взгляда, не архитектура, а мечта! Но был внутри fastcgi-обработчика кусок говнокода, просто ронявший процесс fastcgi-сервера exception-ом. Как вы уже, догадались, тот юный падаван что писал данный кусок говнокода, по своей юности, просто не знал слова «unit test». А nginx, когда падала одна нода, тут же перенаправлял _тот_же_самый_ запрос на следующую ноду… вызывая такой же exception и такое же падение! В результате… все четыре ноды ложились всегда разом! К счастью, история кончилась более-менее хорошо, старшие опытные джедаи обьяснили тому юному падавану сакральный смысл значения «покрывать код тестами», бессмысленные exceptionы были выпилены и в далекой-далекой галактике вновь воцарился мир и покой!
Казалось бы причем тут тема продвигаемая автором топика и какое она имеет отношение к этой поучительной истории?
А то, как-то нехорошо получается! Вы смешиваете в кучу все, обзываясь направо-налево непонятным словом «сбой»:
1) «Сбой» как «форсмажорные ситуации», в основном внешней, «хардварной природы», которые по определению находятся вне контроля вашей программы.
2)
Так вот, насчет таких «говнокодерских сбоев» у меня есть одна очень поучительная история:
Давным-давно в далекой-далекой галактике… жил-был nginx, выполнявший функции балансировщика, и были две ноды (потом к ним присоединилась третья и четвертая) на которых работали fastcgi-обработчики. Все выглядело супер — любую из нод можно было «прозрачно» погасить/перезагрузить/выткнуть/переткнуть/подоткнуть/проапгрейдить! Котороче с первого взгляда, не архитектура, а мечта! Но был внутри fastcgi-обработчика кусок говнокода, просто ронявший процесс fastcgi-сервера exception-ом. Как вы уже, догадались, тот юный падаван что писал данный кусок говнокода, по своей юности, просто не знал слова «unit test». А nginx, когда падала одна нода, тут же перенаправлял _тот_же_самый_ запрос на следующую ноду… вызывая такой же exception и такое же падение! В результате… все четыре ноды ложились всегда разом! К счастью, история кончилась более-менее хорошо, старшие опытные джедаи обьяснили тому юному падавану сакральный смысл значения «покрывать код тестами», бессмысленные exceptionы были выпилены и в далекой-далекой галактике вновь воцарился мир и покой!
Казалось бы причем тут тема продвигаемая автором топика и какое она имеет отношение к этой поучительной истории?
Способов выявить сбои масса и они зависят от задач и условий. Реплика может останавливаться, если внутри сработает assert, или, если супервизор увидит, что она выдаёт не то, что две другие. И т.д.
Чтобы не рассказывать глупые сказки, просто упомяну, что у машиниста крутого немецкого скоростного поезда есть кнопочка перезапуска системы. И нажимают её гораздо чаще чем хочется. Естественно, если её нажмут на полной скорости, сразу произойдёт экстренная остановка. С самолётами сложнее. Хотя тот же Ариан-5 получил команду на самоликвидацию. Но там людей не было.
Чтобы не рассказывать глупые сказки, просто упомяну, что у машиниста крутого немецкого скоростного поезда есть кнопочка перезапуска системы. И нажимают её гораздо чаще чем хочется. Естественно, если её нажмут на полной скорости, сразу произойдёт экстренная остановка. С самолётами сложнее. Хотя тот же Ариан-5 получил команду на самоликвидацию. Но там людей не было.
Кнопочка reset-а выведенная человеку это правильно (как и вообще возможность ручного прямого управления в любой системе). Но, уже тот факт, что ее _вообще_ _нажимают_, как бы характеризует что код писанный «индусами», по большей части, тестировался такими же «индусами». И хвастаться тут нечем.
Вы, кстати, не ответили на мой вопрос что же вы подразумеваете под словом «сбой», а пытаетесь бодро перевести стрелки на «супервизор, который увидит, что что-то не то».
Вы, кстати, не ответили на мой вопрос что же вы подразумеваете под словом «сбой», а пытаетесь бодро перевести стрелки на «супервизор, который увидит, что что-то не то».
Не сложно заметить, что я тут не отчитываюсь, а просто комментирую то, что мне интересно.
Да, как бы, все уже заметили. Ведь Ваш весьма «прозрачно» читающийся «посыл», действительно «не сложно заметить» ;) И это естественно, это не способствует протеканию диалога с Вами в «конструктивном русле».
В софте, где за ошибки расплачиваются человеческими жизнями, тоже всё делается не проще чем у хирургов. Правда, делается не оптимально, не всегда правильно и очень-очень дорого. С другой стороны, хирурги тоже не все хорошие.
А про то, что представляют из себя программисты, в этом варианте было предусмотрительно вырезано. Иначе возмущения было бы на порядок больше.
А про то, что представляют из себя программисты, в этом варианте было предусмотрительно вырезано. Иначе возмущения было бы на порядок больше.
В софте, где за ошибки расплачиваются человеческими жизнями, тоже всё делается не проще чем у хирургов. Правда, делается не оптимально, не всегда правильно и очень-очень дорого
Вы не последовательны в своих действиях и мыслях. Не далее, как несколько часов назад Вы утверждали, что качество ничего не стоит: habrahabr.ru/post/164277/#comment_5651501, а теперь пишите, что очень-очень дорого…
1. Ни один человек не может удержать в голове систему размера ядра операционной системы.
2. Человеческий мозг не приспособлен для прокручивания в голове всех возможных негативных кейсов, потому что он природой заточен на положительные. Именно поэтому человек так хорошо играет в шахматы, ездит по треку лучше роботов и т.д.
3. Любой хороший программист выстраивает логику работы программы в голове (рисуя на бумажке, составляя майндмэпы или просто размышляя, кому как удобнее), а потом отражает её в коде.
У всех бывают ошибки, в том числе и у хирургов. Вопрос лишь в том, как минимизировать их количество. Для этого в критичных отраслях типа авиации давно придумали схемы, позволяющие максимально сократить количество ошибок в коде, и, самое главное, обнаружить их на как можно более раннем этапе разработки. Для обычных же программ, так сказать, повседневных, это сводится к 2-3 уровневому тестированию: (опционально) юнит-тесты, тесты, проводимые разработчиком на положительные и основные отрицательные кейсы, и полноценное функциональное тестирование продукта в prod-like среде, под похожей на реальную нагрузкой.
В целях минимизации ошибок в системах, разрабатываемых для mission critical задач, но не связанных непосредственно с человеческими жизнями, обычно применяются code style guide с жёсткими рамками (типа запрещения работы с динамической памятью) и специализированными фреймворками. В итоге возможность появления ошибок на стадии кодирования почти полностью исключена, а на стадии проектирования внесения изменений, требуемых бизнесом заказчика, решается за счёт двойной проверки.
В этом посте автор написал ряд очевидных мыслей (типа надо добавлять дебажные сообщения, писать внятные сообщения об ошибках, показывать пользователю ошибки на его языке, смотреть состояние в особых точках программы), ряд непонятных заблуждений (писать die т.к. нет брекпоинтов, что программисты не проверяют коды ошибок в коде, и что они вообще зазнайки и не хотят признавать своих ошибок, и что это — стандарт индустрии), и закончил пост никак.
Какие можно сделать выводы?
Может быть, автор работал с самыми дешёвыми аутсорсерами из индии, которые действительно обладают некоторыми из перечисленных качеств, такими, как нежелание признавать ошибки (азиатский тип мышления) и низкая квалификация? Но зачем тогда обобщать это, называть это стандартом для индустрии? Или может быть у автора был неудачный опыт с agile методологиями, опять же низкоквалифицированной командой? В любом случае, это не даёт повода ни автору, ни вам заявлять, что в индустрии всё так. Ведь индустрия — это в том числе Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Особенно печально, что автор так и не указал, кто же он такой и чем занимается, откуда у него такая экспертная оценка состояния индустрии (и экспертная ли?). В комментариях он не отвечает на прямые вопросы, касающиеся частей статьи или его профессиональных навыков. Можно ли доверять экспертному мнению человека, который не подкрепил свои доводы ничем? Можно ли доверять экспертному мнению человека, который даже не написал, в какой именно области он эксперт?
2. Человеческий мозг не приспособлен для прокручивания в голове всех возможных негативных кейсов, потому что он природой заточен на положительные. Именно поэтому человек так хорошо играет в шахматы, ездит по треку лучше роботов и т.д.
3. Любой хороший программист выстраивает логику работы программы в голове (рисуя на бумажке, составляя майндмэпы или просто размышляя, кому как удобнее), а потом отражает её в коде.
У всех бывают ошибки, в том числе и у хирургов. Вопрос лишь в том, как минимизировать их количество. Для этого в критичных отраслях типа авиации давно придумали схемы, позволяющие максимально сократить количество ошибок в коде, и, самое главное, обнаружить их на как можно более раннем этапе разработки. Для обычных же программ, так сказать, повседневных, это сводится к 2-3 уровневому тестированию: (опционально) юнит-тесты, тесты, проводимые разработчиком на положительные и основные отрицательные кейсы, и полноценное функциональное тестирование продукта в prod-like среде, под похожей на реальную нагрузкой.
В целях минимизации ошибок в системах, разрабатываемых для mission critical задач, но не связанных непосредственно с человеческими жизнями, обычно применяются code style guide с жёсткими рамками (типа запрещения работы с динамической памятью) и специализированными фреймворками. В итоге возможность появления ошибок на стадии кодирования почти полностью исключена, а на стадии проектирования внесения изменений, требуемых бизнесом заказчика, решается за счёт двойной проверки.
В этом посте автор написал ряд очевидных мыслей (типа надо добавлять дебажные сообщения, писать внятные сообщения об ошибках, показывать пользователю ошибки на его языке, смотреть состояние в особых точках программы), ряд непонятных заблуждений (писать die т.к. нет брекпоинтов, что программисты не проверяют коды ошибок в коде, и что они вообще зазнайки и не хотят признавать своих ошибок, и что это — стандарт индустрии), и закончил пост никак.
Какие можно сделать выводы?
Может быть, автор работал с самыми дешёвыми аутсорсерами из индии, которые действительно обладают некоторыми из перечисленных качеств, такими, как нежелание признавать ошибки (азиатский тип мышления) и низкая квалификация? Но зачем тогда обобщать это, называть это стандартом для индустрии? Или может быть у автора был неудачный опыт с agile методологиями, опять же низкоквалифицированной командой? В любом случае, это не даёт повода ни автору, ни вам заявлять, что в индустрии всё так. Ведь индустрия — это в том числе Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Особенно печально, что автор так и не указал, кто же он такой и чем занимается, откуда у него такая экспертная оценка состояния индустрии (и экспертная ли?). В комментариях он не отвечает на прямые вопросы, касающиеся частей статьи или его профессиональных навыков. Можно ли доверять экспертному мнению человека, который не подкрепил свои доводы ничем? Можно ли доверять экспертному мнению человека, который даже не написал, в какой именно области он эксперт?
в какой именно области он эксперт?
В Донецкой ведь…
писать die т.к. нет брекпоинтов
Забавненько. Люди, похоже, текст не читают, а сразу начинают с комментариев.
В итоге возможность появления ошибок на стадии кодирования почти полностью исключена,
Тоже перл. Тем более, по сравнению с тем, что там на самом деле происходит и какие люди там работают.
Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Мы всё ещё о mission critical или уже о Бангалоре?
Особенно печально, что автор так и не указал, кто же он такой и чем занимается,
Автору это совершенно не нужно. Он пишет не для людей, которые определяют правильность мысли по звёздам на погонах.
Забавненько. Люди, похоже, текст не читают, а сразу начинают с комментариев.
В итоге возможность появления ошибок на стадии кодирования почти полностью исключена,
Тоже перл. Тем более, по сравнению с тем, что там на самом деле происходит и какие люди там работают.
Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Мы всё ещё о mission critical или уже о Бангалоре?
Особенно печально, что автор так и не указал, кто же он такой и чем занимается,
Автору это совершенно не нужно. Он пишет не для людей, которые определяют правильность мысли по звёздам на погонах.
Забавненько. Люди, похоже, текст не читают, а сразу начинают с комментариев.
Ой, это разве в статье было? Я то думал, только комментарии читал…
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Тоже перл. Тем более, по сравнению с тем, что там на самом деле происходит и какие люди там работают.
Видимо, у вас таки личная обида. Разные там люди работают, зависит от жадности вендора.
Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
А вы как, по ключевым словам только ориентируетесь? Тогда повторю — вышеперечисленные компании — это тоже часть индустрии. Делают продукты, которыми успешно пользуется весь мир.
Автору это совершенно не нужно. Он пишет не для людей, которые определяют правильность мысли по звёздам на погонах.
Люди хотят понять, откуда у автора такие мысли. Раз вы обобщаете свой частный опыт на всю индустрию — будьте добры, обоснуйте. Или признайте, что это проблемы проектов, в которых вы участвовали.
Ну, значит, читал и не понял. Тоже бывает.
Люди хотят понять, откуда у автора такие мысли.
Люди пытаются доказать, что «на самом деле всё совсем не так». Вот только попытки всё с какими-то левыми сказками и нерелевантными собственными переживаниями и от сертификаций внезапно перескакивают к страничкам на яваскрипте…
Люди хотят понять, откуда у автора такие мысли.
Люди пытаются доказать, что «на самом деле всё совсем не так». Вот только попытки всё с какими-то левыми сказками и нерелевантными собственными переживаниями и от сертификаций внезапно перескакивают к страничкам на яваскрипте…
Так поясните. Вот вы сами писали:
Смотрим выше, не поддерживает что?
не поддерживают точки останова с дебаг символами? Конечно поддерживают.
Логгер не поддерживает разные уровни сообщений? Так любой нормальный логгер умеет это, некоторые даже умеют не компилировать добавление дебажных логов в релизной версии бинарника.
Что я не так понял? Вы имели в виду что-то другое, что не поддерживается?
Простите, но это смешно. Во-первых, вы сами перескочили с темы отсутствия багов к сертифицикации. Я даже специально процитирую другой ваш комментарий:
Вот как, как связано априорное доверие к STL и наличие у неё какого-либо сертификата для софта, который принципиально сертифицирован не будет? К тому же, голословно заявив, что «результат предсказать практически невозможно.» вы не назвали ни одной программы, которая бы использовала STL но перепроверяла потом результат. Кстати, запихнуть что-то плохое в стандартные контейнеры довольно сложно, если не использовать приведения типов — компилятор просто не даст вам это сделать.
Во-вторых, касательно скриптиков на яваскрипте… Их тоже надо писать, и в них тоже желательно не иметь ошибок. Вы где-то в статье писали, что всё написанное касается только сертифицируемого софта для поездов? Нет. Тогда чем плох скрипт на яваскрипте как пример программы, в которой надо избежать багов?
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Смотрим выше, не поддерживает что?
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
не поддерживают точки останова с дебаг символами? Конечно поддерживают.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Логгер не поддерживает разные уровни сообщений? Так любой нормальный логгер умеет это, некоторые даже умеют не компилировать добавление дебажных логов в релизной версии бинарника.
Что я не так понял? Вы имели в виду что-то другое, что не поддерживается?
Люди пытаются доказать, что «на самом деле всё совсем не так». Вот только попытки всё с какими-то левыми сказками и нерелевантными собственными переживаниями и от сертификаций внезапно перескакивают к страничкам на яваскрипте…
Простите, но это смешно. Во-первых, вы сами перескочили с темы отсутствия багов к сертифицикации. Я даже специально процитирую другой ваш комментарий:
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Вот как, как связано априорное доверие к STL и наличие у неё какого-либо сертификата для софта, который принципиально сертифицирован не будет? К тому же, голословно заявив, что «результат предсказать практически невозможно.» вы не назвали ни одной программы, которая бы использовала STL но перепроверяла потом результат. Кстати, запихнуть что-то плохое в стандартные контейнеры довольно сложно, если не использовать приведения типов — компилятор просто не даст вам это сделать.
Во-вторых, касательно скриптиков на яваскрипте… Их тоже надо писать, и в них тоже желательно не иметь ошибок. Вы где-то в статье писали, что всё написанное касается только сертифицируемого софта для поездов? Нет. Тогда чем плох скрипт на яваскрипте как пример программы, в которой надо избежать багов?
Надо пригласить психолога для ТС — полезные местами вещи смачно перемешаны с обидами на более решительных умных товарищей.
я вот не думал что увижу вживую Эффект Даннинга — Крюгера. При чем так ярко выраженную.
Увы, но в приборах и устройствах, которые делают что-то важное, в случае внутренних сбоев происходит останов и перезапуск в безопасном режиме.
Мне интересно, Вы действительно не понимаете что ничего не понимаете о чем Вы говорите? И Вы правда не понимаете что сами себе абсолютно противоречите?
Просто из любопытства — Вы хотя бы примерно представляете КАК пишут код для самолетов и поездов? Просто из любопытства не попробовали хотя бы погуглить какие стандарты к качеству кода предъявляются и насколько медленно там пишется основной код? И как любой код тщательно тестируется и покрывается тестами? И как проходят аудит?
Мы проходили аудит при разработке бекенда навигационной системы для BMW — и вот как раз таки с довольно жестко спрашивали качество тестов и при чем требовали показать как заводятся таски, как они выполняются, как таски свзяаны с тестами, качество покрытия кода тестами, и качество покрытия тестами требования к системе — т.е. все то, что, судя по вашей статье — делать не надо.
При чем у нас были еще мягкие требования — для простой навигацонной системы. Судя по всему вы даже близко не представляете КАК пишется код для самолетов и поездов иначе эта статья не появилась бы на свет.
Увы, но в приборах и устройствах, которые делают что-то важное, в случае внутренних сбоев происходит останов и перезапуск в безопасном режиме.
Мне интересно, Вы действительно не понимаете что ничего не понимаете о чем Вы говорите? И Вы правда не понимаете что сами себе абсолютно противоречите?
Просто из любопытства — Вы хотя бы примерно представляете КАК пишут код для самолетов и поездов? Просто из любопытства не попробовали хотя бы погуглить какие стандарты к качеству кода предъявляются и насколько медленно там пишется основной код? И как любой код тщательно тестируется и покрывается тестами? И как проходят аудит?
Мы проходили аудит при разработке бекенда навигационной системы для BMW — и вот как раз таки с довольно жестко спрашивали качество тестов и при чем требовали показать как заводятся таски, как они выполняются, как таски свзяаны с тестами, качество покрытия кода тестами, и качество покрытия тестами требования к системе — т.е. все то, что, судя по вашей статье — делать не надо.
При чем у нас были еще мягкие требования — для простой навигацонной системы. Судя по всему вы даже близко не представляете КАК пишется код для самолетов и поездов иначе эта статья не появилась бы на свет.
Зачем мне гуглить, если код для поездов я писал, а с сертификацией для самолётов и автомобилей разбирался в рамках профессиональной деятельности? Естественно, не по википедии, а по оригиналам стандартов.
при разработке бекенда навигационной системы для BMW
Это достаточно простой уровень с простейшими требованиями, не завязанный на безопасность. Система управления поездом или контроллер управления тормозной колодкой автомобиля — вещи совершенно другие. Отличие между мной и вами только в том, что вы строите теории, а я знаю. Причём, не только про софт, но и на уровне организации процессов.
судя по вашей статье — делать не надо.
Мне необходимо ткнуть благородного дона лицом в то место, где написано «надо» и как раз для подобного случая? Причём, сказано почему именно надо.
при разработке бекенда навигационной системы для BMW
Это достаточно простой уровень с простейшими требованиями, не завязанный на безопасность. Система управления поездом или контроллер управления тормозной колодкой автомобиля — вещи совершенно другие. Отличие между мной и вами только в том, что вы строите теории, а я знаю. Причём, не только про софт, но и на уровне организации процессов.
судя по вашей статье — делать не надо.
Мне необходимо ткнуть благородного дона лицом в то место, где написано «надо» и как раз для подобного случая? Причём, сказано почему именно надо.
именно про это и говорю — вы меняете свое мнение так быстро что просто не понимаете что сами себе сильно противоречите:
Выше на комментарий: habrahabr.ru/post/164277/#comment_5652637
программу без ошибок можно написать за бесконечно большее время и бесконечно большой бюджет.
вы отвечаете: Это всё сказки и мифы. Один дурак написал — сотня повторила.
Здесь вы говорите что это не так — что меня надо ткнуть меня в то место где вы про это якобы пишете — навернео вы говорили про эти участки
> Естественно, мелочное тестирование необходимо, когда по стандарту надо подтвердить каждую строчку кода или пять раз в неделю вылавливать результаты посещения шаловливых ручек коллег. Но далее сами же критикуете этот подход — «это не двигает нас вперед. И очень хреново отражает работу в задачах реального времени и реальных данных.». «Индустрия молится на Unit Testing. Это модно, это прогрессивно, это агильно. Вот только цель его ответить на вопрос «Я, правда, гений, да?»»
это вы так считаете «надо»? Там Вы сказали так что весь подтекст такой — ну да есть там всякие unit-тесты и индустрия обязывает местами делать это — но это все херня для умников — надежные приложения можно сделать и без этого.
> Отличие между мной и вами только в том, что вы строите теории, а я знаю. Причём, не только про софт, но и на уровне организации процессов.
Знаете? И при этом не можете привести ни одного практического примера и ни одного аргумента, не можете сказать что конкретно вы писали, не можете сказать что конкретно делаете? Ведь суть всех ваших комментаривев можно свести к одному: если не поняли — вы дураки — вам бесплатно объяснять ничего не буду — читайте книгу.
Например, про себя могу сказать что работаю в софтверной компании, последние два года в направлении мобильных разработок. Последнее что мы выпустили около месяца назад это официальное приложение Шереметьево. Стараюсь выступать на конференциях, стараюсь помогать другим разработчикам — при чем консультирую достаточно много разработчиков практически каждый день.
Ну это я как теоретик, вам же, практику, не составит труда хоть немного рассказать о себе?
Выше на комментарий: habrahabr.ru/post/164277/#comment_5652637
программу без ошибок можно написать за бесконечно большее время и бесконечно большой бюджет.
вы отвечаете: Это всё сказки и мифы. Один дурак написал — сотня повторила.
Здесь вы говорите что это не так — что меня надо ткнуть меня в то место где вы про это якобы пишете — навернео вы говорили про эти участки
> Естественно, мелочное тестирование необходимо, когда по стандарту надо подтвердить каждую строчку кода или пять раз в неделю вылавливать результаты посещения шаловливых ручек коллег. Но далее сами же критикуете этот подход — «это не двигает нас вперед. И очень хреново отражает работу в задачах реального времени и реальных данных.». «Индустрия молится на Unit Testing. Это модно, это прогрессивно, это агильно. Вот только цель его ответить на вопрос «Я, правда, гений, да?»»
это вы так считаете «надо»? Там Вы сказали так что весь подтекст такой — ну да есть там всякие unit-тесты и индустрия обязывает местами делать это — но это все херня для умников — надежные приложения можно сделать и без этого.
> Отличие между мной и вами только в том, что вы строите теории, а я знаю. Причём, не только про софт, но и на уровне организации процессов.
Знаете? И при этом не можете привести ни одного практического примера и ни одного аргумента, не можете сказать что конкретно вы писали, не можете сказать что конкретно делаете? Ведь суть всех ваших комментаривев можно свести к одному: если не поняли — вы дураки — вам бесплатно объяснять ничего не буду — читайте книгу.
Например, про себя могу сказать что работаю в софтверной компании, последние два года в направлении мобильных разработок. Последнее что мы выпустили около месяца назад это официальное приложение Шереметьево. Стараюсь выступать на конференциях, стараюсь помогать другим разработчикам — при чем консультирую достаточно много разработчиков практически каждый день.
Ну это я как теоретик, вам же, практику, не составит труда хоть немного рассказать о себе?
«Карл Маркс и Фридрих Энгельс — это не муж и жена, а четыре разных человека» Честное слово, делать мне нечего, как объяснять ошибки в ваших логических построениях.
Что и кому я делаю, я даже клиентам рассказываю в самых общих чертах. Потому что все проекты обычно сопровождает договор о неразглашении, а бросаться словами Сименс, Алкатель, Бомбардир хорошо только для детского сада.
Поучать население я закончил лет пятнадцать назад. Потому что толку нет.
И дело не в том, чтобы бесплатно объяснять. Просто напрягает беседовать с людьми, которые вместо чтения книжек смотрят картинки. Да и разговор идёт не о написанном, а о каких-то дополнительных измышлениях вокруг этого.
Что и кому я делаю, я даже клиентам рассказываю в самых общих чертах. Потому что все проекты обычно сопровождает договор о неразглашении, а бросаться словами Сименс, Алкатель, Бомбардир хорошо только для детского сада.
Поучать население я закончил лет пятнадцать назад. Потому что толку нет.
И дело не в том, чтобы бесплатно объяснять. Просто напрягает беседовать с людьми, которые вместо чтения книжек смотрят картинки. Да и разговор идёт не о написанном, а о каких-то дополнительных измышлениях вокруг этого.
Я надеюсь смогу правильно донести мысль:
В своей статье местами вы пишете правильные и очевидные любому более менее среднего уровня программисту. Иначе сервисы подобные BugSense просто не существовали бы.
В качестве подтверждения части ваших идей я могу привести статью, что я совсем не против прототипирования и быстрой разработки а очень даже за
И конечно же надо все логгировать. В том же приложении Шереметьево в релизе мы поменяли поведение таким образом что если случается критическая необработанная ошибка, вместо того что бы молча свалится, пользовтелю выдается предупреждение типа «просим прощения, что то пошло не так, но мы это залоггировали и в следующей версии обязательно поправим» и сами в это время получаем детальный лог с подробным StackTrace с цепочкой вызовов с именами классов и методов, что значительно упрощает поиск причины возникновения ошибки в коде. а пользователя перенаправляем на главную страницу вместо того что бы валить приложение.
Набрасываются же на вас за те «откровения» что иногда можно увидеть у молодых разработчиков, которые недавно освоили азы какого нибудь языка программирования и поняли что оказывается разрабатывать то совсем не сложно как это стараются преподнести злобные и страшные программисты, которые скрывают что все просто на самом деле:
Вы утверждаете что логи наше все, но при этом вы категорически против try/catch:
> Зачем же тогда придумали try..except конструкции
> Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
По моему здесь просто высшая точка противоречия самому себе — все события надо логгировать но при этом try/catch только для «гениев» в плохом смысле слова гения. Как?! Как это вообще возможно такое написать и при этом иметь за плечами какой нибудь опыт разработки? Я все еще надеюсь что я вас не так понял и что не все так плохо на самом деле. Ну конечно есть еще вариант что на вас снизошло божественное озарение как можно логгировать ошибки без их обработки и вы по праву презираете нас разработчиков как низжих существ.
Agile, TDD, BDD и т.п. понятное дело что подходят далеко не всем. Одно дело когда разрабатываются микро-проекты от силы на 1-4 месяца на 1-2 человека и в этом случае TDD, BDD и т.п. может повысить стоимость разработки.
Но ведь далеко не все проекты находятся на уровне задач типа «интернет магазина», или «cms» и т.п. по сути уже давным давно обкатанных и избитых задач, которые в силу своей простоты еще есть возможность избежать каких либо методологий и тестирования и сделать продукт вовремя.
Именно поэтому появляются Agile, Kanban и TDD, BDD и т.п. что бы снизить существенно стоимость разработки, управлять сложностью, разбивать большие задачи на небольшие, что бы была возможность итеративно регулярно раз в две недели выпускать работающий продукт который можно и нужно показывать заказчику. С которым обсуждаются следующие фичи для следующей итерации. И конечно же так или иначе все их идеи далеко не новы и понятно что если бы огромное количество команд и компаний успешно его не использовали бы — они так и не получили бы сколь нибудь значимой популярности.
Критика в Ваш адрес направлена из за того что вы даже не допускаете мысль что Unit тесты, Agile и т.п. методологии это не игры гениев а что это ДЕЙСТВИТЕЛЬНО где то НАДО. Даже если от этого не зависят жизни людей. Вы уверены что эти умники и так могли бы все сделать быстро и качественно, но оттачивают свой ум и соревнуются друг с другом в гениальности и сообразительности — и все это за счет несчастного заказчика тратящий несколько миллионов долларов годами за какую нибудь систему, которую можно было бы написать в десятки раз быстрее просто заменив все эти извраты на хорошее логгирование.
Кстати вы совершенно неправильно понимаете ценность UnitTest-ов. Их ценность не в том что бы застраховать код от ошибок и избежать логгирования, как ошибочно думают многие из тех кто начинают его применять. Зеленый тест не гарантирует абсолютно ничего — только то что тест зеленый и все. Их ценность в том что он по сути вынуждает писать слабосвязанный код, который уже гораздо проще сопровождать и безболезненно рефакторить под часто меняющиеся требования. Мало того в больших системах зачастую пишут тест который имитируют соби и тест проверят — действительно ли логгер сработал и записал правильный лог о произошедшем событии?
Очень хорошо что вы осознали что логировать надо. И что это существенно помогает отлаживать софт. И вы это вживую используете в своих, судя по всему небольших проектах. Вас же критикуют за то что вы не понимаете что есть задачи совсем другого порядка которые нельзя решить одним лишь логгированием. И критикуют за то что понимать вы это категорически не желаете.
В своей статье местами вы пишете правильные и очевидные любому более менее среднего уровня программисту. Иначе сервисы подобные BugSense просто не существовали бы.
В качестве подтверждения части ваших идей я могу привести статью, что я совсем не против прототипирования и быстрой разработки а очень даже за
И конечно же надо все логгировать. В том же приложении Шереметьево в релизе мы поменяли поведение таким образом что если случается критическая необработанная ошибка, вместо того что бы молча свалится, пользовтелю выдается предупреждение типа «просим прощения, что то пошло не так, но мы это залоггировали и в следующей версии обязательно поправим» и сами в это время получаем детальный лог с подробным StackTrace с цепочкой вызовов с именами классов и методов, что значительно упрощает поиск причины возникновения ошибки в коде. а пользователя перенаправляем на главную страницу вместо того что бы валить приложение.
Набрасываются же на вас за те «откровения» что иногда можно увидеть у молодых разработчиков, которые недавно освоили азы какого нибудь языка программирования и поняли что оказывается разрабатывать то совсем не сложно как это стараются преподнести злобные и страшные программисты, которые скрывают что все просто на самом деле:
Вы утверждаете что логи наше все, но при этом вы категорически против try/catch:
> Зачем же тогда придумали try..except конструкции
> Для гениев. Да и человек с опытом прекрасно знает, что на самом деле в except в реальной ситуации помещают реальные программитсы.
По моему здесь просто высшая точка противоречия самому себе — все события надо логгировать но при этом try/catch только для «гениев» в плохом смысле слова гения. Как?! Как это вообще возможно такое написать и при этом иметь за плечами какой нибудь опыт разработки? Я все еще надеюсь что я вас не так понял и что не все так плохо на самом деле. Ну конечно есть еще вариант что на вас снизошло божественное озарение как можно логгировать ошибки без их обработки и вы по праву презираете нас разработчиков как низжих существ.
Agile, TDD, BDD и т.п. понятное дело что подходят далеко не всем. Одно дело когда разрабатываются микро-проекты от силы на 1-4 месяца на 1-2 человека и в этом случае TDD, BDD и т.п. может повысить стоимость разработки.
Но ведь далеко не все проекты находятся на уровне задач типа «интернет магазина», или «cms» и т.п. по сути уже давным давно обкатанных и избитых задач, которые в силу своей простоты еще есть возможность избежать каких либо методологий и тестирования и сделать продукт вовремя.
Именно поэтому появляются Agile, Kanban и TDD, BDD и т.п. что бы снизить существенно стоимость разработки, управлять сложностью, разбивать большие задачи на небольшие, что бы была возможность итеративно регулярно раз в две недели выпускать работающий продукт который можно и нужно показывать заказчику. С которым обсуждаются следующие фичи для следующей итерации. И конечно же так или иначе все их идеи далеко не новы и понятно что если бы огромное количество команд и компаний успешно его не использовали бы — они так и не получили бы сколь нибудь значимой популярности.
Критика в Ваш адрес направлена из за того что вы даже не допускаете мысль что Unit тесты, Agile и т.п. методологии это не игры гениев а что это ДЕЙСТВИТЕЛЬНО где то НАДО. Даже если от этого не зависят жизни людей. Вы уверены что эти умники и так могли бы все сделать быстро и качественно, но оттачивают свой ум и соревнуются друг с другом в гениальности и сообразительности — и все это за счет несчастного заказчика тратящий несколько миллионов долларов годами за какую нибудь систему, которую можно было бы написать в десятки раз быстрее просто заменив все эти извраты на хорошее логгирование.
Кстати вы совершенно неправильно понимаете ценность UnitTest-ов. Их ценность не в том что бы застраховать код от ошибок и избежать логгирования, как ошибочно думают многие из тех кто начинают его применять. Зеленый тест не гарантирует абсолютно ничего — только то что тест зеленый и все. Их ценность в том что он по сути вынуждает писать слабосвязанный код, который уже гораздо проще сопровождать и безболезненно рефакторить под часто меняющиеся требования. Мало того в больших системах зачастую пишут тест который имитируют соби и тест проверят — действительно ли логгер сработал и записал правильный лог о произошедшем событии?
Очень хорошо что вы осознали что логировать надо. И что это существенно помогает отлаживать софт. И вы это вживую используете в своих, судя по всему небольших проектах. Вас же критикуют за то что вы не понимаете что есть задачи совсем другого порядка которые нельзя решить одним лишь логгированием. И критикуют за то что понимать вы это категорически не желаете.
Ладно, в награду за столько набитых букв. Стоит запомнить, что приложения класса mission critical немного отличаются от того, что вы писали. И определяется это не «здравым смыслом», а толстыми нудными стандартами и подобными документами на отраслевом или фирменном уровне.
1. Критичные приложения управления дублируются. Хотя бы по той причине, что ошибки / сбое в электронике и железе должны тоже обрабатываться правильно. Надёжной считается система минимум из трёх реплик.
2. Правильной реакцией на ошибку, обработка которой не предусмотрена, является останов реплики. Потому что запрещено выдавать в результатах не валидную информацию. (В смысле за такие фокусы ответственные рискуют получить тюремный срок)
3. Диагностика сохраняется не для того, чтобы было интересно пользователю или программистам, а в качестве приложения для суда. Это немного другой класс ответственности.
4. Unit Testing применяется для того, чтобы доказать, что каждая строчка текста оттестирована. То есть, покрытия кода тестами должно быть сто процентов, что для функциональных тестов в больших системах просто не реально.
5. Agile, Kanban и TDD, BDD и т.п. и прочая лабуда стоимость разработки не снижают. Даже наоборот, когда вдруг случайно это начинают сравнивать в реальных цифрах, а не в ощущениях, получается дороже и хуже. Этому есть вполне объективные причины, которых я здесь упоминать не буду. Причины популярности тоже элементарны, но опять же повторять эти выкладки здесь мне влом. Также есть и пути лечения, но это получается совсем не то, что под этими волшебными словами понимает большинство народу. Всё отличие между мной и вами только в том, что вы предполагаете и верите, а я проверяю и знаю факты. Из смешного, встречал людей, которые применяют agile для софта для ядерных станций. Правда, это совсем не тот agile, на который молятся создатели сайтов и гораздо ближе к древним методам разработки тридцатилетней (минимум) давности. Но продают они это, естественно, под популярной маркой agile.
6. Сочетание слов «вы понимаете / считаете / думаете, что» без вопросительного знака показывает полную профессиональную непригодность человека, их говорящего. Единственное употребление, которое может прозвучать из уст профессионала имеет форму «Правильно ли я вас понял?»
В вашем случае в большинстве мест на вопрос будет стоять ответ «не правильно».
7. Дальше сюда мне писать не надо. Я и так слишком много времени потратил на пустопорожние беседы вроде «Я нашёл картинку в Интернете, докажи что она не правильна» и «Мне вот такое померещилось, значит ты дурак». На замечательные комменты «Я выяснил, что автор на самом деле...» отвечать тем более смысла не имеет.
Про остальные ляпы и заблуждения писать влом. Они есть практически в каждом абзаце, но нафиг и пофиг
1. Критичные приложения управления дублируются. Хотя бы по той причине, что ошибки / сбое в электронике и железе должны тоже обрабатываться правильно. Надёжной считается система минимум из трёх реплик.
2. Правильной реакцией на ошибку, обработка которой не предусмотрена, является останов реплики. Потому что запрещено выдавать в результатах не валидную информацию. (В смысле за такие фокусы ответственные рискуют получить тюремный срок)
3. Диагностика сохраняется не для того, чтобы было интересно пользователю или программистам, а в качестве приложения для суда. Это немного другой класс ответственности.
4. Unit Testing применяется для того, чтобы доказать, что каждая строчка текста оттестирована. То есть, покрытия кода тестами должно быть сто процентов, что для функциональных тестов в больших системах просто не реально.
5. Agile, Kanban и TDD, BDD и т.п. и прочая лабуда стоимость разработки не снижают. Даже наоборот, когда вдруг случайно это начинают сравнивать в реальных цифрах, а не в ощущениях, получается дороже и хуже. Этому есть вполне объективные причины, которых я здесь упоминать не буду. Причины популярности тоже элементарны, но опять же повторять эти выкладки здесь мне влом. Также есть и пути лечения, но это получается совсем не то, что под этими волшебными словами понимает большинство народу. Всё отличие между мной и вами только в том, что вы предполагаете и верите, а я проверяю и знаю факты. Из смешного, встречал людей, которые применяют agile для софта для ядерных станций. Правда, это совсем не тот agile, на который молятся создатели сайтов и гораздо ближе к древним методам разработки тридцатилетней (минимум) давности. Но продают они это, естественно, под популярной маркой agile.
6. Сочетание слов «вы понимаете / считаете / думаете, что» без вопросительного знака показывает полную профессиональную непригодность человека, их говорящего. Единственное употребление, которое может прозвучать из уст профессионала имеет форму «Правильно ли я вас понял?»
В вашем случае в большинстве мест на вопрос будет стоять ответ «не правильно».
7. Дальше сюда мне писать не надо. Я и так слишком много времени потратил на пустопорожние беседы вроде «Я нашёл картинку в Интернете, докажи что она не правильна» и «Мне вот такое померещилось, значит ты дурак». На замечательные комменты «Я выяснил, что автор на самом деле...» отвечать тем более смысла не имеет.
Про остальные ляпы и заблуждения писать влом. Они есть практически в каждом абзаце, но нафиг и пофиг
И не стоит себя так позорить откровенной дешевой и популярной у молодых разработчиков «отмазкой» прикрывающих пустое резюме NDA. Особенно смешно это выглядит когда вчерашний студент приходит и заявляет что он много работал над крупными проектами и мы должны платить ему бОльшую зарплату нежели мы можем ему предложить, но не может нам рассказать где он работал и кем и тем более над чем, потому что NDA.
Еще одно противоречие — говорите о проектах так как будто писали для секретной службы и чуть ли вам не придется убить нас, если расскажете над чем работали — ибо NDA, НО при этом говорите что работали всего лишь с рядовыми компаниями типа Sony, Alcatel и т.п. Здесь не мало людей знакомых с NDA. Неужели для вас сделали такое исключение и в отличае от своих же собственных сотрудников, даже после завершения и сдачи проекта в эксплуатацию, Вам запрещено упоминать кем вы работали, и в каком проекте принимали участие?
Еще одно противоречие — говорите о проектах так как будто писали для секретной службы и чуть ли вам не придется убить нас, если расскажете над чем работали — ибо NDA, НО при этом говорите что работали всего лишь с рядовыми компаниями типа Sony, Alcatel и т.п. Здесь не мало людей знакомых с NDA. Неужели для вас сделали такое исключение и в отличае от своих же собственных сотрудников, даже после завершения и сдачи проекта в эксплуатацию, Вам запрещено упоминать кем вы работали, и в каком проекте принимали участие?
О, прикольная фишка! Надо на заметку взять :))
— Так, платите мне 100500 денег!
— А где вы работали?
— Я работал во мнооогих местах, но NDA, не могу вам рассказать.
— Ок, а чем вы там занимались?
— NDA`ил конечно.
— Хм… А что такое например CRUD? Или Observer pattern? Ну или сколько будет 8 | 16 &~ 32?
— NDA! Это единственное умное сочетание которое я знаю.
— Так, платите мне 100500 денег!
— А где вы работали?
— Я работал во мнооогих местах, но NDA, не могу вам рассказать.
— Ок, а чем вы там занимались?
— NDA`ил конечно.
— Хм… А что такое например CRUD? Или Observer pattern? Ну или сколько будет 8 | 16 &~ 32?
— NDA! Это единственное умное сочетание которое я знаю.
Поучать население я закончил лет пятнадцать назад. Потому что толку нет.
Мне просто интересно: вы так округлили или действительно в 13(!) лет «закончили поучать людей потому, что толку нет».
Эта фраза уж совсем странная.
Мне просто интересно: вы так округлили или действительно в 13(!) лет «закончили поучать людей потому, что толку нет».
Эта фраза уж совсем странная.
2800 постов с 2006 года. Каждый день по посту-другому. :) Надеюсь, это как-то сгенерированно, иначе не ясно, когда товарищь писатель работает над софтом для поездов. :)
P.S. Ну, и гугл в придачу. Очень скрытный человек. :))
P.S. Ну, и гугл в придачу. Очень скрытный человек. :))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Source code как способ думать