Тема: Программирование  |   Дата: 23.02.2016

Программная мудрость для разработчиков.

Существует Великая колхозная доктрина, состоящая из 10 основных правил, которыми должен руководствоваться программист. Название этой доктрины связано с колхозными программистами, которые передавали эти правила из поколения в поколение десятилетиями. Время проходило, и учение подвергалось разным толкованиям и нововведениям. Современные теоретики предоставляют нам эту доктрину в искаженном виде. Только широко провозгласив о существовании колхозной доктрины, мы сможем возродить ее, можем подробнее изучить принципы, посетив курсы программирования (Киев). При участии определенного количества людей нам удалось понемногу возобновить и представить вашему вниманию основные правила для программистов.

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

Даже если вы являетесь лидером команды, считаться с мнением коллег просто необходимо. Так, например, вы видите решение какой-то проблемы посредством Paxos. Но не факт, что ваша команда владеет какой-либо информацией о вашем Paxos. А среди тех людей, которые приходят к вам на собеседование, найдутся те, которые даже не имеют понятия, что это такое. Суть проблемы заключается не в ваших малоквалифицированных специалистах, а в вас. Вы принимаете такое решение, поддержать которое сможете только вы сами. Если данное решение не есть подходящим для вашей компании, не стоит на этом зацикливаться. Постарайтесь найти другой подход и разрешить конфликт таким способом, чтобы все остались довольны.

Исключительно ситхи считают все абсолютным. По их мнению, стоит запускать только один процесс в Docker, использовать те переменные, которые не могут меняться, использовать в своей практике только ООП подход, писать всю информацию исключительно в Vim, считать макбуки идеальными устройствами для работы. Они могут также отвергать все существующие языки за исключением Erlang, так как в нем есть remsh и возможность горячего обновления кода. Все это просто чушь. Иное мнение заключается в том, что нужно избегать категорических заявлений. Например, свалить все на базу данных, язык программирования и т.д. Технологии мало когда ошибаются. Неправильные действия в основном делают люди. Тщательно анализируйте сложившеюся ситуацию. Во время анализа руководствуйтесь исключительно строгими критериями. Свою фантазию оставьте на потом.

Необходимо противостоять перфекционизму. В связи с тем, что над проектом работало большое количество специалистов, коды постоянно менялись. Соответственно это приводило к определенному количеству недостатков и неудобств. Не стоит пытаться изменить чье-то мнение. Каждый по-своему называет переменные, расставляет отступы или использует более быстрый код. От этого не зависит счастье и комфорт пользователей. Не стоит спорить об этих вещах. Вы просто потратите зря свое время.

Не нужно изобретать что-то новое. Сегодня довольно сложно найти такую задачу, с которой еще никогда никто не сталкивался и не выложил ее в виде SaaS. Если у вас возникают какие-то вопросы при решении той или мной задачи, не стоит замыкаться в себе. Перенимайте опыт своих коллег. Возможно, уже есть решение данной задачи. Нет необходимости в записи своего собственного ORM. Лучше откорректировать что-то старое, чем придумать что-то новое.

Доверяйте только сами себе. Не стоит идти на поводу у маркетингового рынка или у своих друзей. Не стоит верить в то, что при использовании DynamoDB были потеряны все данные. Если мы говорим о WhatsApp, которая использует Erlang, не стоит надеяться на автоматическое построение идеальной системы. Что касается Riak – это ключевая база данных. Если с Basho вы сможете в подарок получить MapReduce и еще кучу всяких мелочей, не стоит на это вестись. Не факт, что все это будет безукоризненно работать в Riak. Для того, чтобы проверить возможности вашего оборудования, загрузите в PostgreSQL ваши объемы данных. Вы сможете увидеть количество транзакций, которые он реально тянет с теми настройками, которые вы смогли осилить. Благодаря Vagrant, вы сможете проверить уровень падения данных при падении узлов.

Старайтесь руководствоваться самыми простыми решениями. Все эти выкрутасы типа теории категорий, доказательства корректности программ и т.д. просто неуместны. Пользователи врядли станут задумываться о количестве использованных монад и доказанных теорем при создании проекта. Лучше напишите несколько дополнительных нагрузочных тестов, которые просты в выполнении и проверенны временем. Если практически все проекты построены на базе РСУБД типа MySQL или PostgreSQL со всеми комплектующими, то необходимости в проекте MongoDB нет. Добавите себе еще больше проблем.

Будьте консерватором. Но, при этом не бойтесь нововведений. Вполне возможно, что Git превосходит Subversion, а достигнуть продуктивности вы сможете, только программируя на Java. В новейших технологиях есть какая-то изюминка. Задайтесь целью, для достижения которой вам необходимы нововведения и двигайтесь вперед.

Весь процесс не заключается в написании кода. Большое количество задач решаются простейшим образом (не техническим). К примеру, нет совершенно никакой необходимости в долгосрочной и дорогостоящей оптимизации при недостатке памяти. Достаточно будет расширить объем оперативной памяти. Не стоит реагировать на решение проблем самостоятельно. Инициатива – это хорошо. Но, ввести начальство в курс дела – куда лучше и надежнее. Программистам нельзя перегружаться. Они нуждаются в полноценном отдыхе. Отдых не должен вредить пользователю. Если речь идет о переработках, значит, начальство просто не может рационально распределить обязанности и задачи. Переработка – это просто иллюзия для программиста. Я думаю, мало толку будет от программиста , который устал. Лучше дать ему перерыв для более плодотворной работы в будущем.

Колхозная доктрина – уникальная и вечная доктрина. Путем естественного отбора практически все программисты приходят к ней. О том, чтобы ее приходилось навязывать кому-то, речи даже не идет. Но, есть и исключение из правил. Такие исключения стоит сразу же отстранять от работы в компании.

Таким образом, если у вас возник интерес к текстовому редактору, то эта процедура происходит без типов на Erlang.

Не стоит забывать о том, что колхозная доктрина – это руководство для тех, кто планирует работать на отлично, а не как попало. Работоспособность и опытность должна быть видна без всяких заморочек и доказательств. Программисты должны понимать процесс работы в течение пяти минут. Не стоит действовать наугад. Нужно быть объективными. Колхозная доктрина о прагматизме. В процессе создаются только те рабочие приложения, которые в состоянии решить конкретную задачу в минимальный срок и в пределах разумного. Пускай эти решения будут неразумными с точки зрения математики. В реальном мире на красоту решений никто сейчас не обращает внимание. Главное, чтобы эти решения были продуктивными и обдуманными.

А что вы мне скажете по этому поводу? Вы за ордена или за теоретиков?

Автор статьи: Игнатий Власенко (Компьютерные курсы "Столица").

Если Вам понравилась статья — ставьте лайк и делитесь этой информацией!