Народ, у кого какие методы (план) в написании программ (не обязательно для 1с).

например:

формирование тз
построение блок схемы
...
написание окончательного варианта.

хотелось бы придумать (прочитать) про универсальные подходы, чтобы экономить время в написании программ.

первое и самое главное - найти заказчика

(0) http://www.ozon.ru/context/detail/id/3159814/

Страутсрап, Буч, Дийкстра.
Начни с них.

>>построение блок схемы

это еще кто-то делает?

(0)
начало алгоритма:
вопрос главбух дура?
да - конец.
нет - объясните на пальцах.

(4) бывает,... когда сложно...

(0)
1. Сделать копию базы, на случай кривых рук.
2 и далее. По ситуации

(0)
1. Сделайте мне здесь, чтобы было как там.
2. Сделать им тут как где-то.
3. Отдать поделку.
4. PROFIT!

(4) я делаю только схема принципиальная и на листочке. Очень помогает систематизировать хотелки.

(0)
Шаг1 Подумать.
Шаг2 Сделать
Результат удовлетворяет?
Да
Сделано
Нет
Получить опыт
Конец //результат удовлетворяеи?
Задача еще нужна?
Да
Идем к Шаг1
Нет
Сделано
Конец //Задача еще нужна?

(4) Месяца три назад мне дали ТЗ с блок-схемой, с которой долго соображал, пока не забил.

(0)обязательно сделать так
чтобы переписать всю конфу
чтобы новый функционал конфликтовал со старым
чтобы доработка заняла год а поддержка требовала расширения штата
чтобы ничего не работало без вызова тобою обработок с твоей флешки
чтобы решение использовало прямые запросы и приблуды на делфях без исходников, хранение кода в файлах
ну и т.д. и т.п.

пример: переломать упп так чтобы в одной базе БУ понимать как фискалку а УУ не как весь учет а как весь минус БУ и называть это УУ.

есть 2 принципиально разных подхода: эджайл, вотерфол

(14) http://www.leanpro.ru/index.php/interesno-yumor/26-tsikl-pdca-po-russki

(0) Диплом не писал в институте чтоле?

Я смотрю, тут собрались "мудрецы в башнях из слоновой кости" ?

Проза жизни всегда победит!

(13) ухахахаха... у меня так сейчас просит расчетчик зп... типа регл зп и черна зп как вся зп - регл зп :)

Тебе сюда: ПЯТНИЦА !!!

ИМХО, в нашей действительности, когда требования меняются несколько раз в день, применимы только agile-методы и прочее экстремальное программирование. Пока будет рисоваться блок-схема, другой исполнитель уже реализует все требования заказчика)) Хотя может это мне так не везет...

1) Понять вопрос(Что хотят)
2)Понять причину(Для чего хотят и в результате пересмотреть пункт 1)
3) Построить принципиальную схему Реализации(Выделить основные блоки) Если не возможно то значит что то не верно поняли Возвращаемся к пункту 1.
4) Согласовать с заказчиком(Возможно не сколько итераций начиная с пункта 1).
5)Для каждого блока Построить принципиальную схему (разбить на меньшие блоки)  Цикл выполнения этого пункта продолжается до достижения минимальных блоков.В процессе выполнения возможен переход на пункт 3.
6) Реализация минимальных блоков полученных в пункте 5. Если реализация не возможна то возвращаемся в пункт 5 с полученными знаниями.
7) Показ заказчику если заказчик доволен тогда Получение оплаты Иначе пункт 1

(1) Нет. Первое и самое главное - найти богатого заказчика :)

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

(15)+100500
большая часть нашего бизнеса основана на связях в силовых ведомствах, часть федерального уровня
отжать невозможно ибо уже отжали бы если что...
и вот они имею потребность драть персонал
просто издеваться над кем-то не посвящая в реалии бизнеса но требуя некоей отдачи от людей нанятых чтобы он советовал им
поэтому возвращаясь с сабжу абсолютно не важно какой подход
главное выработать иммунитет к людям которые всё равно тебя назовут дураком и попытаются недоплатить/неоплатить сверхурочку/компенсацию за отпуск.
т.е. если ты можешь что-то сделать то делай а веселые картинки не отмажут тебя от идиотов

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

(19)сакральный смысл продажи души дъяволу в уважении к дибилам. они накормят тебя работой )))

(25) Аж слеза выступила, очередные дибилы дерут во все щели непризнаного бизнесмена

(22)главное фиксация приемки этапов исполнения.
если функционал принят и используется значит уже никак и никто не смеет сказать
"ваша программа работает не правильно. мы работаем не так"
придется вежливо попросить
"исправьте пожалуйста вот здесь мы ТЕПЕРЬ (не тогда) хотим вот так"

(27)спасибо. но нет. я больше ни капли ни сантиметра.
зарекся.

(0) 1-й пункт найти постановщика задачи

(0) все было придумано до твоего рождения еще
SWEBOK

(0) не знаю как в идеале, но реально для меня - ТЗ это прикрытие своего зада. В случае если заказчик начнет борзеть и говорить что "твоя программа работает не так" - ты его тыкаешь носом в ТЗ и на его подпись в этом ТЗ.

Реально же предусмотреть все и написать подробное ТЗ сложно.
Некоторые нюансы возникают только в процессе реализации.

Поэтому у меня сначала - реализация, потом написание ТЗ. Если проект большой, то блочно: немного реализовал и это в ТЗ описал. Ну и естественно схематично что-то набрасываю на бумаге перед реализацией.

ну или как вариант в (30)

(0)маленький совет
в 1С чем меньше кода в типовую тем более оптимально решение

(0) http://macode.ru/ - универсальнее некуда