О некачественности ПО.
Давно хотел эту штуку схоронить, вот наконец-то победил лень)
Собственно, скопировано из ветки вконтакте практически целиком 1в1 (единственная правка: два моих поста идуших подряд в 1 соединены). С автором мы вместе работали почти 2 года и части описываемых вещей я был участником на всех возможных ролях, как, собственно и автор).
Итак, слово передаётся ему..
Егор Смирнов
Уже в который раз после дальней поездки на машине у меня возникают в голове такие вот мысли:
Практически весь софт, в написании которого я участвовал в последние четыре года, был крайне ненадежным. Игровые сервера и сервера приложений постоянно валились, глючили, теряли связь, жрали память, плевались ошибками и ни в какую не хотели работать стабильно.
Даже прошедший тестирование в QA сервер обычно мог работать в лучшем случае неделю, после чего его приходилось придерживать руками чтобы он не падал. То есть подкрутить конфиг там, добавить памяти здесь, быстренько сделать маленький патчик, ребутнуть сеть, остановить лишние сервисы.
Если же намечася показ начальству или заказчику - показатели стабильности и надежности по закону подлости и вовсе пробивали пол и улетали к соседям снизу. И я уже как-то к подобному привык, да и все привыкли, "ну а чо, система сложная", типа так и надо. Ну упадет - перезапустим, делов-то. Подобные проблемы перестали восприниматься как проблемы и стали нормальным ходом работы, а отсутствие проблем - наоборот чем-то выдающимся, праздником прям каким-то.
А вот машина, на которой я езжу. Я купил ее уже не новой, четыре года, 55 тысяч пробега. И вот еду я и еду по финским дорогам. А потом по русским колдобинам. Ночью и днем, в дождь, туман. В разных режимах - то втапливая педаль в пол чтобы обогнать фуру на трассе, то часами крутя мотор на холостых в пробке. То несясь почти на предельной скорости, то тошня 40, убивая подвеску ямами на наших загородных "шоссе". Часами, днями, неделями и месяцами. И поршни все так же молотят, крутятся валы, ремни, дрыгают амортизаторы, бегает ток по проводам - тысячи деталей, система ничуть не менее сложная чем наши программы, а то и более, и вот оно работает и работает, годами, без усталости, в любых условиях, не давая даже повода открыть капот.
И я задумываюсь, что за инженеры создали это, да и многие другие произведения техники, что смогли сделать это так вот надежно. И почему мы, вся наша индустрия, которая в общем-то тоже считается "инженерной" в некотором смысле, неспособны породить что-либо близкого по надежности? Почему машины - работают, а программы - глючат и тормозят?
Тут вы скажете мне, что я необъективен. Что программы я вижу на этапе создания, когда они еще не успели избавиться от проблем, а машины наоборот - уже после того как все собрано и проверено. И что бывет супер-надежный софт, все эти бортовые программы самолетов и космических кораблей, а машины тоже бывают ломучими, даже новые.
Может быть.
Но вот точно могу сказать, что если бы те фирмы, в которых я работал, делали автомобили - я бы лучше того, пешочком.
10 окт в 0:54
Анатолий Рехлов
купи себе Приору и наслаждайся =)))
10 окт в 1:00
Вадик Зайцев
сравни хотябы бюджеты на разработку авто и на разработку игрового сервера. + в авто каждую детальку таки-можно потрогать и всячески протестировать, в то время как программный продукт довольно абстрактная штука с внезапным поведением. Болты и гайки - примитивнее чем ну не знаю. внутренняя кухня необходимая даже тупо для запуска "привет-мира".
я не сильно оправдываю корявость софтописания ( кстати от того упадет ли игровой сервер - не зависят жизни миллионов, а от надёжности той же подвески - да, отсюда более слабые требования к качеству ), но основная причина кмк, всё таки большая тестопригодность отдельных элементов авто и о5 таки - куда как более обширное и продолжительное тестирование оных + на порядки большие вложения в разработку.
10 окт в 1:03
Денис Тимошенко
Unit-тесты, unit-тесты, unit-тесты...! Программный продукт начинает себя предсказуемо вести только при достаточном покрытии оными. А без тестов - так, прототипчики (хоть сколько угодно сложные и крутые).
http://lib.rus.ec/b/146089/read
http://ru.wikipedia.org/wiki/TDD
С комментарием выше - согласен
10 окт в 1:48
Егор Смирнов
Ну так суть не в том что можно так сделать, а в том что по моему опыту никто так не делает. Хотя все знают как надо.
Разработка автомобиля стоит дороже, но во многом именно потому что его "можно потрогать". Производство деталей предсерийное дорогое. Ну и народу там больше занято, чем в среднем ИТ проекте.
10 окт в 2:26
Егор Смирнов
Это как если бы разработчики автомобиля сказали "аа, вон те гайки возьмем, проверять не будем, нафиг, это же гайка, что там может сломаться?"
10 окт в 2:27
Вадик Зайцев
вот в том и ответ - что нормальная качественная разработка - охрененно долгая и дорогая штука, в которой плюс ко всему задействовано уйма профессионалов разного толка. но т.к. зачастую несмертельна реализация на-отъебись, то имеем что имеем)
10 окт в 2:29
Владимир Смирнов
Автомобили приходится делать надежными, потому что за вред, причиненный пользователю, на компанию подадут в суд. А софт абстрактный, поэтому и навредить может только абстрактно. И никому нет дела до высокой надежности. Там, где есть риск материального ущерба, софт надежен - биржевые системы, авионика, и т.д. Наверное, автомобильные автопилоты протестируют не менее тщательно, чем сами автомобили.
10 окт в 4:32
Анатолий Шалыто
Просто автомобиль проектируется, а программа пишется! Будете проектировать программы с выпуском проектной документации и верификацией и ПО станет надежным
13 окт в 20:19
Анатолий Шалыто
Программы пишутся как стихи. А разве стихи должны быть надежными?
13 окт в 20:29
Егор Смирнов
Хех, про стихи хорошее сравнение, действительно похоже.
С документацией все совсем печально, во всяком случае в нашей "несерьезной" области программирования, не связанной со всякими самолетами и ядерными реакторами. Народ настолько привык, что обычно ее нету, что даже уже и не ищет. Я в свое время подробно описывал на проектной вики то, что делал, писал инструкции и FAQ'и - а для кого? Туда никто все равно не заходил, так как не верили что там может что-то быть. Когда я тыкал в это описание, все удивлялись "ооо, а чо, тут и инструкция есть? фигасе!".
В итоге получается, что писал в основном для себя же, чтобы при необходимости через полгода легче было вспомнить как оно работает.
14 окт в 16:58
Сергей Попов
Аналогично и я пишу. Мне пол года не надо. Достаточно двух недель :(
MagIstr
Хм я несильно прогромист, но админ..
И более опытные коллеги говорят что софт должен писатся так что его падение должно быть незаметным, т.е пусть упала софтина, но после этого ее перезапустило и она продолжила работать как ни в чем небывало, конечно при таком подходе опять же встает вопрос скорости разработки, но имхо это разумный компромисс между написанием стихов и абсолютно точным ТЗ.
25 окт в 10:02
=================================================================================================
Помимо этого как раз примерно в те же дни наткнулся на еще пару интересных статей подобной тематики, в кратце суть была такая:
Организации занимающиеся разработкой ПО делятся на 5 категорий по предсказуемости сроков и результата: с одного края находятся те компании, работая с которыми невозможно заранее утверждать о том насколько качественным будет выпущенный продукт и в какие сроки это качество будет достигнуто, на противоложном краю - имея на руках только ТЗ можно уверенно заранее знать что в результате работы получится именно то что нужно, с минимумом ошибок, выявленных в процессе эксплуатации и достигнуто это будет в адекватные сроки.
Так вот распределены компании согласно этому критерию в виде пирамиды, где в низу находится большинство, а на вершине - всего 4-6 компаний со всего мира.
И собственно речь шла о том как построена работа как раз в 1 из этих 4-6и - компании, занимающейся разработкой ПО для американских космических кораблей и пр.
Идея их в том, что порядка 90% времени они тратят на проектирование, описание всего и вся, т.е. максимальную детализацию ТЗ, до такой степени, когда буквально каждая команда, в исходном программном тексте имеет своё четкое проектное описание и обоснование. Аналогично происходит процесс модернизации - сперва "теор." часть, документирование, затем, собственно, внесение изменений. Естественно это не единственный ключ к успеху, там работают толковые люди и есть серьёзный внутренний отдел контроля качества, так же состоящий в т.ч. и из программистов, но основной смысл в том, что до того как будет написана первая строчка кода, на неё пишется спека, настолько детальная и подробная, что, в общем-то, непосредственное участие программиста в собственно процессе кодирования уже не нужно - можно сделать кодогенератор по спекам ( полагаю в скором они к этому и придут, если ещё не.. ). Естественно подобный процесс обеспечивает предсказуемость и качество.
Сейчас придумано множество различных методик организации рабочего процесса и процесса непосредственно кодирования, которые, какбы должны повысить предсказуемость результата: различные скрамы-канбаны, хр, тдд, люто ненавистное мною т.н. "парное" программирование и пр. Они действительно в какой-то степени работают, НО в любом случае они имеют свой предел повышения качества, который, вообще говоря, всё ещё очень далёк от результатов первой 4-6ки. По-тому как внизу всей это организационной надстройки всё равно стоит обычный программист, который грубо говоря фигачит код как ему в голову придёт, согласно своему моментному настрою, знаниям, страхам и убеждениям, со всеми вытекающими. Я не буду давать всему этому какую-либо оценку, т.к. это тупо факт и его можно только принять как данность.
Так вот, к чему всё я это написал, как показал мой собственный опыт - разработки с нуля, ковыряния в чужом коде, обсуждений с участвующими в различных этапах разработки людьми, не обязательно программистами, изучение т.н. "историй успеха" - большинство прибыльных проектов, на момент выхода в окупаемость как правило представляли собой нечто, собранное на коленке, с кучей явных, досаждающих пользователям ошибок на всём периоде жизни проекта. НО при всём при этом, от этих вещей никогда не зависило ничего кроме максимум, сохранности какой-то мелкой личной информации людей ну и прибыли владельцев.
На эту тему можно ещё писать много и разно, но не будем)
Моё мнение по этой теме такое (без детализации, кат 5 - самый верх, кат. 1 - самый низ той самой условной пирамиды орг-ий):
Большинство разработчиков не захочет работать в комп. уровня 5 в должности обычных программистов, а, вероятно - и вовсе не сможет (это спорно, вполне мб что большинству банально не хватает строгой, близкой к производственной управленческой политики на местах для выдачи качественного результата).
Большинству компаний нет смысла подниматься выше условно 3-ей кат (см. ниже).
Для решения большинства задач оптимальными являются компании кат. 3-4 по времени и качеству результата, но в силу повсеместного рынка работают в итоге 1-2, иногда - 3, при этом никаких реальных проблем не случается.
Для решения оставшихся задач компании ниже кат. 4 и 5 просто неприемлимы и передача работы к ним равносильно преступлению.
Принцип "доверяй но проверяй" никто не отменял, даже по отношению к компаниям кат. 4-5.
А что вы обо всём этом думаете? В частности, согласны ли вы с мнением, что большинству ПО д0лжно быть некачественным, ибо, как говорится, "се ля ви" или же считаете что например каждый мало-мальски посещаемый сайт обязан не уступать в качестве подлиным швейцарским часам?
Собственно, скопировано из ветки вконтакте практически целиком 1в1 (единственная правка: два моих поста идуших подряд в 1 соединены). С автором мы вместе работали почти 2 года и части описываемых вещей я был участником на всех возможных ролях, как, собственно и автор).
Итак, слово передаётся ему..
Егор Смирнов
Уже в который раз после дальней поездки на машине у меня возникают в голове такие вот мысли:
Практически весь софт, в написании которого я участвовал в последние четыре года, был крайне ненадежным. Игровые сервера и сервера приложений постоянно валились, глючили, теряли связь, жрали память, плевались ошибками и ни в какую не хотели работать стабильно.
Даже прошедший тестирование в QA сервер обычно мог работать в лучшем случае неделю, после чего его приходилось придерживать руками чтобы он не падал. То есть подкрутить конфиг там, добавить памяти здесь, быстренько сделать маленький патчик, ребутнуть сеть, остановить лишние сервисы.
Если же намечася показ начальству или заказчику - показатели стабильности и надежности по закону подлости и вовсе пробивали пол и улетали к соседям снизу. И я уже как-то к подобному привык, да и все привыкли, "ну а чо, система сложная", типа так и надо. Ну упадет - перезапустим, делов-то. Подобные проблемы перестали восприниматься как проблемы и стали нормальным ходом работы, а отсутствие проблем - наоборот чем-то выдающимся, праздником прям каким-то.
А вот машина, на которой я езжу. Я купил ее уже не новой, четыре года, 55 тысяч пробега. И вот еду я и еду по финским дорогам. А потом по русским колдобинам. Ночью и днем, в дождь, туман. В разных режимах - то втапливая педаль в пол чтобы обогнать фуру на трассе, то часами крутя мотор на холостых в пробке. То несясь почти на предельной скорости, то тошня 40, убивая подвеску ямами на наших загородных "шоссе". Часами, днями, неделями и месяцами. И поршни все так же молотят, крутятся валы, ремни, дрыгают амортизаторы, бегает ток по проводам - тысячи деталей, система ничуть не менее сложная чем наши программы, а то и более, и вот оно работает и работает, годами, без усталости, в любых условиях, не давая даже повода открыть капот.
И я задумываюсь, что за инженеры создали это, да и многие другие произведения техники, что смогли сделать это так вот надежно. И почему мы, вся наша индустрия, которая в общем-то тоже считается "инженерной" в некотором смысле, неспособны породить что-либо близкого по надежности? Почему машины - работают, а программы - глючат и тормозят?
Тут вы скажете мне, что я необъективен. Что программы я вижу на этапе создания, когда они еще не успели избавиться от проблем, а машины наоборот - уже после того как все собрано и проверено. И что бывет супер-надежный софт, все эти бортовые программы самолетов и космических кораблей, а машины тоже бывают ломучими, даже новые.
Может быть.
Но вот точно могу сказать, что если бы те фирмы, в которых я работал, делали автомобили - я бы лучше того, пешочком.
10 окт в 0:54
Анатолий Рехлов
купи себе Приору и наслаждайся =)))
10 окт в 1:00
Вадик Зайцев
сравни хотябы бюджеты на разработку авто и на разработку игрового сервера. + в авто каждую детальку таки-можно потрогать и всячески протестировать, в то время как программный продукт довольно абстрактная штука с внезапным поведением. Болты и гайки - примитивнее чем ну не знаю. внутренняя кухня необходимая даже тупо для запуска "привет-мира".
я не сильно оправдываю корявость софтописания ( кстати от того упадет ли игровой сервер - не зависят жизни миллионов, а от надёжности той же подвески - да, отсюда более слабые требования к качеству ), но основная причина кмк, всё таки большая тестопригодность отдельных элементов авто и о5 таки - куда как более обширное и продолжительное тестирование оных + на порядки большие вложения в разработку.
10 окт в 1:03
Денис Тимошенко
Unit-тесты, unit-тесты, unit-тесты...! Программный продукт начинает себя предсказуемо вести только при достаточном покрытии оными. А без тестов - так, прототипчики (хоть сколько угодно сложные и крутые).
http://lib.rus.ec/b/146089/read
http://ru.wikipedia.org/wiki/TDD
С комментарием выше - согласен
10 окт в 1:48
Егор Смирнов
Ну так суть не в том что можно так сделать, а в том что по моему опыту никто так не делает. Хотя все знают как надо.
Разработка автомобиля стоит дороже, но во многом именно потому что его "можно потрогать". Производство деталей предсерийное дорогое. Ну и народу там больше занято, чем в среднем ИТ проекте.
10 окт в 2:26
Егор Смирнов
Это как если бы разработчики автомобиля сказали "аа, вон те гайки возьмем, проверять не будем, нафиг, это же гайка, что там может сломаться?"
10 окт в 2:27
Вадик Зайцев
вот в том и ответ - что нормальная качественная разработка - охрененно долгая и дорогая штука, в которой плюс ко всему задействовано уйма профессионалов разного толка. но т.к. зачастую несмертельна реализация на-отъебись, то имеем что имеем)
10 окт в 2:29
Владимир Смирнов
Автомобили приходится делать надежными, потому что за вред, причиненный пользователю, на компанию подадут в суд. А софт абстрактный, поэтому и навредить может только абстрактно. И никому нет дела до высокой надежности. Там, где есть риск материального ущерба, софт надежен - биржевые системы, авионика, и т.д. Наверное, автомобильные автопилоты протестируют не менее тщательно, чем сами автомобили.
10 окт в 4:32
Анатолий Шалыто
Просто автомобиль проектируется, а программа пишется! Будете проектировать программы с выпуском проектной документации и верификацией и ПО станет надежным
13 окт в 20:19
Анатолий Шалыто
Программы пишутся как стихи. А разве стихи должны быть надежными?
13 окт в 20:29
Егор Смирнов
Хех, про стихи хорошее сравнение, действительно похоже.
С документацией все совсем печально, во всяком случае в нашей "несерьезной" области программирования, не связанной со всякими самолетами и ядерными реакторами. Народ настолько привык, что обычно ее нету, что даже уже и не ищет. Я в свое время подробно описывал на проектной вики то, что делал, писал инструкции и FAQ'и - а для кого? Туда никто все равно не заходил, так как не верили что там может что-то быть. Когда я тыкал в это описание, все удивлялись "ооо, а чо, тут и инструкция есть? фигасе!".
В итоге получается, что писал в основном для себя же, чтобы при необходимости через полгода легче было вспомнить как оно работает.
14 окт в 16:58
Сергей Попов
Аналогично и я пишу. Мне пол года не надо. Достаточно двух недель :(
MagIstr
Хм я несильно прогромист, но админ..
И более опытные коллеги говорят что софт должен писатся так что его падение должно быть незаметным, т.е пусть упала софтина, но после этого ее перезапустило и она продолжила работать как ни в чем небывало, конечно при таком подходе опять же встает вопрос скорости разработки, но имхо это разумный компромисс между написанием стихов и абсолютно точным ТЗ.
25 окт в 10:02
=================================================================================================
Помимо этого как раз примерно в те же дни наткнулся на еще пару интересных статей подобной тематики, в кратце суть была такая:
Организации занимающиеся разработкой ПО делятся на 5 категорий по предсказуемости сроков и результата: с одного края находятся те компании, работая с которыми невозможно заранее утверждать о том насколько качественным будет выпущенный продукт и в какие сроки это качество будет достигнуто, на противоложном краю - имея на руках только ТЗ можно уверенно заранее знать что в результате работы получится именно то что нужно, с минимумом ошибок, выявленных в процессе эксплуатации и достигнуто это будет в адекватные сроки.
Так вот распределены компании согласно этому критерию в виде пирамиды, где в низу находится большинство, а на вершине - всего 4-6 компаний со всего мира.
И собственно речь шла о том как построена работа как раз в 1 из этих 4-6и - компании, занимающейся разработкой ПО для американских космических кораблей и пр.
Идея их в том, что порядка 90% времени они тратят на проектирование, описание всего и вся, т.е. максимальную детализацию ТЗ, до такой степени, когда буквально каждая команда, в исходном программном тексте имеет своё четкое проектное описание и обоснование. Аналогично происходит процесс модернизации - сперва "теор." часть, документирование, затем, собственно, внесение изменений. Естественно это не единственный ключ к успеху, там работают толковые люди и есть серьёзный внутренний отдел контроля качества, так же состоящий в т.ч. и из программистов, но основной смысл в том, что до того как будет написана первая строчка кода, на неё пишется спека, настолько детальная и подробная, что, в общем-то, непосредственное участие программиста в собственно процессе кодирования уже не нужно - можно сделать кодогенератор по спекам ( полагаю в скором они к этому и придут, если ещё не.. ). Естественно подобный процесс обеспечивает предсказуемость и качество.
Сейчас придумано множество различных методик организации рабочего процесса и процесса непосредственно кодирования, которые, какбы должны повысить предсказуемость результата: различные скрамы-канбаны, хр, тдд, люто ненавистное мною т.н. "парное" программирование и пр. Они действительно в какой-то степени работают, НО в любом случае они имеют свой предел повышения качества, который, вообще говоря, всё ещё очень далёк от результатов первой 4-6ки. По-тому как внизу всей это организационной надстройки всё равно стоит обычный программист, который грубо говоря фигачит код как ему в голову придёт, согласно своему моментному настрою, знаниям, страхам и убеждениям, со всеми вытекающими. Я не буду давать всему этому какую-либо оценку, т.к. это тупо факт и его можно только принять как данность.
Так вот, к чему всё я это написал, как показал мой собственный опыт - разработки с нуля, ковыряния в чужом коде, обсуждений с участвующими в различных этапах разработки людьми, не обязательно программистами, изучение т.н. "историй успеха" - большинство прибыльных проектов, на момент выхода в окупаемость как правило представляли собой нечто, собранное на коленке, с кучей явных, досаждающих пользователям ошибок на всём периоде жизни проекта. НО при всём при этом, от этих вещей никогда не зависило ничего кроме максимум, сохранности какой-то мелкой личной информации людей ну и прибыли владельцев.
На эту тему можно ещё писать много и разно, но не будем)
Моё мнение по этой теме такое (без детализации, кат 5 - самый верх, кат. 1 - самый низ той самой условной пирамиды орг-ий):
Большинство разработчиков не захочет работать в комп. уровня 5 в должности обычных программистов, а, вероятно - и вовсе не сможет (это спорно, вполне мб что большинству банально не хватает строгой, близкой к производственной управленческой политики на местах для выдачи качественного результата).
Большинству компаний нет смысла подниматься выше условно 3-ей кат (см. ниже).
Для решения большинства задач оптимальными являются компании кат. 3-4 по времени и качеству результата, но в силу повсеместного рынка работают в итоге 1-2, иногда - 3, при этом никаких реальных проблем не случается.
Для решения оставшихся задач компании ниже кат. 4 и 5 просто неприемлимы и передача работы к ним равносильно преступлению.
Принцип "доверяй но проверяй" никто не отменял, даже по отношению к компаниям кат. 4-5.
А что вы обо всём этом думаете? В частности, согласны ли вы с мнением, что большинству ПО д0лжно быть некачественным, ибо, как говорится, "се ля ви" или же считаете что например каждый мало-мальски посещаемый сайт обязан не уступать в качестве подлиным швейцарским часам?