Основы программирования: как начать писать код. Как писать коды для программ

как начать писать код / TeachMePlease

Окончил курс по языку программирования, но писать код не научился. С подобным сталкиваются многие новички. Пользователи Reddit описывают проблему так:

Я прошёл онлайн-курс по Python, но всё равно не знаю, как написать полноценную программу.
Я знаю теорию, но не могу применить её на практике.
Я знаю, что такое цикл while, но не знаю, как и в каких случаях использовать его.

Разбираемся, в чём может быть проблема и как её решить.

Проблема: искусственная среда программирования

Многие онлайн-курсы и книги предлагают новичкам работать в искусственной среде программирования, которая сопровождает написание кода различными инструкциями и подсказками. Она не соответствует тому, как в действительности работают разработчики. Когда курс заканчивается и бывший студент пытается совладать с реальной средой программирования, он чувствует себя потерянным, потому как привык к учебным инструментам, которые на каждом шагу предлагают подсказки.

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

Проблема: чрезмерные руководства

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

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

Проблема здесь — в чрезмерном руководстве. Ученика натаскивают на синтаксис языка, не уделяя при этом должного внимания основным идеям и понятиям программирования.

Синтаксис — это просто набор символов, которые используются для определённого языка программирования. Можно провести параллель с естественными языками: умение написать и произнести фразу на французском “S'il vous plaît” не имеет смысла, если вы не знаете её значения.

Только знание и понимание концепций, которые лежат в основе программирования, позволит понять, как работает код.

Решение 1: использовать реальные среды разработки

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

Узнайте, какой редактор чаще всего используют для выбранного вами языка, и установите его. Тщательно изучите его работу: как создать проект, запустить код, какие есть горячие клавиши и сокращения.

Напишите код, сохраните его и запустите — это будет вашим первым серьёзным шагом, ведь именно так работают настоящие разработчики.

Решение 2: писать код с нуля

Достаточно подсказок и инструкций! Начните с пустого файла, в который вы добавите каждую строку кода самостоятельно.

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

Не копипастите чужой код. Если вы используете работающих чужой код — вы ничему не научитесь. Изучайте чужой код, но не копируйте!

Главное на данном этапе — дойти до решения самостоятельно, а не получить уже готовое. Каждый раз, когда вы ищите и исправляете ошибку, вы получаете реальный опыт программирования.

Решение 3: писать много кода, очень много кода

Программирование — не теоретическая дисциплина: чтения книг, просмотра учебных видео и выполнения тренировочных упражнений недостаточно, чтобы освоить её. Чтобы научить программировать, нужно написать тысячи строк кода.

Ваша первая программа сможет немногое, а в вашем коде будет масса ошибок — но это не столь важно. Главное, сразу не разочаровываться в своих способностях и не бросить всё.

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

Решение 4: просить о помощи

Некоторые задачи и ошибки кажутся нерешаемыми: вы бьётесь час, другой, но ничего не приходит в голову. Возможно, пришло время попросить совет.

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

Чтобы получить корректный ответ на свой вопрос, стоит научиться правильно составлять запрос:

Скопируйте сообщение об ошибке, которое выводится в редакторе и укажите его в вопросе.
Нет сообщения об ошибке, объясните, какого результата вы ожидаете от работы программы, и что происходит при её запуске на самом деле.
Вставьте фрагмент кода, укажите код полностью в посте, если он небольшой. Если большой — используйте Github Gist или Pastebin и укажите ссылку на код.
Отформатируйте код. Не вставляйте его обычным текстом, используйте редактор кода.
Напишите, что вы уже пытались сделать с кодом.
Используйте корректную терминологию — в этом вам поможет изучение теории.

Программирование — непростое занятие, которое требует реальной заинтересованности и способности часами думать над решением задачи. Если вы воспользуетесь решениями из статьи и не передумаете становиться разработчиком — вы действительно готовы ступить на эту стезю.

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

Источник: When You Know the Basics, but You Still Can't Code

blog.teachmeplease.ru

Как писать чистый и красивый код

Параметры для контроля конкурентности

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

Приоритетная инверсия (Priority Inversion)

Чтобы понять различные механизмы блокировки, нам также необходимо понять приоритеты тредов. Как вы можете догадаться, треды могут выполняться с высоким или низким приоритетами – высокие раньше, а низкие позже. Типичным примером является процесс с низким приоритетом, получающий ресурс, который требуется высокоприоритетному процессу, а затем он вытесняется процессом среднего приоритета, поэтому процесс высокоприоритетного процесса блокируется на ресурсе, в то время как средний приоритет фактически выполняется, даже обладая более низким приоритеом. Это называется Приоритетной инверсией (Priority Inversion) и может привести к тому, что тред с более высоким приоритетом будет “голодать до смерти”, так как он никогда не будет выполнен. Поэтому, определенно, надо избегать этого.

Представьте себе наличие двух высокоприоритетных тредов (1 и 2) и тред с низким приоритетом (3). Если 3 блокирует ресурс, к которому 1 хочет получить доступ, 1 придется ждать. Поскольку 2 имеет более высокий приоритет, вся его работа будет выполнена в первую очередь. В случаях, когда процесс не заканчивается, тред 3 не будет выполнен, и, таким образом, поток 1 будет заблокирован до бесконечности.

Наследование приоритета (Priority Inheritance)

Решение для Priority Inversion – это наследование приоритета (Priority Inheritance). В этом случае тред 1 отдаст приоритет треду 3, если он заблокирован. Таким образом, тред 3 и 2 имеет высокий приоритет и оба выполняются (в зависимости от ОС). Как только 3 разблокирует ресурс, высокий приоритет возвращается к треду 1, и он будет продолжать свою первоначальную работу.

Atomic

Atomic содержит ту же идею, что и транзакция в контексте базы данных. Вы наверняка захотите написать значение сразу, как одну операцию. Приложения, скомпилированные для 32 бит, могут иметь довольно странное поведение при использовании int64_t и не иметь его в atomic. Почему? Давайте подробно рассмотрим, что происходит:

int64_t x = 0 Thread1: x = 0xFFFF Thread2: x = 0xEEDD

Наличие неатомной операции может привести к тому, что первый поток начнет записывать в x. Но поскольку мы работаем в 32-разрядной операционной системой, мы должны разделить значение, которое мы записываем в x, на две очереди 0xFF.

Когда в то же время Thread2 попытается записать значение в x, может произойти планирование операций в следующем порядке:

Thread1: part1 Thread2: part1 Thread2: part2 Thread1: part2

В итоге мы получим:

x == 0xEEFF

который не равен ни 0xFFFF, ни 0xEEDD.

Используя atomic, мы создаем единую транзакцию, которая приведет к следующему поведению:

Thread1: part1 Thread1: part2 Thread2: part1 Thread2: part2

В результате x содержит значение, установленное Thread2. Сам Swift не работает с atomic. В Swift Evolution предлагается добавить его, но на данный момент вам придется реализовать его самостоятельно.

Lock

Lock – это простой способ предотвратить доступ нескольких тредов к ресурсу. Сначала тред проверяет, может ли он войти в защищенную часть или нет. Если он может войти, он блокирует защищенную часть и продолжает работу. Как только он выйдет, то разблокирует его. Если при входе тред встречает заблокированную часть, то он будет ждать. Обычно это делается при помощи сна и регулярного пробуждения, что позволяет проверить, заблокирован все еще ресурс, или нет.

В iOS это можно сделать с помощью NSLock. Но имейте в виду, что при разблокировке тред должен быть тем же самым, что и блокировал.

Существуют также другие типы блокировок, такие как рекурсивные блокировки (recursive locks). С их помощью тред может блокировать ресурс несколько раз и должен отпускать его так часто, как он заблокирован. В течение всего этого времени исключается работа других тредов.

Другим типом является блокировка чтения-записи (read-write lock). Это полезно для больших приложений, когда многие треды читают ресурсы и иногда пишут. Пока тред не пишет в ресурс, все треды могут получить к нему доступ. Как только тред хочет писать, он блокирует ресурс для всех тредов. Они не могут читать, пока блокировка не будет отпущена.

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

Циклическая блокировка (Spinlock)

Блокировка состоит из нескольких операций, которые «усыпляют» треды, пока они снова не включатся. Это приводит к изменениям контекста для CPU (переключением регистров и так далее для сохранения состояния тредов). Эти изменения требуют большого времени вычислений. Если у вас действительно небольшие операции, которые вы хотите защитить, вы можете использовать спинлоки. Основная идея в том, потоки опрашивают блокировку в процессе ожидания. Для этого требуется больше ресурсов, чем просто в спящих тредах. В то же время они наблюдают за изменением контекста и, таким образом, быстрее работают при небольших операциях.

Это звучит неплохо в теории, но в iOS всегда все по другому. iOS имеет концепцию Quality of Service (QoS). С QoS может случиться так, что треды с низким приоритетом не будут выполняться вообще. Наличие спинлока на таком треде и более приоритетный тред, пытающийся получить доступ к его ресурсу, приведут к тому, что более приоритетный тред будет «голодать» по нижнего треда, не разблокируя требуемый ресурс и блокируя самого себя. Как результат, спинлоки являются незаконными на iOS.

Mutex

Mutex подобен замку. Разница в том, что это могут быть разные процессы, а не только треды. К сожалению, вам придется реализовать свой собственный Mutex, поскольку Swift его не поддерживает. Это можно сделать с помощью pthread_mutex от C.

Semaphore

Семафор – это структура данных, обеспечивающая взаимную эксклюзивность в синхронизации тредов. Он состоит из счетчика, очереди FIFO и методов wait() и signal().

Каждый раз, когда тред хочет войти в защищенную часть, он вызывает wait () на семафоре. Семафор уменьшит счетчик, и пока он не равен 0, треду будет разрешено работать. В противном случае он сохранит тред в очереди. Всякий раз, когда тред выходит из защищенной части, он будет вызывать signal(), чтобы информировать семафор. Семафор сначала проверяет, есть ли очередь ожидания. Если есть, то из нее вызывается тред, который сможет продолжить работу. Если нет, он снова увеличит счетчик.

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

Можно рассматривать двоичный семафор (семафор со значением счетчика 0 или 1) как Mutex. Но в то время как Mutex связан с механизмом блокировки, семафор является сигнальным механизмом. Это особо не помогает, так где же разница?

Механизм блокировки – это защита и управление доступом к ресурсу. Таким образом, он предотвращает одновременное обращение нескольких тредов к одному ресурсу. Сигнальная система больше напоминает вызов “Эй, я закончил! Продолжай!”. Например, если вы слушаете музыку на своем мобильном телефоне и вам звонят, общий ресурс (наушники) будет задействован на телефоне. Когда звонок закончится, система проинформирует ваш mp3-плеер при помощи сигнала для продолжения. Это тот случай, когда следует предпочесть семафор мьютексу.

Так в чем же фишка? Представьте, что у вас есть тред с низким приоритетом (1), который находится в защищенной области, и у вас есть тред с высоким приоритетом (2), который просто вызывает wait() на семафоре. 2 спит и ждет, когда семафор разбудит его. Теперь у нас есть тред (3), который имеет более высокий приоритет, чем 1. Этот тред в сочетании с QoS блокирует сигнал от 1 к семафору и, таким образом, голодают оба других потока. Таким образом, семафоры в iOS не имеют приоритетного наследования (Priority Inheritance).

Synchronized

В Objective-C существует также опция использования @synchronized. Это простой способ создания мьютекса. Поскольку у Swift его нет, мы должны копнуть глубже. Вы можете познакомиться с @synchronized, вызвав objc_sync_enter.

Поскольку я неоднократно видел этот вопрос в интернете, давайте ответим на него тоже. Насколько я знаю, это не конфиденциальный метод, поэтому его использование не исключает вас из App Store.

Concurrency Queues Dispatching

Поскольку в Swift нет мьютекса, и синхронизация также была удалена, он стал золотым стандартом для разработчиков Swift, которые используют DispatchQueues. Если вы используете его синхронно, то получите такое же поведение, как и мьютекс, так как все действия помещаются в одну очередь. Это предотвращает одновременное выполнение.

Недостатком является большое количество времени, поскольку нужно много перемещений и изменений контекста. Это не имеет значения, если ваше приложение не нуждается в высокой вычислительной мощности, но в случае, если у вас возникнут потери фреймов, вы можете рассмотреть другое решение (например, Mutex).

Dispatch Barriers

Если вы используете GCD, у вас есть больше возможностей для синхронизации вашего кода. Один из них – Dispatch Barriers. С их помощью мы можем создавать блоки защищенных частей, которые должны выполняться вместе. Мы также можем контролировать, в каком порядке выполняется асинхронный код. Это звучит странно, но представьте, что вам предстоит выполнить долгую задачу, которую можно разделить на части. Эти части необходимо запускать по порядку, но их можно снова разделить на более мелкие куски. Эти меньшие куски части могут выполняться асинхронно. Dispatch Barriers теперь можно использоваться для синхронизации больших частей, в то время как отдельные куски могут работать сами по себе.

Trampoline

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

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

Заключение

Вау, это был довольно тяжелый пост. Существует так много возможностей для параллельного программирования, и этот пост раскрыл вам только самые общие положения. В то же время, существует множество механизмов и много примеров для рассмотрения. Я, наверное, раздражаю всех на работе всякий раз, когда говорю о тредах, но они важны, и медленно, но верно, но мои коллеги начинают соглашаться. Как раз сегодня я должен был исправить ошибку, в которой операции получали асинхронный доступ к массиву, а Swift, как мы узнали, не поддерживает атомарные операции. Угадайте, что? Это заканчивалось сбоем и падением. Возможно, этого не произошло бы, если бы все мы знали больше о конкурентности, но, честно говоря, я тоже этого не заметил.

Изучить свои инструменты – лучший совет, который я могу вам дать. Надеюсь мой пост дал вам отправную точку для параллелизма, а также предоставил способ контролировать хаос, который проявится, как только вы погрузитесь глубже. Удачи!

apptractor.ru

7 правил написания программ, которые не умрут вместе с вами / Хабр

Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.

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

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

Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости. Разве вы хотите оставить после своей смерти миру ещё больше SEGFAULT-ов? Хотите ли вы, чтобы сисадмины занимались починкой систем, которые сломались из-за вашего дерьмового кода? Чтобы ваш менеджер проектов вспоминал вас как инженера, работа которого бесила пользователей?

Ничего плохого в быстром продвижении вперёд нет, но в какой-то момент нужно осознать, что низкокачественный код далеко вас не уведёт.

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

1. Накат обновлений отнимает много времени и сил? 2. Система рушится даже от небольшого обновления? 3. Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей? 4. Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них? 5. Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?

Если вы ответили «да» – эта статья для вас. Читайте, а лучше прочтите два раза.

1. Делите на модули

Мозг человека – сложное устройство, сложнее любого процессора, при этом он не справляется с решением сложных задач. Допустим, сложно сразу умножить 13*35. Но если разделить эти операции на простые: 35*10 + 30*3 + 5*3 = 455, то подсчёт упрощается. Разбивая задачу на простые и независимые, мы приходим к ответу.

Так же и с программами. Разбейте программу на несколько частей, файлов, директорий. проектов. Все зависимости выведите в одно место, используйте принцип MVC или его вариант. Такой код и читать проще, и отлаживать легче. В большинстве случаев отладка приведёт вас к нескольким строкам кода, а не к файлу из тысячи строк. Накатывая апдейты одного модуля, вы не сломаете всю остальную систему.

2. Тестируйте

Фу, тесты. Брррррр!

Такая реакция естественна, потому что нас учили, будто тесты не являются частью программирования. Вас учат шаблонам в С++, но не тому, как их тестировать. В этом и проблема. Некоторые считают, что тесты над писать до самой программы.

Мне всё равно, когда вы пишете тесты, если вы их пишете. Не надо геройствовать, начните с простого (print(add(1, 1) == 2)), а затем уже переходите на фреймворк для тестов в вашем языке.

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

3. Непрерывная интеграция

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

Для своих проектов я использую TravisCI и Drone.io. Когда я делаю новое дополнение кода, платформа делает билд и выполняет тесты.

4. Автоматизируйте

У больших проектов всегда есть куча мелких вспомогательных задач. Некоторые люди делают текстовики с командами и копируют их оттуда. Но проще освоить скрипты на bash (и/или Python). Вот некоторые задачи, которые необходимо автоматизировать скриптами:

— преобразование README.md в другие форматы — автоматическое тестирование (включая создание тестовых серверов и данных, удаление временных файлов и т.д.) — заливка кода на сервер разработки — размещение программы на продакшене — автоматическое обновление зависимостей

5. Избыточность

Первое, что вы видите на git-scm.com:Git – бесплатная распределённая система контроля версий с открытым исходным кодом, предназначенная для работы как с малыми, так и очень большими проектами, с высокой скоростью и эффективностью.

Распределённая. Это ключевое слово. Ущипните себя, если вы хоститесь только на гитхабе. Потому, что это единая точка отказа. Если гитхаб падает, или во время push-операции вы повредили файлы, ваш процесс разработки останавливается.

Залогиньтесь на Bitbucket и выполните следующее в вашем репозитории:

# rename origin remote git remote rename origin github # add the gitlab remote (for the love of everything that’s holy, use ssh) git remote add bitbucket <remote link for bitbucket> # push existing code to new remote git push -u bitbucket —all # let’s magic git config -e # add this in the file [remote “origin”] url = [email protected]:username/reponame.git url = <remote link for bitbucket>

Теперь, когда вы заливаете код, изменения идут как на Github, так и на Bitbucket. Никогда не знаешь, когда что-либо сломается. И всегда полезно иметь бэкапы. Вот, как это работает у меня:

— весь код живёт в директории Codebase в Dropbox. Автоматическая синхронизация. — почти весь код живёт на Github — самый важный код живёт на двух частных зеркалах – одно в школе, другое на моём AWS

Я потеряю свой код, только если настанет конец света.

6 Коммиты

Это должно быть вам знакомо. Загляните в историю, и вы увидите что-то вроде:«исправил ошибку в модуле»

СЕРЬЁЗНО?!?!

Исправил? Какую ошибку? В каком модуле?

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

Чтоб не напрягаться, просто воспользуйтесь следующей шапргалкой:

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

добавил новую форму в заголовок, чтобы было легче собирать ссылки. закрыл #3

вместо

удалил всякое, ибо почему бы и нет, хех

7. Планируйте

Даже если вы выполняете все предыдущие правила и чувствуете себя богом программирования, всё равно может случиться всё, что угодно. Имейте план на самый плохой случай. Что, если трафик побьёт рекорды? Откуда вы возьмёте бэкапы, если система упадёт? Кому звонить ночью, если сервер навернётся?

Продумайте, но не перестарайтесь. Автоматизируйте всё, что возможно. Затем задокументируйте всё подробно. Так, чтобы тот, кто получит ваш код, тоже смог следовать плану. Иметь план – не только значит выглядеть умнее, это значит реально быть умнее.

Вот такие правила и определяют хорошую программу. Если вас они не убедили, ответьте мне на два вопроса:

1. Ожидаете ли вы от новичка, присоединившегося к вам, что он поймёт существующий код с лёгкостью? 2. Является ли рефакторинг кода простым и быстрым делом?

Если нет – перечитайте заново. Сохраните, поделитесь с командой.

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

Счастливого программирования.

habr.com