История изменений
Исправление slapin, (текущая версия) :
0. нанимаем опытных разрабов без проблем первого рода
1. review большим количеством народу
2. «покрытие тестами»
3. брутальная проверка всех источников входных данных без предположений что там может быть.
4. Свечка в церкви. Еще одна в заднице того, кто накосячил в прошлый раз.
5. Консервативная модель разработки - сомнительный принцип, я считаю, но многие оценивают как благо, так как меньше динамики, больше возможности подумать.
6. Оперативное исправление проблем, поддержка продукта.
Остальное в наши дни свою эффективность не доказало. Я тут не рассматриваю исключение человеческого до...неаккуратности и использование вместо языков VM, так как тут появляется кажущаяся возможность сэкономить на программистах, но тут баг вылезет в VM и всё равно будет бить по репутации продукта, да и не все человеческие ошибки VM исключит, а только самые нубские. Я не верю в решение этих проблем использованием какого-либо VM, разве что если получится потом пальцем на VM показать и вам это сойдёт с рук. Особенно если в VM добавляются еще какие свои наьивные библиотеки... Разработка ПО связано со сжатыми сроками. Баги, включая баги безопасности, - часть рисков. Если риски слишком велики - используйте указанные выше методы, и если таки вылез баг - оперативно исправляйте. И помните, если бы за баги в медицинском оборудовании, проводящие к летальному исходу, программиста, сделавшего ошибку, сажали на срок в тюрьму, или с программиста, уронившего своей ошибкой ракету, заставляли вернуть её полную стоимость, это не повысило бы безопасность, просто оборудование бы стоило столько, что никто бы никогда не смог его купить, так как было бы слишком мало желающих это делать. Поэтому это всегда компромисс и баланс. Errare humanum est.
Исправление slapin, :
0. нанимаем опытных разрабов без проблем первого рода 1. review большим количеством народу
2. «покрытие тестами»
3. брутальная проверка всех источников входных данных без предположений что там может быть.
4. Свечка в церкви. Еще одна в заднице того, кто накосячил в прошлый раз.
5. Консервативная модель разработки - сомнительный принцип, я считаю, но многие оценивают как благо, так как меньше динамики, больше возможности подумать.
6. Оперативное исправление проблем, поддержка продукта.
Остальное в наши дни свою эффективность не доказало. Я тут не рассматриваю исключение человеческого до...неаккуратности и использование вместо языков VM, так как тут появляется кажущаяся возможность сэкономить на программистах, но тут баг вылезет в VM и всё равно будет бить по репутации продукта, да и не все человеческие ошибки VM исключит, а только самые нубские. Я не верю в решение этих проблем использованием какого-либо VM, разве что если получится потом пальцем на VM показать и вам это сойдёт с рук. Особенно если в VM добавляются еще какие свои наьивные библиотеки... Разработка ПО связано со сжатыми сроками. Баги, включая баги безопасности, - часть рисков. Если риски слишком велики - используйте указанные выше методы, и если таки вылез баг - оперативно исправляйте. И помните, если бы за баги в медицинском оборудовании, проводящие к летальному исходу, программиста, сделавшего ошибку, сажали на срок в тюрьму, или с программиста, уронившего своей ошибкой ракету, заставляли вернуть её полную стоимость, это не повысило бы безопасность, просто оборудование бы стоило столько, что никто бы никогда не смог его купить, так как было бы слишком мало желающих это делать. Поэтому это всегда компромисс и баланс. Errare humanum est.
Исходная версия slapin, :
0. нанимаем опытных разрабов без проблем первого рода 1. review большим количеством народу 2. «покрытие тестами» 3. брутальная проверка всех источников входных данных без предположений что там может быть. 4. Свечка в церкви. Еще одна в заднице того, кто накосячил в прошлый раз. 5. Консервативная модель разработки - сомнительный принцип, я считаю, но многие оценивают как благо, так как меньше динамики, больше возможности подумать. 6. Оперативное исправление проблем, поддержка продукта.
Остальное в наши дни свою эффективность не доказало. Я тут не рассматриваю исключение человеческого до...неаккуратности и использование вместо языков VM, так как тут появляется кажущаяся возможность сэкономить на программистах, но тут баг вылезет в VM и всё равно будет бить по репутации продукта, да и не все человеческие ошибки VM исключит, а только самые нубские. Я не верю в решение этих проблем использованием какого-либо VM, разве что если получится потом пальцем на VM показать и вам это сойдёт с рук. Особенно если в VM добавляются еще какие свои наьивные библиотеки... Разработка ПО связано со сжатыми сроками. Баги, включая баги безопасности, - часть рисков. Если риски слишком велики - используйте указанные выше методы, и если таки вылез баг - оперативно исправляйте. И помните, если бы за баги в медицинском оборудовании, проводящие к летальному исходу, программиста, сделавшего ошибку, сажали на срок в тюрьму, или с программиста, уронившего своей ошибкой ракету, заставляли вернуть её полную стоимость, это не повысило бы безопасность, просто оборудование бы стоило столько, что никто бы никогда не смог его купить, так как было бы слишком мало желающих это делать. Поэтому это всегда компромисс и баланс. Errare humanum est.