Да объявлений глобальных может быть сколько угодно в месте объявления не выполняется никаких операций с памятью (собственно и места то никакого нет). (это если в одном модуле, если в разных то следует добавлять extern )
А вот в случае локального объявления (даже без инициализации) требуется выделить место на стеке и тут уже «бяда-бяда огорчение» ему что 2 раза там место выделять? вот и ругается.
Не не пойдет. Один великий сказал «Я понимаю что я ничего не понимаю».
Вон возьми хотя бы STL — чем глубже в лес тем толще дровосеки, иногда такие конструкции завернешь что мама дорогая объясните мне почему это работает :)
Да какой это менеджемент. Архитектор принимает решение о высокоуровневом дизайне комплекса, какие инструменты использовать. Причем часто это мотивируется "*опой чую", но все его *опе доверяют ибо она столько уже всего повидала :))
что то типа «компилировать только при растущей Луне но не позднее чем через день после затмения и только когда Юпитер находиться с Сатурном в противостоянии»?
Ну значит Вы неправильно меня поняли: под переписыванием я понимаю «разработать заново» в том числе и изменив парадигму, концепцию, ТЗ если хотите. Неизменной остается лишь задача заказчика, которую он хочет решить этим софтом. Причем часто задача которую он озвучивает — совсем не то какую он решает конкретно. Давайте продолжим с аналогиями.
Приходит к вам заказчик и говорит — разработайте мне что то забивать гвозди. Вы трудитесь стараетесь придумываете молоток. Отдаете заказчику — а он в итоге недоволен — гвозди не удобно забиваются. Вы ищете баги (действительно зачем ручка квадратная — сделаем эргономичную) фиксите, новая супер пупер версия — заказчик все равно недоволен.
А потом вы идете и выясняете а зачем емиу молоток — гвозди забивать, а зачем их забивать — картины на стену вешать, стоп а стены какие — гипсокартонные и у вас молоток плохой — из гипсокартона забитые им гвозди вываливаются. И Ваш архитектор придумывает шуруп и отвертку и ему выдвигают премию. Ура все довольны.
Да уже погуглил.
Чтото последнее время не до блогов было. Про StackOverflow конечно же слышал. Но факт остается фактом — критикуя ОДНО ИЗ решений Microsoft человек находится уровнем ниже. А про то что это решение помогло возможно избежать проблем в других сферах? Отрицательный результат это тоже результат и иногда не менее полезный.
Для меня «творчество» что то сродни интуитивного создания кода — выбор решения, возможно локально не самого оптимального, в условиях недостатка информации, но такого которое целом продукте/после n-дцати лет развития/после 10^m-ного переписывания ТЗ окажется более выгодным чем оказались бы другие.
Творчество это попытка найти решение не то которое на поверхности, а другое, не очевидное. То про которое не написал еще Кнут. Многие пытаются, мало кто находит, но те кто находят становятся Гейтсами, Фаулерами, Кнуттами.
Ну нет в программировании места роботам. Сгенерить из UML код можно, только он так себе получиться.
А все эти «доказательства 90х» годов и ведут к тому что банальному текстовому notepad 00-х годов ресурсов надо как хорошей такой игрухе 90-х.
Видимо вам повезло не работать с «роботами». Которые напишут точно так как указано в ТЗ и ни грамму не подумают, что ТЗ писал сосед по палате того самого «склонного к насилию психопата».
И мысли не допустят что заказчик скажет: «да я написал это ТЗ, но вы что сами не видите что это не удобно. И вообще ваш продукт гавно, а вот у конкурентов видите какая конфетка. Все больше я с вами не работаю и вместо новой версии у вас куплю продукт конкурента».
SIP и RTP — протоколы более низкого уровня чем «протокол» кодека, по факту это только «транспорты» и «маршрутизаторы». Голос как таковой они не кодируют, хотя могут налагать некие ограничения или правила кодирования/декодирования. Например сопоставить динамический Payload из RTP и использованный кодек без информации из контролинга очень сложно. Но все таки уже собранный фрагмент можно декодировать и без наличия RTP.
Компанию Microsoft и Netscape упомянутые в статье я знаю много слышал и использовал, как и про их продукты. А вот про Joel Spolsky, его компанию Fog Creek Software и продукты этой компании я услышал впервые. Так что позвольте с изрядной долей скептицизма отнестись к его советам и коментариям. Переписывание с нуля МОЖЕТ позволить (а может конечно и нет) вывести ваш продукт на качественно новый уровень, в то время как рефакторинг такого качественного скачка (конечно если уж изначально было не все так плохо) не даст.
Это риск, но риск зачастую оправдан. Что то сродни стартапу, но уже на базе приобретенного опыта и знаний в этой области.
Пример: есть куча продуктов в некой сфере, пользователь привык делать какие то действия чтобы добиться какого то результата. Все продукты позволяют сделать эти действия. Какие то быстрее, какие то медленнее, какие то красивее, какие то удобнее, где то кросплатформенно и прочее прочее. Пользователь в целом удовлетворен. Но конкретно ему надо получить вполне конкретный результат на вполне конкретном наборе железа и достаточно ограниченном поле выбора.
Абстрагировавшись от софта — ему дует из дверного проема и он хочет закрыть его от ветра. Например ковром. Ок. Одни ему предлагают набор ниток и иголок чтобы он соткал его сам, многие предлагают уже готовые ковры различных расценок, расцветок да чего угодно. Он ими пользуются и да они действительно закрывают проем си из него не дует, в принципе любой может зайти, но мы люди гостеприимные, и он изнашивается но в принципе сойдет.
Ваш Софт (то бишь фабрика ковров) такая вся универсальная, вяжет разные расцветки, ковры. И вот вы ее улучшаете. По разному раставляете станки (рефакторите), оптимизируете логистику поставок ниток, увольняете нерадивых швей, воспитываете корпоративную основу. Дабы сделать ковер прочнее проводите НИИР по иследованию кевларовых нитей. Но в целом вы как и все кто рядом.
А потом кто то решает переписать фабрику, изменить концепцию, по другому подойти к проблеме пользователя и построить завод деревянных дверей или «придумать» окна. Опаньки новые пользователи, новые характеристики, новые возможности, а все потому что когда то решили закрывать проем тканью вместо того чтобы придумать петли…
Дак стремиться всегда хорошо. Прочитать того же Фаулера — полезно. Плохо только когда начитавшись и думая что все поняли начинают городить куды не попадя.
А по аналогии со станком — вы в конце документации не замечали строк вида «производитель оставляет за собой возможность изменить конструкцию, если это не ухудшает потребительских характеристик, без уведомления и т.д.»
Да по документации все хорошо. Должен быть винт, а его нету. Ввернем винт. Ой совсем работать перестало :) Документацию ведь тоже люди пишут. Так что таки код это лучшая документация (правда только если отбросить закидоны компиляторов, ньюансы оптимизаторов, тонкости синтаксиса и особенности языка).
К сожалению это реальность, единственное что дамп это не совсем причина. Далеко не факт что «дамп» окажется кривым и непонятным, а «правильный код» логичным и очевидным.
На практике дамп сознания без коментов гораздо легче разобрать и понять, чем такой же объем стройной архитектуры без тех же коментов, особенно наблюдая только часть кода и не видя всю иерархию наследования и реализации методов. Все эти красивые архитектуры годны когда надо быстро получить общее понимание как это работает. А вот когда надо понять почему вдруг виртуальный метод Draw фигуры указывающей на окружность рисует квадрат… и прочие закидоны.
Неужели ни у кого не было случаев когда синглтон приходилось «разсинглтонивать»?
Или наследовать от класса в котором деструктор не виртуальный а по всему коду работают с указателями?
Или когда в стройном логичном интерфейсе треть методов лишние, треть устарела, а оставшиеся делают не совсем то что раньше подразумевалось и было отражено в названии?
Вы кстати давно разговаривали с бывшими студентами — кандидатами на должность программист? Которые пишут в CV «Уверенное владение С++»? Да половина из них не сможет правильно ответить зачем и когда нужен виртуальный деструктор. Большая часть не объяснит зачем в прототипе копирующего конструктора модификатор const перед ссылкой. Чем чреват сингл тон. Хорошо если понимает чем постфиксный инкремент от префиксного отличается. Кого брать на баг фикс то?
Так что зачастую плоский топорный код оказывается предпочтительней. Особенно в случае когда у заказчика код вдруг не работает и от скорости решения зависит не только материальное благополучие вашего проекта/компании.
Продукту лет десять, текущей инкарнации (основной части кода) около 4х лет. Количество этой части далеко за миллион строк. Надежность 365/7/24. Поддержка/разработка полсотни человек.
Предыдущий «проект» слишком громкий. Исходников несколько гиг, разработка по всему миру, надежность не такая высокая но огромная комеррческая стоимость. Разработка по CMM5 и CMMI.
Так что я знаю что такое «хороший код», и какой код оказывается в итоге в конечном продукте. Как его поддерживать, и как тестировать.
Конечно «коммерческий код», все эти новомодные TDD, SCRUM, XP. Это все хорошо просто замечательно, а многие мысли из них просто гениальны, но используется как правило лишь часть. Ибо окружающий мир, рынок и заказчик это такой random().
А вот в случае локального объявления (даже без инициализации) требуется выделить место на стеке и тут уже «бяда-бяда огорчение» ему что 2 раза там место выделять? вот и ругается.
Вон возьми хотя бы STL — чем глубже в лес тем толще дровосеки, иногда такие конструкции завернешь что мама дорогая объясните мне почему это работает :)
Приходит к вам заказчик и говорит — разработайте мне что то забивать гвозди. Вы трудитесь стараетесь придумываете молоток. Отдаете заказчику — а он в итоге недоволен — гвозди не удобно забиваются. Вы ищете баги (действительно зачем ручка квадратная — сделаем эргономичную) фиксите, новая супер пупер версия — заказчик все равно недоволен.
А потом вы идете и выясняете а зачем емиу молоток — гвозди забивать, а зачем их забивать — картины на стену вешать, стоп а стены какие — гипсокартонные и у вас молоток плохой — из гипсокартона забитые им гвозди вываливаются. И Ваш архитектор придумывает шуруп и отвертку и ему выдвигают премию. Ура все довольны.
Чтото последнее время не до блогов было. Про StackOverflow конечно же слышал. Но факт остается фактом — критикуя ОДНО ИЗ решений Microsoft человек находится уровнем ниже. А про то что это решение помогло возможно избежать проблем в других сферах? Отрицательный результат это тоже результат и иногда не менее полезный.
Творчество это попытка найти решение не то которое на поверхности, а другое, не очевидное. То про которое не написал еще Кнут. Многие пытаются, мало кто находит, но те кто находят становятся Гейтсами, Фаулерами, Кнуттами.
Ну нет в программировании места роботам. Сгенерить из UML код можно, только он так себе получиться.
А все эти «доказательства 90х» годов и ведут к тому что банальному текстовому notepad 00-х годов ресурсов надо как хорошей такой игрухе 90-х.
А применили бы творческий подход, глядишь результаты станут другими
И мысли не допустят что заказчик скажет: «да я написал это ТЗ, но вы что сами не видите что это не удобно. И вообще ваш продукт гавно, а вот у конкурентов видите какая конфетка. Все больше я с вами не работаю и вместо новой версии у вас куплю продукт конкурента».
Компанию Microsoft и Netscape упомянутые в статье я знаю много слышал и использовал, как и про их продукты. А вот про Joel Spolsky, его компанию Fog Creek Software и продукты этой компании я услышал впервые. Так что позвольте с изрядной долей скептицизма отнестись к его советам и коментариям. Переписывание с нуля МОЖЕТ позволить (а может конечно и нет) вывести ваш продукт на качественно новый уровень, в то время как рефакторинг такого качественного скачка (конечно если уж изначально было не все так плохо) не даст.
Это риск, но риск зачастую оправдан. Что то сродни стартапу, но уже на базе приобретенного опыта и знаний в этой области.
Пример: есть куча продуктов в некой сфере, пользователь привык делать какие то действия чтобы добиться какого то результата. Все продукты позволяют сделать эти действия. Какие то быстрее, какие то медленнее, какие то красивее, какие то удобнее, где то кросплатформенно и прочее прочее. Пользователь в целом удовлетворен. Но конкретно ему надо получить вполне конкретный результат на вполне конкретном наборе железа и достаточно ограниченном поле выбора.
Абстрагировавшись от софта — ему дует из дверного проема и он хочет закрыть его от ветра. Например ковром. Ок. Одни ему предлагают набор ниток и иголок чтобы он соткал его сам, многие предлагают уже готовые ковры различных расценок, расцветок да чего угодно. Он ими пользуются и да они действительно закрывают проем си из него не дует, в принципе любой может зайти, но мы люди гостеприимные, и он изнашивается но в принципе сойдет.
Ваш Софт (то бишь фабрика ковров) такая вся универсальная, вяжет разные расцветки, ковры. И вот вы ее улучшаете. По разному раставляете станки (рефакторите), оптимизируете логистику поставок ниток, увольняете нерадивых швей, воспитываете корпоративную основу. Дабы сделать ковер прочнее проводите НИИР по иследованию кевларовых нитей. Но в целом вы как и все кто рядом.
А потом кто то решает переписать фабрику, изменить концепцию, по другому подойти к проблеме пользователя и построить завод деревянных дверей или «придумать» окна. Опаньки новые пользователи, новые характеристики, новые возможности, а все потому что когда то решили закрывать проем тканью вместо того чтобы придумать петли…
А по аналогии со станком — вы в конце документации не замечали строк вида «производитель оставляет за собой возможность изменить конструкцию, если это не ухудшает потребительских характеристик, без уведомления и т.д.»
Да по документации все хорошо. Должен быть винт, а его нету. Ввернем винт. Ой совсем работать перестало :) Документацию ведь тоже люди пишут. Так что таки код это лучшая документация (правда только если отбросить закидоны компиляторов, ньюансы оптимизаторов, тонкости синтаксиса и особенности языка).
На практике дамп сознания без коментов гораздо легче разобрать и понять, чем такой же объем стройной архитектуры без тех же коментов, особенно наблюдая только часть кода и не видя всю иерархию наследования и реализации методов. Все эти красивые архитектуры годны когда надо быстро получить общее понимание как это работает. А вот когда надо понять почему вдруг виртуальный метод Draw фигуры указывающей на окружность рисует квадрат… и прочие закидоны.
Неужели ни у кого не было случаев когда синглтон приходилось «разсинглтонивать»?
Или наследовать от класса в котором деструктор не виртуальный а по всему коду работают с указателями?
Или когда в стройном логичном интерфейсе треть методов лишние, треть устарела, а оставшиеся делают не совсем то что раньше подразумевалось и было отражено в названии?
Вы кстати давно разговаривали с бывшими студентами — кандидатами на должность программист? Которые пишут в CV «Уверенное владение С++»? Да половина из них не сможет правильно ответить зачем и когда нужен виртуальный деструктор. Большая часть не объяснит зачем в прототипе копирующего конструктора модификатор const перед ссылкой. Чем чреват сингл тон. Хорошо если понимает чем постфиксный инкремент от префиксного отличается. Кого брать на баг фикс то?
Так что зачастую плоский топорный код оказывается предпочтительней. Особенно в случае когда у заказчика код вдруг не работает и от скорости решения зависит не только материальное благополучие вашего проекта/компании.
Продукту лет десять, текущей инкарнации (основной части кода) около 4х лет. Количество этой части далеко за миллион строк. Надежность 365/7/24. Поддержка/разработка полсотни человек.
Предыдущий «проект» слишком громкий. Исходников несколько гиг, разработка по всему миру, надежность не такая высокая но огромная комеррческая стоимость. Разработка по CMM5 и CMMI.
Так что я знаю что такое «хороший код», и какой код оказывается в итоге в конечном продукте. Как его поддерживать, и как тестировать.
Конечно «коммерческий код», все эти новомодные TDD, SCRUM, XP. Это все хорошо просто замечательно, а многие мысли из них просто гениальны, но используется как правило лишь часть. Ибо окружающий мир, рынок и заказчик это такой random().