Эх… если действительно интересно, что Вы делаете правильно, а что нет, — посмотрите Code Style разных крупных проектов. Посмотрите, как всё устроено внутри крупных и успешных компаний, с какими проблемами они сталкивались и как их решали. Я, например, так и делаю.
Я все проблемы пережил на своём опыте. И только когда своей головой дошёл до того, как правильно делать, начал изучать, что у других компаний. И оказалось, что мои позиции полностью совпадают с принятыми практиками. Только теперь я понимаю, почему у них такие практики приняты.
Задачи так или иначе никогда не укладываются в оценочные сроки. Понятное дело, что на практике диаграмма будет сильно отклоняться от изначальной версии. Но ничего не мешает её перестраивать по ходу решения задач. Это всё равно может помочь решить целевую сложную задачу в крайние сроки.
Изменение делается не просто так. Оно имеет определённую цель, вот эта цель и описывается. В коммитах нежелательно упоминать ни файл, ни строку. А именно — суть изменения. Например, «исправил такую-то ошибку». Или «Не использовать устаревшую функцию» такую-то.
Причём заметьте, что люди, которые увидят, что в коммите убрали устаревшую функцию, по крайней мере могут узнать о существовании этой проблемы. А сухой комментарий будет просто проигнорирован. Его могут даже не заметить.
Но, разумеется, если исправляется количество пробелов в отступе согласно внутренним стандартом — можно написать «стилистические правки». Если код слегка порефакторился для упрощения его понимания, — «повышение читабельности».
дисциплина(/самодисциплина) — самая главная, тут уже в комментариях упоминали;
читабельность — всё и везде должно быть одинакового стиля и все должны придерживаться одинаковых правил написания (сокращает время вникания в чужой код, разработка быстрее);
беклог проблем, которые есть в проекте и которые не решены;
отчётность — клиент может пожаловаться на баг, тогда можно легко найти этот баг и узнать, например, в какой версии он был исправлен и был ли исправлен вообще.
Комментарий в любом случае обязателен, это да. Тут может быть Вы правы, я сам пока не практиковал указывание в комментариях номеров issue, погорячился.
Но так или иначе сам коммит будет содержать номер issue. Тот же `git blame` покажет всю необходимую информацию.
А насчёт исчерпывающих комментариев — спорно. Если внутри функции, то там могут быть краткие пояснения, но если код интуитивно непонятен. Существует практики самодокументирования кода и декомпозиции. Если потребовалось написать большой комментарий внутри функции, — значит что-то требуется разнести по более мелким функциям.
А вот большие комментарии к самим функциям — это хорошая практика. И тут лучше использовать системы вроде Doxygen. Впрочем, зависит от языка. В Питоне — своя система, в Яве — своя.
3 issue с зависимостями, один из которых proposal. В комментарии должна быть ссылка на соответствующий issue, дабы другие не повторили ошибки. Примеры кода должны также быть указаны в issue.
Полезный с Вашей точки зрения код Вы всегда можете оставить в какие-либо сниппеты, либо создать issue и туда добавить на крайний случай. Да даже в Вики можно создать страничку, посвящённую не до конца решённой проблеме. Поэтому то, что Вы привели в качестве довода, — доводом не является.
А теперь представьте, что я в 16 файлах закомментировал в разных местах строки, решающие Вашу задачу. Вам нужно:
* раскомментировать только правильные строки (а ведь в таком случае я не один там закомментированный код оставлял);
* понять, почему они были закомментированы (может там баг есть архитектурный, который не скоро, но проявится), а человек мог уже давно уволиться;
* заставить всё это в итоге работать.
Часто бывает легче, наоборот, переписать полностью чужой код, чем попытаться его использовать.
Вас переубедить у меня нет цели, но комментарии другие люди тоже читают, поэтому я всё-таки распишу, что и почему.
С Gitlab можно. В Gitlab wiki есть. Не очень удобный, но всегда можно WikiMedia поставить и интегрировать. Там по сути просто ссылка в пункте меню меняется и всё.
А в плане задач меня интересовала следующая схема. Я создаю множество задач, каждой выставляю оценочное время выполнения. Проставляю между ними зависимости. Затем делаю что-то вроде milestone'а, указывая, какие программисты в нём должны участвовать. Система в итоге должна построить диаграмму Ганта для скорейшего достижения milestone'а. В идеале ещё было бы хорошо, чтобы каждой задаче можно было проставлять оценку сложности для корректного распределения между юниорами, мидлами и сеньорами.
Пока по описаниям не нашёл ни одной такой системы.
Меня больше интересует, что она даёт разработчикам? Там есть какая-либо система распределения задач по программистам, если каждой задаче прописано время и проставлены зависимости? Своего рода распараллеливание с минимальными запланированными сроками исполнения. И вообще, там можно выстраивать зависимости, как сделано в RedMine?
А, то есть, в баг трекере описывать мелкое изменение нужно, а коммит описать — сложно? Да даже если в баг трекер завезли, то и номер issue должен быть, и краткое описание изменений. `git log` должен понятным образом описывать изменений. Но работает это, когда все члены команды придерживаются общих правил.
Наоборот. Это начинается через несколько лет. Причём потом все прекрасно осознают, почему код должен быть читабельным, и почему не должно быть исключений. Всегда необходимо заводить объяснения, привязанные к психологии.
Во сколько раз больше времени Вы потратите на понимание этого исправления (правильно ли исправлено)? И насколько быстро Вы сможете найти этот коммит через неделю, когда Ваш коллега скажет Вам, что проблема с предварительной обработкой файлов исправлена им пару недель назад, чтобы убедиться, не та ли это регрессия, которая вдруг возникла? Ведь коммит мог быть и таким:
А ведь коммит мог быть "Исправлена ошибка предварительной обработки файлов с исходным кодом". И через пустую строчку даже могли бы быть расписаны симптомы бага.
Имеет смысл писать длинное сообщение даже тогда, когда оно больше, чем само изменение. Это необходимо, чтобы все члены команды знали, что и зачем ты сделал. Это быстрее для них, чем вникать в код.
К тому же потом всегда можно легко по истории найти коммит и сделать ему revert, в случае необходимости.
Нельзя допускать попадание подобного в коммиты. Для этого есть отдельные ветки. К тому же, закомментированный код может быстро устареть из-за рефакторингов, потеряв ценность, или даже став неработоспособным.
Код должен быть читабельным, а для этого там не должно быть закомментированных кусков.
Вероятно, имеется в виду rebase ветки с последующим вливанием, при котором обычно не создаётся автоматического коммита слияния с названием ветки. Тогда удаление ветки действительно приведёт к отсутствию упоминаний о ней.
В gitlab, например, при вливании запросов на слияние всегда создается коммит слияния. Или даже можно делать squash коммитов, но это повлечёт потерю истории изменений.
Начнем с детей — ну не знаю, может мне повезло, но мне ращение ребенка, в основном, радость. Времени занимает не шибко много.
Я часто наблюдаю ситуацию, когда детьми занимается в основном мать, а отец занимается своими делами. Не этот случай? Показателем тут может быть, кто летом по вечерам гуляет с ребёнком. Редко вижу детей с отцами. Для меня тоже, само собой, в радость растить ребёнка, но это ещё и труд. Я должен не просто вырастить ребёнка, но ещё и научить учиться, развить интеллект и воспитать. А тут уже не обойдёшься одним только телевизором с мультиками. Хотя я сам тоже не всё свободное время с ребёнком провожу. Уж очень люблю самообразованием заниматься.
Учтите, что люди видят страхи, которые нас пугают и склонны делать в основном, лучше чем плохо.
Не знаю, чем такое будущее может напугать… оно просто по факту ничего не изменит в жизни людей в общем счёту. Очередная революция, подобно промышленной, когда кучи мастеров остались не у дел из-за появления конвейеров, но у людей появились массовые товары. Одним — хуже, другим — лучше. Так было всегда. Просто новый этап в развитии общества.
Будьте оптимистичней, это ничего не стоит, но жизнь облегчает.
Это был как раз оптимистический вариант развития событий. Пессимистический — к власти приходят долгожители, появляются налоги на детей. Начинается сначала подъём развития стран-долгожителей, затем упадок и деградация. Подобно естественному отбору религий и форм правления начинается отбор форм уклада жизни (я даже не знаю как это назвать).
И Вы забыли учесть, что пенсию не просто могут отменить, за социальные выплаты тоже нужно будет бороться. Иначе как государству обеспечивать всех людей, когда их и так много, а банально места будет уже всем не хватать. Пример уже есть — Китай. Самая дешёвая рабочая сила, самое трудолюбивое население.
Лично мне просто нравится тот факт, что всё меняется. Тут не может быть хороших направлений или плохих, т. к. всё будет претерпевать естественный отбор (идей, направлений, государств и т. п.). Просто я не питаю иллюзий о безоблачном будущем для все живущих людей. Такое природа никогда не закладывает в свои творения. Всегда выживает наиболее гибкая система, которой легче приспособиться к меняющимся условиям.
Видимо, уже меняется понятие жизни. Т.к. для меня жизнь — это, в первую очередь, вырастить своих детей. Чтобы те вырастили своих. И т. д. И поверьте, на публикации в таком случае времени крайне мало остаётся. Качественно написать научно-популярную статью займёт от месяца до нескольких месяцев, в лучшем случае, если занять всё своё время изучением вопроса. Поэтому могут рождаться только побочные публикации, если и так приходится что-то изучать.
И если Вы серьёзно думаете, что в будущем долголетие будет счастливым и беспечным, то глубоко ошибаетесь. Вы будете вкалывать каждый день, чтобы постоянно покупать дорогостоящие лекарства от старости (их в совокупности будет очень много, как и терапий).
Пенсия будет уже назначаться по факту наличия признаков старения. Это означает, что Вы должны будете принести все справки, доказывающие, что Вы дошли до пенсионного состояния здоровья, а не возраста. И каждый год Вы снова должны будете приносить эти справки, как сейчас делают инвалиды.
И многие будут хотеть растить детей. Поэтому вполне вероятен налог на долголетие, увеличивающийся с возрастом. Иначе невозможно будет уместить всех вместе.
Смерти станут более резкими, слабо предсказуемыми, т. к. будут лечиться одни проблемы, но будут оставаться какие-либо другие, незаметные с виду. Скорее всего будет и много побочных эффектов от лечения старости. Вероятно, будет ориентация на молодой внешний вид. А лечиться сразу от всего у людей не хватит средств. Это создаст новые виды рисков для работодателей и страхи у людей.
Могу сказать одно, век генетики сделает мир неузнаваемым. Но я надеюсь краем глаза увидеть этот мир в будущем.
Я все проблемы пережил на своём опыте. И только когда своей головой дошёл до того, как правильно делать, начал изучать, что у других компаний. И оказалось, что мои позиции полностью совпадают с принятыми практиками. Только теперь я понимаю, почему у них такие практики приняты.
Причём заметьте, что люди, которые увидят, что в коммите убрали устаревшую функцию, по крайней мере могут узнать о существовании этой проблемы. А сухой комментарий будет просто проигнорирован. Его могут даже не заметить.
Но, разумеется, если исправляется количество пробелов в отступе согласно внутренним стандартом — можно написать «стилистические правки». Если код слегка порефакторился для упрощения его понимания, — «повышение читабельности».
Много. И разных. Например:
Но так или иначе сам коммит будет содержать номер issue. Тот же `git blame` покажет всю необходимую информацию.
А насчёт исчерпывающих комментариев — спорно. Если внутри функции, то там могут быть краткие пояснения, но если код интуитивно непонятен. Существует практики самодокументирования кода и декомпозиции. Если потребовалось написать большой комментарий внутри функции, — значит что-то требуется разнести по более мелким функциям.
А вот большие комментарии к самим функциям — это хорошая практика. И тут лучше использовать системы вроде Doxygen. Впрочем, зависит от языка. В Питоне — своя система, в Яве — своя.
Вам сюда:
habr.com/post/145592
А теперь представьте, что я в 16 файлах закомментировал в разных местах строки, решающие Вашу задачу. Вам нужно:
* раскомментировать только правильные строки (а ведь в таком случае я не один там закомментированный код оставлял);
* понять, почему они были закомментированы (может там баг есть архитектурный, который не скоро, но проявится), а человек мог уже давно уволиться;
* заставить всё это в итоге работать.
Часто бывает легче, наоборот, переписать полностью чужой код, чем попытаться его использовать.
Вас переубедить у меня нет цели, но комментарии другие люди тоже читают, поэтому я всё-таки распишу, что и почему.
А в плане задач меня интересовала следующая схема. Я создаю множество задач, каждой выставляю оценочное время выполнения. Проставляю между ними зависимости. Затем делаю что-то вроде milestone'а, указывая, какие программисты в нём должны участвовать. Система в итоге должна построить диаграмму Ганта для скорейшего достижения milestone'а. В идеале ещё было бы хорошо, чтобы каждой задаче можно было проставлять оценку сложности для корректного распределения между юниорами, мидлами и сеньорами.
Пока по описаниям не нашёл ни одной такой системы.
Чем набирать
git showна каждый маленький коммит вместо понятного сообщения? Ну-ну.Я тут быстренько накидал пример качественно написанного кода на bash с исправлением ошибки в виде diff и, например, сделал коммит "Исправлена ошибка":
Во сколько раз больше времени Вы потратите на понимание этого исправления (правильно ли исправлено)? И насколько быстро Вы сможете найти этот коммит через неделю, когда Ваш коллега скажет Вам, что проблема с предварительной обработкой файлов исправлена им пару недель назад, чтобы убедиться, не та ли это регрессия, которая вдруг возникла? Ведь коммит мог быть и таким:
А ведь коммит мог быть "Исправлена ошибка предварительной обработки файлов с исходным кодом". И через пустую строчку даже могли бы быть расписаны симптомы бага.
К тому же потом всегда можно легко по истории найти коммит и сделать ему revert, в случае необходимости.
Код должен быть читабельным, а для этого там не должно быть закомментированных кусков.
В gitlab, например, при вливании запросов на слияние всегда создается коммит слияния. Или даже можно делать squash коммитов, но это повлечёт потерю истории изменений.
Я часто наблюдаю ситуацию, когда детьми занимается в основном мать, а отец занимается своими делами. Не этот случай? Показателем тут может быть, кто летом по вечерам гуляет с ребёнком. Редко вижу детей с отцами. Для меня тоже, само собой, в радость растить ребёнка, но это ещё и труд. Я должен не просто вырастить ребёнка, но ещё и научить учиться, развить интеллект и воспитать. А тут уже не обойдёшься одним только телевизором с мультиками. Хотя я сам тоже не всё свободное время с ребёнком провожу. Уж очень люблю самообразованием заниматься.
Не знаю, чем такое будущее может напугать… оно просто по факту ничего не изменит в жизни людей в общем счёту. Очередная революция, подобно промышленной, когда кучи мастеров остались не у дел из-за появления конвейеров, но у людей появились массовые товары. Одним — хуже, другим — лучше. Так было всегда. Просто новый этап в развитии общества.
Это был как раз оптимистический вариант развития событий. Пессимистический — к власти приходят долгожители, появляются налоги на детей. Начинается сначала подъём развития стран-долгожителей, затем упадок и деградация. Подобно естественному отбору религий и форм правления начинается отбор форм уклада жизни (я даже не знаю как это назвать).
И Вы забыли учесть, что пенсию не просто могут отменить, за социальные выплаты тоже нужно будет бороться. Иначе как государству обеспечивать всех людей, когда их и так много, а банально места будет уже всем не хватать. Пример уже есть — Китай. Самая дешёвая рабочая сила, самое трудолюбивое население.
Лично мне просто нравится тот факт, что всё меняется. Тут не может быть хороших направлений или плохих, т. к. всё будет претерпевать естественный отбор (идей, направлений, государств и т. п.). Просто я не питаю иллюзий о безоблачном будущем для все живущих людей. Такое природа никогда не закладывает в свои творения. Всегда выживает наиболее гибкая система, которой легче приспособиться к меняющимся условиям.
И если Вы серьёзно думаете, что в будущем долголетие будет счастливым и беспечным, то глубоко ошибаетесь. Вы будете вкалывать каждый день, чтобы постоянно покупать дорогостоящие лекарства от старости (их в совокупности будет очень много, как и терапий).
Пенсия будет уже назначаться по факту наличия признаков старения. Это означает, что Вы должны будете принести все справки, доказывающие, что Вы дошли до пенсионного состояния здоровья, а не возраста. И каждый год Вы снова должны будете приносить эти справки, как сейчас делают инвалиды.
И многие будут хотеть растить детей. Поэтому вполне вероятен налог на долголетие, увеличивающийся с возрастом. Иначе невозможно будет уместить всех вместе.
Смерти станут более резкими, слабо предсказуемыми, т. к. будут лечиться одни проблемы, но будут оставаться какие-либо другие, незаметные с виду. Скорее всего будет и много побочных эффектов от лечения старости. Вероятно, будет ориентация на молодой внешний вид. А лечиться сразу от всего у людей не хватит средств. Это создаст новые виды рисков для работодателей и страхи у людей.
Могу сказать одно, век генетики сделает мир неузнаваемым. Но я надеюсь краем глаза увидеть этот мир в будущем.