суббота, 28 февраля 2009 г.
Энергетика явлений
среда, 4 февраля 2009 г.
Методология разработки программ.
Вчера писал много кода и писал быстро, но когда из всего, что написал в итоге получилась слегка каша (не говорю полная каша, потому что код вполне такой обычный и юзать можно, но не желательно), задумался, а как вообще надо писать программы?
1. Пишем быстро (сроки ведь поджимают, не так ли?), почти не думаем, что пишем, т.е. пишем на автомате, потом запускаем в надежде, что заработает. Если заработало, верим, что работает во всех случаях и пишем дальше. Когда всплывают баги, фиксим.
В итоге получается куча костылей, но код абы как работает, баги всплывают часто, но и исправляются быстро. Продукт получается тоже быстро.
2. Пишем медленно, после того как придумали архитектуру, каждая функция вылизывается, проверяются значения входные, чётко описываем все возможные варианты исхода. Когда используем чужую функцию, вообще не забиваем на проверку ошибок, исключений, буквально обрабатываем каждый вариант и следим, чтобы всё имело смысл. После написания модуля/части программы, пишем также старательно кучу тестов, перепроверяем 10 раз. Баги должны всплывать редко, но страдает время изготовления продукта. За счет того, что архитектура должна быть адекватной, случаются не редко большие рефакторинги, однако вероятно в больших проектах это позволяет как-то где-то удержать разрастающуюся сложность под контролем.
Так проходит 5 лет и продукт релизится, хороший стабильный, времени затрачено уйма, надеемся, что железо и требования не переросли продукт. PROFIT!
Не поймите не правильно, я постарался описать две крайности той методики, которую можно использовать при написании программ. Главным образом тут речь о самоконтроле, управлении приоритетами и распорядком. Т.е. те вещи, о которых особо не говорят, но каждый применяет. Стало интересно, неужто так всё плохо и непонятно? Может кто-нибудь знает книжки на тему? Был бы очень благодарен.