Программист.
Вы ещё не поняли? Или политесом занимаетесь? Это никогда не будет доведено до конца. Подход с вероятностями как ковровая бомбардировка - хоть одна мышь, да проскочит. Абсолютно неверно пускать кошку туда, где только на данный момент вероятность толще (я про 2-2-4-4). Изложенными там выкладками можно лишь математически подтвердить правильное решение.
Но можно привести программное решение, которое переберёт комбинации примерно на 10 шагов вперёд и выведет ходы кошки с вероятностью мышки в зубах 1. Это было бы реабилитацией
ps не, а вот если бы я на последнем комиксе клетки не квадратными, а прямоугольными отформатировал, то ассоциация с шахматами случилась бы?
Но можно привести программное решение, которое переберёт комбинации примерно на 10 шагов вперёд и выведет ходы кошки с вероятностью мышки в зубах 1. Это было бы реабилитацией
ps не, а вот если бы я на последнем комиксе клетки не квадратными, а прямоугольными отформатировал, то ассоциация с шахматами случилась бы?
НПП
Спорщики, а не пора ли вам в Курилку тематического подфорума?
Спорщики, а не пора ли вам в Курилку тематического подфорума?
Именно так я и думал, когда читал спойлер.
То есть, если речь идет о той же вероятности в "1", что и вероятность появления орла при подкидываниях монеты (_бесконечном_ числе подкидываний), то это не решение задачи Толстопуза.
Но мало ли, вдруг у Mad_Dollar'а было решение с конечным числом ходов...
Всегда есть шанс, что ты чего-то не понимаешь
Ну а та фраза, которую Вы цитируете - это просто возможность Mad_Dollar'у благополучно спрыгнуть с темы (зачем зажимать человека в угол, правильно?). Если это называется "политесом" - то да, этим я и занимаюсь.
P.S. Ассоциация с шахматами случилась у меня, когда сам решал эту задачу (то есть несколько до появления комиксов).
То есть, если речь идет о той же вероятности в "1", что и вероятность появления орла при подкидываниях монеты (_бесконечном_ числе подкидываний), то это не решение задачи Толстопуза.
Но мало ли, вдруг у Mad_Dollar'а было решение с конечным числом ходов...
Всегда есть шанс, что ты чего-то не понимаешь
Ну а та фраза, которую Вы цитируете - это просто возможность Mad_Dollar'у благополучно спрыгнуть с темы (зачем зажимать человека в угол, правильно?). Если это называется "политесом" - то да, этим я и занимаюсь.
P.S. Ассоциация с шахматами случилась у меня, когда сам решал эту задачу (то есть несколько до появления комиксов).
Над достаточно эффективным решением я размышляю уже лет 6 ...
> Пасибки, что уделили внимание. Посмотрел код. Если не учитывать общую многословность, то оно "практически" тоже самое, но чуть дольше. А упростить?
далеко не то же самое
Вариант с пхп нихрена нечитаемый - названия переменных, форматирование, однострочничество ... читать такой код все равно что разбираться в душевной травме сбивчиво говорящего человека с дефектами речи
Вариант от Велла - читается и понимается с листа. Упрощать там нечего, сокращать тем более, наоборот считаю не хватает { }, но в этом случае мелочи ...
Или место на диске под сорс код экономится? Или склонность к однострочничеству со времен перфокарт сохранилась?
далеко не то же самое
Вариант с пхп нихрена нечитаемый - названия переменных, форматирование, однострочничество ... читать такой код все равно что разбираться в душевной травме сбивчиво говорящего человека с дефектами речи
Вариант от Велла - читается и понимается с листа. Упрощать там нечего, сокращать тем более, наоборот считаю не хватает { }, но в этом случае мелочи ...
Или место на диске под сорс код экономится? Или склонность к однострочничеству со времен перфокарт сохранилась?
Читайте дальше. Уже разобрались что далеко не одно и тоже.
> Читайте дальше. Уже разобрались что далеко не одно и тоже.
Я и дальше прочитал, немного ...
Очень смешно, особенно когда проверку на граничные условия покритиковали за нагрузку на процессор. Речь идет о рил тайм приложении? Эй, тогда вы реально облажались выбрав php в качестве инструмента! Нет? тогда забудьте про это лишний процессорный такт! Не надо заниматься охотой на ведьм, наукой давно доказано что их нет. И после этих замечаний, высказанных даже как будто всъерьез, кто-то там еще рассуждает о сферических конях в вакууме?! 
Проверка на граничные условия и оптимизация перформанса это две абсолютно не связанные с собой вещи. К тому же помимо самой проверки, эта строка кода просто объясняет какие входные данные не могут быть, и это между прочим важно.
Код должен быть читаемым и понятным, это должно быть очевидно человеку имеющему дело с поддержкой и развитием приложения, тем более большого приложения. За названия переменных типа r_x, r_y надо саечки ставить за однострочничество тоже.
В общем то и все, а обсуждать саму логику метода смысла не вижу, там вобще с профессиональной точки зрения обсуждать нечего, ну да целочисленные вычисления быстрее плавающих, но во-первых это детский сад критиковать по этому поводу модельный пример, во-вторых это вряд ли имеет большое значение, а в третьих это особо не касается того стало лучше или хуже.
Я и дальше прочитал, немного ...
Очень смешно, особенно когда проверку на граничные условия покритиковали за нагрузку на процессор. Речь идет о рил тайм приложении? Эй, тогда вы реально облажались выбрав php в качестве инструмента!
Нет? тогда забудьте про это лишний процессорный такт! Не надо заниматься охотой на ведьм, наукой давно доказано что их нет. И после этих замечаний, высказанных даже как будто всъерьез, кто-то там еще рассуждает о сферических конях в вакууме?! Проверка на граничные условия и оптимизация перформанса это две абсолютно не связанные с собой вещи. К тому же помимо самой проверки, эта строка кода просто объясняет какие входные данные не могут быть, и это между прочим важно.Код должен быть читаемым и понятным, это должно быть очевидно человеку имеющему дело с поддержкой и развитием приложения, тем более большого приложения. За названия переменных типа r_x, r_y надо саечки ставить
за однострочничество тоже.В общем то и все, а обсуждать саму логику метода смысла не вижу, там вобще с профессиональной точки зрения обсуждать нечего, ну да целочисленные вычисления быстрее плавающих, но во-первых это детский сад критиковать по этому поводу модельный пример, во-вторых это вряд ли имеет большое значение, а в третьих это особо не касается того стало лучше или хуже.
Спасибо, что считаете меня перспективным спецом, надеюсь у меня еще действительно есть куда расти, несмотря на 10+ лет стажа преимущественно тем самым пресловутым enterprise программистом
И за приглашение спасибо, но пока мне интересно на моем текущем месте во всех смыслах
Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК, он возможно из тех кто умеет подковывать блоху, но на этом навыке нормальный производственный процесс наладить неполучится, поэтому идет на ощупь, набивает шишки, что в общем наверное естественно. Плохо что не пытается понять приводимые ему резоны и пытается стоять на своем, такая негибкость только вредна. Ну и вообще если у него весь codebase ГК, то сделать из него конфетку быстро не реально, сначала гк, потом уже потихоньку, болезненно придется вытягивать это болото, и то при соблюдении технологических правил.
Вобщем ТС удачи и хороших сотрудников!
И за приглашение спасибо, но пока мне интересно на моем текущем месте во всех смыслах
Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК, он возможно из тех кто умеет подковывать блоху, но на этом навыке нормальный производственный процесс наладить неполучится, поэтому идет на ощупь, набивает шишки, что в общем наверное естественно. Плохо что не пытается понять приводимые ему резоны и пытается стоять на своем, такая негибкость только вредна. Ну и вообще если у него весь codebase ГК, то сделать из него конфетку быстро не реально, сначала гк, потом уже потихоньку, болезненно придется вытягивать это болото, и то при соблюдении технологических правил.
Вобщем ТС удачи и хороших сотрудников!
Я Вас приглашал? ))) Не может быть. Просто в части формулировок вы даже меня переплюнули, а это, поверьте,, не 10 лет "энтерпраз" программировать
Мне кажется, или сакральный смымл всего противостояния будет открыт? =)
Да, в организациях, кторые озабочены получением прибыли от качественно отрелизенного продукта, большую неделимую ставку ставят не на "гениев", а на тех, кто стандартно качстсвенно и без изысков пишет в рамках воркфлоу, предсказуемо, с запланированными багами (да, по времени и количеству! чудо!), с запланированной скоростью (божемой, как это возможжно!) и много чего еще имеет в плюс. И да - с запланированным кодестайлом, запланированными инпрувментами, реальными эстимацииями и кучей разно чисто рабочей фигни, включая +- оценку расходов бизнеса на "этот проект" на следующие пару лет...
Чудо прям, не знаю как описать.
Мне кажется, или сакральный смымл всего противостояния будет открыт? =)
Да, в организациях, кторые озабочены получением прибыли от качественно отрелизенного продукта, большую неделимую ставку ставят не на "гениев", а на тех, кто стандартно качстсвенно и без изысков пишет в рамках воркфлоу, предсказуемо, с запланированными багами (да, по времени и количеству! чудо!), с запланированной скоростью (божемой, как это возможжно!) и много чего еще имеет в плюс. И да - с запланированным кодестайлом, запланированными инпрувментами, реальными эстимацииями и кучей разно чисто рабочей фигни, включая +- оценку расходов бизнеса на "этот проект" на следующие пару лет...
Чудо прям, не знаю как описать.
Спасибо, что считаете меня перспективным спецом, надеюсь у меня еще действительно есть куда расти, несмотря на 10+ лет стажа преимущественно тем самым пресловутым enterprise программистомГлавное, чтобы высказывающийся сам верил в то, что говорит/пишет. А то, бывает, порисуется на нгс, а потом утыкается в переполненную багзиллу своего чудо-как-идеального проекта. Повторюсь, но жизнь показывает, что те, кто часто произносит/пишет фразу "ГК", часто очень близко находятся с озвученной субстанцией
Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК, он возможно из тех кто умеет подковывать блоху, но
Особо доставляет удовольствие, когда "настоящие специалисты" о стаже говорят. Это первый звоночек... Если при этом дуют щёки, то вообще отпад
Чудо прям, не знаю как описать.Да говорили уже о конвейере. Действительно, всё достаточно буднично без элемента экзистенции, как в анекдоте про скучающую на отдыхе проститутку "а вокруг станки, станки..."
Тема-то о том, что получает ТС такого отработанного станочника (скорее всего не самого лучшего) и удивляется переменам в окружающем мире... Напоминает старинное кино с Ч.Чаплиным, когда мужик после рабочего дня выходит с конвейера Форда забавным дурачком.
Кому-то грустно, а кто-то гордится своим образом жизни.
"кукушка хвалит петуха за то, что хвалит он кукушку". (с) А. Крылов.
Вы так здорово расплевались по тому коду "как стало", и так скромно умолчали о той части "как было"... "как было" - сами писали, не? Или "там всё нормально" всегда так пишу...
Вы так здорово расплевались по тому коду "как стало", и так скромно умолчали о той части "как было"... "как было" - сами писали, не? Или "там всё нормально" всегда так пишу...
А вот это я бы выделил жирным шрифтом. Потому что это и есть РЕАЛЬНАЯ адекватная оценка труда "энтерпрайз программистов со стажем", которые как раз и писали весь этот ГК. Причем, что характерно, оценка "ИЗНУТРИ" от коллеги...
Собственно это и есть основная причина создания топика...
Меня теперь волнует несколько другой вопрос:
Согласно закону об авторском праве, имена авторов этого ГК, обязаны к указанию где-нибудь на страницах портала... потому как авторское право должно быть соблюдено...
... однако, согласно закону о защите персональных данных... этого делать низзя...
Как быть? Вот мне почему-то кажется что страна должна знать своих героев...
Собственно это и есть основная причина создания топика...
Меня теперь волнует несколько другой вопрос:
Согласно закону об авторском праве, имена авторов этого ГК, обязаны к указанию где-нибудь на страницах портала... потому как авторское право должно быть соблюдено...
... однако, согласно закону о защите персональных данных... этого делать низзя...
Как быть? Вот мне почему-то кажется что страна должна знать своих героев...
А можно было ответить и по поводу проверки аргументов, которую если не ошибаюсь вы же и презрительно прокомментировали, я вполне конкретно и наглядно обозначил почему скепсис там неуместен. Но вы ответили так как ответили. Вот на сентенцию выше мне ответить собственно нечего 
> Вы так здорово расплевались по тому коду "как стало", и так скромно умолчали о той части "как было"... "как было" - сами писали, не? Или "там всё нормально" всегда так пишу...
Еще раз глянул, там тоже плохо, но немного по другому :))
Ну как было наверное хуже, но на таких маленьких примеров замерить что хуже сложно. Есть же "как надо", а есть "как не надо"
Еще раз глянул, там тоже плохо, но немного по другому :))
Ну как было наверное хуже, но на таких маленьких примеров замерить что хуже сложно. Есть же "как надо", а есть "как не надо"
Можно сколько угодно ругать труд коллег, злится и т.п.
а) это не конструктивно
б) это Вас не красит
в) на все есть причины. Если производственный процесс не налажен, то вина в этом не на программистах, а скорее на тех кто его так отстроил. Вы и сами теперь в той же упряжке энтерпрайз программирования, через некоторое время когда через энное количество бранчей, мержей и рефакторингов в коммит логах будет только Ваши логины, Вы и сами превратитесь в этого "героя"
а) это не конструктивно
б) это Вас не красит
в) на все есть причины. Если производственный процесс не налажен, то вина в этом не на программистах, а скорее на тех кто его так отстроил. Вы и сами теперь в той же упряжке энтерпрайз программирования, через некоторое время когда через энное количество бранчей, мержей и рефакторингов в коммит логах будет только Ваши логины, Вы и сами превратитесь в этого "героя"
> Тема-то о том, что получает ТС такого отработанного станочника (скорее всего не самого лучшего) и удивляется переменам в окружающем мире...
бубубу
раньше и трава была зеленее и деревья выше
бубубу
раньше и трава была зеленее и деревья выше
На предыдущее:
Во-от! В том то всё и дело, что РАЗОБРАТЬСЯ в том коде который был - Вам оказалось по-просту не под силу... зато делать замечания про "не феншуйный" пример - а то! в лёт... "энтерпрайз", аднака... за версту видно. А ведь это был, всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... чего Вам дочитать также не удалось... а вовсе не пример феншуйного оформления, как все красны девицы здесь подумали...
зато и конструктивно, и красит то как!
ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.
зато радостно кричать "нашел косяк" в том, что предлагалось для ДРУГИХ целей - ай, да молодцы! и красиво то как!
Во-от! В том то всё и дело, что РАЗОБРАТЬСЯ в том коде который был - Вам оказалось по-просту не под силу... зато делать замечания про "не феншуйный" пример - а то! в лёт... "энтерпрайз", аднака... за версту видно. А ведь это был, всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... чего Вам дочитать также не удалось... а вовсе не пример феншуйного оформления, как все красны девицы здесь подумали...
зато и конструктивно, и красит то как!
ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.
зато радостно кричать "нашел косяк" в том, что предлагалось для ДРУГИХ целей - ай, да молодцы! и красиво то как!
Ну зачем Вы всё раскрыли? Пускай таки люди "со стажем" пишут как хотят. У них же другая реальность. "Другой слой ПО" - это другой человек этажом выше, такой же пуп земли со стажем. Каждый модуль у них обязан быть бункером, потому что кого возьмут с улицы на работу в следующий раз - не известно. У них программы из проверки параметров друг у друга состоят. На задачу заказчика по остаточному принципу. Но ровно до момента пока не замаячит дедлайн, и за спиной в затылок не задышит возбуждённый пм
Здесь всё просто - эта задача такой боян, что все успели переср@ться по поводу решения еще задолго до нас.
Что-то новое мы вряд ли сможем придумать
Что-то новое мы вряд ли сможем придумать
Не расстраиваейтесь, нервные клетки не восстанавливаются
> всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... а вовсе не пример феншуйного оформления
Я повторятся не буду, оставайтесь при своей религии если хотите. Не вы один рефакторите код, это достаточно обычная операция и случается далеко не по одному разу на одно и то же место, поэтому делая не по "фэншую" Вы себе же или коллеге грабель кидаете, помимо всего прочего.
> ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.
Лично мне банально ничего не надо доказывать. А там уж понимайте как умеете
> всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... а вовсе не пример феншуйного оформления
Я повторятся не буду, оставайтесь при своей религии если хотите. Не вы один рефакторите код, это достаточно обычная операция и случается далеко не по одному разу на одно и то же место, поэтому делая не по "фэншую" Вы себе же или коллеге грабель кидаете, помимо всего прочего.
> ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.
Лично мне банально ничего не надо доказывать. А там уж понимайте как умеете
вербализовывать надо свои соображения, а не прикрываться умными фразами типа "уровнем понимания".
Расставлять проверки надо совершенно точно там, где в результате ошибочных входных данных возникнет исключительная ситуация, причина которой уже будет неочевидна / сложна для восстановления. Это минимум. А так надо чекать все, это нормально, две три строчки в начале метода только добавляют понимания, у вас больше аргументов или сильно замороченная проверка? Значит непорядок с дизайном скорее всего. Приватные методы чекать не надо. Вот и весь уровень понимания, на уровне правило, из которого бывают исключения конечно (каламбур, да)
Про транзакции посмотрите что такое декларативные транзакции в частности и аспекты вообще. Это интересно. Ручное управление транзакциями давно не актуально.
> а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя
Вы продаете Заказчику строчки? Афигеть!
И из контекста ваще непонятно было что процедура внутренняя, чем докажите?
Расставлять проверки надо совершенно точно там, где в результате ошибочных входных данных возникнет исключительная ситуация, причина которой уже будет неочевидна / сложна для восстановления. Это минимум. А так надо чекать все, это нормально, две три строчки в начале метода только добавляют понимания, у вас больше аргументов или сильно замороченная проверка? Значит непорядок с дизайном скорее всего. Приватные методы чекать не надо. Вот и весь уровень понимания, на уровне правило, из которого бывают исключения конечно (каламбур, да)
Про транзакции посмотрите что такое декларативные транзакции в частности и аспекты вообще. Это интересно. Ручное управление транзакциями давно не актуально.
> а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя
Вы продаете Заказчику строчки? Афигеть!
И из контекста ваще непонятно было что процедура внутренняя, чем докажите?
А подскажите мне какое-нибудь средство в дот нете чтобы выкинуть свой эксепшен на ошибку валидации, а?
Ну посмотрел, java.awt.image.BufferedImage, чем-то перекликается со случаем ТС, нормально все там с валидацией. И чо?
Ну а волокут то наверное не энтерпрайз программисты, а чудо человеки великаны.
Короче давайте поконструктивней, можно с наездами, но по делу, мы же профессионалы, да?
Ну посмотрел, java.awt.image.BufferedImage, чем-то перекликается со случаем ТС, нормально все там с валидацией. И чо?
Ну а волокут то наверное не энтерпрайз программисты, а чудо человеки великаны.
Короче давайте поконструктивней, можно с наездами, но по делу, мы же профессионалы, да?
А чего тогда было так бурно в тему влезать? Ни понял... покрасоваться чтоли?
Моя "религия" достаточно проста: код должен писаться ровно тот, который нужен. Писаться грамотно. "Грамотно" - это:
а) лаконично. исполняемая часть кода должна быть оптимизирована "максимально возможно". То есть как можно меньше жрать процессорное время на избыточности кодирования. "Лишние вычисления" - это всегда впустую потраченное процессорное (и не только!) время, снижение надежности.
б) лаконично. Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности. "Лишние" данные - это ВСЕГДА лишние пересылки = нагрузки трактов, опять же время работы, опять же надежность.
в) лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации, объемов, снижению надежности и качества работы ПО. И резко повышает стоимость дальнейшего сопровождения и развития.
г) лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще. Ни текстовых, ни числовых. Всё должно выноситься в файлы настроек, таблицы настроек, локализаций, ресурсов и т.д. Корму что больше нравится...
д) развернуто. В части документирования и описания созданного ПО.
Замечу, что п1-4, для интерпретирующих языков (PHP, из модных Рельсы Рубика) имеют особую важность, потому как кроме выполняемых затрат, есть ещё и затраты на интерпретацию и подготовку выполнения...
Вроде как ничего сложного в моей религи нет. Да, профессиональных копрокодеров вовсе не приглашаю в неё. Каждый делает свой выбор самостоятельно. Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Современные настольные однопользовательские железки, по мощности ПРЕВОСХОДЯТ старшие модели IBM 360 в разы... и то что они НЕ справляются в простыми задачами - и есть результат ДЕГРАДАЦИИ отрасли, точнее перевода в копроэкономику...
Ещё раз... а чего так бурно влезли в тему тогда? Напомню начало: тема была (и есть) о деградации в ИТ отрасли, завышенных требованиях неграмотных специалистов "со стажем (копрокодирования)" к ожидаемой зарплате... Вы вроде как кинулись возражать... дескать всё не так, это аффтар дурак.
... а теперь "не надо доказывать"... собственно, согласен. Чего тут можно доказывать? По Вашим текстам, Ваша позиция понятна и прозрачна.
Моя "религия" достаточно проста: код должен писаться ровно тот, который нужен. Писаться грамотно. "Грамотно" - это:
а) лаконично. исполняемая часть кода должна быть оптимизирована "максимально возможно". То есть как можно меньше жрать процессорное время на избыточности кодирования. "Лишние вычисления" - это всегда впустую потраченное процессорное (и не только!) время, снижение надежности.
б) лаконично. Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности. "Лишние" данные - это ВСЕГДА лишние пересылки = нагрузки трактов, опять же время работы, опять же надежность.
в) лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации, объемов, снижению надежности и качества работы ПО. И резко повышает стоимость дальнейшего сопровождения и развития.
г) лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще. Ни текстовых, ни числовых. Всё должно выноситься в файлы настроек, таблицы настроек, локализаций, ресурсов и т.д. Корму что больше нравится...
д) развернуто. В части документирования и описания созданного ПО.
Замечу, что п1-4, для интерпретирующих языков (PHP, из модных Рельсы Рубика) имеют особую важность, потому как кроме выполняемых затрат, есть ещё и затраты на интерпретацию и подготовку выполнения...
Вроде как ничего сложного в моей религи нет. Да, профессиональных копрокодеров вовсе не приглашаю в неё. Каждый делает свой выбор самостоятельно. Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Современные настольные однопользовательские железки, по мощности ПРЕВОСХОДЯТ старшие модели IBM 360 в разы... и то что они НЕ справляются в простыми задачами - и есть результат ДЕГРАДАЦИИ отрасли, точнее перевода в копроэкономику...
Ещё раз... а чего так бурно влезли в тему тогда? Напомню начало: тема была (и есть) о деградации в ИТ отрасли, завышенных требованиях неграмотных специалистов "со стажем (копрокодирования)" к ожидаемой зарплате... Вы вроде как кинулись возражать... дескать всё не так, это аффтар дурак.
... а теперь "не надо доказывать"... собственно, согласен. Чего тут можно доказывать? По Вашим текстам, Ваша позиция понятна и прозрачна.
tolstopuz вы как мысленное упражнение попытайтесь представить разработку действительно большого продукта с миллионами строк кода, создаваемого сотней программистов.
Просто ИМХО у вас мышление "Левши который блоху подковал". Такой "Левша" найдет много проблем в коде и архитектуре любого большого продукта но сам он такой продукт никогда создать не сможет. Не сможет просто потому что иррационально смотрит на вещи:
- занимается premature оптимизацией
- уверен что его код не ломается и багов после поставки не должно быть
- думает что тесты писать не стоит т.к. его код не ломается
- думает что все коллеги должны быть такими же Левшами.
В реальной жизни большого проекта все как раз наоборот:
- Premature оптимизация ВРЕДНА. Основной принцип keep it stupid simple - большие программы пишуться "для людей" а не для того чтобы экономить циклы процессора
- Код ломается. Ломается обычно после изменений (представьте проект со 100 программистами и как в таком проекте делают рефакторинги и изменения)
- Если нет автоматического теста то код либо уже поломан либо БУДЕТ поломан в будущем
- Коллеги бывают разные и не все они Левши. Во многом люди "ломают" код не потому что они неквалифицированные а из-за:
* противоречий в требованиях - новая фича "ломает" предудущую про которую программист даже не в курсе (а тестов то нет опачки!)
* из-за сложности понимания всех тонкостей и особенности работы системы
* из-за невнимательности
Просто ИМХО у вас мышление "Левши который блоху подковал". Такой "Левша" найдет много проблем в коде и архитектуре любого большого продукта но сам он такой продукт никогда создать не сможет. Не сможет просто потому что иррационально смотрит на вещи:
- занимается premature оптимизацией
- уверен что его код не ломается и багов после поставки не должно быть
- думает что тесты писать не стоит т.к. его код не ломается
- думает что все коллеги должны быть такими же Левшами.
В реальной жизни большого проекта все как раз наоборот:
- Premature оптимизация ВРЕДНА. Основной принцип keep it stupid simple - большие программы пишуться "для людей" а не для того чтобы экономить циклы процессора
- Код ломается. Ломается обычно после изменений (представьте проект со 100 программистами и как в таком проекте делают рефакторинги и изменения)
- Если нет автоматического теста то код либо уже поломан либо БУДЕТ поломан в будущем
- Коллеги бывают разные и не все они Левши. Во многом люди "ломают" код не потому что они неквалифицированные а из-за:
* противоречий в требованиях - новая фича "ломает" предудущую про которую программист даже не в курсе (а тестов то нет опачки!)
* из-за сложности понимания всех тонкостей и особенности работы системы
* из-за невнимательности
Кстати примеры "косяков" ваших бывших коллег (отсутствие обработки ошибки сервера/получения данных, не использование транзакций) просто наглядно показывает что ваша система в зачаточном состоянии (либо никому не нужна и никем не используется). Т.к. это просто детские ошибки.
Также вам стоит учитывать что язык PHP известен огромным количеством малоквалифицированных прогаммистов т.к. на этом языке издервле клепают поделки. Я вообще за всю жизнь видел очень мало стоящих программистов на PHP т.к. нормальные программисты старались его избегать. Много лет это был уродец еше тот, только в 5 версии вроде появилось нормальное ООП (но и сейчас я бы не стал выбирать PHP). Но раз уж у вас используется эта технология то вам приходится мириться с этим "контингентом"
Также вам стоит учитывать что язык PHP известен огромным количеством малоквалифицированных прогаммистов т.к. на этом языке издервле клепают поделки. Я вообще за всю жизнь видел очень мало стоящих программистов на PHP т.к. нормальные программисты старались его избегать. Много лет это был уродец еше тот, только в 5 версии вроде появилось нормальное ООП (но и сейчас я бы не стал выбирать PHP). Но раз уж у вас используется эта технология то вам приходится мириться с этим "контингентом"
Спасибо, что Вы есть 
Спасибо, что не понимаете разницу между границами своего приложения, своих объектов и модулей и границами внешней библиотеки/компоненты. Восхищает, что Вы не закостенели после 10 лет стажа и делаете смелые попытки чтения чужого кода. Пусть даже так
И за мудрый совет по IDE отдельное спасибо. Право, даже не подозревал...
Я зря беспокоился, что ТС вносит элемент обучения. Оказывается его посты толком почти никто не читает. Люди со стажем лишь ищут возможность присоветовать IDE.
Ну не томите же, какая IDE облегчит всем жизнь?
Спасибо, что не понимаете разницу между границами своего приложения, своих объектов и модулей и границами внешней библиотеки/компоненты. Восхищает, что Вы не закостенели после 10 лет стажа и делаете смелые попытки чтения чужого кода. Пусть даже так
И за мудрый совет по IDE отдельное спасибо. Право, даже не подозревал...
Я зря беспокоился, что ТС вносит элемент обучения. Оказывается его посты толком почти никто не читает. Люди со стажем лишь ищут возможность присоветовать IDE.
Ну не томите же, какая IDE облегчит всем жизнь?
Зачем мысленно? Первый, мною сколоченный (небольшой правда) программистский коллектив, повзрослев стал на ноги самостоятельно и теперь имеет оборот около 10млн у.е. в год (если уже не больше, данные на 2001г.)... Не сказать что удачно сколоченный, ну так на то и "первый"... многие из Вас туда регулярно на работу просятся, ежели вчё.
Поясните пожалуйста простой вопрос: КОМУ ВРЕДНА и для КОГО озвученные пункты моей религи реально плохи?
- занимается premature оптимизацией?!? Что в этом плохого, если ВСЕ коллеги будут повышать свою квалификацию и становится Левшами? Аналогично и по другим пунктам... плиз. Хотя, после этого:
- уверен что его код не ломается и багов после поставки не должно быть
- думает что тесты писать не стоит т.к. его код не ломается
- думает что все коллеги должны быть такими же Левшами.
Поясните пожалуйста простой вопрос: КОМУ ВРЕДНА и для КОГО озвученные пункты моей религи реально плохи?
Несколько советов, по созданию нормально работающего ПО:
1. Настраиваемость кода. В коде, по возможности НЕ должно быть совсем константных значений хардкодом. Они все обязаны выносится в инструменты настройки ПО. На проектах студентов, в свое время, снижал по 0.5 балла за каждую константу в коде проекта.
if тра_ля_ля == 1 then чего-то делаем endif -- -0.5 балла за константу (1) и минус 0.5 балла за отсутствующий блок else, если не докажешь что он гарантированно не нужен.
2. Создание ВСЕХ элементов ветвлений (if-elseif-else, switch-default) даже если в них делать нечего (как правило "пока нечего")... вот как раз там где "нечего" и можно втыкать различные диагностические сообщения типа "ой... странное значение... новый тип параметра = способ обработки? Добавьте сюда код тоже..." Это не просто "полезно", а в больших проектах как раз является гигантским подспорьем по "потеряшкам" функционала... далеко не каждый юз-кейс используется регулярно... и когда через пару лет, кто-то нарвется на такое сообщение - оно сильно помогает. Проверено на практике.
3. Проверка всех входящих данных, которые приходят от:
а) пользователей. "Человеку свойственно ошибаться", а часто - сознательно;
б) внешних программ, работающих асинхронно. "Прога может и не работать в данный момент";
... и т.п.
И совсем "не важно" как тут думают, что результат приватного метода проверять НЕ надо... необходимость проверки зависит не от приватности метода выдавшего результат, а от возможной степени недоверия к входным данным. Так данные взятые из БД - зачастую есть смысл перепроверять (как в примере выше с ресайзингом картинок), несмотря на то что вроде как сами же их туда и сложили... Почему? Да просто всё: если сервер НЕ вернул данные (асинхронный код - может себе позволить такое легко!), то ... "вот он большой банан"...
В принимавшихся проектах студентов, недостаточность проверок данных снижала оценку на 1 балл за каждую отсутствующую проверку...
4. Постоянный рефакторинг собственного кода. Когда-то это даже подавалось как метод писания проекта "снизу вверх", кажется... Поначалу и сам пишу код "как получится"... с теми же константами и т.п. Это достаточно быстро и сразу работает. Но, как только появляется кусок кода, который надо просто скопировать и заменить в нем пару символов... вот тут надо приучить себя бить по пальцам! Это первый звоночек по рефакторингу... своего же копрокода. Потому что, то что было написано "сразу" - это далеко НЕ продакшн...
Для любознательных, отправлю к книжкам ИБМ-овцев (то ли Баррон, то ли кто-то другой) "Теория второй системы"... как-то так... вот эту схему писания кода и надо вбить себе в пальцы. На автоматике.
5. Оптимизация исполнения. Как ни странно, но занимаясь этим вопросом ещё на стадии создания первой версии кода, устраняются многие проблемы, неявно присутствующие в плохо проектированных ТЗ, в том числе и в части структур данных.
Так что, можете посмотреть с точки зрения этих требований на свой код и если оценка окажется отрицательной... учитесь дальше...
1. Настраиваемость кода. В коде, по возможности НЕ должно быть совсем константных значений хардкодом. Они все обязаны выносится в инструменты настройки ПО. На проектах студентов, в свое время, снижал по 0.5 балла за каждую константу в коде проекта.
if тра_ля_ля == 1 then чего-то делаем endif -- -0.5 балла за константу (1) и минус 0.5 балла за отсутствующий блок else, если не докажешь что он гарантированно не нужен.
2. Создание ВСЕХ элементов ветвлений (if-elseif-else, switch-default) даже если в них делать нечего (как правило "пока нечего")... вот как раз там где "нечего" и можно втыкать различные диагностические сообщения типа "ой... странное значение... новый тип параметра = способ обработки? Добавьте сюда код тоже..." Это не просто "полезно", а в больших проектах как раз является гигантским подспорьем по "потеряшкам" функционала... далеко не каждый юз-кейс используется регулярно... и когда через пару лет, кто-то нарвется на такое сообщение - оно сильно помогает. Проверено на практике.
3. Проверка всех входящих данных, которые приходят от:
а) пользователей. "Человеку свойственно ошибаться", а часто - сознательно;
б) внешних программ, работающих асинхронно. "Прога может и не работать в данный момент";
... и т.п.
И совсем "не важно" как тут думают, что результат приватного метода проверять НЕ надо... необходимость проверки зависит не от приватности метода выдавшего результат, а от возможной степени недоверия к входным данным. Так данные взятые из БД - зачастую есть смысл перепроверять (как в примере выше с ресайзингом картинок), несмотря на то что вроде как сами же их туда и сложили... Почему? Да просто всё: если сервер НЕ вернул данные (асинхронный код - может себе позволить такое легко!), то ... "вот он большой банан"...
В принимавшихся проектах студентов, недостаточность проверок данных снижала оценку на 1 балл за каждую отсутствующую проверку...
4. Постоянный рефакторинг собственного кода. Когда-то это даже подавалось как метод писания проекта "снизу вверх", кажется... Поначалу и сам пишу код "как получится"... с теми же константами и т.п. Это достаточно быстро и сразу работает. Но, как только появляется кусок кода, который надо просто скопировать и заменить в нем пару символов... вот тут надо приучить себя бить по пальцам! Это первый звоночек по рефакторингу... своего же копрокода. Потому что, то что было написано "сразу" - это далеко НЕ продакшн...
Для любознательных, отправлю к книжкам ИБМ-овцев (то ли Баррон, то ли кто-то другой) "Теория второй системы"... как-то так... вот эту схему писания кода и надо вбить себе в пальцы. На автоматике.
5. Оптимизация исполнения. Как ни странно, но занимаясь этим вопросом ещё на стадии создания первой версии кода, устраняются многие проблемы, неявно присутствующие в плохо проектированных ТЗ, в том числе и в части структур данных.
Так что, можете посмотреть с точки зрения этих требований на свой код и если оценка окажется отрицательной... учитесь дальше...
Спасибо конечно за ваши советы, но я их и до вас знал
На самое интересное - про авто тесты - вы и не ответили. Сколько бы вы не расставляли "лишние" else от них будет не сильно много толку если ошибка "ой что-то неправильно" вылетит у клиента - а просто сделать патч для этой версии будет стоить примерно 100 тыс долларов. 100 тыс долларов на то, чтобы саппорт идентифицировал проблему, передал ее в отдел разработки, там ее исправили (пара строк кода), создали патч или минорную версию продукта, продукт прошел QA, был отослан клиенту, клиент остановил кластер их 20 машин, задеплоил новую версию приложения, запусти кластер и подождал пока он "прогреется" (кеши заполнятся часто используемыми данными). И это не какой-то rocket science - а обычная крупная enterprise система.
А теперь еще прикиньте что все шаги кроме самого первого надо повторить для 5 версий продукта и продукт обновить у еще 100 клиентов.
---
Я же говорю вы живете в идеальном мире где все системы написны исключительно правильно что любое изменение максимально локализовано. Только опять таки вам в голову не приходят варианты измений вызванные новыми требованиями которые затрагивают несколько слоев и компонентов (да бывают и такие). И не надо говорить что программисты должны быть телепатами что начальная архитектура должна предусматривать все возможные изменения. Хотя безусловно опыт и чутье влияет на гибкость архитектуры.
---
Ну а уж про вредность premature optimization вы и без меня почитаете например тут http://c2.com/cgi/wiki?PrematureOptimization. Важно понять что под оптимизацией я понимаю ухудшение читабельности и сопровождаемости кода во имя экономии памяти или процессора.
---
to олдж: простите что перевлал цитату, хотя смысл остался тем же. У меня плохая память на имена, даты, цитаты
На самое интересное - про авто тесты - вы и не ответили. Сколько бы вы не расставляли "лишние" else от них будет не сильно много толку если ошибка "ой что-то неправильно" вылетит у клиента - а просто сделать патч для этой версии будет стоить примерно 100 тыс долларов. 100 тыс долларов на то, чтобы саппорт идентифицировал проблему, передал ее в отдел разработки, там ее исправили (пара строк кода), создали патч или минорную версию продукта, продукт прошел QA, был отослан клиенту, клиент остановил кластер их 20 машин, задеплоил новую версию приложения, запусти кластер и подождал пока он "прогреется" (кеши заполнятся часто используемыми данными). И это не какой-то rocket science - а обычная крупная enterprise система.
А теперь еще прикиньте что все шаги кроме самого первого надо повторить для 5 версий продукта и продукт обновить у еще 100 клиентов.
---
Я же говорю вы живете в идеальном мире где все системы написны исключительно правильно что любое изменение максимально локализовано. Только опять таки вам в голову не приходят варианты измений вызванные новыми требованиями которые затрагивают несколько слоев и компонентов (да бывают и такие). И не надо говорить что программисты должны быть телепатами что начальная архитектура должна предусматривать все возможные изменения. Хотя безусловно опыт и чутье влияет на гибкость архитектуры.
---
Ну а уж про вредность premature optimization вы и без меня почитаете например тут http://c2.com/cgi/wiki?PrematureOptimization. Важно понять что под оптимизацией я понимаю ухудшение читабельности и сопровождаемости кода во имя экономии памяти или процессора.
---
to олдж: простите что перевлал цитату, хотя смысл остался тем же. У меня плохая память на имена, даты, цитаты
только одно замечание, работающий код годами сам по себе содержит багу - он устарел за это время хз сколько раз.
расскажу знакомым дизигнерам, как анекдот, поржем.
да, кстати забыл спросить общий код зовется standart C library?
как бэ для скорости реляционные БД не самое лучшее решение
ктати жигулятор и бентли тоже одно и тоже, там тоже есть общее - металл.
расскажу знакомым дизигнерам, как анекдот, поржем.
да, кстати забыл спросить общий код зовется standart C library? как бэ для скорости реляционные БД не самое лучшее решение
ктати жигулятор и бентли тоже одно и тоже, там тоже есть общее - металл.
точно! нужна новая модель именно этого года. Модель прошлого года должна идти со скидкой
C standard library очень древняя, да?
Или уже не важно и можно без повода ржать?
расскажу знакомым дизигнерам, как анекдот, поржем.Вы так легко и со смехом садитесь в лужу, что остаётся только ржать с дизайнерами
C standard library очень древняя, да?
как бэ для скорости реляционные БД не самое лучшее решениеВам голоса в голове сказали про реляционные БД? Причём здесь MUMPS?
Или уже не важно и можно без повода ржать?
несколько замечаний
> Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности.
Именно поэтому Вы использовали массив в качестве ответа, а не спец класс? Тогда для сведения, и по памяти и по процессору оба решения идентичные, а вот по качеству коду нет.
> лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации
Код должен быть слабо связанным. Для этого деление на модули (архитектура) должно быть в первую очередь сделано исходя из функциональных зависимостей и во вторую очередь исходя из технических. Только в этом случае реализация новой фишки или существенные изменения в поведении системы могут быть произведены относительно безболезненно. Сильно связанный код становится мертвым кодом, его нельзя менять, в одном месте поменяешь в другом отвалится и т.п. сложности.
Поэтому копипаст возможен, в нем гораздо меньше криминала чем в сильной связанности кода.
> лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще.
А чего тогда у Вас в коде была константа SAFE_EQUALS = 0.0001 ? Кстати в этом случае она уместна, так что правило это не годится, но в подавляющем большинстве случаев это действительно так, хотя я надеюсь не имелись ввиду захардкоженные имена событий или там ключей по которым эти значения вытаскиваются :)) Ну и в качестве придирки - это не про лаконичность.
> развернуто. В части документирования и описания созданного ПО.
Я бы хотел добавить, что код должен писаться так, чтобы он был self documenting. Потому что чтобы вы не написали в комментарии и в спецификации - работать будет код и только он, как бы это банально не звучало. Еще и поэтому важны проверки, они еще и "документируют" код. Еще и поэтому важны юнит тесты - чтобы понять как реально работать с каким то модулем - я обязательно загляну в его юнит тесты.
> Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Заказчику похер на религию программистов, он покупает решению, которое должно работать на текущем железе, а не на IBM-360. И PHP это далеко не ассемблер. Очнитесь, ситуация 20 летней давности неактуальна уже 20 лет.
З.Ы. доказывать не собираюсь приводя свой код, а в тему влез просто поговорить, просто увидел какой у Вас апломб, Вы весь в белом, вокруг одни копроделы, вот и захотелось разобраться так сказать
> Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности.
Именно поэтому Вы использовали массив в качестве ответа, а не спец класс? Тогда для сведения, и по памяти и по процессору оба решения идентичные, а вот по качеству коду нет.
> лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации
Код должен быть слабо связанным. Для этого деление на модули (архитектура) должно быть в первую очередь сделано исходя из функциональных зависимостей и во вторую очередь исходя из технических. Только в этом случае реализация новой фишки или существенные изменения в поведении системы могут быть произведены относительно безболезненно. Сильно связанный код становится мертвым кодом, его нельзя менять, в одном месте поменяешь в другом отвалится и т.п. сложности.
Поэтому копипаст возможен, в нем гораздо меньше криминала чем в сильной связанности кода.
> лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще.
А чего тогда у Вас в коде была константа SAFE_EQUALS = 0.0001 ? Кстати в этом случае она уместна, так что правило это не годится, но в подавляющем большинстве случаев это действительно так, хотя я надеюсь не имелись ввиду захардкоженные имена событий или там ключей по которым эти значения вытаскиваются :)) Ну и в качестве придирки - это не про лаконичность.
> развернуто. В части документирования и описания созданного ПО.
Я бы хотел добавить, что код должен писаться так, чтобы он был self documenting. Потому что чтобы вы не написали в комментарии и в спецификации - работать будет код и только он, как бы это банально не звучало. Еще и поэтому важны проверки, они еще и "документируют" код. Еще и поэтому важны юнит тесты - чтобы понять как реально работать с каким то модулем - я обязательно загляну в его юнит тесты.
> Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Заказчику похер на религию программистов, он покупает решению, которое должно работать на текущем железе, а не на IBM-360. И PHP это далеко не ассемблер. Очнитесь, ситуация 20 летней давности неактуальна уже 20 лет.
З.Ы. доказывать не собираюсь приводя свой код, а в тему влез просто поговорить, просто увидел какой у Вас апломб, Вы весь в белом, вокруг одни копроделы, вот и захотелось разобраться так сказать