Про оптимизацию

Много говорили об этом и писали в умных книжках, но этот почти инстинктивный страх "а вдруг чё" сильнее здравого смысла. Поэтому:

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

Естественно, это всё не отрицает необходимости делать качественно при любых условиях.

Википедия отключена в знак протеста. Если зайти на статью, скажем, на немецком, то вместо неё будет отображатся просьба поддержать отмену реформы в области авторского права в интернете. Как сказано из текста протеста, реформа предполагает "серьезно ограничить свободный интернет".

Как выглядит типичная разработка "домашних" проектов.

Как же я люблю критические статьи и когда здравый смысл важнее, чем тупые тренды. Прошлись по Agile и Scrum: https://habr.com/post/430890/

Хабр

Где Agile ужасен, особенно Scrum

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее...

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

Про личную вики, потоки информации и другие вещи я еще пишу здесь: http://krsnv.ru/blog

Хорошая статья про Code Review https://m.habr.com/company/yandex/blog/422143/

Аналогичные принципы и подходы я даю стажерам в eLama Junior Lab.

Среди руководителей разработки, внедряющих agile, считается, что гибкие методологии противоречат документации. Что документация - зло, она тормозит процессы и максимум того, что может производить команда - это пользовательская документация. Они возмущаются, что "Работающий продукт важнее исчерпывающей документации" и каким-то образом делают вывод, что внутренней документации в agile не должно быть. Это полная чушь!

Если вы упираете на формулировки в Agile-манифесте и слова авторитетных людей - обратите внимание на Constraints (http://agilemodeling.com/artifacts/constraint.htm)

Разработчики не хотят писать документацию - они любят писать код. Они не умеют и не хотят осваивать русский язык, с его сложными оборотами и неоднозначными формулировками. Однако именно разработчики и инженеры являются носителями знания о продукте. Если на крупном проекте не будет хорошей внутренней документации, то вы обрекаете себя на более трудную отладку багов, на чудовищный bus factor и полную непрогнозируемость работ.

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

Я считаю, что решение ребуса существует.

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

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

В детстве у меня была любимая книга, которая называлась "О чем размышляют роботы". Опубликована в 1982 году (это целых 36 лет назад!). Она целиком состояла из комиксов. Главная тема: как научить робота распознавать образы и реагировать на окружающий мир. Банки данных, тест Тьюринга, система вход-выход, искусственный разум. Полистайте её. Просто из любопытства. За столько лет многое изменилось. Компьютеры уменьшились, скорости их работы возрасли во много степеней. А вот проблемы ИИ остались прежними :)