Ой глухое это дело «хороший код» vs «потоки сознания» и прочее. Вот приходит тут такой умник и начинает писать «хороший код» который лично я называю «академическим» придумывает иерархии интерфейсы и т.д. Но имеем что?
1. Затягивание сроков, что уже плохо.
2. Ситуация когда заказчик знает что ему надо хотябы в общих чертах это уже идеально, обычно он хочет «хочу чтобы было все чиста клева» поэтому часто надо нарисовать по быстрому дабы убедиться что все все поняли.
3. Практика показывает, что все эти стройные классы, инкапсуляции, наследования и другие умные слова в динамично развивающемся проекте старше 3х лет гроша выеденного не стоят. Ибо давно засунули в класс публичный член или сломали иерархию или как то заюзали классик по хитрому.
4. Я не знаю ни одного программера который бы сумел предусмотреть все. Причем чем опытнее программер тем больше он предусмотрит и тем сложнее будет впихнуть то про что он забыл «но заказчику это надо позарез»отсюда см. п3.
5. Костыли в «стройной системе костылей и подпорок» выглядят надежнее и гармоничнее, чем костыли в «стройной иерархии и архитектуре». А я еще не встречался с продуктами где обошлись без костылей.
Ну и основная проблема: а кто это будет все фиксить? Кода без ошибок не бывает. Но и нормально сконструированный код с хорошим наследованием, с полиморфизмом, шаблонами и т.д. у заказчика сыграет в сегфолт. А кто у нас на багфиксе? А на багфиксе у нас студенты ибо все остальные умники которые проектируют архитектуру они все выше этого банального баг фикса и бакфиксить код не будут/некогда ибо думают над задачами.
В итоге этот студент начинает править код в меру своего понимания. А лапша тем и хороша что нигде кроме этого места больше не используется, так что сломает он только локально, проверит и поправит.
А вот если архитектура хорошая то сломать он может сразу много, причем в самом неожиданном месте, и отыграет это опять у заказчика, ибо он свою локальную часть он проверит, тестеры проверят еще соседние, но все не проверят даже юнит тесты.
Резюмируя: «академический код» — хорошо, но в «академиях». На практике такой код поддерживается ничуть не проще, а зачастую для своей поддержки требует квалифицированных кадров. Да шансы что он сыграет меньше, но уж если сыграет (а он обязательно сыграет) то с барабанами, блэкджеком и другими атрибутами.
А на счет рефакторинга: — самый лучший рефакторинг — переписать все. Все равно заказчик теперь лучше знает что ему надо, и мы это лучше понимаем, есть известные проблемы, узкие места, наработки, опыт, можно предложить другую концепцию. Вообщем затратив сопоставимые ресурсы есть шансы получить хороший качественный скачок.
Так что я не доверяю ничему сложнее «калькулятора» и для меня главный критерий качества кода — его понятность/очевидность и уже во вторую очередь «архитектура»
Сегодня он играет джаз, а завтра родину продаст!!!
*рассыпая песок" а я даже видел и пробовал ЭВМ с перфокартами… Нам еще на кафедре показывали, все экзаменационные билеты на старых пробитых перфокартах были… теперешним ужо не кажут.
Деградируют потихоньку программеры… раньше помница есть у тебя 48К ОЗУ (на спектруме) и крутись как хочешь. А метр оперативки на 8086 просто заоблачной сказкой тогда казался. Оптимизировались и по памяти и по скорости. Я как то плавненько в сегодняшний гигагерцовый мир перешел, через мобильные платформы. А студенты нынешние считают что ассемблер уже не нужен, да что ассеблер Си говорят уже не нужен, низкоуровневое программирование не нужно. Все на богомерские шарпы да жавы заглядыватся, питонами разными стращают :).
Но неее. Нужны еще люди старой закалки. Когда надо с 10 гигабитной карты таки 9,8 гигабит получить. Когда надо процессы к ядрам привязывать да чтобы в пределах одной ноды оставались. Так что мы ишо повоюем!!! Мы ишо покажем вам кузькину мать!!!
К сожалению это касается не только сталинок и хрущовок. стандарт TN-C-S (хотя бы этот) только только начали лет может 10 последних строить, и за МКАДом успели построить всего ничего.
Просто пройтись по квартирам и посмотреть какие «технические» и «дизайнерские» решения используются при типовом ремонте… Например сан узлы — подвесные алюминиевые потолки. В них споты R50 E14. потолок опущен от реального сантиметров на 10. У Оптогана я не нашел ни имитаций «стандартных ламп спотов R50 E14», ни «кастомных» светильников длиной менее 10 см. Хотя как понимаю как раз спотам и нужны точечные светильники типа диодов, и на рынке вполне достаточно подобной продукции из поднебесной.
А если поспотреть на остальные люсты — то там либо галогенки либо стандартные. Причем опять таки мода на первые.
З.Ы. не судите строго это я с позиции одного конкретного обывателя говорю. Как раз в ванну подбираю альтернативу 60 ватным спотам R50 E14. Но люминисценки максимум 11W («советские» макс. 55) и очень долго разгораются. Алтернатива вроде LED 5W… но ведь китай.
Спасибо огромное за статью. Надеюсь что она все таки пессимистична и в ближайшем времени стоимость LED-ламп станет сопоставима с люминисцентными энергосберегайками. Все таки набелевку за сверхмощные LED получили то наши.
для передачи той же мощности потребуются провода гораздо толще. А это уже проблема ведущая например к увеличению кабель каналов в панелях и прочее.
Ну и самое главное «защита от дурака» если будут рядом 220 и 12 то обязательно вкрутят 12В лампу в 220. даже если у одной цоколь будет круглый а у другой квадратный :)
Для заливки данных почитайте про COPY и pg_restore, как вариант шапку из результата pg_dump'a — можно значительно ускорить загрузку отключив несколько параметров, не создавая индексов, много данных в одной транзакции (множественный инсерт порядка тысячи записей или банальный COPY) Ну и несколько коннектов… Но это для многоядерных машинок.
Ну и практика показывает что результаты тестов имееют очень мало схожего с реальной нагрузкой. Например у вас может быть идеальный отклик пока все (или хотябы индекс) помещается в шарной памяти, но затем единственный запрос SELECT * FROM толстая_таблица вытесняет все из буффера и просаживает io ниже плинтуса.
Или все хорошо и великолепно но затем «идеальный индекс» распухает до невозможных размеров перестает помещаться в память и привет. Причем разница измерения показателей (например транзакций в секунду) может быть на несколько порядков ( я не шучу вместо 10 тысяч вставок в секунду довольно резко проседаем до нескольких десятков вставок). При этом постгрес достаточно сильно оптимизирован. Поэтому все может быть очень хорошо даже с запасом, но по определенному закону у кастомера набор данных будет как раз тем единственным который максимально деградирует БД.
Так что тестируйте, тестируйте, тестируйте… но Еще больше анализируйте, и анализируйте.
Я например вообще склонен отказаться от оценок прямых результатов, в сторону оценок влияния нагрузки на систему. Например не время отклика на запрос, а утилизация системы при таком то числе запросов.
Ну и повторюсь любые тесты это синтетика. А никакая синтетика так не нагнет сервер как единственный кривой запрос кастомера. :)
Лично мое отношение к яблоку нельзя назвать позитивным… Но когда уходит такой Человек… Он определил лицо современного SOHO desktop, и Его вклад в доступность мира IT для рядового пользователя невозможно переоценить.
Вот я и зарегистрировался, за что отдельное спасибо persei.
Для начала хочу искренне поблагодарить Andrey2008 за внимание к проекту Miranda IM в целом и за указание на ошибки от имени разработчика модуля «clist_modern» (то бишь меня), который собственно и поминался чаще всего в статье.
К сожалению приведенные примеры ошибок (кроме одного) либо как таковыми не являлись, либо были в неработающем коде, ну или просто оказывались «плохим кодом», но не ошибочным. Но нет предела совершенству — посему код упомянутый в статье вы можете уже на trunc не найти.
Кстати пример номер раз в статье неверен, ибо sizeof &a, где а есть char *a[n]; вернет размер всего массива, а не первого его элемента. Собственно в этом и разница между массивом и указателем на массив, но все равно спасибо.
Хотелось бы немного оправдаться: не забывайте что проекты подобные миранде максимум хобби для уже сложившихся программистов. А чаще всего — исследовательская площадка для новичков стремящихся в сеньоры. Например по коду модерна можно проследить мою эволюцию как программиста :).
К сожалению наступает момент когда новичок стал сеньором и даже больше. И на старые проекты просто не хватает времени. Да и интересы уже гораздо дальше. А в свой старый код «как посмотришь так вздрогнешь». Поэтому я бы поостерегся называть код миранды (как минимум модерна) неплохим. Плохо то что упомянутые ошибки в коде это лишь мелочь на поверхности. Архитектурные просчеты (а их там легион) не выявит никакой PVC. А вреда от них…
И напоследок «почему Open Source'ники не используют инструменты подобные PVC: Вы цену лицензии видели? Причем записать „умение работать с PVC“ себе в актив вообщем сомнительно, особенно навичку — он просто не поймет о чем ему мегажелезка вещает. Ну а пользовать его нелегально — ай ай ай.
В принципе даже в серьезных коммерческих проектах использование под вопросом. Хотябы потому, что серьезные проекты разворачиваются на кросс платформах, где винде часто достаются несерьезные вещи вроде морды лица, писаная и переписанная на коленке раз надцать на каких нибудь шарпах из одних компонентов. И зачастую дешевле набрать стаю тестеров-студентов по 5 копеек пучек, или уделить больше времени на ревью кода, чем заплатить за лицензию софтине которая поможет вытащить на свет божий несколько некритичных багов которые тестеры почему то пропустили.
1. Затягивание сроков, что уже плохо.
2. Ситуация когда заказчик знает что ему надо хотябы в общих чертах это уже идеально, обычно он хочет «хочу чтобы было все чиста клева» поэтому часто надо нарисовать по быстрому дабы убедиться что все все поняли.
3. Практика показывает, что все эти стройные классы, инкапсуляции, наследования и другие умные слова в динамично развивающемся проекте старше 3х лет гроша выеденного не стоят. Ибо давно засунули в класс публичный член или сломали иерархию или как то заюзали классик по хитрому.
4. Я не знаю ни одного программера который бы сумел предусмотреть все. Причем чем опытнее программер тем больше он предусмотрит и тем сложнее будет впихнуть то про что он забыл «но заказчику это надо позарез»отсюда см. п3.
5. Костыли в «стройной системе костылей и подпорок» выглядят надежнее и гармоничнее, чем костыли в «стройной иерархии и архитектуре». А я еще не встречался с продуктами где обошлись без костылей.
Ну и основная проблема: а кто это будет все фиксить? Кода без ошибок не бывает. Но и нормально сконструированный код с хорошим наследованием, с полиморфизмом, шаблонами и т.д. у заказчика сыграет в сегфолт. А кто у нас на багфиксе? А на багфиксе у нас студенты ибо все остальные умники которые проектируют архитектуру они все выше этого банального баг фикса и бакфиксить код не будут/некогда ибо думают над задачами.
В итоге этот студент начинает править код в меру своего понимания. А лапша тем и хороша что нигде кроме этого места больше не используется, так что сломает он только локально, проверит и поправит.
А вот если архитектура хорошая то сломать он может сразу много, причем в самом неожиданном месте, и отыграет это опять у заказчика, ибо он свою локальную часть он проверит, тестеры проверят еще соседние, но все не проверят даже юнит тесты.
Резюмируя: «академический код» — хорошо, но в «академиях». На практике такой код поддерживается ничуть не проще, а зачастую для своей поддержки требует квалифицированных кадров. Да шансы что он сыграет меньше, но уж если сыграет (а он обязательно сыграет) то с барабанами, блэкджеком и другими атрибутами.
А на счет рефакторинга: — самый лучший рефакторинг — переписать все. Все равно заказчик теперь лучше знает что ему надо, и мы это лучше понимаем, есть известные проблемы, узкие места, наработки, опыт, можно предложить другую концепцию. Вообщем затратив сопоставимые ресурсы есть шансы получить хороший качественный скачок.
Так что я не доверяю ничему сложнее «калькулятора» и для меня главный критерий качества кода — его понятность/очевидность и уже во вторую очередь «архитектура»
*рассыпая песок" а я даже видел и пробовал ЭВМ с перфокартами… Нам еще на кафедре показывали, все экзаменационные билеты на старых пробитых перфокартах были… теперешним ужо не кажут.
Деградируют потихоньку программеры… раньше помница есть у тебя 48К ОЗУ (на спектруме) и крутись как хочешь. А метр оперативки на 8086 просто заоблачной сказкой тогда казался. Оптимизировались и по памяти и по скорости. Я как то плавненько в сегодняшний гигагерцовый мир перешел, через мобильные платформы. А студенты нынешние считают что ассемблер уже не нужен, да что ассеблер Си говорят уже не нужен, низкоуровневое программирование не нужно. Все на богомерские шарпы да жавы заглядыватся, питонами разными стращают :).
Но неее. Нужны еще люди старой закалки. Когда надо с 10 гигабитной карты таки 9,8 гигабит получить. Когда надо процессы к ядрам привязывать да чтобы в пределах одной ноды оставались. Так что мы ишо повоюем!!! Мы ишо покажем вам кузькину мать!!!
Просто пройтись по квартирам и посмотреть какие «технические» и «дизайнерские» решения используются при типовом ремонте… Например сан узлы — подвесные алюминиевые потолки. В них споты R50 E14. потолок опущен от реального сантиметров на 10. У Оптогана я не нашел ни имитаций «стандартных ламп спотов R50 E14», ни «кастомных» светильников длиной менее 10 см. Хотя как понимаю как раз спотам и нужны точечные светильники типа диодов, и на рынке вполне достаточно подобной продукции из поднебесной.
А если поспотреть на остальные люсты — то там либо галогенки либо стандартные. Причем опять таки мода на первые.
З.Ы. не судите строго это я с позиции одного конкретного обывателя говорю. Как раз в ванну подбираю альтернативу 60 ватным спотам R50 E14. Но люминисценки максимум 11W («советские» макс. 55) и очень долго разгораются. Алтернатива вроде LED 5W… но ведь китай.
Ну и самое главное «защита от дурака» если будут рядом 220 и 12 то обязательно вкрутят 12В лампу в 220. даже если у одной цоколь будет круглый а у другой квадратный :)
Для заливки данных почитайте про COPY и pg_restore, как вариант шапку из результата pg_dump'a — можно значительно ускорить загрузку отключив несколько параметров, не создавая индексов, много данных в одной транзакции (множественный инсерт порядка тысячи записей или банальный COPY) Ну и несколько коннектов… Но это для многоядерных машинок.
Ну и практика показывает что результаты тестов имееют очень мало схожего с реальной нагрузкой. Например у вас может быть идеальный отклик пока все (или хотябы индекс) помещается в шарной памяти, но затем единственный запрос SELECT * FROM толстая_таблица вытесняет все из буффера и просаживает io ниже плинтуса.
Или все хорошо и великолепно но затем «идеальный индекс» распухает до невозможных размеров перестает помещаться в память и привет. Причем разница измерения показателей (например транзакций в секунду) может быть на несколько порядков ( я не шучу вместо 10 тысяч вставок в секунду довольно резко проседаем до нескольких десятков вставок). При этом постгрес достаточно сильно оптимизирован. Поэтому все может быть очень хорошо даже с запасом, но по определенному закону у кастомера набор данных будет как раз тем единственным который максимально деградирует БД.
Так что тестируйте, тестируйте, тестируйте… но Еще больше анализируйте, и анализируйте.
Я например вообще склонен отказаться от оценок прямых результатов, в сторону оценок влияния нагрузки на систему. Например не время отклика на запрос, а утилизация системы при таком то числе запросов.
Ну и повторюсь любые тесты это синтетика. А никакая синтетика так не нагнет сервер как единственный кривой запрос кастомера. :)
Это огромная потеря не только для мира IT.
R.I.P, Steve
#include <conio.h>
int _tmain(int argc, _TCHAR* argv[])
{
char *(ImgIndex[64]);
printf( "%d, %d, %d \n",sizeof( ImgIndex ), sizeof( &ImgIndex ), sizeof( ImgIndex[0] ) );
return 0;
}
MS VC++ 2005
Вывод: 256, 256, 4
g++ ( x64)
Вывод: 512, 8, 8
Очередной довод: не надо так писать.
Для начала хочу искренне поблагодарить Andrey2008 за внимание к проекту Miranda IM в целом и за указание на ошибки от имени разработчика модуля «clist_modern» (то бишь меня), который собственно и поминался чаще всего в статье.
К сожалению приведенные примеры ошибок (кроме одного) либо как таковыми не являлись, либо были в неработающем коде, ну или просто оказывались «плохим кодом», но не ошибочным. Но нет предела совершенству — посему код упомянутый в статье вы можете уже на trunc не найти.
Кстати пример номер раз в статье неверен, ибо sizeof &a, где а есть char *a[n]; вернет размер всего массива, а не первого его элемента. Собственно в этом и разница между массивом и указателем на массив, но все равно спасибо.
Хотелось бы немного оправдаться: не забывайте что проекты подобные миранде максимум хобби для уже сложившихся программистов. А чаще всего — исследовательская площадка для новичков стремящихся в сеньоры. Например по коду модерна можно проследить мою эволюцию как программиста :).
К сожалению наступает момент когда новичок стал сеньором и даже больше. И на старые проекты просто не хватает времени. Да и интересы уже гораздо дальше. А в свой старый код «как посмотришь так вздрогнешь». Поэтому я бы поостерегся называть код миранды (как минимум модерна) неплохим. Плохо то что упомянутые ошибки в коде это лишь мелочь на поверхности. Архитектурные просчеты (а их там легион) не выявит никакой PVC. А вреда от них…
И напоследок «почему Open Source'ники не используют инструменты подобные PVC: Вы цену лицензии видели? Причем записать „умение работать с PVC“ себе в актив вообщем сомнительно, особенно навичку — он просто не поймет о чем ему мегажелезка вещает. Ну а пользовать его нелегально — ай ай ай.
В принципе даже в серьезных коммерческих проектах использование под вопросом. Хотябы потому, что серьезные проекты разворачиваются на кросс платформах, где винде часто достаются несерьезные вещи вроде морды лица, писаная и переписанная на коленке раз надцать на каких нибудь шарпах из одних компонентов. И зачастую дешевле набрать стаю тестеров-студентов по 5 копеек пучек, или уделить больше времени на ревью кода, чем заплатить за лицензию софтине которая поможет вытащить на свет божий несколько некритичных багов которые тестеры почему то пропустили.