Хаха)) Что-то вспомнилось, когда лет 12 назад я начал осваивать яву, в учебниках писали, что ява разработана, чтобы тоже запиливать её во все подряд домашние приборы с унифицированным интерфейсом, которые потом можно в единую сеть собирать.
Не знаю, как другие, но под заголовком «принципы проектирования сайтов» лично я ожидал увидеть конкретные схемы, алгоритмы и архитектуры (что-то вроде того, что на картинке нарисовано), а не просто набор советов, который, в общем-то, подойдёт для любой схожей области, например, статью можно было бы назвать «принципы проектирования спортивных автомобилей» — никто бы не заметил подлога. Я, конечно, утрирую, но идею вы, думаю, поняли :)
Но моя главная задача — экспериментировать с новой, не UNIX-derived, архитектурой.
А если не секрет, Вы уже определились, какие новаторские архитектурные решения Вы хотели бы Но моя главная задача — экспериментировать с новой, не UNIX-derived, архитектурой опробовать?
Я сам не участник разработки Kolibri (во всяком случае, пока), но, во-первых, я знаю, что её уже используют в достаточно серьезных делах (боюсь соврать, поэтому подробности можете, если хотите, почитать на их форуме), а во-вторых, мне кажется, что экспериментировать должно быть проще, когда куча мелкой, но важной работы уже проделано. Грубо говоря, можно сесть и самому писать дрова под видео/звук/мышь и т.п., потратив на это годик-другой, а можно воспользоваться готовым решением (благо, исходники — вот они), и заняться сразу самым интересным, не размениваясь по мелочам. :)
Почитал про него. Пожалуй, это примерно то, что я имел в виду. Правда, пишут, что он больше для промежуточной компиляции, нежели для непосредственного программирования…
Надо уважать право других программистов быть слабее вас. В конце концов чаще всего над конечным продуктом трудится больше 1го человека.
Я уважаю право своих подчиненных на улучшение своих навыков и обычно не жалею времени, чтобы помочь им в этом нелегком пути. Если я вижу, что человек заинтересован в улучшении своего уровня, я ему помогу всеми доступными мне способами, а если вижу, что не заинтересован, то скорее всего мы с ним вскоре расстанемся. Конечно, это происходит, потому что я работаю с небольшой группой, в которой все время приходится решать новые задачи и искать новые решения для старых. Простые «рабочие лошадки», по 5 лет выполняющие одинаковые задачи, востребованы в больших и долгих проектах, но не у нас.
Вот геймдевелоперов часто видно издалека.
Я пока еще не стал бы называть себя геймдевелопером — в эту тему только начал погружаться. Прежде всего я — веб-девелопер.
месиво из алгоритма, оптимизаций, хаков считать нормой.
Я большой поклонник красивого кода и всегда стараюсь писать как можно более красиво, хотя, признаюсь, стараюсь не забывать про то, что «лучшее — враг хорошего», и разного рода заплатки, конечно же, периодически появляются в моём коде, например, когда мне говорят: «а вот для вот этого особого пользователя пусть в этом месте будет не 5, а 6».
Хочу заметить, что, хотя я практически не знаю ассемблер, ваш код очень классно читать — все так здорово откомментированно.
Мне всегда было интересно, а нельзя ли, сохранив всю мощь макроассемблера как низкоуровневого языка, доработать его так, чтобы он еще больше походил на высокоуровневые языки, чтобы снизить порог вхождения при его изучении, и одновременно облегчить поддержку кода?
Как Вы думаете, товарищи, какого синтаксического сахара, можно было бы добавить в данный язык, так, чтобы это не повлияло на производительность?
Я тоже сталкивался с подобной проблемой при переходе на MariaDB.
Смысл запроса был примерно такой:
SELECT * FROM (SELECT a, b FROM t1 ORDER BY b) GROUP BY a
Прикол в том, что MySQL возвращал для каждого a наименьший b, а MariaDB для каждого a — черте-какой b.
Я написал баг-репорт, а мне объяснили так:
>> I know that while grouping MySQL uses first met value for those columns that are not grouped.
No, it doesn't. Again, you rely on pure luck; and now, *this* is explicitly documented in MySQL manual:
MySQL extends the use of GROUP BY so that the select list can refer to nonaggregated columns not named in the GROUP BY clause. <..> You can use this feature to get better performance by avoiding unnecessary column sorting and grouping. However, this is useful primarily when all values in each nonaggregated column not named in the GROUP BY are the same for each group. The server is free to choose any value from each group, so unless they are the same, the values chosen are indeterminate.
Поэтому советую очень внимательно относиться к группировке и сортировке во вложенных запросах.
А в Вашем случае, конечно, всё без проблем делается без подзапросов.
Помните, что MySQL любит делать декартово произведение кортежей, где надо, и где не надо.
Я же несколько раз упомянул, что комментарии должны пояснять смысл происходящего, а не дублировать код. Конечно же, я не комментирую каждый чих.
Я считаю, что довольно хорошо откомментированны, например, исходники Андроида, хотя лично на мой вкус в некоторых отдельных местах их всё-таки не хватает — бывает сложновато разобраться.
Хорошая практика подразумевает, что ты при изменении кода должен перечитать соответствующие комментарии и исправить их. Да, баги в комментах могут так же появляться, как и в коде, тем более что отдебажить комменты нельзя, но это вовсе не означает, что следует от них отказаться.
Например, если ты меняешь список параметров функции, то, будь добр, отрази эти изменения в комментах к ней.
Плотность, с которой лично я комментирую свой код зависит от таких параметров:
1. Если это разовая или очень срочная (но не очень сложная) задачка, то могу оставить почти без комментариев — только самые сложные места.
2. Если я пишу код, который в обозримом будущем буду поддерживать только я, то комментирую самые сложные места и смысл отдельных методов и объектов.
3. Если я работаю над кодом со своей командой, то стараюсь сделать так, чтобы у моих соратников было как можно меньше вопросов вида: «Что это тут за хитровыжопленная хрень? Я вообще не понимаю, как это работает!». Т.е. стараюсь, чтобы, если я ушел в отпуск, то без меня могли что-то дописать. В этом случае я могу в комментариях расписать какие-то архитектурные особенности и связи.
4. Если я работаю на аутсорс, то стараюсь сделать так, чтобы мой код мог разобрать любой адекватный программист, не матерясь в мой адрес на каждой строчке и не тратя по полчаса на 5 строк. Да, и еще, очень здорово, когда программисту не обязательно разбираться в предметной области, чтобы прочитать данную программу.
К сожалению, я не гений, и практика не всегда соответствует теории, но я по крайней мере стараюсь :)
Не воспринимайте всё буквально. «Главный рабочий объект» — это шаблон описания объекта, а на самом деле там должна быть описана роль данного объекта в вычислениях. Объект назван «Processor» — всего лишь, чтобы отразить, что он что-то делает.
Название «mainProcessor» ничего не говорит о том, чем этот Processor будет заниматься, а именно это должно быть отражено в комментариях:
// Основной обработчик клиентских вызовов (для красных вариантов)
var redProcessor = new Processor();
Потому что дальше может, например, оказаться такой код:
// Вспомогательный обработчик клиентских вызовов (для синих вариантов)
var blueProcessor = new Processor();
// Вспомогательный обработчик клиентских вызовов (для зелёных вариантов)
var greenProcessor = new Processor();
И, пожалуйста, не доказывайте мне что вместо redProcessor можно написать main_red_client_recall_processor, потому что пример упрощенный, а в реальной жизни всё может оказаться сложнее.
Люди, которые полагаются на самодокументированый код, не понимают, что постановка задачи и её реализация в конкретном коде — это разные вещи. Да, свой код обычно легко читать. Но даже зная предметную область, вникнуть в перепетии чужого кода (да еще и не откомментированного по-человечески!) становится нетривиальной задачей.
Те, кто утверждает, что комментирование кода излишняя трата времени — либо просто оправдывают свою лень, либо не работали в плотной команде, либо через чур самоуверенны, либо просто недалёки. Ну, наверное, еще бывают гении, чей код на столько прозрачен и читабелен, что действительно не требует комментариев, но такие люди не имеют права навязывать свои методы работы обычным людям, которых большинство, и у которых код не такой красивый и чистый.
Я как руководитель команды программистов утверждаю, что код без адекватных комментариев — ВСЕГДА становится проблемой, после того как автор данного кода уходит из проекта.
А если не секрет, Вы уже определились, какие новаторские архитектурные решения Вы хотели бы Но моя главная задача — экспериментировать с новой, не UNIX-derived, архитектурой опробовать?
Может, им стоило бы как раз на Анси-С или С-- все писать?.. И гибко, и проще, вроде бы…
Вот тут не понял аргументации, извините.
Я уважаю право своих подчиненных на улучшение своих навыков и обычно не жалею времени, чтобы помочь им в этом нелегком пути. Если я вижу, что человек заинтересован в улучшении своего уровня, я ему помогу всеми доступными мне способами, а если вижу, что не заинтересован, то скорее всего мы с ним вскоре расстанемся. Конечно, это происходит, потому что я работаю с небольшой группой, в которой все время приходится решать новые задачи и искать новые решения для старых. Простые «рабочие лошадки», по 5 лет выполняющие одинаковые задачи, востребованы в больших и долгих проектах, но не у нас.
Я пока еще не стал бы называть себя геймдевелопером — в эту тему только начал погружаться. Прежде всего я — веб-девелопер.
Я большой поклонник красивого кода и всегда стараюсь писать как можно более красиво, хотя, признаюсь, стараюсь не забывать про то, что «лучшее — враг хорошего», и разного рода заплатки, конечно же, периодически появляются в моём коде, например, когда мне говорят: «а вот для вот этого особого пользователя пусть в этом месте будет не 5, а 6».
Мне всегда было интересно, а нельзя ли, сохранив всю мощь макроассемблера как низкоуровневого языка, доработать его так, чтобы он еще больше походил на высокоуровневые языки, чтобы снизить порог вхождения при его изучении, и одновременно облегчить поддержку кода?
Как Вы думаете, товарищи, какого синтаксического сахара, можно было бы добавить в данный язык, так, чтобы это не повлияло на производительность?
нуну))
Смысл запроса был примерно такой:
SELECT * FROM (SELECT a, b FROM t1 ORDER BY b) GROUP BY a
Прикол в том, что MySQL возвращал для каждого a наименьший b, а MariaDB для каждого a — черте-какой b.
Я написал баг-репорт, а мне объяснили так:
Поэтому советую очень внимательно относиться к группировке и сортировке во вложенных запросах.
А в Вашем случае, конечно, всё без проблем делается без подзапросов.
Помните, что MySQL любит делать декартово произведение кортежей, где надо, и где не надо.
Я считаю, что довольно хорошо откомментированны, например, исходники Андроида, хотя лично на мой вкус в некоторых отдельных местах их всё-таки не хватает — бывает сложновато разобраться.
Хорошая практика подразумевает, что ты при изменении кода должен перечитать соответствующие комментарии и исправить их. Да, баги в комментах могут так же появляться, как и в коде, тем более что отдебажить комменты нельзя, но это вовсе не означает, что следует от них отказаться.
Например, если ты меняешь список параметров функции, то, будь добр, отрази эти изменения в комментах к ней.
Плотность, с которой лично я комментирую свой код зависит от таких параметров:
1. Если это разовая или очень срочная (но не очень сложная) задачка, то могу оставить почти без комментариев — только самые сложные места.
2. Если я пишу код, который в обозримом будущем буду поддерживать только я, то комментирую самые сложные места и смысл отдельных методов и объектов.
3. Если я работаю над кодом со своей командой, то стараюсь сделать так, чтобы у моих соратников было как можно меньше вопросов вида: «Что это тут за хитровыжопленная хрень? Я вообще не понимаю, как это работает!». Т.е. стараюсь, чтобы, если я ушел в отпуск, то без меня могли что-то дописать. В этом случае я могу в комментариях расписать какие-то архитектурные особенности и связи.
4. Если я работаю на аутсорс, то стараюсь сделать так, чтобы мой код мог разобрать любой адекватный программист, не матерясь в мой адрес на каждой строчке и не тратя по полчаса на 5 строк. Да, и еще, очень здорово, когда программисту не обязательно разбираться в предметной области, чтобы прочитать данную программу.
К сожалению, я не гений, и практика не всегда соответствует теории, но я по крайней мере стараюсь :)
Название «mainProcessor» ничего не говорит о том, чем этот Processor будет заниматься, а именно это должно быть отражено в комментариях:
Потому что дальше может, например, оказаться такой код:
И, пожалуйста, не доказывайте мне что вместо redProcessor можно написать main_red_client_recall_processor, потому что пример упрощенный, а в реальной жизни всё может оказаться сложнее.
Люди, которые полагаются на самодокументированый код, не понимают, что постановка задачи и её реализация в конкретном коде — это разные вещи. Да, свой код обычно легко читать. Но даже зная предметную область, вникнуть в перепетии чужого кода (да еще и не откомментированного по-человечески!) становится нетривиальной задачей.
Те, кто утверждает, что комментирование кода излишняя трата времени — либо просто оправдывают свою лень, либо не работали в плотной команде, либо через чур самоуверенны, либо просто недалёки. Ну, наверное, еще бывают гении, чей код на столько прозрачен и читабелен, что действительно не требует комментариев, но такие люди не имеют права навязывать свои методы работы обычным людям, которых большинство, и у которых код не такой красивый и чистый.
Я как руководитель команды программистов утверждаю, что код без адекватных комментариев — ВСЕГДА становится проблемой, после того как автор данного кода уходит из проекта.