Здравствуйте, Lloyd, Вы писали: L>Т.е. вы можете просто-напросто взять и усложнить архитектуру и сделать разработку дороже, несмотря на то, что требования могут и не измениться? L>Вы действительно счастливый человек.
а вы можете сьесть тонну креветок? ах, вы ничего про это не говорили. вот и я тоже ничего про усложнение и удорожания вроде не писал. так что не выдумывайте всякую ерунду. если хотите мне возразить, приведите лучше пример изменения требований, когда рефакторинга не избежать простым более грамотным проектированием системы заранее.
Здравствуйте, __kot2, Вы писали: __>если хотите мне возразить, приведите лучше пример изменения требований, когда рефакторинга не избежать простым более грамотным проектированием системы заранее.
недавно например, портировал одну свою старую игрушку на iphone. я уже и забыл как она там внутри устроена, лет 5 назад ее написал. как портировал? игрушка состояла из логики и чужого фреймворка. выкинул фреймфорк, заменил своим, все, игрушка заработала. никакой вообще возни со старым кодом — он фиксирован и заморожен, никакого рефакторинга.
Рефакторинга иногда не избежать.
Иногда нужно прикрутить фичу, а с текущей архитектурой это оказыается невозможным. Поэтому правится архитектура, и только потом прикручивается фича. Частенько с начала проекта эта фича просто не предполагается.
Характерный пример — добавление возможности подключать плагины.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали: Ф>Частенько с начала проекта эта фича просто не предполагается.
когда я написал ту игру iphone даже в проекте не было и портировать ее я вообще никуда не собирался
Ф>Характерный пример — добавление возможности подключать плагины.
плагин это загружаемая dll ка имеющая доступ к некоему классу-классам позволяющим получать инфу и контролировать поведение приложения. вводил как-то плагины в два совершенно разных приложения, где изначально их не было. не рефакторилось вообще ничего.
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
я конешно не просветленный но щетаю что архитектура должна быть максимально возможно простой и построена мало связанной между собой блоками. кроме того она должна соответствовать масштабу задачи. и еще быть единообразной везде-везде во всем-во всем. и еще она должна быть без халтуры — т.е. нельзя давать ей расползаться, за этим важно следить когда работает команда, чтоп она соблюдала соглашения (или в критическом случае меняла их, если они явно не соответствуют, но меняла везде).
а! и еще если функционал какой-то решили выкинуть, то нужно взять себя в руки и код тоже удалить со всеми связями. многие этого не любят, ведь как от себя отрезаешь...
это лично мой опыт, хотя я вроде где-то может чо-то такое и читал. ну и может кто-то назовет меня после этого ко или наоборот порящим непрофессиональную фигню, но вот такой мой опыт все равно
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, 0K, Вы писали: 0K>>Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр. __>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Dym On, Вы писали:
__>>>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы. DO>>Откуда такой максимализм? Рефакторинг возникает в процессе понимания задачи, изменений требований и т.п. "Во время пути собака могла подрасти" (С). Когда начинаешь работать над проектом требования одни, пока разрабатываешь у клиента могут поменяться бизнес-процессы, задачи, пройти реорганизация и т.д. DO>>Потом, понимание задачи тоже приходит не сразу. В процессе разработки начинаешь видеть где и что неправильно, дыры в архитектуре. __>ну я же тоже не сразу "сел и стал писать". я прошел через то время, когда все переписывалось и переписывалось и все как-то не выходило ничего и опять переписывалось и опять менялось и опять переписывалось. а завтра еще кое-что переписывалось и послезавтра. __>сейчас я пишу один раз код, который слегка меняется во время тестирования, после этого фризится и я им могу лет пять-десять пользоваться не внося ни единого изменения. нет такого чтобы сел, сделал иерархию классов, поделал че-то полгода, потом давай эту иерархию переделывать. все делается один раз и на всю жизнь проекта с минимумом правок.
Без обид, но лично мне смутно в это вериться. Наверняка можно найти условия при которых твоя иерархия будет непригодна или будет требовать серьезной модификации.
ИМХО, программирование и проектирование в частности, это такая область, где постоянно необходимо совершенствоваться, пробовать новые методы и подходы, нельзя просто застыть на месте и перестать учиться. Нет никакой черты за которой ты можешь сказать, я супер гуру и лучше уже не сделать.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, 0K, Вы писали: 0K>>Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр. __>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
И еще вопрос, используете ли вы bug tracking?
Просто суть в том, что если мастер пишет код, который содержит баги, это плохой мастер и он не обладает достаточной квалификацией, чтобы поправить эти баги. И даже, если ему удасться пофиксить что-то костылями и заплатками, то он наплодит дополнительно тучу новых багов. По сути, bug tracking не нужен вообще. Когда человек на собеседовании говорит мне, что он пользуется bug tracking-ом, я на него смотрю как на идиота, потому как я сам даже не тестирую свой код, ибо настоящий мастер пишет код так, чтобы он работал сразу и наповал, и независимо от изменяющихся во времени и пространстве требований.
Здравствуйте, __kot2, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Здравствуйте, preview, Вы писали:
P>Здравствуйте, __kot2, Вы писали:
__>>... и называет он это умным словом рефакторинг.
P>И еще вопрос, используете ли вы bug tracking?
Туда же:
Исползуете ли вы IDE/редактор кода?
Потому как настоящему мастеру хватит этого:
d:\>copy con main.cpp
...
int main(int argc, char* argv[])
{
_
Здравствуйте, samius, Вы писали:
S>Исползуете ли вы IDE/редактор кода? S>Потому как настоящему мастеру хватит этого: S>int main(int argc, char* argv[])
S>А теперь-то понял, что незачем этого ламера Фаулера читать с его глупостями.
дело в том, что рефакторинг звучит как умное слово и не считается чем-то постыдным, именно поэтому вопрос о рефакторинге позволяет реально выяснить, насколько хорошо дела в проекте с архитектурой. копиписта, например, считается постыдной и на вопрос "как часто в твоей архитектуре ты используешь копипасту" многие предпочтут ответить "никогда" вне зависимости от реального положения дел, а рефакторинг звучит уже как что-то умное и люди не будут стараться приврать, чтобы выставить себя в лучшем свете
Здравствуйте, preview, Вы писали: P>И еще вопрос, используете ли вы bug tracking? P>Просто суть в том, что если мастер пишет код, который содержит баги, это плохой мастер и он не обладает достаточной квалификацией, чтобы поправить эти баги. И даже, если ему удасться пофиксить что-то костылями и заплатками, то он наплодит дополнительно тучу новых багов. По сути, bug tracking не нужен вообще. Когда человек на собеседовании говорит мне, что он пользуется bug tracking-ом, я на него смотрю как на идиота, потому как я сам даже не тестирую свой код, ибо настоящий мастер пишет код так, чтобы он работал сразу и наповал, и независимо от изменяющихся во времени и пространстве требований.
рефакторинг это переделывание. баг фиксинг это исправление багов. разница понятна? вот сделал ювелир украшение. потом взял его и переделал — распилил на части, заново собрал или вообще часть отпилил и наварил новую. это рефакторинг. а если нужно просто раскатать кольцо под палец, поскольку оно не налазит, то это ерундовое пятиминутное дело и это багфиксинг.
Здравствуйте, __kot2, Вы писали: __>рефакторинг это переделывание. баг фиксинг это исправление багов. разница понятна? вот сделал ювелир украшение. потом взял его и переделал — распилил на части, заново собрал или вообще часть отпилил и наварил новую. это рефакторинг. а если нужно просто раскатать кольцо под палец, поскольку оно не налазит, то это ерундовое пятиминутное дело и это багфиксинг.
даже более точно сказать не "раскатать кольцо под палец", поскольку это "изменение требований" — универсальная отмазка всех криворуких программистов, а багфиксинг это скорее подогнуть чуть защелку чтобы защелкивалась лучше
кстати, косвенная причина хорошей архитектуры — отстусвие хронических и сложнодетектируемых багов. их нет вообще. есть только ерундовые, да и тех мало. типичные правки таких багов — одна строка, а то и менее 10 символов.
Здравствуйте, __kot2, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? "
+500. очень много программистов "дрочат" код. и хотя я совсем не программист, а потому не авторитет, но все же считаю, что писать нужно или хорошо, или проводить "большую чистку", переписывая большие куски кода.
поделюсь своей историей. больше двух лет назад начал писать свою первую "промышленную" программу и на момент написания у меня не было не только опыта, но и перечня требований к проекту, который стремительно эволюционировал и на движок гоночной машины навешивался плуг с сенокосилкой.
через полтора года, когда объем кода перевалил за отметку 10 килострок, проект полностью потерял управляемость, превратившись в помесь сандвича со спаггети и дальнейшее развитие зашло в тупик. полгода проект не развивался (мелкий багфикс и мини-фичи не в счет). и вот сегодня началась большая чистка. на данном этапе мы точно знали что нам надо и какая часть кода наиболее полезна. а работаем мы в жестоком реалтайме и вот чтобы обойти по скорости конкурентов начали выбрасывать все личшее, все что только можно выбросить.
дошла очередь и до меня. добавили в двух местах if(0), отключив два движка из трех и убив 2/3 кода, обеспечив десятикратный прирост скорости, пускай и ценой потери многих полезных фич (впрочем, без них можно обойтись).
какой можно из этого сделать вывод? оставшийся код если с него сорвать все обертки уклаывается в тысячу строк и который разделяется на две неравные части -- меньше сто строк выполняются в условиях жесткого реалтайма на сенсорах с малыми ресурсами, а на серверную часть выносится валидация, которую можно переписать с си на питон или руби для большей гибкости. а для максимальной оптимизации на сенсор вместо бинарного дерева с ручной оптимизацией забацать dfa. и быстрее будет, и декомпиляция затруднительна (если кто захочет этим заняться).
вот такая история. если бы я кинулся занматься рефркаторингом когда проект начал подавать первые признки потери управляемости -- это ничего бы не решило, только бы время убил. а вот сейчас пора радикального редизайна.
__>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер.
я еще только учусь программировать, но уже сформулировал себя правило, что писать каждую строчку надо так, чтобы потом ее никогда и ни при каких обстоятельствах не переписывать. и как ни смешно, но лучший путь достижения совершенства написания кода это... _не_ _писать_. покурив хорошей травы, неожиданно выясняешь, что действительно, ничего и не нужно писать.
> и называет он это умным словом рефакторинг.
я называю это дрочением кода.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, 0K, Вы писали:
0K>С опытом учишься видеть главное и не зацикливаешься на мелочах. Кстати, достичь сего "просветления" неплохо помогают грамотные вопросы.
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Самый важный вопрос, который программист должен задать себе и всем вокруг, перед тем, как начать решать задачу — "зачем это надо?". Ответ на этот вопрос принесёт много просветления в неокрепшие умы и поможет уже просветлённым сохранять незамутнённое сознание.
Здравствуйте, monax, Вы писали:
M>Самый важный вопрос, который программист должен задать себе и всем вокруг, перед тем, как начать решать задачу — "зачем это надо?".
Заказчик иногда не может внятно объяснить зачем это надо, а не только программист.
----
Пишутся прототипы, рисуются схемы, клепаются диаложки, по ходу дела выписываютс требования. И эдак месяца через 2 появляется ТЗ, а заказчик уже в сотоянии ответить какие задачи система будет решать. Вот только к этому моменту некоторое кол-во г-на уже написано.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, preview, Вы писали: P>>И еще вопрос, используете ли вы bug tracking? P>>Просто суть в том, что если мастер пишет код, который содержит баги, это плохой мастер и он не обладает достаточной квалификацией, чтобы поправить эти баги. И даже, если ему удасться пофиксить что-то костылями и заплатками, то он наплодит дополнительно тучу новых багов. По сути, bug tracking не нужен вообще. Когда человек на собеседовании говорит мне, что он пользуется bug tracking-ом, я на него смотрю как на идиота, потому как я сам даже не тестирую свой код, ибо настоящий мастер пишет код так, чтобы он работал сразу и наповал, и независимо от изменяющихся во времени и пространстве требований. __>рефакторинг это переделывание. баг фиксинг это исправление багов. разница понятна? вот сделал ювелир украшение. потом взял его и переделал — распилил на части, заново собрал или вообще часть отпилил и наварил новую. это рефакторинг. а если нужно просто раскатать кольцо под палец, поскольку оно не налазит, то это ерундовое пятиминутное дело и это багфиксинг.
Очень похоже, что у вас еще юношеский максимализм не унялся (собсно, я поэтому про год окончания школы и спрашивал). Думаю, вы в более-менее крупных разработках с кол-вом людей на проекте > 1 никогда участия не принимали и с заказчиками, которые иногда сами не могут сформулировать, что именно они хотят, не общались. Очень похоже, что вы работаете на себя (шароварщик или фрилансер) или просто один программер в конторе (и швец, и жнец и на дуде игрец), и собственно, с этих позиций вы и рассуждаете. Сами себе поставили задачи, сами реализовали, тишь и благодать.
Рефакторинг для меня это возможность убрать лишнее и привести структуру/архитектуру кода под уже более-менее устоявшиеся требования, потому как в серьезных проектах на ранних этапах эти самые требования могут меняться на полностью противоположные. И если паттерн/архитектура удовлетворяли текущим требованиям, то после изменений в требованиях эти самые паттерн/архитектура могут препятствовать дальнейшему развитию проекта, это особенно актуально, если над проектом трудится команда, а не один человек. В условиях того же agile, я считаю, что refactoring прототипа (первой версии) продукта просто необходим, потому как на данном этапе ты только и занимался тем, что уточнял требования и подстраивался под пожелания заказчика, что несомненно сказывается на качестве и количестве кода. Полагаю, что вы с этим просто никогда не сталкивались, но жизнь вас научит.
Здравствуйте, __kot2, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Рефакторинг — это в том числе исправление архитектурных ошибок. Если вы не проводите рефакторинг, то это не значит, что вы не допускаете ошибок. Это всего лишь значит, что вы их не исправляете. Слабоватый повод для гордости, если честно
