плюс пять копеек к тому, что лучше 100 раз подумать. надо ли — микросервисы — это по разспределенная система с сервисами, которые имеют тенденцию отвалится чаще, чем если бы бежали в рамках одного процесса. Дизайнить такую систему в разы сложнее, дороже и дольше, чем обычный монолит, а плюсы от микросервисов не всегда уж такие очевидные.
А я давно жду, когда же появится компания, которая будет наполнять интернет фейковым позитивным/негативным контентом. Не то, что это здорово для интернета в целом, но выглядят вполне логичным шагом в условиях тотальной публичности. Пойди потом, разберись, что правда, а что нет.
Нет, не кажется. Если он кидает исключение — в Java это документируется throws декларацией. Могу прокомментировать и специфическую операцию, и константы, если будет пример. Я понимаю весь скептицизм, сам такой был, пока не показали, как действительно можно писать самодокументирующийся код и не поводили за ручку, тыкая в разные места приговаривая «э-э-э, зачем комментарий, сделай вот так!».
Комментарии полезны если описываешь public API и не показываешь код. Но у них другое предназначение, этот кейс я упоминал ниже в одном из комментариев. Ок, еще полезны в парочке экзотических случаев. В большинстве же своем комментарии пишут там, где нужно было бы просто подумать над именами и разделить по функциям. В том числе, когда код не понятен.
В этом случае необходимо делать рефакторинг, а не писать комментарии, объясняющие плохо написанный код. Мало того, что это накапливающийся технический долг, так еще и комментарии устареют и будут врать через 3-4 итерации.
Обучение методике/принципам/etc, которые необходимы для использования продукта это отдельный продукт (будь то курсы или книга или ...), со своей целевой аудиторией, задачами и, иногда, жизненным циклом. И уж тем более это не readme файл, который Том призывает писать в самом начале проекта. Впрочем, его понять можно — он описывает все в контексте гитхаба, чтобы люди начали добавлять readme в свои проекты и тем самым привлекать новых людей в проекты (и гитхаб). Другое дело, что хак, а хаки имеют тенденцию накапливаться и бить по лбу своих создателей.
Если пользователю требуются что-то прочитать, чтобы понять, как оно работает или как его запустить — значит юзабилити программы можно улучшить либо упростить способ установки/запуска. В идеале пользователь ничего не читает, а может пользоваться программой с первых секунд.
Наиболее практичным способом обмена информацией с командой является «взять и пообщаться с командой», а не сгенерировать документ, который потом необходимо поддерживать. Зафиксировать принятые дизайн решения лучше будет в тестах.
Документирование в readme мало чем отличается от комментирования на уровне методов, на уровне классов или пакетов. Как и в случае с комментариями — если в вашем проекте есть readme файл, то значит в нем еще достаточно возможностей, для улучшения.
В целом же, товарищ Tom Preston-Werner, похоже, слабо понимает принципы и ценности, например, XP, где основная идея — как разрабатывать софт так, чтобы он соответствовал пожеланиям клиентов.
Опыт обрубания внешнего трафика на ддос атаки у нас есть. А внутри умельцев найти быстро — страна маленькая. Что касается порталов с ссылками — у нас портал один, откуда скачивается софт и все о нем знают + основные сми дублируют инфу. «Взлом базы данных» это непонятный кейс, если опишешь поподробнее, то смогу прокомментировать.
Это мое краткое обобщение оффициальных спек. Информацию на эстонском можно найти здесь: www.vvk.ee/index.php?id=10598. Оттуда можно уже найти pdf-ы с общим описанием компонентов систем, анализом рисков и технической документацией. Google translate в помощь :)
Нехватку людей, я пожалуй, комментировать не буду — все же это case by case, возможно в маленькой партии и не найдется умельца. В крупных партиях — даже у нас, но парочка людей найдется. Что касается «не-так-поняли», то здесь мы все-таки имеем дело с техникой и всегда можно продемонстрировать, что именно и как поняли. Тестирование про принципу белого ящика позволяет выявить и предъявить потенциальные дыры. Вообщем это действительно гораздо сложнее, чем просто поставить подпись в глухом участке за человека, который на выборы не явился.
[я] в роли пользователя
[хочу] сохранить задачу в форме Х
[чтобы] она отобразилась в форме Y
а CodeNotes генерирует тест заглушку и добавляет в код. Проект собирается, тест не проходит, разработчикам улетает информация на мейл.
а не пробовали договариваться на релиз каждую неделю? Потребность в подробном описании задания должна отпасть.
В целом же, товарищ Tom Preston-Werner, похоже, слабо понимает принципы и ценности, например, XP, где основная идея — как разрабатывать софт так, чтобы он соответствовал пожеланиям клиентов.