«The Zen of Python» и мои AGILE комплексы привели к неожиданным выводам

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

Мои попытки самоанализа¶

Итак, вот уже месяц, как я занимаюсь "узкой задачей" - постигаю Питон...
Поначалу было легко и приятно, за январь я между делом подготовил 26 постов. Сначала это были конспекты, потом практикумы, ... но как только я перешел к "постаноке задачи" (обработка CSV файлов), то возникли проблемы - мозг не хочет кодировать, а по утрам и вовсе не хочет думать...

Может быть не стоило столько времени тратить на постановку задачи? Но мой опыт создания уродцев на VB говорит об обратном. Я тогда наплодил десятка два дополнений для Excel, продал их только один раз, а мог бы и сегодня их использовать... Я тогда не верил, что могу освоить объектное программирование...

Получается, что я изучаю не только сам язык, я учусь программировать объектами..., осваиваю IDLE и восполняю пробелы, например Unicode...

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

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

The Zen of Python¶

In [1]:

 import this 

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Это оригинал «The Zen of Python»,выдал его интерпретптор ... а ниже перевод из Википедии

Красивое лучше, чем уродливое.

Явное лучше, чем неявное.

Простое лучше, чем сложное.

Сложное лучше, чем запутанное.

Плоское лучше, чем вложенное.

Разреженное лучше, чем плотное.

Читаемость имеет значение.

Особые случаи не настолько особые, чтобы нарушать правила.

При этом практичность важнее безупречности.

Ошибки никогда не должны замалчиваться.

Если не замалчиваются явно.

Встретив двусмысленность, отбрось искушение угадать.

Должен существовать один — и, желательно, только один — очевидный способ сделать это.

Хотя он поначалу может быть и не очевиден, если вы не голландец[7].

Сейчас лучше, чем никогда.

Хотя никогда зачастую лучше, чем прямо сейчас.

Если реализацию сложно объяснить — идея плоха.

Если реализацию легко объяснить — идея, возможно, хороша.

Пространства имён — отличная штука! Будем делать их побольше!

Agile Manifesto¶

Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: 

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану 

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Основополагающие принципы Agile-манифеста
Мы следуем таким принципам:

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

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

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

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

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

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Работающий продукт — основной показатель прогресса.

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

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

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

Чем хороши метафоры? Тем, что в них всегда можно найти подтверждение своим плохо вербализированным мыслям. Потому опускаю свои рассуждения, но перехожу сразу к выводам:¶

• По утрам лучше читать учебники, а не кодировать.
• А смотреть видео лучше, чем читать учебники.
  
• После обеда не надо напрягать вображение.
• Дабы не напрягать воображение, надо кодировать первое, что пришло в голову.
• Чем кодировать все подряд, лучше копипастить шедевры.
• Понять чужие шедевры проще, чем создать свои.
• Если тебе в голову пришла гениальная догадка, не спеши кодировать.
• Обязательно есть те, кому было надо это же раньше тебя.
• Фрагментов кода много не бывает, даже, если они из учебников.
• Длинные фрагменты для зануд, и ты скоро станешь занудой.
• Уж если видишь ошибки в чужом коде, начинай писать свой

Когда метафор слишком много, то это напрягает. Потому несколько выводов на простом русском языке¶

Пост я начал вчера, потом пошел играть в теннис. На свежем воздухе удалось найти пару рецептов. Первый - утром не работать, а читать учебеники... Голова все равно не соображает. А второй никак не хотел формулироваться из проблемы в решение.
И вот, наконец, сегодня два часа назад я понял, что:
не надо писать библиотеку "CSV процессинг" самому, уже ясно, что там будут "подводные камни" (подобные кодировкам unicode)..., а мне нельзя тратить много времени на кодирование.
Значит, мне надо "ставить задачку", как я это сделал здесь..., но после этого искать чужой код, а не писать свой.
Но так я не получу элементарных навыков кодирования, нужна же практика. Нужна, но практиковаться нужно на коротких примерах "из учебников".
Другими словами, нужно сочетать изучение чужого "сложного кода" с простыми примерами a- фрагментами кода.

Посты чуть ниже также могут вас заинтересовать