Я как прогаммист

Когда возникает какая то идея могу сидеть сутками за её реализацией, а когда нет под рукой компьютера - использую любые подручные средства. Часто пытаюсь писать сразу оптимальный алгоритм. Тестирую и делаю небольшие правки очень много времени, пока каждый пиксель не будет утверждён внутренним цензором. Иногда решения приходят мне перед сном, во сне еще не приходят, надеюсь это хорошо. Рефакторинг моё второе имя. Черновой и чистовой код у меня имеют квантовые состояния. Жена ругается - я пишу, жена спит - я пишу, жена проснулась - я уже выспался и пишу. У меня есть пару десятков незаконченных проектов, а от кода законченных мне обычно страшно. Надоело писать - ем.

 

Евгений так часто рефлексировал, что стал фаталистом.

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

Но правила несколько позже. Расскажу про мою битву с мельницей. А. Одним из показателей качества программы (алгоритма) есть время за которое она (он) выполняется. Б. У любого программиста есть две функции - сделать что бы оно работало, и сделать что бы оно работало лучше. 

Мне придумалось писать довольно простой но требовательный к ресурсам алгоритм, связанный с обработкой изображения. Его суть не столь важна, на любом высокоуровневом языке он бы занял десяток строк. Первым делом надо выбрать язык на котором он будет написан, а поскольку любой программист знает что машинный код это то что будет выполнятся максимально быстро, решено было делать на ассемблере. Изучил ассемблер, что на самом деле было довольно полезно для меня, написал алгоритм, давай его проверять. Здесь пошли крушения моих титаников, первый утонул из за операционной системы, всё что выполняется в режиме ядра ОС - раза в полтора быстрее самых, казалось бы, идеальных решений написанных в машинном коде. Таким образом любые велосипеды заменяющие функции ОС - бессмысленны, и следует из этого то, что если нам нужна какая либо функция - начинаем искать в ядре операционной системы. Надо скопировать 500 байт - не пишем на ассеммблере, пишем копи мемори. Второй титаник потопили современные компиляторы. Причем прямо сразу на дно. Переписав код на С++, я с удивлением обнаружил что код выполнялся, в определённых случаях, даже быстрее чем на асм. Чтож я искал утешение в том что просто не в силах использовать все инструкции процессора x86, и возможно в моём идеальном коде есть что улучшать. Когда C# время показал идентичное С++ и почти тоже что и в машинном коде. Дальше - хуже, Visual Basic - тоже, причем один в один как C#, хотя я там даже не старался оптимизировать код. В большинстве случаев код на ассмблере давал прирост в скорости не более чем на 1%, а иногда наоборот был медленнее. А внедрять его достаточно неудобно, а еще для 64 и 32 бит надо писать отдельно. У внутреннего моего перфекциониста разболелось горло. Я могу писать крутые, совершенные алгоритмы, только вот запускать их негде, а те которые есть где запускать - лучше писать на высокоуровневых языках. Я пришел к тому с чего начал. У меня не появилось супер силы и я не смог выйти за грани реальности. Теперь я буду писать сортировку пузырьком так же как и школьник, но буду знать что это лучшее решение.

Правила:

  • У любой программы есть узкое горлышко - имеет смысл оптимизировать только его - всё остальное пустая (часто довольно внушительная) трата твоего времени.
  • Чаще пытайся понять как это будет скомпилировано, и выполнятся процессором.
  • Помни про память, доступ к которой занимает время - не выполняй в одном потоке обработку данных из разных областей памяти.
  • Хочешь что то пооптимизировать - начни с объектной модели. Чешутся руки - опиши работу функций.
  • Не знаешь как что то сделать - ищи в документации к ОС, в документации к Фреймворку, не нашел - плохо искал, ищи снова. Не нашел второй раз, - спроси у гугла, нашел но не понял как работает? - ищи в документации к ОС,  в документации к Фреймворку по функциям которые не понял.
  • Есть исходный код фреймворка - читай. Используешь объект или функцию из фреймворка - лучше знать как она работает. Часто можно вообще не использовать именно этот тип объекта, а использовать его основу.
  • Хочешь сделать что то лучше чем кто то уже придумал - делай. Есть 1% вероятности что ты не разочаруешься.
  • Тестов никогда не бывает много. Тесты это то что должно занимать 10/10 времени от написания программы.

 

 

редакция от 10 июля 2016