Сначала предисловие к серии было на пару абзацев, но Остапа понесло, потому отдельно эссе про серию эссе и вообще о проблеме.

Среда разработчиков и программистов за скоро уже столетие порождала и порождает собственную мифологию, собственные страшилки, рассказываемые джуниорам перед сном и обязательно при выключенном свете. Почти все эти страшилки довольно категоричны в формулировке и выглядят как «вот так НИКОГДА нельзя делать» (иначе тебя заберёт чёрный гробик).

И почти все они в своей истории / сути содержат следующее:

  • не давать слабо обученным людям опасный инструмент;
  • N лет назад что-то было опасным, но вышел уже с десяток major версий без этой проблемы;
  • что-то пробивало себе на рынок путь хайповой критикой существующих технологий;
  • вполне разумное утверждение бестолковым сообществом было упрощено, доведено до абсурда и поднято на знамя;
  • непонимание чего-то количественно или качественно сложного, а потому боязнь;
  • наконец, за десятилетия знания / инструменты эволюционировали достаточно, чтобы в полной мере компенсировать опасное, но отмены страшилки не произошло.

Чем опасны страшилки? Ведь это, казалось бы, опыт поколений, что для ремесла разработки актуально. Говорит тебе дедушка не строгать по направлению к себе, значит, не надо строгать так, чревато. Они опасны тем, что легко принимаются на веру, легко эксплуатируют, скажем, интеллектуальную лень разработчика, легко передаются устно (что проще, час объяснять, как правильно что-либо сделать, или же за минуту озвучить запрет?) – разработчик выстраивает стену между собою и инструментом.


И тут ещё раз напомню то, за что топлю: всё является инструментом, созданным для определённого кластера задач или же эволюционировавшим до удобства решения такового. Инструмент не может быть плохим, но он может быть использован неподходящим человеком для решения неподходящей задачи – аксиома. И дальше уже от уровня развития человека зависит оценка ситуации: у дурака инструмент получит клеймо плохого, а умный поймёт, что сам чёт не тем занят.

До того, как клеймить, специалист должен найти ответы на следующие вопросы:

  • для какой задачи был создан инструмент?
  • хорошо ли он решает эту задачу?
  • если не хорошо, то почему?
  • какие задачи он может хорошо решать?
  • что требуется для того, чтобы инструмент решал задачу хорошо?
  • какие требования к оператору входят в условия использования инструмента?

Что интересно, в быту мы без дотошности (ну, за некоторым исключением) вполне применяем этот список. Одежда выбирается сообразно задачам (дождевик в дождь, треники на зарядку, плавки на пляж и т.д.), еда сообразно распорядку дня и потребностям организма (надеюсь, здесь нет альтернативных, сгрызающих утром 1 кг солёного сала, а потом икающих «фу какое плохое сало, сало надо запретить, сало опасно»), людей руководители всё же стараются ставить подходящих работе, а не «так, Плисецкая, сегодня разгружаешь вагоны с щебнем».

Наконец, ваши личные предпочтения (ой, я люблю зелёные молотки, а не красные), если вы стремитесь стать профессионалом, должны уйти на третий план, если предпочтение снижает эффективность работы.


Серией эссе «Elm Street» я попробую внятно сдампить в текст концентрат думаемого про некоторые известные страшилки. Темп написания… ну вряд ли быстро, т.к. потребуется провести немало архивной работы, но не думаю, что заброшу. Самому интересно поставить запятые в ряде тем.

На данный момент не в планах, но под рассмотрением следующее:

  • GOTO зло.
  • Глобальные переменные зло.
  • Хранимые процедуры зло.
  • Монолит зло.
  • Возвращать ошибки результатом функции (как в C принято) зло.
  • Макросы зло.
  • Динамическая / статическая типизация зло.
  • Преждевременная оптимизация зло.
  • Изобретать велосипед зло.
  • Строки длиннее 80 символов зло.

Список со временем будет дополняться, я смотрю в тред, в котором народ предлагал свои версии, но как-то обозревать буду всё же то, о чём успел сложить мнение.

Также этот список будет содержанием – по мере написания эссе пункты превратятся в ссылки.

Эссе тоже будут дополняться.


Как-то так.