Собственно, программирование включает в себя проектирование, кодерство и отладку. Вопрос следующий: насколько глубоко следует проектировать?
Поясню.Я глупый школьник. Когда кол-во строк в программе не превышало 700-800, достаточно было подумать об "этом" в "общем", сесть писать сразу, потом набросать заплаток, в случае чего.
Теперь, взявшись за серьезную(бесполезный, правда) вещь, я обнаруживаю, что путаюсь в функциях и классах. А много можно было сделать лучше. А много можно было сделать короче. В итоге я все нафиг удалил и сел сначала за бумагу, где набросал граф проекта. Пока стало веселее… Также замечаю, что при проработке деталей на бумаге программирование сводится к написанию N функций(классов, методов, вещей, нужное подчеркнуть).
Тем не менее мой взрослый друг говорит, что садится сразу за комп и проектирование архитектуры происходит у него в голове. Все это от моей неопытности\тупости, разные проекты или все по разному работают? Ведь у друга может быть 1кстрок\час, а у человека, заранее все расписавшего на бумаге, 5кстрок\час + заранее спроектированный макет…
Интересно послушать опыт больших и умных дядек, а конкретно:
1) Какую часть в % от проекта занимают три стадии(проектирование, кодерство и отладка)?
2) Какую часть хотели бы ВЫ, чтобы они занимали(ведь это может определять и заказчик, или, допустим, надо быстро выпустить пре-альфу, ведь так бывает?)
3) Насколько глубоко вы занимаетесь проектированием?
4) Насколько глубоко вы БЫ ХОТЕЛИ заниматься проектированием?
Спасибо за ответы, заранее ; )
18 февраля 2010 в 15:00
Хм, спасибо за ответы.)
18 февраля 2010 в 14:03
Ваще, знаете, что проектирование – самое важная стадия и опыт проектировщика драгоценнейший в софтДевелопменте! Поэтому проектируйте всё (ну почти всё!) и заодно набирайте опыт.
1)40% – проектирование, 25 – кодирование, 35 – отладка.
2) 100% – проектирование – я бы так хотел!
3) Определить классы, взаимодействие классов, определение атрибутов и методов.
4) ЭЭЭЭ….хз незнаю!
И да поможет Вам UML!
16 февраля 2010 в 21:05
Александр, мой вам совет – сначала немного анализируйте, потом напишите.
когда допишите и будет работать, через денек взгляните на свой код и смотрите, что и как лучше было бы сделать и переделывайте. это наиболее удачная практика, по крайней мере моя.
16 февраля 2010 в 2:04
Спасибо за ответы. Я кое-что понял)
16 февраля 2010 в 2:02
Всё дело в том, что ты выкинул интереснейшую часть процесса арзработки ПО – анализ. Это выяснение что собственно нужно. Из-за того, что программировали не то, что нужно умерло гораздо больше проектов чем из-за плохой архитектуры.
Сначала спроектировать а потом написать – проверенная дорога в ад. К сожалению даже самые талантливые архитекторы не могут предсказать всех трудностей в процессе программирования и перепетий эволюции требований. Поиск баланса между глубоким предварительным проектированием и формированием архитектуры "на ходу" (в том числе и посредством рефакторинга) древнейшая проблема промышленной разработки. Рассказать о всех возможных факторах, которые надо учитывать при смещении баланса и возможных последствиях этого не представляется возможным в рамках местной дискуссии, да и нет тут людей с должными опытом и квалификацией.
Лучшее что могу посоветовать – пробовать, искать ошибки и думать головой.
16 февраля 2010 в 2:01
Нет, разумеется нужно представлять в общих чертах что пишем, на чём пишем, зачем и для кого. Но нужно понимать, что все это не догма, а лишь стартовая установка.
Но вообще т.н. гибкие методологии разработки предполагают практически непрерывное проектирование. Разумеется есть понятие итерации – то есть проектирование – кодинг – тестирование, но уже в процессе кодинга на одной итерации вполне можно думать про проектирование на следующей
16 февраля 2010 в 2:00
> почти после каждой встречи с заказчиком…
хм…
Я в общем, про "полезность").
Но писать и одновременно проектировать может быть не самым рациональным, не так ли?
Общую канву все равно же надо представлять, ведь так)?
16 февраля 2010 в 1:04
Хм. Понятно, спасибо.
А часто изменяется требование к продукту)?
16 февраля 2010 в 1:04
> А часто изменяется требование к продукту)?
В реальности? ну почти после каждой встречи с заказчиком) Да и часто нельзя сразу сказать какие функции нужны продукту. иногда выпускаешь его и понимаешь сколько всего тут не хватает, а сколько всего никому не нужно.
> Все это от моей неопытности\тупости, разные проекты или все по разному работают?
Ну вообще кстати, если вам не нравится ваш прошлый код, он кажется нелогичным и запутанным и хочется его сделать лучше – это нормально. Даже более того ненормально когда этого не происходит – это значит, что вы перестали расти над собой и нужно срочно что-то менять.
> Ведь у друга может быть 1кстрок\час, а у человека, заранее все расписавшего на бумаге, 5кстрок\час + заранее спроектированный макет
Вообще глупо мерить "полезность" программиста в строках в час. Разумеется, если вы заранее знаете что писать, все спроектированно – осталось только набить – в этом случае процесс набивания будет идти гораздо быстрее, чем если вы будете писать и параллельно думать.
Но ошибка проектированияможет убить все ваши труды. А если проектирование идет непрерывно – цена ошибки уменьшается – вам придется меньше переписывать и вы можете нагнать и перегнать скоростного-кодера)
16 февраля 2010 в 1:03
Требований к функциям программы
Рефакторинг: "процесс такого изменения кода, при котором не меняется внешнее поведение кода, но улучшается его внутренняя структура".
Рефакторинг фактически техника подготовки кода к будующим изменениям, зачастую она применяется непосредственно перед этими изменениями для оптимизации структуры программы конкретно для них.
16 февраля 2010 в 1:03
Требований к продукту.
Рефакторинг – по сути это изменение архитектуры, сочетается с изменением инкаспулированных вещей – например перенос метода и полей или группы методов в другой класс, выделение интерфейсов, расформирование некоторых классов, изменение зависимостей. Но вообще говоря например взять кусок кода и выделить его в отдельную функцию – тоже рефакторинг – очень распространенный. А уж самый детский рефакторинг – это простое переименование.
16 февраля 2010 в 1:02
Алексей, спасибо за ответ.
Николай, требований к форматированию кода? Рефакторинг – изменение инкапсулированных вещей, или мы о разном говорим)?
16 февраля 2010 в 1:00
nuff вообще-то говорит, что отладка занимает больше половины времени… Странно, может быть, действительно, он неправ)?
16 февраля 2010 в 1:00
Николай, там было именно ПО.
Почему именно про рефакторинг все говорят)?
16 февраля 2010 в 1:00
1. Я не умею определять границы этих стадий.
2. Я-бы хотел, чтобы всё по 0.
3. До уровня необходимого, чтобы понять что делать сейчас.
4. До уровня необходимого, чтобы понять что делать сейчас.
16 февраля 2010 в 1:00
> Почему именно про рефакторинг все говорят)?
Потому что это современно, молодежно и повышает карму, по совместительству рефакторинг – единственный способ выжить в условиях постоянно изменяющихся требований.
16 февраля 2010 в 0:05
Ну токачтоже обсуждалиже //vkontakte.ru/topic-912_22753141
че сегодня день тоски по проектированию?
1) Они не разделяются. А если под отладкой понимать исправление багов, то можно считать 100% времени занимает отладка)
2) Ну ээ… хочу сесть накидать на бумажке юзкейсы проекта, сделать HLD, если проект на несколько человекомесяцев то на это дело не тратить больше недели. Дальше: кодить-рефактоить-кодить-рефактоить итп.
3) минимально, но важно вовремя успевать рефакторить.
4) совсем не хочу им заниматься, хочу писать системы настолько слабосвязные что их архитектуру можно было бы менять мгновенно и бесплатно. что конечно не реально.
16 февраля 2010 в 0:04
1) все зависит от проекта… ну даже самая примитивная программа – построение графиков должна быть спроектировано грамотно продумани классы и их методы…(как пример)
проект-50%
кодерство-40%
отладка-10%
2) затрудняюсь ответить
3) достаточно глубоко, это компенсирует время отладки(грамотное проектирование)
4) затрудняюсь ответить