Самый быстрый способ продвижения – делать надежно, гарантированно, с проверками, по заранее определённому плану. Нужно быть уверенным в фундаменте, предусматривать возможные эксцессы по завершении каждого шага. Есть правда «Но», но это не должно занимать много времени.
Данный метод хорошо реализует TDD (test driver development), когда проверка (тест) создается до того, как будет создан проверяемый код. Соблюдая принципы Unit-тестирования мы получаем не только проверенный код, но слабосвязанную и модульную архитектуру.
Диагностика: постоянно в отладке, вы не можете предугадать результат, гарантировать работоспособность отдельных модулей по отдельности. Выгода использования метода - сокращение времени на разработку в 2-3 раза, получение удовольствия от порядка и осознания контроля над ситуацией.
На надежность влияет предсказание и обработка возможных исключительных ситуаций. Представление их в наиболее удобном виде. Например в нашей компании принят стандарт: тело всех веб-методов обертывается в try\catch с протоколированием в лог с записью сообщения и контекста вызова (пользователь, входные данные функции), выдачей статуса 505 в браузер, чтобы в инструментах разработчика строка подсвечивалась красным и легко обнаруживалась.
На олимпиадах за безрезультатные попытки сдачи задачи нас штрафовали! И парни, трудящиеся сейчас в яндексе, предложили стратегию: обсудили алгоритм, один пишет код, другой придумывает тесты, третий подбирает следующие задачи и продумывает их решение. После решения задачи мы прогоняли тесты, обнаруживая, что была б штрафная, быстро-быстро исправляли код и пробовали вновь, так, в среднем, минут за 5-10 мы исправляли код и сдавали задачу. Процесс напоминал игру и конвейер одновременно, а мы были на нем повара лепящие задачи, как горячие пирожки.
Олимпиадное программирование имеет жесткий срок, обычно возникает желание программировать очень быстро, лишь бы, лишь бы. Не заботясь о стиле, названии переменных, смысловых блоках и т.д.. Простые задачи проходили и при абы каком решении, посложнее задачи мне лично чаще всего удавалось решить только после того, как наводил порядок.
У начинающих разработчиков частый подход – сделай все сразу, затем проверяй. Причем нет уверенности в каждом модуле, что они сделали. Применим математику. Возьмем вероятность того, что модуль работает за 50%. Тогда модуль из двух будет работать с вероятностью
M=0,5*0,5=0,025
т.е
Mn=pm^n
где pm – вероятность корректной работы модуля. Итоговую вероятность не уменьшает только одно значение – единица. Ее и следует добиваться.
Один из методов борьбы с ошибками – дублирование, когда одну и ту же функцию выполняют два и более модулей. К примеру наш обмен с 1С выполняет ночную проверку и в случае расхождений данных переимпортирует их, а далее нам приходит отчет на почту по сравнению данных. Т.е. мы выполняем тройной контроль.
Нагрузочное тестирование, документация, соблюдение стиля кодирования, проверка граничных ситуаций, покрытие тестами – это все подход делай надежно. Применяйте его на пути к вашей цели!
Мы увлечены программированием больших систем, ведем блог в контакте https://vk.com/itbtr Публикуем методы, принципы и разборы на сайте http://flipworldit.ru/. Заходите, будем рады!