"Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы."

Из записной книжки Мистера Томпкинса. Deadline, Том ДеМарко

Возможно ли создавать программы без ошибок?

Очевидно что полностью избавиться от неопределенного поведения невозможно . Однако, точно можно создать инструмент который избавит от ошибок на своём уровне. 

Меня зовут Александр Козин, программирую с 1996 года и создаю приложения для Apple с 2008-ого. 

Участвовал в проектах:

• Western Union
• Audi
  
• YOTA
  
• Bork
  
• 2gis Flamp
• Kings and Queens by David Starkey
  
• Rema1000
  
• 585 Золотой
  
• И многих других

Закончил институт по специализации «Автоматизация Технологических Процессов и Производств в Машиностроении». Моей дипломной работой была экспертная система для автоматизации в машиностроении на iOS, 2011 год. Эта идея превратилась в экспертную систему для разработки ПО.

Могу сказать точно- все продукты похожи. В каждом мы тратим уйму времени на документацию, оценку, коммуникации, проектирование и разработку. 

Сегодня я предлагаю обсудить исключительно последний пункт- работу с кодом. 

Непосредственно разработка это только:

• Новый функционал
• Исправление ошибок 

Реализовывать новые задачи часто увлектельно и захватывает. Легко получается войти в поток. И в начале проекта нет ошибок чтобы исправлять - 100% времени уходит на развитие. 

Однако, в процессе неизбежно накапливаются недочёты. Забытый технический долг слипается в legacy, логика превращается в монолит и процент времени на отладку растёт, иногда драматически. 

Драматичность, кстати, напрямую зависит от качества кода:

Мистер Томпкинс отложил ручку. Да, похоже, все так и есть. Раз на отладку и исправление ошибок уходит около половины всего времени и ресурсов, то чтобы добиться выдающихся результатов, можно только сократить время, отведенное на отладку. В таком случае останется больше времени на проектирование. Да, с этим нельзя не согласиться.

Deadline, Том ДеМарко

Половину! 

The Raw, Эдди Мерфи
https://youtu.be/3dJzvpJF33g?si=bUgLBADjRY4mftov

Хорошо, если в длительных проектах получится сохранять паритет. Однако, на практике, может уходить и больше 80% времени на отладку, раскапывание legacy и прочие рефакторинги. Соотношение зависит в основном от качества применяемых решений- пресловутого качества кода. Это задокументированная реальность.

Тогда почему качество кода практически всегда уступает в приоритете срокам сдачи?

Очень заманчиво получить быструю скорость разработки сразу на старте проекта. Со временем темп непременно падает: Не значительно при использовании высококлассных качественных решений и категорически в обратном случае.

Почему же это происходит?

Время реализации новых задач напрямую зависит от качества принимаемых решений:

Именно поэтому нанимать двух средних разработчиков за бюджет одного опытного это плохая идея в квадрате. Ведь скорость разработки падает экспоненциально при увеличении размера команды. Но это совсем другая история.

Возвращаясь к нашей, выходит что половину времени в проекте мы тратим на:

• Ошибки
• Технический долг
• Legacy
  

Так как же нам ускорить разработку? Вспоминая грандиозный труд Тома ДеМарко, необходимо только найти подход который позволит писать программы без ошибок. Или части программ использующие этот подход. 

Хах, звучит слишком легко. Но как же нам решить такую невероятную задачу?

Если мы будем использовать подход с лучшими решениями (высокое качество кода), это произойдет автоматически:

Время исправления ошибок не давит на сроки реализации новых задач, не нужно на скорую руку вносить изменения накапливая тех. долг. А забытый навсегда долг не превратиться в legacy. Profit.

Нам нужны решения высокого качества которые легко тестировать, переиспользовать, поддерживать и объединять.

- Но как мы можем написать код без единой ошибки?
- Ну, смотрите. Вот только что вы обнаружили ошибку в одном из модулей. Где находится эта ошибка?
- В модуле.
- Нет. Она находится на границе. На самой границе модуля. Конечно, бывают и локальные ошибки, в середине модуля, но их легче всего выловить и исправить. Самые коварные ошибки, настоящие, те, которые отнимают у разработчиков массу времени и сил, обнаруживаются в интерфейсе между модулем и всей остальной программой.
—Правильно, это каждому известно. И что же?

Deadline, Том ДеМарко

Сказано – сделано! Осталось только найти это место на самой границе и сфокусироваться на этой прослойке. 

В современной разработке мы все используем архитектурные паттерны: MVC, MVP, MVVM, VIPER, etc.

И все они начинаются с Модели. Это объекты и сервисы для их получения. То самое место взаимодействия SDK и наших модулей. 

Очень логично начать с начала. К тому же, именно в этом слое концентрация ошибок максимальная. Вот он Profit. 

Чтобы решить любую задачу, нужно поставить цели. Их всего четыре:

• TDD
• Reuse
• Update
• Connect

Если код нужно переиспользовать, он не должен содержать дефектов. И vice versa. Протестированный код легко переиспользовать- он изолирован раз покрыт Unit тестами и не содержит ошибок в покрытых кейсах.

Такой код легко поддерживать и обновлять. Из него можно создавать сложные конструкции используя совместно разные блоки логики. 

Согласно ИКР (идеальному конечному результату), всё должно остаться так, как было, но либо должно исчезнуть вредное, ненужное качество, либо появиться новое, полезное качество.

Найти идею: Введение в ТРИЗ, Генрих Альтшуллер

Вообразим Идеальный Конечный Результат:

Язык программирования в котором достаточно только описать объект чтобы получить его максимально быстро с минимальными затратами ресурсов. 

В теории программирования это называется декларативным языком. Он полностью инкапсулирует логику создания и получения любых объектов.

Подходит для всех платформ:

//Получи одну геопозицию, один набор шагов, пользователя из сети и выполни блок кода
Location.one | PedometerData.one | CurrentUser.one | .all {

}

//Объект для которого не нужны опции настройки
|{ (result: Object) in
            
}

//Объект с данными на входе
ingredients | { (result: Object) in
            
}

//Один, все, по условию
ingredients | .one { (t: T) in
            
} | .every { (u: U) in

} | .while { (v: V) in
  true
}

Прототип работает на Swift:

//Request current Location
|{ (location: CLLocation) in 

}

//Request .authorizedAlways permissions once
CLAuthorizationStatus.authorizedAlways | .one { (status: CLAuthorizationStatus) in
            
}

//Retrieve Pedometer Data updates
|{ (data: CMPedometerData) in 

}

//Scan for Bluetooth Peripheral
|{ (peripheral: CBPeripheral) in 

}

//Wait for a Notification
UIWindow.keyboardWillShowNotification | { (n: Notification) in
            
}

//Scan an NFC tag
|.every { (tag: NFCNDEFTag) in

}

//Perform Face Observation
URL(string: "http://example.com/image.jpg") | { (faces: [VNFaceObservation]) in

}

//Perform Pose Observation
//Wait for two persons
data | .while { (bodies: [VNHumanBodyPoseObservation]) in
    bodies < 2
}

//Detect shake
|{ (motion: UIEvent.EventSubtype) in
    if motion == .motionShake {
                
    }
}

Wand это декларативный язык. Транслируется в нативный код на этапе препроцессинга. Реализация для Android, Windows, Linux будет сделана в фонде.

В OpenSource на GitHub выложено ядро и плагины для распространенных задач:

https://github.com/The-Wand/Wand

Техническая презентация на КофеКод Краснодар в Т-Банке и How To:

https://www.youtube.com/playlist?list=PLvprpeoOl6IoZ67BcD-t0rS1L5c5J4lPh

Мы можем создавать программы для бизнеса в которых не будет ошибок на коммерческой основе и сохранять такие плагины для Wand приватными. 

На длительных проектах, потенциально на 50% эффективней. 

Пишите мне по вопросам создания оптимальных программ (ИКР) для любых платформ.