С опытом учишься видеть главное и не зацикливаешься на мелочах. Кстати, достичь сего "просветления" неплохо помогают грамотные вопросы.
Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Здравствуйте, 0K, Вы писали: 0K>Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? "
суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Здравствуйте, __kot2, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Вот еще один вопрос: используете ли вы систему контроля версий?
Суть в том, что система контроля версий нужна либо для
1) плохих программистов, которые переписывают и исправляют один и тот же программный модуль по несколько раз, причем сами не понимают, что делают и иногда хотят откатываться к предыдущим версиям
2) программисты не доверяют друг другу, либо не способны договариваться друг с другом (в частности не могут договориться даже до того, кто какой модуль в данный момент редактирует)
Есть еще такой вопрос: используете ли вы профайлер?
Суть в том, что если с самого начала пишется эффективный код, то профайлер для этого кода вообще не нужен, так как он ничего интересного не покажет. Если же применяется популярный нынче подход: быстро-быстро говнокодим, то в этой команде скорее всего будет популярен профайлер, чтобы определять где слой говна самый толстый.
Здравствуйте, __kot2, Вы писали:
__>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Ты так говоришь, будто это что-то плохое
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, __kot2, Вы писали:
__>>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг. 0>Ты так говоришь, будто это что-то плохое
ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы.
Здравствуйте, __kot2, Вы писали:
__>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы.
Либо просто другой философии разработки
Если два человека за равное время выдают результат одинакового качества, но один сначала думает-думает, а потом рожает конечный результат, а второй пишет прототипный код, который потом "доводит напильником", то разве можно говорить, что у кого-то тут руки из попы?
Здравствуйте, __kot2, Вы писали:
0>>Ты так говоришь, будто это что-то плохое __>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы.
Вы счастливый человек, у вас не изменяются требования.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, __kot2, Вы писали:
__>>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы. 0>Либо просто другой философии разработки 0>Если два человека за равное время выдают результат одинакового качества, но один сначала думает-думает, а потом рожает конечный результат, а второй пишет прототипный код, который потом "доводит напильником", то разве можно говорить, что у кого-то тут руки из попы?
не существует единой самой хорошей и самой правильной архитектуры, но бывают люди которые знают и умеют пользоваться только одним подходом и получая чужой код, вполне возможно, прекрасный код, но написанный в другой философии, начинают подстраивать его под себя, переделывать, внося в проверенный код разнообразные баги. место этого стоит просто изучить этот подход и спокойно пользоваться уже существующим кодом, расширяя или поддерживая его при надобности.
Здравствуйте, Lloyd, Вы писали: L>Вы счастливый человек, у вас не изменяются требования.
поэтому еще на этапе проектирования нужно абстрагироваться от всех рисковых вещей, которые могут измениться в будущем. например, если просто вбивать в код тупо вызовы opengl функций, то потом будет сложно переводить все на directX, но такой бы проблемы не было, если бы изначально это было выделено в отдельный класс.
Здравствуйте, __kot2, Вы писали:
0>>Если два человека за равное время выдают результат одинакового качества, но один сначала думает-думает, а потом рожает конечный результат, а второй пишет прототипный код, который потом "доводит напильником", то разве можно говорить, что у кого-то тут руки из попы? __>не существует единой самой хорошей и самой правильной архитектуры, но бывают люди которые знают и умеют пользоваться только одним подходом и получая чужой код, вполне возможно, прекрасный код, но написанный в другой философии, начинают подстраивать его под себя, переделывать, внося в проверенный код разнообразные баги. место этого стоит просто изучить этот подход и спокойно пользоваться уже существующим кодом, расширяя или поддерживая его при надобности.
Я не об этом. Вот пишут с нуля программу два программиста, один сначала долго думает сразу пишет конечный результат, второй начинает писать быстро, постепенно рефакторингом доводя код до кондиции. Чем первый программист лучше второго?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, __kot2, Вы писали:
0>>>Если два человека за равное время выдают результат одинакового качества, но один сначала думает-думает, а потом рожает конечный результат, а второй пишет прототипный код, который потом "доводит напильником", то разве можно говорить, что у кого-то тут руки из попы? __>>не существует единой самой хорошей и самой правильной архитектуры, но бывают люди которые знают и умеют пользоваться только одним подходом и получая чужой код, вполне возможно, прекрасный код, но написанный в другой философии, начинают подстраивать его под себя, переделывать, внося в проверенный код разнообразные баги. место этого стоит просто изучить этот подход и спокойно пользоваться уже существующим кодом, расширяя или поддерживая его при надобности. 0>Я не об этом. Вот пишут с нуля программу два программиста, один сначала долго думает сразу пишет конечный результат, второй начинает писать быстро, постепенно рефакторингом доводя код до кондиции. Чем первый программист лучше второго?
точно так же как из жигулей 6ки нельзя сделать спортивный мерседес, хоть там все гайки замени из хреновой программы никогда нельзя "вырефакторить" нормальную, хотя есть целая армия тех, кто думает обратное. это те самые люди которые на свои жигули лепят антикрыло, обвес и действительно верят, что "получилось то же самое".
Здравствуйте, __kot2, Вы писали: __>точно так же как из жигулей 6ки нельзя сделать спортивный мерседес, хоть там все гайки замени из хреновой программы никогда нельзя "вырефакторить" нормальную, хотя есть целая армия тех, кто думает обратное. это те самые люди которые на свои жигули лепят антикрыло, обвес и действительно верят, что "получилось то же самое".
то есть нельзя постоянно ремонтируя и подлатывая программу получить то, что изначально проектировалось и делалось как нечто крутое.
Здравствуйте, __kot2, Вы писали:
__>точно так же как из жигулей 6ки нельзя сделать спортивный мерседес, хоть там все гайки замени из хреновой программы никогда нельзя "вырефакторить" нормальную, хотя есть целая армия тех, кто думает обратное. это те самые люди которые на свои жигули лепят антикрыло, обвес и действительно верят, что "получилось то же самое".
Мне эта аналогия кажется неверной, а утверждение необоснованным.
Можно ли привести более строгую аргументацию?
Здравствуйте, __kot2, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Это вы сейчас людей, которые приходят на поддрежку и развитие любого проекта, которому больше нескольких лет "говнокодерами" назвали? А если им еще приходится код за "индусами" править и в нормальное состояние приводить, то они тогда вообще "ламеры" получаются?
Здравствуйте, ilvi, Вы писали: I>Это вы сейчас людей, которые приходят на поддрежку и развитие любого проекта, которому больше нескольких лет "говнокодерами" назвали? А если им еще приходится код за "индусами" править и в нормальное состояние приводить, то они тогда вообще "ламеры" получаются?
в утекших несколько лет назад исходниках Half-life2 можно увидеть куски кода quake 1 и даже части Doom II. И никто эти куски не трогал, не "рефакторил". старый код тоже нет необходимости рефакторить. бывает необходимость примерно раз в 10 лет смены парадигмы — например, переход с однопоточной на многопоточную архитектуру. это уже не рефакторинг, а часто внесение полностью новых решений. а колупаться, менять старый код смысла нет, тем более, если он работает.
I>А если им еще приходится код за "индусами" править и в нормальное состояние приводить, то они тогда вообще "ламеры" получаются?
ну во-первых ситуация переделки за кем-то она дурацкая, конечно, никому такой работы не пожелаю, никогда такой не занимался и надеюсь никогда с этим не столкнусь. и я не утверждаю, что тот, кто переделывает ламер, я утверждаю, что тот кто переделывает свой же код — ламер.
__>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы.
Откуда такой максимализм? Рефакторинг возникает в процессе понимания задачи, изменений требований и т.п. "Во время пути собака могла подрасти" (С). Когда начинаешь работать над проектом требования одни, пока разрабатываешь у клиента могут поменяться бизнес-процессы, задачи, пройти реорганизация и т.д.
Потом, понимание задачи тоже приходит не сразу. В процессе разработки начинаешь видеть где и что неправильно, дыры в архитектуре.
Здравствуйте, __kot2, Вы писали:
L>>Вы счастливый человек, у вас не изменяются требования. __>поэтому еще на этапе проектирования нужно абстрагироваться от всех рисковых вещей, которые могут измениться в будущем. например, если просто вбивать в код тупо вызовы opengl функций, то потом будет сложно переводить все на directX, но такой бы проблемы не было, если бы изначально это было выделено в отдельный класс.
Т.е. вы можете просто-напросто взять и усложнить архитектуру и сделать разработку дороже, несмотря на то, что требования могут и не измениться?
Вы действительно счастливый человек.
Здравствуйте, __kot2, Вы писали:
I>>А если им еще приходится код за "индусами" править и в нормальное состояние приводить, то они тогда вообще "ламеры" получаются? __>ну во-первых ситуация переделки за кем-то она дурацкая, конечно, никому такой работы не пожелаю, никогда такой не занимался и надеюсь никогда с этим не столкнусь. и я не утверждаю, что тот, кто переделывает ламер, я утверждаю, что тот кто переделывает свой же код — ламер.
По-моему, вы просто неправильно понимаете смысл этого слова.
14.04.2011 7:40, Здравствуйте, __kot2 : > вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас > началось? " > суть в том, что рефакторинг суть, если перевести на русский, > переделывание. мастер, который переделывает за себя свою же работу > плохой мастер. а который ее переделывает не нескольку раз очень плохой
Ущербная логика. Рефакторинг это исправление парных ошибок. Так как
ошибки не только обязательный, но и необходимый элемент разработки, их
исправление более чем нормально. Причем частота рефакторинга зависит от
динамики сложности проекта и квалификация программиста тут совершенно ни
при чем.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Dym On, Вы писали:
__>>ну, я знаю что не все согласны со мной. некоторые даже книжки пишут по рефакторингу. но да, я считаю, что когда дело доходит до рефакторинга, то не все ладно в датском королевстве. а перманентный рефакторинг — самое явное свидетельство рук из жопы. DO>Откуда такой максимализм? Рефакторинг возникает в процессе понимания задачи, изменений требований и т.п. "Во время пути собака могла подрасти" (С). Когда начинаешь работать над проектом требования одни, пока разрабатываешь у клиента могут поменяться бизнес-процессы, задачи, пройти реорганизация и т.д. DO>Потом, понимание задачи тоже приходит не сразу. В процессе разработки начинаешь видеть где и что неправильно, дыры в архитектуре.
ну я же тоже не сразу "сел и стал писать". я прошел через то время, когда все переписывалось и переписывалось и все как-то не выходило ничего и опять переписывалось и опять менялось и опять переписывалось. а завтра еще кое-что переписывалось и послезавтра.
сейчас я пишу один раз код, который слегка меняется во время тестирования, после этого фризится и я им могу лет пять-десять пользоваться не внося ни единого изменения. нет такого чтобы сел, сделал иерархию классов, поделал че-то полгода, потом давай эту иерархию переделывать. все делается один раз и на всю жизнь проекта с минимумом правок.
Здравствуйте, 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, Вы писали:
__>вопрос такой — "часто ли занимаетесь рефакторингом? и давно это у вас началось? " __>суть в том, что рефакторинг суть, если перевести на русский, переделывание. мастер, который переделывает за себя свою же работу плохой мастер. а который ее переделывает не нескольку раз очень плохой мастер. и по сути человек который уже сделал плохую архитектуру не обладает квалификацией сделать ее хорошо, хотя может понимать, что сделана она плохо. но вера в себя сильна и человек занимается переливанием из пустого в порожнее — переделыванием на то же, но вид сбоку. и называет он это умным словом рефакторинг.
Рефакторинг — это в том числе исправление архитектурных ошибок. Если вы не проводите рефакторинг, то это не значит, что вы не допускаете ошибок. Это всего лишь значит, что вы их не исправляете. Слабоватый повод для гордости, если честно
Здравствуйте, 0K, Вы писали:
0K>С опытом учишься видеть главное и не зацикливаешься на мелочах. Кстати, достичь сего "просветления" неплохо помогают грамотные вопросы.
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Ну к примеру — Все на интерфейсах vs иногда пожертвовать интерфейсами ради лучшей читаемости кода. Естественно для внутренних разработок.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Lloyd, Вы писали: L>>Т.е. вы можете просто-напросто взять и усложнить архитектуру и сделать разработку дороже, несмотря на то, что требования могут и не измениться? L>>Вы действительно счастливый человек. __>а вы можете сьесть тонну креветок? ах, вы ничего про это не говорили.
поэтому еще на этапе проектирования нужно абстрагироваться от всех рисковых вещей, которые могут измениться в будущем.
— это и есть усложнение функционала в угоду возможным изменениям в будущем, котое может и не наступить. У Спольски есть неплохая статья про архитектурных астронавтов, как раз об усложнятелях и абстрагателях.
__>вот и я тоже ничего про усложнение и удорожания вроде не писал. так что не выдумывайте всякую ерунду. если хотите мне возразить, приведите лучше пример изменения требований, когда рефакторинга не избежать простым более грамотным проектированием системы заранее.
Я сейчас в таком работаю. 4 года назад писался как простенький репорт в экселе. Сейчас — под 2 сотни пользователей по всему миру, отдельный сервер приложений для обсчетов, интеграция с хранилищем данных, из которого ежежневно выкачивается какое-то немерянное количество новых записей, каждый день под несколько миллионов записей со стороны пользователей.
Чтобы это предвидеть, надо как минимум быть Ностадамусом.
S>>А теперь-то понял, что незачем этого ламера Фаулера читать с его глупостями. __>дело в том, что рефакторинг звучит как умное слово и не считается чем-то постыдным, именно поэтому вопрос о рефакторинге позволяет реально выяснить, насколько хорошо дела в проекте с архитектурой.
Совершенно верно, но только связь, прямо противоположна той, которую вы обозначили несколькими постами ранее. Нет рефакторинга — код постепенно скатывается в сра*** га***.
__>копиписта, например, считается постыдной и на вопрос "как часто в твоей архитектуре ты используешь копипасту" многие предпочтут ответить "никогда" вне зависимости от реального положения дел,
Конечно, никогда, но не по той причини, что вы описали, а потому что вопрос — бредовый. Что вообще такое "копипаста в архитектуре"?
__>а рефакторинг звучит уже как что-то умное и люди не будут стараться приврать, чтобы выставить себя в лучшем свете
1. Не уловил связи между рефакторингом и копипастой.
2. Рефакторинг не звучит как что-то умное, слово как слово.
Здравствуйте, 0K, Вы писали:
0K>Предлагаю в этот топ скидывать такие списки с вопросами (не просто абы-какие вопросы, а вопросы выработанные в результате опыта). Меня больше интересуют вопросы по архитектуре приложений. Хотя не против мельком глянуть и на другие вопросы: по технологиям, по языкам и пр.
Если бы ко мне пришёл собеседоваться Будда Шакьямуни...
То я бы спросил его про strcspn.
Я ни разу не мучал этим вопросом реальных живых людей. Ни разу. Не потому что я мизантроп, не потому что я не верю в людей, а просто речь об уровне просветления -- я никогда не собеседовал людей на позиции где ТАКОЙ уровень вхождения в тонкости реально требовался бы.
Но раз вы хотите, давайте попробуем.
Итак, это открытый матч, вы можете пользоваться чем угодно, гуглом, головой и соседом, но попробуйте ответить содержательно:
-- что делает функция strcspn, зачем она нужна, что принимает-возвращает, каким пунктом стандарта C99 регламентируется, в каких случаях её использование даёт реальные преимущества (приведите пример кода, приведите альтернативные решения, покритикуйте)
-- как бы вы её реализовали, если бы разрабатывали стандартную библиотеку (запишите код на C)
-- оцените среднее число итераций, которое сделает написанный вами код по равномерно распределённым входным строкам (равномерно распределёнными считаем и строчки образцов тоже). Дайте верхние/нижние асимптотические оценки вашего кода по времени/памяти. Можно ли на них как-то поиграть, выигрывая одно за счёт другого? Какой ценой?
-- проанализировав среднее число итераций предложите оптимизацию этой функции по быстродействию в среднем случае. Сколько позволяет выиграть ваша оптимизация в среднем случае? Сравните реализацию этой функции как минимум в трёх известных вам реализациях стандартной библиотеки C, сравните с вашей реализацией, покритикуйте себя и других
-- обобщая, объясните зачем эта функция вообще включена в стандарт языка C
Здравствуйте, 0K, Вы писали:
0K>Предлагаю в этот топ скидывать такие списки с вопросами
У нас на физтехе когда я был студентом преподаватели говорили, что вопрос по билету на экзамене — это всего лишь предлог для интересной беседы
(по физике конечно).
Я считаю, что все тех-интервью должны строиться на этом принципе, пусть и немного юморном.
Здравствуйте, Tilir, Вы писали:
T>Итак, это открытый матч, вы можете пользоваться чем угодно, гуглом, головой и соседом, но попробуйте ответить содержательно:
T>-- что делает функция strcspn, зачем она нужна, что принимает-возвращает, каким пунктом стандарта C99 регламентируется, в каких случаях её использование даёт реальные преимущества (приведите пример кода, приведите альтернативные решения, покритикуйте)
Мягко говоря, очень станно видеть такой вопрос в ответе на пост, начинающийся со слов
С опытом учишься видеть главное и не зацикливаешься на мелочах.
Вы бы еще предложили спросить, сколько раз встречается артикль "the" в упомянутом стандарте.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Философ, Вы писали: Ф>>Частенько с начала проекта эта фича просто не предполагается. __>когда я написал ту игру iphone даже в проекте не было и портировать ее я вообще никуда не собирался
MV/MVC это уже классика, но сомневаюсь что к примеру компилятор C++ вы написали бы без рефакторинга.
Здравствуйте, Lloyd, Вы писали:
L>С опытом учишься видеть главное и не зацикливаешься на мелочах.
Просто я не согласен в этом с автором Мой опыт подсказывает, что по-настоящему с опытом начинаешь ценить и видеть мелочи и ньюансы. Между прочим вопрос сколько раз артикль the встречается в стандарте C99 кажется мне вполне нормальным Если дан final draft в формате pdf, можно спросить:
— какие библиотеки языка C человек знает (или может нагуглить) для разбора pdf-документов
— попросить сравнить две-три из них, аргументировать выбор подходящей
— попросить написать с использованием выбранной библиотеки код, который считает количество артиклей the в стандарте
— обсудить оптимизацию этого кода и его надёжность
Здравствуйте, UA, Вы писали: UA>Здравствуйте, __kot2, Вы писали: __>>Здравствуйте, Философ, Вы писали: Ф>>>Частенько с начала проекта эта фича просто не предполагается. __>>когда я написал ту игру iphone даже в проекте не было и портировать ее я вообще никуда не собирался UA>MV/MVC это уже классика, но сомневаюсь что к примеру компилятор C++ вы написали бы без рефакторинга.
то есть нельзя построить здание, скажем, МГУ не разломав его снова на части и не переделав посреди постройки?
L>- это и есть усложнение функционала в угоду возможным изменениям в будущем, котое может и не наступить. У Спольски есть неплохая статья про архитектурных астронавтов, как раз об усложнятелях и абстрагателях.
не читал но одобряю. воще видел когда при старте не проекта даже а некого отдельного функционала не очень то и большого в существующем проекте люди говорят "так щас посмотрим, какие патерны тут надо юзать" (и таки находят применение этим патернам, причем и гоф, и фаулер и еще что-нибудь из известного блога).
и все ж согласно и задумчиво кивают — как же мы без патернов, что ж это за архитектура то такая.
правда хорошо — скажешь, да давай сделаем просто вот так, потом если усложняться будет мона тут вот таким макаром будет додолбить. и все облегченно кивнут и спорить не будут (кроме совсем уж клиники), ну вот нашелся один лох, который патернов забоялся, ну шо ж, ответственность на нем в случае проблем — он нам не дал настоящую архтяктуру возвести. а там сделают и забудут.
__>сейчас я пишу один раз код, который слегка меняется во время тестирования, после этого фризится и я им могу лет пять-десять пользоваться не внося ни единого изменения.
а я вспомнил! вот это ваш обсолют, он достигнут и человеческая цивилизация теперь не нужна
Здравствуйте, MescalitoPeyot, Вы писали: MP>А что, в здании МГУ уже появилась психбольница, ядерный бункер и публичный дом? А у Садовничего в планах Евро-2012 на той же площадке?
все поете старую песню об "изменении требований"?
конечно, если бы строительство здания МГУ начали с расширения бытовки для рабочих, то после надстройки второго этажа нужно было бы рефакторить все — разбирать, делать нормальный фундамент и собирать обратно. возможно, некоторые бы так и сделали. дык флаг им в руки. хоть так могут что-то сделать, уже хорошо. таким людям вполне можно доверить строительство деревянных туалетов, но, конечно, от серьезных проектов их надо держать подальше. но ведь и туалеты кому-то надо строить.
T>-- что делает функция strcspn
... T>-- обобщая, объясните зачем эта функция вообще включена в стандарт языка C
Я бы также хотел заслушать ответ на последний вопрос (все остальные достаточно тривиальны и требуют немного времени на подумать и погуглить). Честно скажу, мне было лень, я только чутка голову включил, — и на мой вкус, окромя реализации чего-то подобного printf() cо строками форматирования, где есть РАЗНЫЕ placeholders, в мою включенную голову не приходит.
Я внесу всего один вопрос: ЗАЧЕМ? Вопрос применим в любом контексте, ответ на него дают весьма редко даже весьма просветленные личности. Обычно отвечать начинают на вопрос "почему?".
T>Просто я не согласен в этом с автором Мой опыт подсказывает, что по-настоящему с опытом начинаешь ценить и видеть мелочи и ньюансы.
Написание "ньюанс" — это почетная часть расстрельного списка типичных ошибок, но суть не в этом.
Я, кажется, понимаю вашу мысль: знание мелочей нужно затем, чтобы осознанно использовать язык программирования. Да, когда человек знает все тонкости, он, скорее всего, будет понимать, как именно работает написанный им код. Следовательно, не будет шаманских плясок с бубном, копипасты и индусятины ("а дай-ка я вот этот кусок вот сюда перенесу — вдруг заработает?").
К сожалению, вы сами блестяще иллюстрируете тот факт, что пользоваться языком (в данном случае русским) можно вполне успешно и не заморачиваясь знанием всех его тонкостей. Языки (и языки программирования в том числе) так устроены, что для пользования ими достаточно иметь привычку использования кое-каких конструкций языка. Привычка дает иллюзию понимания.
T>Между прочим(ЗПТ) вопрос(ЗПТ) сколько раз артикль the встречается в стандарте C99(ЗПТ) кажется мне вполне нормальным(ТЧК) Если дан final draft в формате pdf, можно спросить: T>- какие библиотеки языка C человек знает (или может нагуглить) для разбора pdf-документов
Как вам сейчас абсолютно бесполезно знание, сколько запятых вы пропустили, так и кандидату на должность программиста абсолютно бесполезно знание об именах этих библиотек. Вы ведь не используете знание правил русской пунктуации в своей работе? Вам они, скорее всего, и не интересны. Вот и кандидату вопрос о библиотеках странен и неинтересен, если он не планирует работать с парсингом PDF.
T>- попросить сравнить две-три из них, аргументировать выбор подходящей
Коронный вопрос: зачем?
Какие сведения о кандидате вы хотите получить, спрашивая его аргументацию в выборе среди незнакомых (скорее всего) ему библиотек? Является ли он поклонником или же противником опенсорса?
T>- попросить написать с использованием выбранной библиотеки код, который считает количество артиклей the в стандарте
Я не имею ничего против тестовых заданий, если они оправданы. Но вы должны понимать, что наличие тестового задания автоматически сужает число кандидатов, из которых вам придется выбирать. Да, явные остолопы отсеются, но и многие ценные кандидаты от вас отвернутся — кто-то по принципиальным соображениям, у кого-то просто не хватит времени. И чем менее полезным покажется ваше задание кандидату, тем меньше у него будет стимулов за него взяться.
В вашем случае тестовое задание имеет мало практической пользы. Кандидат должен очень хотеть у вас работать.
T>- обсудить оптимизацию этого кода и его надёжность
Если парсингом занимается библиотека, в основном коде будет, скорее всего, однопроходный цикл и счетчик. Вряд ли обсуждение стратегий оптимизации этого кода получится длинным.
Здравствуйте, keenn, Вы писали:
A>>Ну к примеру — Все на интерфейсах vs иногда пожертвовать интерфейсами ради лучшей читаемости кода. Естественно для внутренних разработок.
K>а какие интерфейсы имеются в виду, эти — interface IFace, class Book implements Readable, etc?
Ага, ими можно логику так запутать, что не разберешься.
"
