[userpic]

... ↑

ex_sbobrovsk689 в посте Openmeta (оригинал в ЖЖ)

Наброски модели...
Ничего особо нового по этой теме наверное не скажу. Уже писано-переписано...
И еще тут нужна консультация эксперта по опенмете :) , с программированием, желательно, незнакомого, чтобы понять, чего для модели не хватает, а что лишнее.
Рабочий цикл.
а) Сначала восстанавливаем контекст вокруг кода, который надо продолжить, или вокруг объекта/модуля, функциональность которого надо развивать.
То есть понять, На чем остановился вчера и Что делать дальше?
Обычно делается это с помощью различных подпорок-напоминалок - обязательно! множества комментариев в коде (через неделю, другую, смысл кода забывается напрочь), документации к проекту (реже :), а также красивого и наглядного оформления самого кода.
б) Проект разделен/делится-в-реальном-времени-разработки (чем сложнее задача, тем больше процесс деления выносится в начало, в отдельный этап) на мелкие кусочки, максимально независимые, чтобы за "рабочий день" (это может быть и полчаса, и 14 часов) сделать целое число таких кусочков, подзадач. Например, мелкие по объему методы объекта/подпрограммы (несколько десятков операторов в каждом). Иначе, разобранный кусочек продолжать очень сложно, если выпал вдруг из процесса (не "закончил кодировать и сразу в постель, а утром встал и сразу за комп" а "закончил кодировать, сходил в кино, выпил пивка, утром покатался на велосипеде, и потом за комп" - тут уже выпадание в наличии).
"Проект разделен на кусочки" - вещь довольно условная. Собственно, понятие "программиста" тоже довольно расплывчато, потому что на первых этапах, когда программа только начинается, основное внимание уделяется ее проектированию, продумыванию архитектуры. Как она будет работать, какие будут внутри нее процессы, как ими управлять, как контролировать. Сверху-вниз классический принцип, без низкоуровневой детализации.
О проектироании здесь говорить не к месту, я имею пока в виду нечто более близкое к модели кодировщика, когда архитектура системы готова, и надо только закодировать техзадание.
То есть на шаге б) формируется некая небольшая цель (очередное расширение функциональности программы, перевод необходимых для реализации функций в состояние "запрограммировано" :). Причем эта цель обычно связана с какими-то внешними, визуальными вещами, которые пользователь может "потрогать" (нажал на кнопку - получил ответ). Сам по себе код, который особо ничего не делает с точки зрения потребителя, стараюсь делать только в конце, в оптимизационных целях в основном.
Текущая цель выбирается произвольно, в основном в зависимости от настроения :) Потому что обычно направлений развития много, и можно достаточно гибко их реализовывать.
с) Программируем :)
Точно так же, собственно, мелкими микрошажками, уже с помощью элементарных операторов.
д) Постоянно тестируем/отлаживаем то, что получается. Сделанный в б) кусочек проверяю часто по шагам, особенно в условных развилках, или где важные результаты формируются, контролируем правильность.
Проблемы обычно возникают/выявляются на шаге д) , если исходно (на более высоком, наверное, метауровне, проектирования программы) архитектура была продумана неточно. Обычно это плохо продуманные (несогласованные) форматы возвращаемых на промежуточных этапах данных, или попытки впихнуть в одну подпрограмму слишком много функциональности, которая бывает востребована и по частям, но потом "выковыривать" ее кусочки после написания кода процедуры уже сложно. Завязки на любые внешние по отношению к подпрограмме переменные, вспомогательные элементы, очень вредят.
Поэтому на шаге б) особо внимательным надо быть к описанию и соблюдению входных/выходных данных, а также к минимизации реализуемой функциональности в одной подпрограмме - она должна быть минимально необходимой по смыслу и максимально автономной и независимой от других элементов программы (что также повышает вероятность ее использования в разных контекстах).