Я вообще всё делаю. Сейчас соц игры на работе, ранее процессор бинарных данных с хитрыми алгоритмами делал, потом систему управления многопроекторным интерактивным кино, сейчас вот ещё играюсь с биржевым ботом, тоже на флеше.
Можно. И можно сделать бюрократию на доступ к боевым серверам. Можно слить конфиг на тестовый и работать на нём. Меньше риска меньше скорость. Это выбор который мы делаем. Есть бекапы и репликация. Это выбор в, в данном случае, того кто фиксит. На его усмотрение. И чем меньше стоит между ним и сервером тем лучше, а он уж в праве выбирать путь. Опять же это работает только в случае высоко профессионального и мотивированного персонала.
а вот это зло.
Простейший пример, недавно(в начале весны) в воскресенье америка время двигала, а в РФ время уже не переводится. У нас и попадали сервера с фейсбуком связанные. Это было толи ночь толи утро нерабочего дня. Узнали об этом программисты благодаря экстренному смс уведомлению о проблемах на серверах. И фиксили прямо на продакшене. И пофиксили. Менеджмент и тестеры и вообще все остальные узнали о результатах в понедельник. Да это форс мажор, да это не часто происходит. Но, блин, на достаточно больших проектах разнесённых по многим странам такое бывает. И когда сервис лежит, хуже уже не сделаешь. И в этот момент нет никаких правил. Мотивированные люди сами знают что они могут делать всё для решения проблемы и решают её. Поэтому никогда не говори никогда. Я к тому что используя наборы правил, а этот набор достаточно хорош, надо знать и границы их применения и в определённые моменты отбросить и погрузиться в ничем не ограниченный цифровой драйв, который позволит в кратчайшие сроки делать то что обычно кажется невозможным.
Да пишите, кто же против то. Вам же код поддерживать. Я говорил о случае когда мы по некому условию разбиваем всё доступное пространство входных данный на некоторые большие области и их специфично обрабатываем. Классической ошибкой в таких штуках является потерять границы. И часто при дебаге и чтении кода на таких местах заостряется внимание. Тут просто сразу дана подсказка что это не ошибочно забыто а сознательно не обработано. Мне это помогает. И, если вы не заметили, не рекомендую всегда так писать. Но в некоторых местах такая штука бывает полезна. Мы код пишем чтоб писать его и поддерживать.
Да, и не так уж это и сложно. Я пришёл к выводу что бритва Оккама работает очень хорошо. Делать надо минимум. Если вы точно знаете что такая более сложная чем регехп обработка будет, то можно сразу функцию заводить. В противном случае нет. Не так уж и долго найти все ссылки на константу и во всех местах на функцию заменить, совсем не сложно. Зато не будет ненужных уровней абстракции. За последние пару лет разработки я понял что всего на перёд всё равно не предусмотришь, а в 10-15 местах заменить одно на другое не проблема, особенно когда ide рефакторинг хорошо поддерживает.
//Тут надо вроде ещё проверку сделать, но этот случай маловероятен, PM сказал забить.
Вот такой зло как раз. У нас, слава всем богам, есть время разработчиков когда они выполняют поддержание кода и инструментов в порядке, и не отчитываются за это время ни перед кем. В такое время это и делается. А мой вариант показывает что не забыли это обработать. Он не маловероятен, он вполне вероятен, только действие не требуется. И не сразу это очевидно. Когда придумывал, думал что понадобится действие. Написал последний елс. Потом попробовал внести в один из ифов также равенство, тоже не круто. Вот и выделил отдельно. И всегда понятно будет почему так, и при чтении руки ни у кого не зачешутся поправить.
Что могу сказать. Расставляем ордера на покупку, а имеющиеся биткоины выводим с биржи. Пока они на аккаунте биржи они не ваши. Вывелся я недельку назад, а ордера расставил только что. Думаю что биткоинова экономика сильно просядет но устоит. Тут и тренд на падение хороший пошёл с 30го мая.
Подождите, вы пишите код, которым описываете, как вы это сделали
не понял мысли.
Я пишу коммент если можно допустить небольшую некрасивость, но с одним комментом понятную, нежели городить новый уровень абстракции.
Блин, тег code херню какую то делает. source надо использовать
if (equation > 0) {
doSmth();
} else if (equation < 0) {
doSmthElse();
} else {
// комментарий о том что случай с равенством нулю не забыт,
// обработка не требуется.
}
Ну тут можно функцию то не городить. А сохранить сам регехп в переменную с именем checkMailRegExp и уже его проверить. А вообще регехп бы статической константой вынести глобально. Чтоб в проекте не было 10 разных валидаций. Я больше люблю разруливать такие вещи говорящими переменными нежели функциями. Если нужна будет какая то более сложная обработка то уже функция отдельная, опять же лучше в каком то паке утилов завести что консистентность проверок поддержать.
А во, ещё практика. Иногда я в коде закладки делаю своеобразные, // guid
И в отдельном файле что помечено какими гуидами. Удобно задумать например какой то рефакторинг, держать его в голове пару недель и расставлять в коде такие метки с местами которым стоит уделить внимание. Потом банальным поиском по проекту элементарно находится. Гуит у меня в ide одним хоткеем ставится.
Пришёл к выводу что это лучше чем всякие системы закладок на код. Потому что команда у нас работает с разными ide + элементарн работать с такими метками даже в блокноте, никогда не рассинхронизируются. В общем счастье одно.
Вообще придерживаюсь принципа: комментируй как это сделано, а не что с.делано.
Ещё недавно видел вот такую штуку и мне прям понравилось: if (equation > 0) {
doSmth();
} else if (equation < 0) {
doSmthElse();
} else {
// комментарий о том что случай с равенством нулю не забыт,
// обработка не требуется.
}
Сразу понятно что и как.
//fallthrough всегда пишу когда применяю.
Иногда вместо обновления приватной переменной изнутри класса дёргаю внешний сеттер, тогда тоже пишу коммент что сеттер дёрнут намеренно. Или геттер с ленивой инициализацией. Этидва случая конечно попахивают, но иногда для простоты и балланса между горой ненужного кода и простотой применяю.
Т.е. если код может быть прочтён двояко, и может быть заподозрена ошибка то пишем коммент.
А вообще с постом согласен, тупы хоменнтариев дублирующих написанное быть не должно.
а вот это зло.
Простейший пример, недавно(в начале весны) в воскресенье америка время двигала, а в РФ время уже не переводится. У нас и попадали сервера с фейсбуком связанные. Это было толи ночь толи утро нерабочего дня. Узнали об этом программисты благодаря экстренному смс уведомлению о проблемах на серверах. И фиксили прямо на продакшене. И пофиксили. Менеджмент и тестеры и вообще все остальные узнали о результатах в понедельник. Да это форс мажор, да это не часто происходит. Но, блин, на достаточно больших проектах разнесённых по многим странам такое бывает. И когда сервис лежит, хуже уже не сделаешь. И в этот момент нет никаких правил. Мотивированные люди сами знают что они могут делать всё для решения проблемы и решают её. Поэтому никогда не говори никогда. Я к тому что используя наборы правил, а этот набор достаточно хорош, надо знать и границы их применения и в определённые моменты отбросить и погрузиться в ничем не ограниченный цифровой драйв, который позволит в кратчайшие сроки делать то что обычно кажется невозможным.
чего и ждём для успешной закупки
Вот такой зло как раз. У нас, слава всем богам, есть время разработчиков когда они выполняют поддержание кода и инструментов в порядке, и не отчитываются за это время ни перед кем. В такое время это и делается. А мой вариант показывает что не забыли это обработать. Он не маловероятен, он вполне вероятен, только действие не требуется. И не сразу это очевидно. Когда придумывал, думал что понадобится действие. Написал последний елс. Потом попробовал внести в один из ифов также равенство, тоже не круто. Вот и выделил отдельно. И всегда понятно будет почему так, и при чтении руки ни у кого не зачешутся поправить.
не понял мысли.
Я пишу коммент если можно допустить небольшую некрасивость, но с одним комментом понятную, нежели городить новый уровень абстракции.
Блин, тег code херню какую то делает. source надо использовать
И в отдельном файле что помечено какими гуидами. Удобно задумать например какой то рефакторинг, держать его в голове пару недель и расставлять в коде такие метки с местами которым стоит уделить внимание. Потом банальным поиском по проекту элементарно находится. Гуит у меня в ide одним хоткеем ставится.
Пришёл к выводу что это лучше чем всякие системы закладок на код. Потому что команда у нас работает с разными ide + элементарн работать с такими метками даже в блокноте, никогда не рассинхронизируются. В общем счастье одно.
Ещё недавно видел вот такую штуку и мне прям понравилось:
if (equation > 0) { doSmth(); } else if (equation < 0) { doSmthElse(); } else { // комментарий о том что случай с равенством нулю не забыт, // обработка не требуется. }Сразу понятно что и как.
//fallthroughвсегда пишу когда применяю.Иногда вместо обновления приватной переменной изнутри класса дёргаю внешний сеттер, тогда тоже пишу коммент что сеттер дёрнут намеренно. Или геттер с ленивой инициализацией. Этидва случая конечно попахивают, но иногда для простоты и балланса между горой ненужного кода и простотой применяю.
Т.е. если код может быть прочтён двояко, и может быть заподозрена ошибка то пишем коммент.
А вообще с постом согласен, тупы хоменнтариев дублирующих написанное быть не должно.