Здравствуйте, TafT, Вы писали:
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Без багов никто писать не может, так что можешь не комплексовать по этому поводу. Понятное дело, к этому нужно стремиться, но ещё надо учиться быстро локализовывать баги, ставить диагноз и душить их, душить.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Тут дело даже не в методиках. В принципе, при определённой сноровке написать 200 строчек работающего безглючного кода можно даже ни разу не запустив компилятор. Это как раз не самое важное. Самые злобные баги приходят к нам не в момент написания кода, а в момент его модификации. Отсюда следует простое правило — код нужно писать так, чтобы его было легко модифицировать в дальнейшем. Это должно быть правилом, всё остальное — следствия из него, в том числе и методики.
Если нам не помогут, то мы тоже никого не пощадим.
В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Здравствуйте, TafT, Вы писали:
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
TT> И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Для этого достаточно использовать типобезопасные языки и правельные техники программирования. Хотя как соломку не подкладывай... Но типобезопасные языки снижают количество необъяснымых и фатальных падений очень координально.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AG>Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном. Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
Попрошу не воспринимать мой пост про больших кошек и прочих больных падений как сигнал к следующему раунду известного флейма или оскорбление для адептов управляемых сред .
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Здравствуйте, Геннадий Васильев, Вы писали:
TT>>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
ГВ>Ну, это сильно нервирует обычно только поначалу. Потом быстро учишься таких ошибок избегать. Ты ведь уже называешь такие ошибки "тупыми"? Кстати, это далеко не самый неприятный и опасный класс ошибок. В конце концов, падение программы — это диагностика ошибки, когда другие средства не помогают.
Самые простые баги это когда GPF вылетает. Это как правило легко трассируется, ловится и исправляется.
А вот когда все работает но где-то порой что-то ... это труба дело.
Например отладка HTML renderera на каком-нибудь сайте типа New York Times.
Он склеен из всяких мелких кусков из разных источников и все в таблицах.
Здравствуйте, TafT, Вы писали:
TT>если человек пишет хорошо но медленно, то кажется что он пишет мало TT>с другой стороны можно писать быстро и криво и потом фиксить.. вроде субъективно работает много, трудится..
На практике почему то получается что человек либо пишет быстро и без багов, либо медленно и с багами.
TT>как это решается в реале? учитываются ли такие особенности?
В реале учитывается куммулятивный эффект. Писать очень медленно конечно неудовлетворительно. Но и написанный на скорую руку код тоже никого не устраивает. У нас в команде его достаточно быстро перепишут, даже если в данный конкретный момент он работает.
... << RSDN@Home 1.2.0 alpha rev. 629 on Windows XP 5.1.2600.131072>>
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Кто-то мне говорил что у Word примерно 5000 незакрытых багов висит. По жизни.
Наличие багов есть индикация факта что программа кем-то востребована.
Может быть и спорное утверждение, но тем не менее.
По определению в той программе что лежит у меня на полочке так и не распакованная багов нет. Для меня.
Латентные баги есть всегда.
А вот последствия от них должны быть минмальны по возможности.
Но это уже вопрос архитектуры.
То что сейчас истываю:
1) Писать всегда БЕЗ музыки и посторонних отвлечений. Музыка, сайты и прочее — во время между тасками, но пока задача не сделана — полносью в ней.
2) Если что то где то нужно сделать, но попозже, то все это записывает на листик! (а не в TODO), и обязательно делается до окончания таска.
3) Максимально стараюсь представить все связанные с таском процессы, вплодь до вызывания конструкторов (если важно).
4) Из n вариантов выбирается самый простой в понимании и чтении, на оптимизацию, экономию строчек и прочего забил!
5) Если от класса (например) нужна какая то функциональность, то сначала пишется (прямо в коде) как я хочу ее использовать (из соображений читабельности, удобства и более/менее универсальности), а потом она реализуется в классе/классах. (В случае необходимости подгоняется друг к другу)
6) Если правлю чужие файлы — то пишу так, как там (у нас все пишут как хотят.. то есть нету единого стиля).
7) Перед сдачей таска тщательно тестируеются вся правленная/сделанная функциональность, и все что могло быть зацепленно (Знание проекта + выписки во время выполнения таска + интуиция )
ИМХО — клево получилось. я вчера таким образом багов 8 нашел, когда добавлял фичу в новую для меня область... то есть в результате -8 багов.
ЗЫ волнует вопрос скорости. Вроде не особо то и медленнее, + не прийдется тратить время на фикс (а фиксить то все равно прийдется), да и по горячим следам фиксится легче. Но все за временем надо еще понаблюдать.
.. и отсюда вопрос к ПМ-ам, Тим лидерам,
если человек пишет хорошо но медленно, то кажется что он пишет мало
с другой стороны можно писать быстро и криво и потом фиксить.. вроде субъективно работает много, трудится..
в первом случае на фичу уйдет 10 часов
во втором, на написание — 5 и еще 10 на фикс багов.. вроде бы первый человек лучше работает, но субъективно работает лучше второй...
как это решается в реале? учитываются ли такие особенности?
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц.
Что такое баг? В смысле — что конкретно ты понимаешь под этим словом? Так вот, когда ты сформулируешь это для себя, то поймёшь, что окружающие, как правило, думают иначе.
TT>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
Так читабельности, логичности или скорости? Всегда придётся выбирать что-то одно в качестве приоритета. Да, и ещё. Две из трёх упомянутых тобой характеристик — субъективные. А как известно, для всех мил не будешь. Иногда тебя будут хотеть укусить просто ради самого укушения.
TT>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Ну, это сильно нервирует обычно только поначалу. Потом быстро учишься таких ошибок избегать. Ты ведь уже называешь такие ошибки "тупыми"? Кстати, это далеко не самый неприятный и опасный класс ошибок. В конце концов, падение программы — это диагностика ошибки, когда другие средства не помогают.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Правильно понимаешь. Иногда это придётся делать вопреки всем без исключения окружающим. Даже авторитетным. Так что, готовься, никто не обещает, что будет легко. Если, конечно, ты не хочешь стать "ещё одним из миллионов и миллионов" (тогда разговаривать с тобой — пустая трата времени).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
TafT wrote: > У кого какие соображения на этот счет? Я так понимаю, это исключительно > работа над собой, может какие то методики/философии, обязательно > применимые в реале!!! Желательно проверенные.
Есть очень хорошая, проверенная, дающая почти 100% гарантии методика.
Называется "переквалифицироваться в управдома".
Еще можно заниматься формальным доказательством кода или тщательным
тестированием каждой строчки.
Anton Batenev wrote: > VD>Для этого достаточно использовать типобезопасные языки и правельные > техники программирования. Хотя как соломку не подкладывай... Но > типобезопасные языки снижают количество необъяснымых и фатальных падений > очень координально. > ИМХО, они их всего лишь скрывают, до поры до времени... По этому, как ты > правильно заметил, как соломку не подкладывай...
Языки с сильной типизацией позволяют раньше ошибки выявлять.
VD>К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
VD>... Проблема в том, что типобезопасные языки и среды живут во враждебном мире где реинтерпретация памяти где попало считается обыйденным делом. И рано или поздно можно засосать проблему извне. Но это в любом случае куда безопаснее чем просто жить в мире где без реинтерпретации памяти нельзя сделать ни шага.
Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном. Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
AB>>По этому, как ты правильно заметил, как соломку не подкладывай...
VD>Вопрос в том насколько ты часто и больно бьешся.
IMHO частота таких падений больше зависит от аккуратности программиста, а уже потом от среды.
Здравствуйте, Anton Batenev, Вы писали:
AB>Вероятно, ты забыл добавть, что все это есть в современных средах (да и то далеко не во всех), а не в тех, что были 4-5 лет назад когда код создавался (это я все про свой проект).
Так вот он и говорил, что сейчас, смотря на этот код и чувствуя непреодолимое желание у вас есть инструменты-помощники.
AB>А про автоматизированный рефакторинг кода, например, SQL — тут я что-то сомневаюсь, что подобное вообще имеется в наличии.
Автоматизированный рефакторинг Сиквела? Ну, ну... Для этого есть правильные разработчики на Сиквеле. Руки и голова решают все. Помогают еще диаграммы.
Здравствуйте, GlebZ, Вы писали:
GZ>Знаю противоположный случай. Один программист писал код с множеством багов. В конце концов его уволили. И тут оказалось что в группе из 5 человек — 70 процентов кода написал именно он. Приглашали его за дополнительные деньги консультировать. GZ>Тоже ситуация не очень хорошая.
Багов за ним числилось тоже 70% от общего количества?
Здравствуйте, Anton Batenev, Вы писали:
AB>Э... Поясни, плз... Пусть у меня есть код. Его критическая оценка говорит мне о том, что его надо выбросить и написать заново — мне самому себе на него смотреть стыдно... Однако, у него есть одна особенность — этот код работает уже 3 года и работает так как надо. Сколько ему еще потребуется работать и через сколько времени он станет неподдерживаемым я не могу сказать. Это во первых.
Если приходится править код, то во время правки производи рефакторинг изменяемых участков кода... и будет тебе щастье.
AB>Во вторых, если при проектировании системы изначально допустили некоторую логическую ошибку, то тут о постепенном рефакторинге речи не идет — ибо начинать надо с самого верхнего уровня иерархи (классов например или структуры данных таблиц в базе).
Это почему же "не идет"? Очень даже идет.
AB>Но ведь все равно рано или поздно наступим на грабли ибо не допускать ошибок невозможно...
Грабли != ошибки. Грабли — это заранее известные провоцирующие на ошибки обстоятельства.
Грабли конечно можно научиться объходить, перепрыгивать, на худой конце, уварачиваться от них. Есть не мало мастеров этого дела. Они уже достигли такой искусности, что могут идти прямо через поле граблей и получить всего 1-2 раза по кумполу.
Но куда лучше просто убрать грабли и не бояться получить по кумполу каждую минуту.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Anton Batenev, Вы писали:
AB>Я понял твою точку зрения, логикой понимаю, что ты прав и другого выхода, меньшего по затратам, наверное, нет и быть не может, однако, сердце противится этому А противится оно по следующией причине: через некоторое время, при таком подходе, другой человек, читающий этот код, будет подобен археологу, на глазах которого рождается, становится и (не дай бог) умирает цивилизация — люди меняются, стиль программирования меняется как почерк, приходят одни, уходят другие. Даже при наличии соглашения о стилях кодирования, исходный код зрелого продукта будет представлять собой винигрет из смешания культур и вероисповеданий помноженый на время.
Не знаю, плакать надо или смеяться — но обычно так оно и есть
Здравствуйте, VladD2, Вы писали:
TT>>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. VD>Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
При этом, важно не поддаваться на провокации, подобные описанным в статье Джоэеля Спольски "То, чего делать нельзя (Things You Should Never Do)".
Есть одна причина, по которой программисты всегда хотят выбросить старый код и начать сначала: они всегда считают, что старый код ужасен. По моим наблюдениям, они, возможно, неправы. Считать этот код ужасным их заставляет глубокий, фундаментальный закон программирования:
TT>> И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д. VD>Для этого достаточно использовать типобезопасные языки и правельные техники программирования. Хотя как соломку не подкладывай... Но типобезопасные языки снижают количество необъяснымых и фатальных падений очень координально.
ИМХО, они их всего лишь скрывают, до поры до времени... По этому, как ты правильно заметил, как соломку не подкладывай...
Здравствуйте, Anton Batenev, Вы писали:
AB>При этом, важно не поддаваться на провокации, подобные описанным в статье Джоэеля Спольски "То, чего делать нельзя (Things You Should Never Do)".
Есть огромная разница между критической оценкой кода и желанием выбросить весь код.
К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
AB>ИМХО, они их всего лишь скрывают, до поры до времени...
Они не могут скрывать ошибки. Они просто не допускают ошибок типов. Проблема в том, что типобезопасные языки и среды живут во враждебном мире где реинтерпретация памяти где попало считается обыйденным делом. И рано или поздно можно засосать проблему извне. Но это в любом случае куда безопаснее чем просто жить в мире где без реинтерпретации памяти нельзя сделать ни шага.
AB>По этому, как ты правильно заметил, как соломку не подкладывай...
Вопрос в том насколько ты часто и больно бьешся.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AB>>При этом, важно не поддаваться на провокации, подобные описанным в статье Джоэеля Спольски "То, чего делать нельзя (Things You Should Never Do)". VD>Есть огромная разница между критической оценкой кода и желанием выбросить весь код.
Э... Поясни, плз... Пусть у меня есть код. Его критическая оценка говорит мне о том, что его надо выбросить и написать заново — мне самому себе на него смотреть стыдно... Однако, у него есть одна особенность — этот код работает уже 3 года и работает так как надо. Сколько ему еще потребуется работать и через сколько времени он станет неподдерживаемым я не могу сказать. Это во первых.
Во вторых, если при проектировании системы изначально допустили некоторую логическую ошибку, то тут о постепенном рефакторинге речи не идет — ибо начинать надо с самого верхнего уровня иерархи (классов например или структуры данных таблиц в базе).
И где мне искать ту огромную разницу?
VD>К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
Вероятно, ты забыл добавть, что все это есть в современных средах (да и то далеко не во всех), а не в тех, что были 4-5 лет назад когда код создавался (это я все про свой проект). А про автоматизированный рефакторинг кода, например, SQL — тут я что-то сомневаюсь, что подобное вообще имеется в наличии.
AB>>ИМХО, они их всего лишь скрывают, до поры до времени... VD>Но это в любом случае куда безопаснее чем просто жить в мире где без реинтерпретации памяти нельзя сделать ни шага.
Но ведь все равно рано или поздно наступим на грабли ибо не допускать ошибок невозможно...
Здравствуйте, VladD2, Вы писали:
VD>Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный
ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
Да, это точно... причем через 2 недели после написания свой же код читать противно...
TT>> И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
VD>Для этого достаточно использовать типобезопасные языки и правельные техники программирования. Хотя как соломку не подкладывай... Но типобезопасные языки снижают количество необъяснымых и фатальных падений очень координально.
Да нет, там есть свои грабли... у нас напимер была утечка памяти... 600Мб/неделю.. .NET
Отсюда следует простое правило — код нужно писать так, чтобы его было легко модифицировать в дальнейшем. Это должно быть правилом, всё остальное — следствия из него, в том числе и методики.
Здравствуйте, TafT, Вы писали:
TT>Отсюда следует простое правило — код нужно писать так, чтобы его было легко модифицировать в дальнейшем. Это должно быть правилом, всё остальное — следствия из него, в том числе и методики.
TT>А это как?
Ну например есть три вложенных цикла с малопонятными именами переменных i, j и k. И где-нибудь внутри обращение типа array[i][k][j] = 10. Вот если писать так, то гемморой при последующей модификации обеспечен на 100%. Во первых в этом случае лучше дать переменным нормальные имена (т.к. компилятору все-равно), а во вторых может быть даже вынести циклы в отделные функции или методы.
А вообще лучше почитать например Макконнелла "Совершенный код".
Здравствуйте, ArtemGorikov, Вы писали:
AG>А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
Подозреваю, что если логика зависит от возможностей авторефакторинга...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Это только если перестать писать код вообще.
Не ошибается ведь только тот, кто ничего не делает.
Здравствуйте, squiz, Вы писали:
AB>>А про автоматизированный рефакторинг кода, например, SQL — тут я что-то сомневаюсь, что подобное вообще имеется в наличии. S>Автоматизированный рефакторинг Сиквела? Ну, ну... Для этого есть правильные разработчики на Сиквеле. Руки и голова решают все. Помогают еще диаграммы.
Автоматизированная система наведения межконтинентальных ракет — сержант и рядовой? (или как там оно в оригинале?)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что такое баг? В смысле — что конкретно ты понимаешь под этим словом? Так вот, когда ты сформулируешь это для себя, то поймёшь, что окружающие, как правило, думают иначе.
Баг — все то, что прийдется исправлять. ( Не считая того, когда просто меняются требования ).
TT>>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
К счастью пока такого не было... И честно, совсем не хочется
TT>>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
ГВ>Правильно понимаешь. Иногда это придётся делать вопреки всем без исключения окружающим. Даже авторитетным. Так что, готовься, никто не обещает, что будет легко. Если, конечно, ты не хочешь стать "ещё одним из миллионов и миллионов" (тогда разговаривать с тобой — пустая трата времени).
Я так уже 14 лет живу, при том, что мне сейчас 19. Знаю как это иногда бывает больно, когда прав, и это точно знаешь, а человек, ответственный — не знает, и тебя ругает... Пришлось научиться объяснять на пальцах, и ломать маску "страшный начальник".
По поводу чего хочу — хочу быть лучшим.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, TafT, Вы писали:
TT>>... без багов.
TT>>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Д>рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Да дело в том, что у меня в команде (но на другом проекте, то есть на большую команду 3 несвязанный проекта, которые образуют комплекс), есть человек такой.. Баги он делает, но так мало! И по скорости не отстает. И код его просто прелесть... На вопрос "как?" отвечает — а ты баги не пиши.....
А еще спросил что у меня по русскому в школе было... Тут меня осенило, но это надо лечить (невнимательность? забывчивать? хз). Вопрос как лечить?
Здравствуйте, Дарней, Вы писали:
Д>рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Знаю противоположный случай. Один программист писал код с множеством багов. В конце концов его уволили. И тут оказалось что в группе из 5 человек — 70 процентов кода написал именно он. Приглашали его за дополнительные деньги консультировать.
Тоже ситуация не очень хорошая.
А вообще код без ошибок может писать только сама ЭВМ. И то, до тех пор пока в метапрограмме программисты не сделали ошибки.
Здравствуйте, TafT, Вы писали: TT>Я так уже 14 лет живу, при том, что мне сейчас 19. Знаю как это иногда бывает больно, когда прав, и это точно знаешь, а человек, ответственный — не знает, и тебя ругает... Пришлось научиться объяснять на пальцах, и ломать маску "страшный начальник".
"Лёлик, только без рук — я всё исправлю!" (c) "Бриллиантовая рука".
Здравствуйте, TafT, Вы писали:
TT>Баг — все то, что прийдется исправлять. ( Не считая того, когда просто меняются требования ).
А ещё поменяться могут несуществующие требования, которые казались очевидными. Здесь нет другого способа, кроме как трясти постановщика задачи для начала и много-много думать. Ну и... учитывать всё, что можно учесть.
TT>>>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. TT>К счастью пока такого не было... И честно, совсем не хочется
Ну, что ж. Если случится — не пугайся.
TT>По поводу чего хочу — хочу быть лучшим.
Что это такое — "быть лучшим"? Где? В чём? Когда?
У тебя есть баг в начальных посылках. Исправь его, остальные сами исправятся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, VladD2, Вы писали:
VD>>К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
AG>А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
А что, смена темы уже стала аргументацией считаться?
AG>Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном.
Серьезно? Жаль мужики не знают. (с)
Большинство С++-программ напичканы опасными конструкциями. Если даже программист их избегает, они все равно появятся благодаря библиотечным вызвом и т.п.
AG> Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
1. Не совсем тоже самое. В C# ты явно выделяшь код занимающийся химией.
2. Правда в том, что для 99% программ небезопасный режим не нужен.
AG>IMHO частота таких падений больше зависит от аккуратности программиста, а уже потом от среды.
Надежда на аккуратность — это самое плохое дизайнерское решение. Человеку свойственно ошибаться и для построения надежной системы нужно продумывать механимы гарантирующие отсуствие ошибок.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TafT, Вы писали:
TT>Да, это точно... причем через 2 недели после написания свой же код читать противно...
Это значит, что не просто есть куда рости, но и нужно рости по быстрее.
Я все же говорил о сроке в пол года- год.
TT>Да нет, там есть свои грабли... у нас напимер была утечка памяти... 600Мб/неделю.. .NET
Понимаш ли?... Ошики бываюр разного порядка. Просто утечка памяти при некотором объеме знаний и наличии средств отладки ловится без проблем. А вот испорченная память может породить ошибку второго или даже третьего порядка. Когда ошибка в одном месте портит памят в другом, а вылетает вообще в третьем.
Что же касается утечек памяти. То достаточно завести глобальный массив или глобальный объект с собитиями и набить их мусором.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если приходится править код, то во время правки производи рефакторинг изменяемых участков кода... и будет тебе щастье.
Это что же тогда получается... Одни модули, которые часто изменяемые, показать не стыдно, а над базовыми, написаными на заре проекта, от которых и начались все пляски, хоть плачь?
Я понял твою точку зрения, логикой понимаю, что ты прав и другого выхода, меньшего по затратам, наверное, нет и быть не может, однако, сердце противится этому А противится оно по следующией причине: через некоторое время, при таком подходе, другой человек, читающий этот код, будет подобен археологу, на глазах которого рождается, становится и (не дай бог) умирает цивилизация — люди меняются, стиль программирования меняется как почерк, приходят одни, уходят другие. Даже при наличии соглашения о стилях кодирования, исходный код зрелого продукта будет представлять собой винигрет из смешания культур и вероисповеданий помноженый на время.
AB>>Во вторых, если при проектировании системы изначально допустили некоторую логическую ошибку, то тут о постепенном рефакторинге речи не идет — ибо начинать надо с самого верхнего уровня иерархи (классов например или структуры данных таблиц в базе). VD>Это почему же "не идет"? Очень даже идет.
Тогда, вероятно, речь идет о создании новой ветки в репозитории, ломании всего старого и построении заново?
AB>>Но ведь все равно рано или поздно наступим на грабли ибо не допускать ошибок невозможно... VD>Но куда лучше просто убрать грабли и не бояться получить по кумполу каждую минуту.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что это такое — "быть лучшим"? Где? В чём? Когда?
Если я правильно понял TafT,то у меня такое же желание.
В принципе, стремиться стать лучшим в своём деле нужно всегда и везде. Тогда если даже самым лучшим не станешь, то успеха всё равно добьёшься.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Проверенная методика — писать код раз в месяц.
Шутка злая естественно, но в ней намёк.
Волков бояться — в лес не ходить
Не стоит заморачиваться на философии, для начала стоит научится писать так, чтобы найденные баги исправлялись максимально быстро, следующий этап, чтобы гайденные баги исправлялись максимально быстро не только автором кода, но и любым программистом из команды автора кода.
Здравствуйте, VladD2, Вы писали:
.
VD>Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
Я знаю человека который пишет без багов Так че там не возможно?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, __SPIRIT__, Вы писали:
__S>>Я знаю человека который пишет без багов Так че там не возможно? WH>А он случайно по воде ходить не умеет?
Нет хотя кто его знает ...
Он мне как то одну вещь в проекте объяснял я просто с открытым ртом сидел и слушал...
Описания что и как доходчиво и внятно + описания почему именно так т.е. вот так то будет то то
Этот человек пишет чуть ли не пол проекта так что скорость дай боже
Здравствуйте, nNeitrino, Вы писали:
N>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Что это такое — "быть лучшим"? Где? В чём? Когда?
N>Если я правильно понял TafT,то у меня такое же желание. N>В принципе, стремиться стать лучшим в своём деле нужно всегда и везде. Тогда если даже самым лучшим не станешь, то успеха всё равно добьёшься.
Ну шо б так ваще без багов — это вряд ли. Да и зачем? Скучно. А шо б меньше — можно попробовать методолгию ХР (Test-infected, test-driven programming и проч.)
CS>Кто-то мне говорил что у Word примерно 5000 незакрытых багов висит. По жизни.
К слову сказать — не только у Word'а.
К сожалению, суровая реальность такова, что частенько приходится сдавать сырой проект, потому что сроки поджимают,а функциональность уже как бы вся готова.
А вообще мне кажется, что программы станут гораздо лучше и безглючнее, если перед каждым новым релизом перед разработчиками будет ставится задача закрыть все существующие баги.
зы: сделал поиск на bugs.sun.com state:open. Найденных багов — 22565
Год назад мне в руки попала книжка издательства Питер с прикольным названием -- "Технологии Пентагона на службе российских программистов. Програмная Инженерия".
Так вот в этой маленькой книжке очень большая часть уделялась программированию без багов. Ну то есть совсем. Только не бегите её покупать сразу -- большая половина этой части состояла из рекламы в духе (текст прямо оттуда)
После обучения программистов методолигии PSP
* в фирме Union Switch and Signal на этапах внедрения и промышленного использования пяти заказных корпоративных систем не встретилось ни одной ошибки. Все работы были выполнены точно в срок;
* в фирме Моторола в 18 проектах общим размером 25 тысяч FP была обнаружена только одна ошибка;
* в фирме AIS время тестирования выпускаемых продуктов сократилось с 2 месяцев до 5 дней.
Прочитав это и ещё кучу такого-же (там же, там такого оч. много) я сразу побежал глазами искать подтверждение того что это часть рекламы каких-нить супер-пупер-курсов и книжку можно в мусор оказалось наоборот -- автор сетовал что в xUSSR таких курсов нет и походу не предвидится. Так что место на моей полке эта книжка таки завоевала.
Ну а теперь об этой методологии. Расшифровывается PSP -- как Personal Software Process, согласно книжке осиливается оно не с ходу, а в несколько странно пронумерованных шагов: 0, 0.1, 1, 1.1, 2, 2.1, 3. А ещё там аж 76 форм стандартов и инструкций составленных институтом SEI который эту методологию и родил. В книжке этих форм и стандартов не было только номер шагов и краткие их описания.
В общем обчитавшись я тогда повёлся, натаскал чего смог в нете и е-муле по теме найти и начал усердно читать. Даже внедрял и субьективно производительность росла а бажность снижалась. Правдой оказалось то что сходу не осилить -- сильно внедрить в себя эту тему я так и не смог -- мало нашёл информации (этот SEI на халяву только крохи даёт, а остальное то-ли за деньги то-ли вообще непонятно), да и вышла бета C# 2.0, которую тоже хотелось освоить поскорее, а на проектах сроки жали... короче подзабил.
Для интересующихся сие таинство может быть одним из путей к нирване. А у меня вопрос к тем кто уже применял. Вы есть вообще такие? Стоит ли продолжать проникаться этим PSP??
Здравствуйте, hi_octane, Вы писали:
_>с Минска, но в Питер думаю забраться
_>У меня в архивах страшный бардак , в течении пары дней соберу хотя-бы в одну кучу всё что натаскал и выложу где-нить, что-бы по 10 раз не отсылать.
> жду с нетерпением
Здравствуйте, hi_octane, Вы писали:
_>с Минска, но в Питер думаю забраться
_>У меня в архивах страшный бардак , в течении пары дней соберу хотя-бы в одну кучу всё что натаскал и выложу где-нить, что-бы по 10 раз не отсылать.
Как поживает разбор завалов?
Если уже выложил поделись ссылочкой плиз
Если нам не помогут, то мы тоже никого не пощадим.
Так че там не возможно?
, в течении пары дней соберу хотя-бы в одну кучу всё что натаскал и выложу где-нить, что-бы по 10 раз не отсылать.