U need a faster processor ? =) Смотрят. Только вот людей таких мало.

Тут пока ожидаю документов от заказчика, значит, самообразовываюсь чтением всякой фигни. И, в частности, один из топиков был "Как Заставить Программиста Сделать Не Идеальную Систему, А То, Что Нужно Заказчику И Вовремя" :D

Исходное сообщение Dr_F0lken U need a faster processor ? =) Смотрят. Только вот людей таких мало.

Угу. Таких с каждым годом все меньше. И да, криворукость современных программеров обычно компенсируется за счет бешеных количеств дешевых мегагерц и гигабайт.

Исходное сообщение Bor_ka И, в частности, один из топиков был "Как Заставить Программиста Сделать Не Идеальную Систему, А То, Что Нужно Заказчику И Вовремя" :D

Дело не в создании идеальной системы, ибо идеал недостижим. Дело в том, что грамотный программист умеет соблюсти баланс между функциональностью и грамотной реализацией. Причем качественной реализации уделяется внимание на самых ранних этапах проектирования, еще до написания кода. Иногда глядя на "what's new" многих прог уши дыбом встают от того, какие "мелкие баги" там исправлены. А все потому, что программист сначала писал код, а потом, получив кучу багрепортов, начал думать.

TraxxOfAxe Ну тут по-моему (1) набрали студентов/Индусо/... по дешёвке и (2) топы срезали в два раза финансирование "чтобы остаться на рынке"

Ситуя следующая. Почему надо писать НОРМАЛЬНЫЙ код. Если мы говорим об обычном клиентском приложении для продвижении в массы. Achtung ! Ненормативная лексика. 1. Нахуй оптимизации. То есть не надо включать опцию компилятора соответствующую. Потому что у клиента скорее всего это "иобнет" в самый ответственный момент вот на таком куске кода. struct mY_vEry_Funky_Struct; memcpy(pDataForFunkyStruct,&mY_vEry_Funky_Struct,sizeof(mY_vEry_Funky_Struct)); .... как-то так. Ебнет точно, потому что скорее всего "для ускорения работы" установили выравнивание по слову или DWORD. И еще включили оптимизацию по скорости. OMG... лучше не думать. 2. Не надо оптимизировать код ! Точнее, применять приемы "из журналов" и тп. Код потом поддерживать. Скорее всего, тебе. Где ты через год найдешь "журнал-с-этой-клевой-статьей". Я не имею ввиду, что надо передавать параметры напрямую, а не по ссылке... Я имею ввиду использование библиотек типа boost, или когда начало транзакции идет в одном классе, середина и конец - в других. Это ЗАПУТЫВАЕТ КОД. 3. Надо делать ЕДИНУЮ, и, желательно, централизованную систему ловли исключений. Любая другая ситуация ЗАПУТЫВАЕТ КОД. 4. НЕ ПИШИТЕ ПОВТОРЫ КОДА. То, что будет исправлено в одном куске, будет забыто в другом. Даже если у Вас 5ый дан по cut'n'paste. 5. Избегайте макросов. Потому что их никогда не отладить. Потому что ОНИ _НЕРЕДКО_ запутывают код. Напишите функцию. 6. #$%! Не реализуйте функцию в .h фАйле !! Мать-перемать. Во-первых, IDE опухает порой от такого. Во-вторых CodeCoverage опухает много раз. 7. Используйте CodeCoverage. Это механизм "покрытия кода". Баги скрываются в ветвлениях. А они отрабатывают далеко не всегда, особенно если программу тестирует сам программист. Теперь вот что. Я недавно "прошел через релиз" и понял, в какой момент грамотно спроектированная система превращается во Франкенштейна. Когда прибегает кто-то из "топов" и верещит, что "надо-срочно-впердолить-или-убрать-фичу". Тут начинается полевая хирургия - тут отрезали, там пришили, потому что нету времени на перепроектирование. Мораль - надо делать так, чтобы добавление или удаление фичи не приводило к кастрации или накачиванию стероидами ВСЕЙ системы. И еще. Ненадо НИЧЕГО делать "на будущее". Оно уже наступило. Если фича неиспользуется, в кодее ее быть НЕ ДОЛЖНО. Просто в 99% это НИКОГДА не понадобится. А вот через месяц тупо глядя в отладчик ты сидишь и думаешь, а нахуа тут это... Последняя фишка. Если кто-то врезал в программу код "пасхально яйца", то его надо в воспитательных целях заставить ежедневно бегать за сигаретами и кофе для всего офиса. Потому что скорее всего там происходит запись по адресу 0x00000. Вот так. (c) Я 2005-2006. Теперь по поводу гигагерц. И оптимизации. К сожалению, любые объектные технологии оптимизации подлежат плохо. Потому как заставить компилятор делать как-то по-другому чревато пунктом 1 из вышеперечисленного. Если мы говорим о Programming Pearls... Ну относитесь к этому, как к хобби. Это как модельки клеить - кто-то криво делает и быстро. А кто-то медленно и аккуратно. Но кайф от этого нельзя измерить в $$$ и евро. Исключительно в объеме fun'a для себя-любимого. Все остальное - зарабатывание бабла.

"мсье знает толк в извращениях"

Исходное сообщение Dr_F0lken Теперь вот что. Я недавно "прошел через релиз" и понял, в какой момент грамотно спроектированная система превращается во Франкенштейна. Когда прибегает кто-то из "топов" и верещит, что "надо-срочно-впердолить-или-убрать-фичу". Тут начинается полевая хирургия - тут отрезали, там пришили, потому что нету времени на перепроектирование. Мораль - надо делать так, чтобы добавление или удаление фичи не приводило к кастрации или накачиванию стероидами ВСЕЙ системы.

мораль - это, конечно, хорошо... но вот только на практике как ты себе такое представляешь? я практически в любом своём проекте стараюсь сделать код максимально модульным, именно по той причине, что лишь при наличии однозначной модульности получается потом достаточно легко и быстро вводить новые изменения какие-т. но есть ещё такая штука, как общая структура. и вот эта-то общая структура вполне может начать "плыть" при изменении какого-т одного модуля. либо наоборот - код начинает множиться по причине введения новых модулей, которые делают почти то же самое что и имеющиеся, но только уже с учётом новых каких-т требований... на самом дее если знаешь какие-т реальные методы структуризации кода и ухода от всех этих последующих "провалов/вспучиваний", плюс с какими-нить прекомпиляторами оптимизирующими - озвучивай :)