как у нас пишут программы и почему их так писать нельзя

Давайте поговорим о том, как у нас пишут программы и почему их так писать нельзя.

В профессиональном программировании есть 3основных бича сроки, ресурсы и требования. Вся эта беда образует легендарный треугольник, но нас это пока не волнует.

Беда в упомянутых выше понятиях в их жесткой зависимости друг от друга. Есть формула, согласно которой хотя бы один из пунктов должен быть жестко зафиксирован. Т.е. мы можем определить требования, прикинуть ресурсы и на базе этого получить сроки или наоборот зафиксировать сроки, прикинуть ресурсы и исходя из полученных результатов получить требования, которые реально можно выполнить… На базе этого баланса и строится работа проектного менеджера.

Люди более или менее знакомые с индустрией прекрасно знают, что в отличии от тех же например физиков у программистов подчас получается чистый дурдом и вакханалия. Сроки нужно умножать на 3 для получения реальных, ресурсы нужно множить на 2, чтобы хоть приблизительно попасть, ну а требования по сути своей больше всего напоминают амебу. Итог! Если мы будем делать программу «паровоз» и команда разработчиков затребует 4 компьютера, Интернет и скажет, что сдаст проект за 2 месяца, то в результате сточив 8 компьютеров и 2 интернета )) через 6 месяцев они сдадут проект «Самолет» *crazy* причем это вполне нормально… ))

Как с этим бороться и что можно сделать…

На самом деле сделать практически ничего нельзя. В силу слабого понимания в начале процесса заказчиком что он хочет и программистами что нужно сделать, каждая из сторон по сути работает над своим проектом. Применение методик подобных тому же информационному дизайну и agile методологиям, позволяет просто быстрее и проще менять разрабатываемый продукт, направляя разработку по изменяемому вектору требований выставляемых заказчиком, но избежать ошибок нет возможности. Их можно минимизировать…

Средства минимизации потерь в ходе работы над программным проектом.

Необходимо провести разведку в той области для которой проводится разработка. Например если мы работаем в области энергетики, то программисты хотя бы приблизительно должны понимать о чем говорят технологи заказчика, иначе это будет разговор слепого с глухим. Оптимально вообще иметь людей обладающих знаниями в предметно области разработки.
Если есть возможность, то архитектора или лид программиста необходимо отправить на местность, с целью понаблюдать за рабочим процессом. На самом деле ничто не дает таких хороших результатов, как наблюдение над всеми стадиями процесса, на местности. Люди заказчика находясь в своих родных пенатах и выполняя привычный набор действий, как правило, не начинают переводить с профессионального на албанский (дабы идиотам незнакомым со сленгом хоть что-то стало понятно) и выпендриваться пытаясь объяснить что они хотят. Имейте ввиду большая часть работников заказчика, да и он сам чаще всего имеют собственное представление о работе программиста и либо уверены в божественной сущности данной специальности (т.е. я скажу у меня крутой комп, а она поймет, что нужно пойти по трахаться) либо в другой крайности - уверены, что программисты это эдакие технодауны которые мешают работать умным и заслуженным людям.
Иметь в команде архитектора. Разработка первичной архитектуры может как ускорить и упростить дальнейшую разработку, так и поставить на ней большой жирный крест. Ошибки на старте к концу проекта могут в разы изменить его конечную стоимость на этапе завершения.
Если пункт 3 вам не светит. А он вам с большой вероятностью не светит так как найти хорошего архитектора тяжело (у нас их ни фига не готовят), а перекупить у фирмы которая его уже нашла или воспитала очень дорого, то единственным вменяемым вариантом является прототипирование на начальных этапах. Прототип должен занимать не более 1 рабочего дня или месяца в зависимости от объема работ и к концу своей разработки давать команде общее представление о возможности либо невозможности использования подобного подхода для конечной реализации системы в целом.
Время и деньги так же может помочь сберечь использование UML. Стирая грани взаимопонимания и переводя их в область диаграмм и прочих прикольных картинок, эта беда реально может позволить общаться на очень сложные темы без слов с использованием лишь карандаша и бумаги. Очень помогает в оценке, как кусков, так и целых системных блоков.
Обратная связь с заказчиком. Если позволить программистам работать без брифингов и в отдалении от заказчика, то из паровоза, как уже было написано ранее, получится - самолет. Это аксиономический факт, спорить с которым бесполезно, по сути. Программисты (хотя бы топы) и заказчик должны находиться в постоянном взаимодействии с целью балансировки хода разработки и динамического изменения набора требований по ходу пьесы
Система управления ошибками на сегодняшний день является практически стандартом де-факто. После того как вам есть уже, что отдать заказчику – отдайте. Чем раньше начинается работа конечных пользователей с системой, тем быстрее они подружатся и полюбят друг друга, тем проще будет устранять ошибки, не давая им перейти критический порог, тем лучше будет понимание процесса обеими участвующими сторонами.
Система контроля версий. При участии в проекте больше 0 программистов данный пункт я считаю суровой необходимостью. Ничто не бывает так полезно как отследить, что и где менялось, просто и быстро выполнить консолидацию проектных файлов, а главное иметь возможность вернуться на пару тройку сборок назад.
Доска. Брифинг доски, так популярные у западных коллег и так презираемые нашим начальством (возможно школьные психологические травмы), являются очень хорошим подспорьем для команды. На них, как правило, можно писать, рисовать, обсуждать написанное и нарисованное или рисовать солнышко с подбитым глазом, если планируется сабантуй. А еще на них можно крепить разные бумажки и объявления.
Парное программирование. Это великолепное средство реально быстрой разработки. Позволяющее с одной стороны минимизировать количество ошибок: один пишет - другой проверяет, а с другой стороны минимизировать время простоя программистского мозга: один пишет - другой думает, что писать дальше. А еще дух соревнования и всегда есть у кого стрельнуть сигаретку. ))))
Если вам хватит терпения (мне пока не хватило) и разума разобраться как работают юнит тесты, то жизнь ваша станет проще и практичнее. Тестирование малыми дозами намного практичнее, чем большими и дает намного лучшие результаты. Еще одним плюсом тестов является возможность детальнее следить за целостностью проекта по ходу разработки и ре факторинга
Ре факторинг. Если есть хотя бы малейший намек на возможность непонимания кода, лучше сразу же это устранять. Любой современный проект требует не только разработки, но и дальнейшей поддержки, поэтому качество и понятность кода выходят на одну из ключевых позиций.
Автоматические сборки. Возможность через определенные временные промежутки получить готовый продукт и полностью пройти все этапы формирования дистрибутива позволяет отследить правильность работы в целом, а автоматизация данного процесса дает возможность быстро доставить очередную сборку тестерам и заказчику.

Подводя итоги

Все описанное выше не более чем личный опыт автора по данной теме. Описанные вещи давно известны и не раз обсуждались в открытых источниках или публикациях. С другой стороны говорить об этом должно и нужно, т.к. хорошего много не бывает.