Для того чтобы сделать любую базу данных высокопроизводительной, надо приложить немало усилий разработчиков.
Конечно, оптимизатор у Firebird оторви да выбрось, но написание «кошерного» высокопроизводительного запроса для MSSQL/Oracle ничуть не проще.
Это не говоря о том, что для большинства прикладных задач никаких специальных проблем с производительностью Firebird нет, зато всегда есть бонусы бесплатности, легкости автоматической установки и нуль-администрируемости.
Вот таким способом и получается антипаттерн «многослойный говнокод», который в итоге хрупок и нереюзабелен настолько, что его проще выкинуть в мусор целиком.
Первая и вторая стадия разделены напрасно: имеет место быть один и тот же синдром золотого молота — серебряной пули.
Более того, рядовой исполнитель может находиться на какой угодно стадии — рецензент и ведущий быстро приведут к общекомандному знаменателю.
Некодирующий архитектор — плохой архитектор, так как гарантированно теряет квалификацию в отрыве от практики.
Конечно, архитектор пишет меньше, чем исполнитель, но пишет обязательно — прототипы, базовые интерфейсы и классы.
В результате строгого следования принципам получается текст, созданный непрофессионалами, редактируемый непрофессионалами, без ссылок на первичные источники, с нейтральной точкой зрения от непрофессионала.
В результате википедия не может служить источником фактов по построению, так как ни авторы статей, ни редакторы профи не являются и не могут отличить откровенно маргинальные источники от «мэйнстрима». Поэтому Борис Соколов существует в вике на равных правах с Кривошеевым, а Волкогонов — с Земсковым. И «нейтральная» точка зрения ан-масс оказывается шарлатанской.
К сожалению, вывод из этого простой и малоприятный: чтение и пополнение википедии — напрасная трата времени и сил.
Я не дизайнер, а разработчик, но могу сказать что автор прав — основной причиной просадки проекта как по срокам, так и по качеству является недостаточная тщательность исполнения, которую обосновывают жесткими сроками.
А на деле грубая или даже грязная работа дает строго обратный эффект, так как перегружает все остальные, и без того наиболее трудоемкие стадии выпуска — рецензирование, отладку, тестирование, внедрение и сопровождение.
Парадоксально, но лучший способ попасть в сроки — считать их рекомендацией, а думать прежде всего о качестве решений и исполнения.
Исключение составляют задачи, которые после определенного срока не имеет смысла делать вообще. Это спортивное программирование и написание прототипов, но такой код никогда не должен попасть в релиз (лучше всего — выкинут сразу после демонстрации).
У таких программ есть один неприятный общий недостаток — выбивают из «потока», что резко снижает продуктивность при интенсивной работе. Интересно, есть ли программы которые могут задерживать отключение, если пользователь активно раюотает с определенным приложением — т.е. пока я пишу и отлаживаю код в IDE, меня лучше не прерывать, а вот все остальное можно блокировать беспрепятственно.
Прочитал — автор статьи деликатно обошел темы активной подсветки и энергопотребления. А разговоры о хрупкости и вовсе джинсовые — можно подумать, что ЖК-экран весь из себя ударопрочный.
А я не помню, как это сделать в МСО — хотя когда писал диплом именно так и сделал. Просто не держу такие знания в голове — все успешно находил, пользуясь штатной справкой
Честно говоря, не вижу никаких причин быть вежливым с теми, кто использует рассмотренные в топике приемы, кроме возможных последствий в рамках административного или уголовного кодекса.
А исполнителей (рекрутеров) желательно предупреждать, что если их обматерят или разобьют им лицо — то это совершенно заслуженное вознаграждение и необходимая составляющая часть стрессового интервью: в этой игре есть мультиплеер.
Конечно, оптимизатор у Firebird оторви да выбрось, но написание «кошерного» высокопроизводительного запроса для MSSQL/Oracle ничуть не проще.
Это не говоря о том, что для большинства прикладных задач никаких специальных проблем с производительностью Firebird нет, зато всегда есть бонусы бесплатности, легкости автоматической установки и нуль-администрируемости.
Хуже всего те, кто мало того что не знает, так еще и знать не хочет!
Более того, рядовой исполнитель может находиться на какой угодно стадии — рецензент и ведущий быстро приведут к общекомандному знаменателю.
Конечно, архитектор пишет меньше, чем исполнитель, но пишет обязательно — прототипы, базовые интерфейсы и классы.
В результате википедия не может служить источником фактов по построению, так как ни авторы статей, ни редакторы профи не являются и не могут отличить откровенно маргинальные источники от «мэйнстрима». Поэтому Борис Соколов существует в вике на равных правах с Кривошеевым, а Волкогонов — с Земсковым. И «нейтральная» точка зрения ан-масс оказывается шарлатанской.
К сожалению, вывод из этого простой и малоприятный: чтение и пополнение википедии — напрасная трата времени и сил.
А на деле грубая или даже грязная работа дает строго обратный эффект, так как перегружает все остальные, и без того наиболее трудоемкие стадии выпуска — рецензирование, отладку, тестирование, внедрение и сопровождение.
Парадоксально, но лучший способ попасть в сроки — считать их рекомендацией, а думать прежде всего о качестве решений и исполнения.
Исключение составляют задачи, которые после определенного срока не имеет смысла делать вообще. Это спортивное программирование и написание прототипов, но такой код никогда не должен попасть в релиз (лучше всего — выкинут сразу после демонстрации).
Пока, увы, маркетологически бессмысленно — пользователи все еще считают гигабайты.
А исполнителей (рекрутеров) желательно предупреждать, что если их обматерят или разобьют им лицо — то это совершенно заслуженное вознаграждение и необходимая составляющая часть стрессового интервью: в этой игре есть мультиплеер.