Ну смех смехом, а когда надо много данных (десятки Тб и более) залить в облако, вы можете, как минимум, нехило за трафик заплатить. Многие провайдеры предоставляют услугу импорта-экспорта похожим способом. Например, Azure Databox.
Мне кажется, надо каждую монету поделить пополам (одна половина в одну кучу, вторая в другую). Если нельзя делить монеты — то недостаточно информации (ну или только мы не различаем их, а кто-то различает — тогда можно ему поручить).
Есть спорные ситуации, где имеют место быть разные мнения и предпочтения, например те же маркер-интерфейсы — кто-то их любит, я считаю их исторической издержкой в случае языка с поддержкой аннотаций или «аттрибутов» в терминологии .NET. Есть правда у них некоторые технические ограничения связанные с наследованием, но суть не в этом.
А есть объективно неверные решения. Примеры, которые я часто встречаю в своём проекте:
код выполняется много раз повторно без причины
метод Initialize написан с кучей всяких ненужных проверок как будто инициализацию собираются делать много раз, но это не так
полный хаос с модификаторами доступа, одни паблики кругом. И всё это вынесено в интерфейс
Есть много других примеров.
Я всегда стараюсь допускать альтернативные точки зрения в области разработки, но эта точка зрения должна быть обоснована. Если аргументы за отсутствуют (недостаточно продебагили, копи-пасты кода или просто непонимание элементарных принципов ООП), то это недостаток и надо на них указывать. Моей мотивацией это делать не является показать своё превосходство над остальными или как-то их унизить. Всё намного проще. :) Мне потом работать с этим всем и возможно придётся долго поддерживать code-base. Поэтому я стараюсь заранее облегчить себе жизнь, ну а кому-то может будет и опыт.
По поводу перфекционизма: • Вера в то, что главное в коде — красота, читаемость и поддерживаемость
Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности), т.к. если мы говорил о долгосрочных Agile-проектах, где классы не пишутся один раз и навсегда, кол-во затраченных часов на определённую модификацию (а значит и затраченные деньги) зависят как раз от этого. • Поиск недостатков в любом коде
Я обычно делюсь всеми найденными недостатками с коллегами. Это уроки, которые должны делать каждый следующий кусок кода лучше. Разумеется, мы не говорим о крайности, когда человек только ищет недостатки вместо выполнения своей работы. • Вера в то, что возможно написать идеальный код за разумное время
Неидеальный, но близкий к идеальному код можно написать за разумное время. Тут важен систематический подход. У многих код получается некачественным из-за того, что вместо того, чтоб начать с высокоуровневого дизайна, они начинают клепать прототипчики с костылями, допиливают его до работоспобного состояния и далее, устав, оставляют свою поделку на века долгие.
Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода, а не круглосуточному изучению каждого коммита в code-base.
По поводу оптимизации: разумеется побитовый сдвиг и вставки ассемблера — это оверкилл. Но пример со сложностью алгоритма O(n) vs O(n^2) неудачный, если мы говорил об обработки большого кол-ва данных. Я бы сказал, что допущение субоптимального алгоритма возможно только если оптимальный алгоритм либо гипер-сложен, либо нечитаемый (при условии, что общее время его выполнения остаётся приемлимым). Я не согласен с тем, что только академикам это надо :)
Я думаю, что будут люди, способные оценить эти способности человека. Ведь как-то обстоят дела с другими профессиями? Не думаю, что профессия программиста чем-то особенна (в плане проверки компетентности)
«Одно дело относительно здоровая конкуренция между двумя производителями железа, и совсем другое — конкуренция между одним производителем одной платформы и кучей производителей другой.»
Первая ситуация как раз не является здоровой конкуренцией (см. определение «Олигополии»), а вторая — является. Из ваших слов — рыночная конкуренция = плохо :D
Кстати, есть поддержка флеш через сторонние приложения, iSwifter, например.
А вот, любители флеш, объясните зачем он нужен на планшете? Видеосервисы уже давно поддерживают HTML5. Только для игр, в которые неудобно будет играть планшете?
Также, шлеш — штука тормозная достаточно. Новые девайсы Apple конечно потянут его на ура, но Стив ведь не хочет чтоб его старые устройства тормозили с новой ОС.
Ну смех смехом, а когда надо много данных (десятки Тб и более) залить в облако, вы можете, как минимум, нехило за трафик заплатить. Многие провайдеры предоставляют услугу импорта-экспорта похожим способом. Например, Azure Databox.
Есть спорные ситуации, где имеют место быть разные мнения и предпочтения, например те же маркер-интерфейсы — кто-то их любит, я считаю их исторической издержкой в случае языка с поддержкой аннотаций или «аттрибутов» в терминологии .NET. Есть правда у них некоторые технические ограничения связанные с наследованием, но суть не в этом.
А есть объективно неверные решения. Примеры, которые я часто встречаю в своём проекте:
код выполняется много раз повторно без причины
метод Initialize написан с кучей всяких ненужных проверок как будто инициализацию собираются делать много раз, но это не так
полный хаос с модификаторами доступа, одни паблики кругом. И всё это вынесено в интерфейс
Есть много других примеров.
Я всегда стараюсь допускать альтернативные точки зрения в области разработки, но эта точка зрения должна быть обоснована. Если аргументы за отсутствуют (недостаточно продебагили, копи-пасты кода или просто непонимание элементарных принципов ООП), то это недостаток и надо на них указывать. Моей мотивацией это делать не является показать своё превосходство над остальными или как-то их унизить. Всё намного проще. :) Мне потом работать с этим всем и возможно придётся долго поддерживать code-base. Поэтому я стараюсь заранее облегчить себе жизнь, ну а кому-то может будет и опыт.
• Вера в то, что главное в коде — красота, читаемость и поддерживаемость
Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности), т.к. если мы говорил о долгосрочных Agile-проектах, где классы не пишутся один раз и навсегда, кол-во затраченных часов на определённую модификацию (а значит и затраченные деньги) зависят как раз от этого.
• Поиск недостатков в любом коде
Я обычно делюсь всеми найденными недостатками с коллегами. Это уроки, которые должны делать каждый следующий кусок кода лучше. Разумеется, мы не говорим о крайности, когда человек только ищет недостатки вместо выполнения своей работы.
• Вера в то, что возможно написать идеальный код за разумное время
Неидеальный, но близкий к идеальному код можно написать за разумное время. Тут важен систематический подход. У многих код получается некачественным из-за того, что вместо того, чтоб начать с высокоуровневого дизайна, они начинают клепать прототипчики с костылями, допиливают его до работоспобного состояния и далее, устав, оставляют свою поделку на века долгие.
Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода, а не круглосуточному изучению каждого коммита в code-base.
Смертокрыл ^_______^
Спасибо!!! :)
Первая ситуация как раз не является здоровой конкуренцией (см. определение «Олигополии»), а вторая — является. Из ваших слов — рыночная конкуренция = плохо :D
А вот, любители флеш, объясните зачем он нужен на планшете? Видеосервисы уже давно поддерживают HTML5. Только для игр, в которые неудобно будет играть планшете?
Также, шлеш — штука тормозная достаточно. Новые девайсы Apple конечно потянут его на ура, но Стив ведь не хочет чтоб его старые устройства тормозили с новой ОС.
Правда, конечно для Samsung это всё равно убытки