В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
TafT wrote: > У кого какие соображения на этот счет? Я так понимаю, это исключительно > работа над собой, может какие то методики/философии, обязательно > применимые в реале!!! Желательно проверенные.
Есть очень хорошая, проверенная, дающая почти 100% гарантии методика.
Называется "переквалифицироваться в управдома".
Еще можно заниматься формальным доказательством кода или тщательным
тестированием каждой строчки.
Здравствуйте, TafT, Вы писали:
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
TT> И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Для этого достаточно использовать типобезопасные языки и правельные техники программирования. Хотя как соломку не подкладывай... Но типобезопасные языки снижают количество необъяснымых и фатальных падений очень координально.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
TT>>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. VD>Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
При этом, важно не поддаваться на провокации, подобные описанным в статье Джоэеля Спольски "То, чего делать нельзя (Things You Should Never Do)".
Есть одна причина, по которой программисты всегда хотят выбросить старый код и начать сначала: они всегда считают, что старый код ужасен. По моим наблюдениям, они, возможно, неправы. Считать этот код ужасным их заставляет глубокий, фундаментальный закон программирования:
TT>> И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д. VD>Для этого достаточно использовать типобезопасные языки и правельные техники программирования. Хотя как соломку не подкладывай... Но типобезопасные языки снижают количество необъяснымых и фатальных падений очень координально.
ИМХО, они их всего лишь скрывают, до поры до времени... По этому, как ты правильно заметил, как соломку не подкладывай...
Anton Batenev wrote: > VD>Для этого достаточно использовать типобезопасные языки и правельные > техники программирования. Хотя как соломку не подкладывай... Но > типобезопасные языки снижают количество необъяснымых и фатальных падений > очень координально. > ИМХО, они их всего лишь скрывают, до поры до времени... По этому, как ты > правильно заметил, как соломку не подкладывай...
Языки с сильной типизацией позволяют раньше ошибки выявлять.
Здравствуйте, Anton Batenev, Вы писали:
AB>При этом, важно не поддаваться на провокации, подобные описанным в статье Джоэеля Спольски "То, чего делать нельзя (Things You Should Never Do)".
Есть огромная разница между критической оценкой кода и желанием выбросить весь код.
К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
AB>ИМХО, они их всего лишь скрывают, до поры до времени...
Они не могут скрывать ошибки. Они просто не допускают ошибок типов. Проблема в том, что типобезопасные языки и среды живут во враждебном мире где реинтерпретация памяти где попало считается обыйденным делом. И рано или поздно можно засосать проблему извне. Но это в любом случае куда безопаснее чем просто жить в мире где без реинтерпретации памяти нельзя сделать ни шага.
AB>По этому, как ты правильно заметил, как соломку не подкладывай...
Вопрос в том насколько ты часто и больно бьешся.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
VD>... Проблема в том, что типобезопасные языки и среды живут во враждебном мире где реинтерпретация памяти где попало считается обыйденным делом. И рано или поздно можно засосать проблему извне. Но это в любом случае куда безопаснее чем просто жить в мире где без реинтерпретации памяти нельзя сделать ни шага.
Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном. Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
AB>>По этому, как ты правильно заметил, как соломку не подкладывай...
VD>Вопрос в том насколько ты часто и больно бьешся.
IMHO частота таких падений больше зависит от аккуратности программиста, а уже потом от среды.
AG>Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном. Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
Попрошу не воспринимать мой пост про больших кошек и прочих больных падений как сигнал к следующему раунду известного флейма или оскорбление для адептов управляемых сред .
Здравствуйте, TafT, Вы писали:
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Без багов никто писать не может, так что можешь не комплексовать по этому поводу. Понятное дело, к этому нужно стремиться, но ещё надо учиться быстро локализовывать баги, ставить диагноз и душить их, душить.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Тут дело даже не в методиках. В принципе, при определённой сноровке написать 200 строчек работающего безглючного кода можно даже ни разу не запустив компилятор. Это как раз не самое важное. Самые злобные баги приходят к нам не в момент написания кода, а в момент его модификации. Отсюда следует простое правило — код нужно писать так, чтобы его было легко модифицировать в дальнейшем. Это должно быть правилом, всё остальное — следствия из него, в том числе и методики.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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%. Во первых в этом случае лучше дать переменным нормальные имена (т.к. компилятору все-равно), а во вторых может быть даже вынести циклы в отделные функции или методы.
А вообще лучше почитать например Макконнелла "Совершенный код".
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц.
Что такое баг? В смысле — что конкретно ты понимаешь под этим словом? Так вот, когда ты сформулируешь это для себя, то поймёшь, что окружающие, как правило, думают иначе.
TT>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
Так читабельности, логичности или скорости? Всегда придётся выбирать что-то одно в качестве приоритета. Да, и ещё. Две из трёх упомянутых тобой характеристик — субъективные. А как известно, для всех мил не будешь. Иногда тебя будут хотеть укусить просто ради самого укушения.
TT>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Ну, это сильно нервирует обычно только поначалу. Потом быстро учишься таких ошибок избегать. Ты ведь уже называешь такие ошибки "тупыми"? Кстати, это далеко не самый неприятный и опасный класс ошибок. В конце концов, падение программы — это диагностика ошибки, когда другие средства не помогают.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Правильно понимаешь. Иногда это придётся делать вопреки всем без исключения окружающим. Даже авторитетным. Так что, готовься, никто не обещает, что будет легко. Если, конечно, ты не хочешь стать "ещё одним из миллионов и миллионов" (тогда разговаривать с тобой — пустая трата времени).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ArtemGorikov, Вы писали:
AG>А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
Подозреваю, что если логика зависит от возможностей авторефакторинга...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Anton Batenev, Вы писали:
AB>Вероятно, ты забыл добавть, что все это есть в современных средах (да и то далеко не во всех), а не в тех, что были 4-5 лет назад когда код создавался (это я все про свой проект).
Так вот он и говорил, что сейчас, смотря на этот код и чувствуя непреодолимое желание у вас есть инструменты-помощники.
AB>А про автоматизированный рефакторинг кода, например, SQL — тут я что-то сомневаюсь, что подобное вообще имеется в наличии.
Автоматизированный рефакторинг Сиквела? Ну, ну... Для этого есть правильные разработчики на Сиквеле. Руки и голова решают все. Помогают еще диаграммы.
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Это только если перестать писать код вообще.
Не ошибается ведь только тот, кто ничего не делает.
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Здравствуйте, squiz, Вы писали:
AB>>А про автоматизированный рефакторинг кода, например, SQL — тут я что-то сомневаюсь, что подобное вообще имеется в наличии. S>Автоматизированный рефакторинг Сиквела? Ну, ну... Для этого есть правильные разработчики на Сиквеле. Руки и голова решают все. Помогают еще диаграммы.
Автоматизированная система наведения межконтинентальных ракет — сержант и рядовой? (или как там оно в оригинале?)
. Всем известно, что реинтерпретация памяти считается в C++ дурным тоном. Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
Если нам не помогут, то мы тоже никого не пощадим.
